changing size of bif file?

[barocca]

TM,
your suggestion of change size of bif file would be worth a try,
but Shogun's bif reader won't compile them
- any ideas?

------------------
DoragonBarocca of Clan Doragon

[Trousermonkey]

Sorry I wasn't able to get to it last night -I just noticed it seems to reset the file size. I've got a partial workaround/method you can use to change it. I haven't tested how this will work in the game; I'll try it tonight.

Open the bif file and save a frame as a bitmap. Next go into your favorite image editor and open this bitmap. Change the size of the canvas in this bitmap to add extra space around the edge. In my quick test this morning I made it a perfect square (8x8 inches). Make note of the size of the image in pixels (mine was 576x576) Next, select and drag one of the sprites from it's normal position to the edge and save the bitmap.

Now go back to RSW's bifeditor and close any active bif files. Select File>New Bif and indicate you want the size to be 576x576. Now import a bmp file. It will move your larger bitmap into the bif image.

I noticed when I saved this larger bif and then reloaded it into the editor that the colors were washed out. Somehow the color conversion routines are getting confused on my computer. I'm not sure if this always happens or was a fluke in my case.

To test this in the game I'm guessing we'd have to modify the size of every frame in the bif file and, if a sprite was moved, we'd have to change the action text file to reflect this change. It might be instructive to just increase the bif size and see if the game will accept a sprite canvas that is larger than normal.

Like I mentioned earlier, I'll try to set aside some time tonight to test this. If there is a problem with the color conversion I'll see if I can figure out what's going wrong in the source but I can make no guarantees. This might be a bug to report in RSW's feedback thread.

Tm

[barocca]

damn,
wash out also occurs in game

shogun seems to have a maximum bif image size too,
have not worked out what that is,
if youwork it out do let me know,

if the bif file is larger than the maximum shogun allows, then shoggy seems to 'compress' or squeeze the images into that maximum.

meaning you get minature images,
also shoggy has a problem with the spears,
try the test and you'll see what i mean,

make sure you take a unit of yari and a unit of naggy, but only edit the yari address file,
so you can see the difference beween the two,
using original addy's for nags
and new addy's for sams.

if we can work out max bf file size, and it is sufficient, then i can edit spears onto the yari sams and do away with shoggy adding the spears altogether.
but we will need the washout problem fixed first.

get your addy's and offsets from mspaint, top left and bottom right corners of unit box desired, and offset for feet > measured from top left corner
just remember to halve the numbers when you edit the text file.

let me know what happens
is 4am - must sleep...

------------------
DoragonBarocca of Clan Doragon

[Kraellin]

i'd suggest that if there is a limit hardwired in the executable that it is prolly the size of the kensai unit. just a guess. it might actually be imposed by a text file, though. dont know.

K.


------------------
The only absolute is that there are no absolutes.

[Trousermonkey]

I did a little more testing but it's going to take a few more hours before I can make any conclusions. I'll continue this tomorrow. Much of my time was spent getting my PC set up again after a recent reinstall.

I suspect the engine might looking for a certain bif size and automatically scales any file down if it's larger than normal. Barocca, do you think you didn't notice the image compression when the bif was only slightly larger because the sprites were then only slightly compressed?

Another really stupid question, asked for the sake of clarity: When you enlarged the canvas did to only add to the bottom and the right side? I would expect it would screw up the sprite rendering if you did otherwise.

I'm loading the tools to start debugging RSW's bif editor. I've identified several repeatable errors I want to investigate. Some problems I've seen (notes for myself):
1. the color table form is too small
2. creating(and possibly opening) a new bif file greater than the standard 256x256 throws an exception (but then seems to create the file ok)
3. saving an image that has been imported from a bitmap seems to wash out the colors in the bif file. Strangely, this wash out doesnt occur when the image is modified manually within the editor.
4. manually drawing pixels in the editor could possibly use the LineTo command instead of the PixelTo command to make the process seem more responsive.

[barocca]

TM,
I made a square, um - a large square (1000x1000), then tried scaling it down to 800x800.

Also it only wahses out the colours if the bif is going to be more than 512 square?

all the new naggy's are copied to a blank frame,
(a frame is extracted from a bif and 'wiped' clean),
then i tinker with all 12 images at once, then copy then to the 'destination' frames.
Then imported,
as long as bif is 512? square = no washout.

------------------
DoragonBarocca of Clan Doragon

[barocca]

avoid using too many primary colours

Red is ok, by itself,
but when i use Blue AND Pale Green i get washout!!!

perhaps One primary colour is fine,
or perhaps it does not like pale green - not sure, have not got time right now to test for that...

(i use primary colours as markers for 'trimming, and as an index marker so that each image will end up in the correct relative position to the next image in the frame set.)

------------------
DoragonBarocca of Clan Doragon

[Trousermonkey]

Keep at it barocca, I didn't want to stall your current progress with pipe dreams of just enlarging the bif.

Due to work pressures I won't be able to get back to this until this weekend at the earliest.
Keep posting your findings here so I (or others) can use them as reference when I can spend some time on this.

Anyone here know the low level protocol of a netchip 2880 on a usb bus?

damn responsibility.

[barocca]

the 2880 is circa 1997 and not officially released,
on usb 2.0 the closest would be the 2280,
on usb 1.1 closest matches are 2888 and 2890,

and what the heck are you doing?
trying to write a device driver?
or are you having network trouble?

for more : www.netchip.com

most usefull document i found, http://www.netchip.com/library/app/an06.pdf


protocol analyser http://www.futureplus.com/

------------------
DoragonBarocca of Clan Doragon

[This message has been edited by barocca (edited 06-21-2002).]

[This message has been edited by barocca (edited 06-21-2002).]

[Trousermonkey]

LOL, thanks! (one of those links helped me out)

Yeah I screwed up, I'm using the 2890 compliant with USB v1.1 and an 8051 as a local host controller -source written in assembly. For some reason my 2890 is NAK'ing OUT packets before enumeration. I've got all the chip and protocol specifications, I just need to get it figured out in the 2 weeks allotted by my higher ups -because it will obviously take me only 10 days to (1)port code written in c, (2)for a different chip, (3)containing only illegible japanese comments, (4)into a board that already has 3 other interfaces crammed into it, (5)contains no available working registers, (6)and is down to the last 800 bytes of application space.

I reverse-engineer point-of-sale terminals and then design/program 'translation modules' used to make our printers looks like their printers. Felt good to vent -I've been working 10-16 hours a day for the past several weeks to get this up and running and I'm at the 11th hour.

To steer back on topic:
Do you see this washout occur even on smaller bif files when you use a wide variety of primary colors? Writing an algorithm to find the best colors for a 256 color bitmap was my biggest hangup when I researched modifying RSW's source to support importing multiple bitmaps. I still haven't had any time to see how RSW handles it.

A really ghetto method of artificially limiting the number of colors used in a series of frames may be to take all the modified bitmap frames and copy and paste them into a single gigantic bitmap. Next save this bitmap with a 15 or 16 bit color depth (thus making use of your image editor's internal color optimization algorithms). Then, re-open this file and break it back up into the individual frames. At this point, these frames should all have identical color tables and the bif editor won't have to work hard to get the colors right. Don't know if this will work...

Tm

[barocca]

as you will see within the next 24 hours
(my estimate of project finished - provided the ClickTeam installer can do all it claims)
Importing the Naginata images into the SamS bif file is within the pallette range available,

what i did when washout occured was import 2 sets of images, with reference markers, the marker used primary blue, pale green and primary red - when i imported to bif reader the whole bif set 'washed out'.

When i went back and changed all the reference markers to red - no problem,
either the pale green upset the bif reader OR i wound up having more than 256 colours!

i will try to test for this when i finish,


your problem - way beyond my area of expertise - like light years - lol

[RSW]

"wash out colors" problem:
bif can only use 16-bits of colors (5-5-5 or 5-6-5 mode).That means 24-bits colors need to be translated into 16-bits colors. The most simple way is to strip off the 3 less significant bits.

Maybe that's why the colors changed after saving and reloading from the bif.