Jump to content
COMBATSIM Forum
DrKevDog

EF2K-Help on SPR files

Recommended Posts

EF2000 has a folder "SPR" and I am hoping to find someone who understands how that process worked within the EF2000 simulation. Since I am not greatly familiar with EF2000, I have no idea what an .spr file is or how sprites or supershapes were used in EF2k.

It is unclear as to whether the acronym stands for sprite or supershape. The extracted version of EF2k has an SPR directory which contains only 2 files: FWSEXPL.spr (8kb) and FWSEXPL1.spr (30kb). FWSEXPL.spr is named in file explode2.3 and FWSEXPL1 is named in the file explode.3. This process is exactly analogous to the way in which many of the .3 files, in TAW, name TM textures. An example is that, in TAW, Taxi_Lux.3 names "TAXIWAY" in its header just as Explode2.3 names "FWSEXPL" in EF2k. The interest in this issue is motivated by an interest in finding a larger TAW portal of entry for AGP textures. It appears that TAW looks for a named texture at a specific address in the .3 files header. The byte preceding the texture name is generally "21" which points to the TM folder, in a search for a TM file. Replacing "21" with "31" in TAW, appears to point to the SPR folder, in a search for a .spr file. That process remains to be fully understood. In a perfect world there would be a pointer, in the TAW .3 file headers, to the AGP files in the AGP folder and the problem would be solved. At this point any help would be appreciated :)

PS: neither of the EF2K explode.3 files have corresponding .ssd files, which is another curiosity.

Share this post


Link to post
Share on other sites

These appear to be sprite files. If I open them in the AXE3 hex editor, then select a graphical representation some explosion-like forms can be seen after playing around with the number of pixels per row:

efsprites.jpg

I have no idea of the exact format or how they are used though.

This Wikipedia page may help:

http://en.wikipedia.org/wiki/Sprite_(computer_graphics)

Share this post


Link to post
Share on other sites

These appear to be sprite files. If I open them in the AXE3 hex editor, then select a graphical representation some explosion-like forms can be seen after playing around with the number of pixels per row:

I have no idea of the exact format or how they are used though.

Thanks. I was 98% convinced it was sprites but I had no resident program to open the files. Again, I am simply looking for a way to bypass the size limited .ini index in order to open up the game to a greater number of AGP textures. The game looks for sprites (.spr) and/or texture map (.tm) files in response to named textures contained in the .3 file header. It seemed reasonable that perhaps there was a similar process for the .raw files or that perhaps the unused .spr mechanism could be converted. It (sprites) seems like such a legacy type system that conversion is probably not feasible. Thus far I have been able to modify the TAW files to call the .spr and have the game look in the SPR folder, only to have the game generate the error: "tmd: invalid slot number". Not quite sure what that is yet.

At any rate, I'll pursue this a bit further, and if no progress, then move on.

Share this post


Link to post
Share on other sites

Of maybe historical interest is the filename FWSEXPL.SPR.

It's possible the FWS part refers to 'FutureWave Software' who were active in this area in the early 90s. Their 'Animator' package became what we now know as Adobe Flash.

Some info, including a link to the program (Unfortunately it doesn't run on 64 bit Vista):

http://en.wikipedia.org/wiki/FutureSplash_Animator

Share this post


Link to post
Share on other sites

Of maybe historical interest is the filename FWSEXPL.SPR.

It's possible the FWS part refers to 'FutureWave Software' who were active in this area in the early 90s. Their 'Animator' package became what we now know as Adobe Flash.

Some info, including a link to the program (Unfortunately it doesn't run on 64 bit Vista):

http://en.wikipedia.org/wiki/FutureSplash_Animator

Well, if you weren't so quick to jump on the 64-bit Vista bandwagon :P you could play this little gem of an animator. Best to do as I do and stick with the old reliable Amiga Operating System :rolleyes:

The wiki article was interesting. Especially the discussion of Netscapes demise at the hands of Microshaft :o

You could be correct on that point regarding FWS. That particular animator runs .spa (Future Splash Animator) files and .spl (Future Splash Player) movies. Apparently there were many companies in the 90's which produced .spr sprites.

Not able to find much on FWS and specifics of sprites. I'll keep searching B)

Share this post


Link to post
Share on other sites
On 2010-06-05 at 7:53 PM, DrKevDog said:

 I'll keep searching B)

It's been over 6 years, so you must have found something by now. :lol:

I've been looking at the TFX1 spr files in a hex editor, but don't know where to start understanding how they are structured.
Like these EF2000 files, there doesn't seem to be much header information before we get to the bitmap.

EDIT:
Now I'm starting to see a bit of a pattern, which seems similar for both the tfx1 and tfx2 .spr files.
The first byte may contain the 'number of sprites'. For the file 'fwsexpl.spr' in the above picture, this number is 4, which corresponds to the number of different sizes of explosion in that visualization of the data.

After the first byte comes a corresponding number of little-endian 2 byte pointers, which presumably lead to the start of each sprite.
At the destination of these pointers, there are two bytes which seem different to the surrounding bytes, particularly seen when the surrounding bytes are zero. I can't yet correlate this with anything useful though...

EDIT2:
If I multiply those destination bytes together, I get a value exactly half of the size of the sprite. So, it seems they are linked to the height and width. The bitmap data looks more 8-bit than 16-bit in nature though.

EDIT3:
That structure is confirmed for the 15 tfx1 and 2 tfx2 .spr files I have in my known folders. The next thing is try to work out how the bitmaps are arranged. These files don't seem to contain anything else, so the bytecode (or whatever) that accesses them must come from elsewhere.

Share this post


Link to post
Share on other sites
10 hours ago, mikew said:

EDIT2:
If I multiply those destination bytes together, I get a value exactly half of the size of the sprite. So, it seems they are linked to the height and width. The bitmap data looks more 8-bit than 16-bit in nature though.

Could it be R, G, B, and alpha in separate planes and scaled to [0…31] range?

Share this post


Link to post
Share on other sites

No, that looks like garbage as well.

At least I can recommend TFX 1’s disp3.spr & targcros.spr for further research, as these have highly regular patterns in them (probably a crosshair):

sprs.png

I'm also pretty sure the two numbers are actual width and height (too much stretching otherwise). I suspect it's a format which has been optimized for the specifics of the graphics processor TFX was designed for. (Early computers did have dedicated sprite processors, didn't they? I'm going to read this: http://amigadev.elowar.com/read/ADCD_2.1/Hardware_Manual_guide/node00AE.html)

 

Share this post


Link to post
Share on other sites

Yes, I'm afraid this may be some hardware specific format..
I've split off the last block from fwsexpl.spr, which has the two bytes 1e37 followed by 3300 bytes to the end of the file. we can split 1e37 to be decimal 30 and 55.
In the hex editor it seems that 30 is better value for width than 55, but I'm still not sure what I'm seeing.
The following is a composite picture of the 3300 bytes as seen in the hex editor, the graphical part being the whole block and the hex data about a third of it.

spr1.png

Share this post


Link to post
Share on other sites

Try this loop:

for(y in height)
  for(x in 2 * width)
  	data[y * width/2 + (x / 4) + (x % 4 * width/2 * height)]

This makes visible the crosshair, radar screens, cockpit buttons, and other stuff.

P.S.: Gotta mirror vertically …

P.P.S: It's a pity these are indexed. I cannot write a thumbnail handler or display them properly in Lean Viewer without embedded colors.

Share this post


Link to post
Share on other sites

Great! Looks like you've cracked it.
I'm sure nobody will notice if you hard code one of the tfx1 palettes into Lean Viewer.

I still don't understand why there are twice as many bytes as width*height...

Share this post


Link to post
Share on other sites
10 hours ago, mikew said:

I still don't understand why there are twice as many bytes as width*height...

FWSEXPL.SPR, last frame, 3300 B, 30×55.

My above algorithm generates a 60×55 (3,300 pixels) image from it, and I think it also picks 3,300 different bytes for that, so that fits well. Honestly I don't know why they stored half the width in the file. It could be because they used the format for larger images (maps; animations?) and tried to avoid overflowing the 0…255 range for each dimension.

I'll try the TFX palette now.

 

Share this post


Link to post
Share on other sites

From that first picture of FWSEXPL:SPR above, the impression is of an explosion effect with four different sizes, and multiple bitmaps at each size to give an animated feel. That just be an artefact of the aliasing effect when picking an arbitrary 60 bytes per row in the hex editor though.

Share this post


Link to post
Share on other sites

Sneak peek: https://app.box.com/s/u6hzzey6uutiyklxixpp3jcstbnjcw70

It would be great if you tried your own decoding approach and compared it to my results. It might be possible that I have missed half of the bytes and just don't find the error in my own code … 

P.S.: Updated for correct color palette display.

Right now I'm limiting the number of frames to 64 in order to avoid false positives with other file types. Now I find some files that contain entire alphanumeric fonts. I should probably lift the limit to 128.

Share this post


Link to post
Share on other sites

Awesome! :icon_bow:

2 hours ago, Krycztij said:

It would be great if you tried your own decoding approach and compared it to my results. It might be possible that I have missed half of the bytes and just don't find the error in my own code … 

I can't come up with anything better. Even if we're not quite 100% correct with the decoding, I'm farly sure we're not missing anything significant.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×