R
rmco2003
Guest
Awesome Tonberry, I'll check it out when I get home, as I've only got .NET on this computer. Thanks for all of your help, you'll be in the credits :wink:
- Status
T
Tonberry
Guest
Try the VB6 code first as it has less bugs. The problem you see may be with images that have a width not divisible by 4 as those images created corrupted BMPs. That's fixed with the VB6 version.
Try it with all the SPRs you can and make a list of the ones that didn't work.
The VB6 version recognizes SPRs with 0, 1, 2 or any number of tables. It just assumes the meaning for tables 2, 3, etc. is the same as for 0 and 1, but that may be wrong. Anyway, I didn't find anything besides table 0 and 1.
I don't think you'll have problems working with BMPs. The compatibility can be 100%, but you have to put each layer into a different BMP and you can select any color to be the mask.
It's not that BMP is bad, it's that the 24bpp version doesn't directly support masks/transparency as other formats do and I'm not sure how good the support is for other color representations. It doesn't support layers and there may be more than 2.
I understand you see this as something negative, but also think that BMP is a very simple format, quite good for learning how to convert from one format to another. Keep in mind that I'm only providing this code as an example.
There are many possibilities for that:
- It's possible that the SPR format is not complete. (But I covered every byte.)
- Perhaps another layer is used for transparency. How many tables do you have for those images?
- Perhaps the transparency/translucency is programmatically added. Something like: if I'm drawing a button with size dx*dy, blend it with the background using a rectangle of size dx*dy. Are those images rectangular?
- It may be some kind of filter.
- I noticed some of the buttons you provided had an effect simulating a diagonal reflection of light crossing the button and a gradient for the borders. Maybe it's something similar.
Try changing the mask color to black/green/red or some unused color.
I'd suggest you get the BMP to SPR conversion working, modify one image and try it with the game to see what happens.
R
rmco2003
Guest
Yes I think they are rectangular, I'm going to be coding the conversion in the morning, I'll probably make your code save things like the amount of tables and layers in one SPR file to a text file, so that it can be rebuilt properly.
[EDIT] I've worked out now that the transparency is done in the second extracted layer, so it seems to be fine. One thing I'm not sure of though is when I'm making the SPR file, how would the layer thing work? In one of the files it extracts two images, the first image is the main one, and the second contains the transparencies, does this mean that they are stored as image 0, and image 1 in table 0? If this is so then it should be alright, I'm just wondering about how complicated the solution will be.
[EDIT2] I've now got the code writing the file signiture, and image amount to an spr file, I've also got code for reading and writing the widths and heights but I need to know where they are written in the BMP header. I've currently got it reading 4 bytes from offset 0x48 for the width, and 4 bytes from offset 0x59 for the height for each bitmap image. It seems to store the data fine, but could you confirm that the offsets are correct please?
[EDIT3] I'm also confused about the pointers for the tables, how exactly would I implement the whole table structure? Do they have a set amount of 32 bit integers or is it variable? What is the base offset you need to multiply the half words by?
Also relating to the second table, is each image stored in a seperate table? Or is there a size limit for the amount of images in each table?
You also mentioned that in some of the files the second table had an offset pointing to a group of 00's, does this mean it doesn't have anything in the second table? How can I tell what SPR files have second tables?
I'm trying to avoid running into size problems, where the game tries to read from the wrong location because the files haven't been padded, etc.
I'm seriously considering modifying your code to output structure information from the SPR files so that I can just read the data and transfer the BMP pixel data directly, I think it would be much easier, and safer.
Waiting for your thoughts
[EDIT] I've worked out now that the transparency is done in the second extracted layer, so it seems to be fine. One thing I'm not sure of though is when I'm making the SPR file, how would the layer thing work? In one of the files it extracts two images, the first image is the main one, and the second contains the transparencies, does this mean that they are stored as image 0, and image 1 in table 0? If this is so then it should be alright, I'm just wondering about how complicated the solution will be.
[EDIT2] I've now got the code writing the file signiture, and image amount to an spr file, I've also got code for reading and writing the widths and heights but I need to know where they are written in the BMP header. I've currently got it reading 4 bytes from offset 0x48 for the width, and 4 bytes from offset 0x59 for the height for each bitmap image. It seems to store the data fine, but could you confirm that the offsets are correct please?
[EDIT3] I'm also confused about the pointers for the tables, how exactly would I implement the whole table structure? Do they have a set amount of 32 bit integers or is it variable? What is the base offset you need to multiply the half words by?
Also relating to the second table, is each image stored in a seperate table? Or is there a size limit for the amount of images in each table?
You also mentioned that in some of the files the second table had an offset pointing to a group of 00's, does this mean it doesn't have anything in the second table? How can I tell what SPR files have second tables?
I'm trying to avoid running into size problems, where the game tries to read from the wrong location because the files haven't been padded, etc.
I'm seriously considering modifying your code to output structure information from the SPR files so that I can just read the data and transfer the BMP pixel data directly, I think it would be much easier, and safer.
Waiting for your thoughts
Last edited:
T
Tonberry
Guest
Wow, that's a lot of questions... and edits. 
I work so I won't be able to answer your questions too fast, but I'll do it eventually.
About how those particular images+transparency are stored in the SPR, well that depends on how you extracted them:
- If you extracted them from the same table, the those will be different images and they'll be stored as image 0 and image 1 in table 0.
- If you extracted the first one from table 0 and the second one from table 1, then you'll have to make sure you store them as image 0 in table 0 and as image 0 in table 1.
In the case of the first files you posted (the ones with the prize), the sprites had the colors in table 0 and the shadows in table 1, so in the file you have:
table0
image 0 (normal)
image 1 (normal)
image 2 (normal)
...
table 1
image 0 (shadow)
image 1 (shadow)
image 2 (shadow)
...
That's where I took the info on BMPs from. It says the offsets are 19 (decimal) for the width in pixels and offset 23 (decimal) for the height. Those offsets are base 1, so that's what you should tell VB6. You have to read 4 bytes to get the width and 4 bytes to get the height.
- A pointer to the next layer (4 bytes).
- A table of pointers to images in the current layer. Each pointer is 4 bytes long and there is 1 pointer for each image. (The total size for the array is 4*image_count)
- Images of the layer. (Variable size.)
The total size for the layer is 4+4*image_count+"the sum of the sizes of the compressed images".
No, there are no half-words in the tables, unless you are confussing the words you have to multiply by 2 with half-words.
A half-word is a 16 bit number in a 32 bit architecture, but the pointers you'll find in the tables are 32 bit, so they are words. The thing with those (32 bit) pointers is that to get a pointer in bytes, you have to multiply their value by 2.
Once you multiply the pointer by 2 to convert to a displacement in bytes, you have to add the base offset. The base offset for all the pointers in a layer is the offset of the first image of the layer.
That means that if you get to the offset of the layer (where the pointer to the next layer is), you'll have the base offset for the pointers '4+4*image_count' bytes afterwards. So:
base_offset = layer_offset + 4 + 4*image_count
You won't find "base_offset" nor "layer_offset" in the program, sorry; those are concepts I'm using now that I have a better idea of the format.
- Pointer to next layer. (4 bytes)
- Table of pointer to images of second layer. (4*image_count bytes)
- Images for second layer. (Variable size.)
image_count is the same for all the layers and the widths and heights of the images are the same for all the layers. You'll notice that image_count, widths and heights are only defined once at the start of the file, before the first layer, so all the tables have the same number of elements (and size) and if image Z from table 0 has width dx and height dy, then image Z from table 1 will have dx*dy pixels. (The size in bytes for image Z in table 0 and 1 may be different because of the compression.)
Every table has the same amount of images because in reality they are different layers of the same images.
- Pointer to next layer. (4 bytes)
- Table of pointer to images of current layer. (4*image_count bytes)
- Images for current layer. (Variable size.)
This allows you to go jumping from layer to layer using the pointer to the next layer. (Don't forget to multiply the value by 2 and add the base_offset of the layer.)
If you get to a layer where the value of the pointer is 0x00000000, then the last layer was the previous one and this layer doesn't have information. There are 4 more bytes after this pointer but the value is 0x00000000 too and there is no table nor images; you reached the end of the file.
It's a little strange, as they could have put the 0x00000000 in the previous pointer, but that's how it is.
So, to get the number of tables you have to jump from layer to layer until you reach 0x00000000.
For what you want the data, it'll be easier if you load all the widths and heights into arrays and do the same for the pointers to the images, then dump the images to BMP sequentially, but that's a rewrite.
If you were using another programming language that supports unsigned values, you could define types for the headers or arrays for the tables to read bunchs of data. You can do that with VB6, but you have to be careful with the automatic type casting because you can end up with wrong values.
I work so I won't be able to answer your questions too fast, but I'll do it eventually.That's a good idea. I'd even recommend you modify the program to export all the data and images at once, but that's practically a rewrite.
That's the thing about BMPs and layers. As BMP doesn't support layers (and I didn't even know there where layers at first), you get 1 BMP for each layer.
About how those particular images+transparency are stored in the SPR, well that depends on how you extracted them:
- If you extracted them from the same table, the those will be different images and they'll be stored as image 0 and image 1 in table 0.
- If you extracted the first one from table 0 and the second one from table 1, then you'll have to make sure you store them as image 0 in table 0 and as image 0 in table 1.
In the case of the first files you posted (the ones with the prize), the sprites had the colors in table 0 and the shadows in table 1, so in the file you have:
table0
image 0 (normal)
image 1 (normal)
image 2 (normal)
...
table 1
image 0 (shadow)
image 1 (shadow)
image 2 (shadow)
...
Here's a link: http://en.wikipedia.org/wiki/Windows_bitmap
That's where I took the info on BMPs from. It says the offsets are 19 (decimal) for the width in pixels and offset 23 (decimal) for the height. Those offsets are base 1, so that's what you should tell VB6. You have to read 4 bytes to get the width and 4 bytes to get the height.
It's variable, but if you know the number of images that will be part of the SPR, you know the size. For each layer you have:
- A pointer to the next layer (4 bytes).
- A table of pointers to images in the current layer. Each pointer is 4 bytes long and there is 1 pointer for each image. (The total size for the array is 4*image_count)
- Images of the layer. (Variable size.)
The total size for the layer is 4+4*image_count+"the sum of the sizes of the compressed images".
No, there are no half-words in the tables, unless you are confussing the words you have to multiply by 2 with half-words.
A half-word is a 16 bit number in a 32 bit architecture, but the pointers you'll find in the tables are 32 bit, so they are words. The thing with those (32 bit) pointers is that to get a pointer in bytes, you have to multiply their value by 2.
Once you multiply the pointer by 2 to convert to a displacement in bytes, you have to add the base offset. The base offset for all the pointers in a layer is the offset of the first image of the layer.
That means that if you get to the offset of the layer (where the pointer to the next layer is), you'll have the base offset for the pointers '4+4*image_count' bytes afterwards. So:
base_offset = layer_offset + 4 + 4*image_count
You won't find "base_offset" nor "layer_offset" in the program, sorry; those are concepts I'm using now that I have a better idea of the format.
The second layer has a structure similar to the first layer:
- Pointer to next layer. (4 bytes)
- Table of pointer to images of second layer. (4*image_count bytes)
- Images for second layer. (Variable size.)
image_count is the same for all the layers and the widths and heights of the images are the same for all the layers. You'll notice that image_count, widths and heights are only defined once at the start of the file, before the first layer, so all the tables have the same number of elements (and size) and if image Z from table 0 has width dx and height dy, then image Z from table 1 will have dx*dy pixels. (The size in bytes for image Z in table 0 and 1 may be different because of the compression.)
Every table has the same amount of images because in reality they are different layers of the same images.
As I said above, all the layers have the same structure:
- Pointer to next layer. (4 bytes)
- Table of pointer to images of current layer. (4*image_count bytes)
- Images for current layer. (Variable size.)
This allows you to go jumping from layer to layer using the pointer to the next layer. (Don't forget to multiply the value by 2 and add the base_offset of the layer.)
If you get to a layer where the value of the pointer is 0x00000000, then the last layer was the previous one and this layer doesn't have information. There are 4 more bytes after this pointer but the value is 0x00000000 too and there is no table nor images; you reached the end of the file.
It's a little strange, as they could have put the 0x00000000 in the previous pointer, but that's how it is.
So, to get the number of tables you have to jump from layer to layer until you reach 0x00000000.
Be my guest.
For what you want the data, it'll be easier if you load all the widths and heights into arrays and do the same for the pointers to the images, then dump the images to BMP sequentially, but that's a rewrite.If you were using another programming language that supports unsigned values, you could define types for the headers or arrays for the tables to read bunchs of data. You can do that with VB6, but you have to be careful with the automatic type casting because you can end up with wrong values.
R
rmco2003
Guest
There are some files that definately aren't working, here's 5 of the problem spr's:
http://bin.mypage.sk/FILES/notworking.zip
This is the only problem I seem to be having with extraction, some sprs just don't work with the code..
http://bin.mypage.sk/FILES/notworking.zip
This is the only problem I seem to be having with extraction, some sprs just don't work with the code..
T
Tonberry
Guest
You shouldn't have poblems with the aura9. The other files have some differences to previous SPRs, but not much:
- The signature is different: "DCSPRITE0.5". That's the reason the export function returns. Be careful because this signature has 11 bytes like the previous one, but it doesn't include 00 at the end.
- The pointer to the next layer seems to point past the end of file when you are processing data from the last layer. (The previous version pointed to 0x00000000.) This will give you an error, so before jumping to the next layer, check to see if you'll end up outside the file.
That's it. I also noticed the image data was encoded a little bit different, but the function I wrote can decode it without modification.
To have the function working again, just compare both signatures and check you won't end up past the end of file when moving to the next layer.
- The signature is different: "DCSPRITE0.5". That's the reason the export function returns. Be careful because this signature has 11 bytes like the previous one, but it doesn't include 00 at the end.
- The pointer to the next layer seems to point past the end of file when you are processing data from the last layer. (The previous version pointed to 0x00000000.) This will give you an error, so before jumping to the next layer, check to see if you'll end up outside the file.
That's it. I also noticed the image data was encoded a little bit different, but the function I wrote can decode it without modification.
To have the function working again, just compare both signatures and check you won't end up past the end of file when moving to the next layer.
R
rmco2003
Guest
Well I've only done a half arsed job, but it seems that the incorrect pointer for the tables doesn't matter. I just allowed the code to recieve SPR files with the older signature and it can extract the images I couldn't do before just fine now.
T
Tonberry
Guest
Here is some code to encode one row from an image to the compressed SPR form. Everything is hardcoded so you'll have to modify it.
To write the information of a complete image to a SPR you have to:
- Write the number of rows to the file.
- For each row:
- Compress the row using a subroutine similar to the one posted. (Don't forget to convert from 24bpp to 16bpp every pixel.)
- Write the compressed row to the file.
All the elements from the image data are 2 bytes long each, so you'll have to use the function Write2 or something similar.
Code: [Select]
To write the information of a complete image to a SPR you have to:
- Write the number of rows to the file.
- For each row:
- Compress the row using a subroutine similar to the one posted. (Don't forget to convert from 24bpp to 16bpp every pixel.)
- Write the compressed row to the file.
All the elements from the image data are 2 bytes long each, so you'll have to use the function Write2 or something similar.
Code: [Select]
Code:
Option ExplicitPrivate Const CNST_VERSION = 10 ' SPR version to compress data to. Valid: 0.5 and 10'Private Const CNST_VERSION = 0.5Private Sub Command1_Click() ' This algorithm encodes a row from an image to SPR format. ' To encode a complete image, all individual rows must be processed by this subroutine. ' Input parameters. Dim width As Long ' Image width. Dim row(0 To 319) As Long ' Row of pixels to compress. (Array from 0 to width-1.) Dim mask_color As Long ' Color used to encode the mask. ' Output parameters. Dim subblocks As Long ' Number of sub-blocks after compression. Dim compressed_row(0 To 480) As Long ' Array that holds compressed row. (Worst case: array from 0 to width*3/2) Dim compressed_x As Long ' Number of elements from 'compressed_row' that effectively hold compressed data. ' Auxiliary variables. Dim x As Long ' Column from 'row' being processed. Dim compressed As Long ' Number of consecutive pixels with mask color. Dim uncompressed As Long ' Number of consecutive pixels without mask color. Dim uncompressed_start As Long ' Used to hold the place in 'compressed_row' where the number of consecutive pixels without the mask color must be written. ' Initialization of input parameters. (For the example.) width = 320 mask_color = 0 'Put some values into the row just to test. row(10) = 8 row(11) = 9 row(12) = 8 row(55) = 7 row(57) = 7 ' Initialization. subblocks = 0 compressed_x = 0 x = 0 ' For every column... Do While x < width ' Get the number of consecutive compressed pixels. compressed = 0 Do While x < width If row(x) <> mask_color Then Exit Do End If compressed = compressed + 1 x = x + 1 Loop ' Add the number of consecutive compressed pixels to the compressed data. compressed_row(compressed_x) = compressed compressed_x = compressed_x + 1 ' Hold the position where the number of consecutive uncompressed pixels must be stored. uncompressed_start = compressed_x compressed_x = compressed_x + 1 ' Get the number of consecutive uncompressed pixels, while adding them to the compressed data. uncompressed = 0 Do While x < width If row(x) = mask_color Then Exit Do End If compressed_row(compressed_x) = row(x) ' *** TODO: Convert the pixel from 24bpp to 16bpp. compressed_x = compressed_x + 1 uncompressed = uncompressed + 1 x = x + 1 Loop ' Store the number of consecutive uncompressed pixels. compressed_row(uncompressed_start) = uncompressed ' End compressed row data depending on SPR version. Select Case CNST_VERSION Case 0.5 ' Version 0.5 simply adds last sub-block. subblocks = subblocks + 1 Case 10 ' Version 10 only adds last sub-block if it has uncompressed pixels. If (uncompressed = 0) Then compressed_x = uncompressed_start - 1 Else subblocks = subblocks + 1 End If End Select Loop ' End of subroutine. ' Show compressed data. Debug.Print subblocks For x = 0 To compressed_x - 1 Debug.Print compressed_row(x) & "; "; Next x Debug.PrintEnd Sub
M
mirex
Guest
Hi, I had no time to comment or look into the file format sooner. I see that you have decoded everything already.
For your information BMP has a possibility to store alpha transparency layer, it can be accomplished by storing 32bit BMP's. You can see these layers in Paint Shop Pro too. I use PSP6/7 and you can see the layer through menu / Mask / Load from alpha channel.
Tonberry: may I use your description and code SPR support into my program Biturn ? You will be credited of course.
rmco2003: I haven't seen the name of the game so far, please can you tell me what game is it ?
For your information BMP has a possibility to store alpha transparency layer, it can be accomplished by storing 32bit BMP's. You can see these layers in Paint Shop Pro too. I use PSP6/7 and you can see the layer through menu / Mask / Load from alpha channel.
Tonberry: may I use your description and code SPR support into my program Biturn ? You will be credited of course.
rmco2003: I haven't seen the name of the game so far, please can you tell me what game is it ?
Last edited:
H
halkun
Guest
taking a stab, it's either FF:Tacticts ot Xoneogears.
However sprites were a PSY-Q thing. So they might be generic.
However sprites were a PSY-Q thing. So they might be generic.
R
rmco2003
Guest
It's just a random Korean MMORPG I'm working on. Mirex if you allow SPR conversion both ways I'll be very happy indeed I think I've reached a point now where my ability isn't good enough to get this done, all I've managed to do is write the easiest things to a new file, and that's using existing code as a base..
Looks like I'm begging again.. :wink:
I think I've reached a point now where my ability isn't good enough to get this done, all I've managed to do is write the easiest things to a new file, and that's using existing code as a base..Looks like I'm begging again.. :wink:
Last edited:
M
mirex
Guest
rmco2003: you should continue on your program. I don't know how long will it take me untill its finished, I have only a little of free time.
R
rmco2003
Guest
I suppose, I'll just have to keep trying to figure out what to do until I get somewhere..
T
Tonberry
Guest
Mirex: No problem, use it however you like. No need for credits unless it's custom.
Thanks for the info on BMP. I don't have PSP so I used Paint to test and it doesn't have 32-bit BMPs.
rmco2003:
This is the data you should save when decoding a SPR to be able to rebuild it later:
1) Signature.
2) Number of images.
3) Number of layers.
4) List with the widths.
5) List with the heights.
6) List with the names of the BMPs generated. (Choose the order. I recommend you list the images in the same order as they are stored in the SPR.)
I'll call this file the "SPR definition file" in this example. I'm assuming you won't change the width or height of the images. (If you'll change them, then don't save them and just get them from the BMPs.)
To rebuild a SPR you'll need that file and all the BMPs. Then you can do something like this:
1) Get the signature from the SPR definition file and write it to the new SPR.
2) Get the number of images from the SPR definition file and write it to the new SPR.
3) Write the list of widths to the new SPR.
4) Write the list of heights to the new SPR.
5) Compress all the BMPs in separate files.
5.1) Load one BMP into memory.
5.2) Create a new file with extension ".SPRI" (or other) and the same name as the BMP.
5.3) Write the height of the image to the SPRI file.
5.4) For every row of the BMP:
5.4.1) Compress the row.
5.4.2) Write the number of sub-blocks generated to the SPRI file.
5.4.3) Write all the compressed data to the SPRI file.
5.5) Get the size in bytes of the SPRI generated and save it to an array for later use.
5.6) Close the SPRI file.
5.7) Repeat for the next BMP, starting at 5.1.
At this point we have the header of the SPR, the sizes of the encoded images and the encoded images. That's enough to build the layers.
6) Add all the layers.
6.1) Calculate the pointer to the next layer and write it to the SPR file. To do this, simply add the size in bytes for all the encoded images of the layer and divide the number by 2.
6.2) For every image in the layer, calculate the pointer to the image and write it to the SPR file.
6.2.1) Take 0 as the pointer to the first image of the layer.
6.2.2) For image I, take the pointer to it as the pointer to previous image (I-1) and add the size of the encoded image (I-1) divided by 2.
6.2.3) Repeat for the rest of the images in the layer. (Go to 6.2.2)
6.3) Append all the SPRI files of the layer to the SPR file.
6.4) Repeat for the next layer. (Goto 6.1)
7) If the SPR version is 10 then write 8 bytes with value 0x00.
8 ) Close the SPR file.
Each subsection tells you how to complete a section.
That's a lot of things to do. I recommend you don't try to do everything at once, but write one step and compare the result to the original SPR. (Don't modify the BMPs at first as it will be easier to find the differences.)
Hope it helps.
Edit: Corrected a mistake in 6.2.2
Thanks for the info on BMP. I don't have PSP so I used Paint to test and it doesn't have 32-bit BMPs.
rmco2003:
This is the data you should save when decoding a SPR to be able to rebuild it later:
1) Signature.
2) Number of images.
3) Number of layers.
4) List with the widths.
5) List with the heights.
6) List with the names of the BMPs generated. (Choose the order. I recommend you list the images in the same order as they are stored in the SPR.)
I'll call this file the "SPR definition file" in this example. I'm assuming you won't change the width or height of the images. (If you'll change them, then don't save them and just get them from the BMPs.)
To rebuild a SPR you'll need that file and all the BMPs. Then you can do something like this:
1) Get the signature from the SPR definition file and write it to the new SPR.
2) Get the number of images from the SPR definition file and write it to the new SPR.
3) Write the list of widths to the new SPR.
4) Write the list of heights to the new SPR.
5) Compress all the BMPs in separate files.
5.1) Load one BMP into memory.
5.2) Create a new file with extension ".SPRI" (or other) and the same name as the BMP.
5.3) Write the height of the image to the SPRI file.
5.4) For every row of the BMP:
5.4.1) Compress the row.
5.4.2) Write the number of sub-blocks generated to the SPRI file.
5.4.3) Write all the compressed data to the SPRI file.
5.5) Get the size in bytes of the SPRI generated and save it to an array for later use.
5.6) Close the SPRI file.
5.7) Repeat for the next BMP, starting at 5.1.
At this point we have the header of the SPR, the sizes of the encoded images and the encoded images. That's enough to build the layers.
6) Add all the layers.
6.1) Calculate the pointer to the next layer and write it to the SPR file. To do this, simply add the size in bytes for all the encoded images of the layer and divide the number by 2.
6.2) For every image in the layer, calculate the pointer to the image and write it to the SPR file.
6.2.1) Take 0 as the pointer to the first image of the layer.
6.2.2) For image I, take the pointer to it as the pointer to previous image (I-1) and add the size of the encoded image (I-1) divided by 2.
6.2.3) Repeat for the rest of the images in the layer. (Go to 6.2.2)
6.3) Append all the SPRI files of the layer to the SPR file.
6.4) Repeat for the next layer. (Goto 6.1)
7) If the SPR version is 10 then write 8 bytes with value 0x00.
8 ) Close the SPR file.
Each subsection tells you how to complete a section.
That's a lot of things to do. I recommend you don't try to do everything at once, but write one step and compare the result to the original SPR. (Don't modify the BMPs at first as it will be easier to find the differences.)
Hope it helps.
Edit: Corrected a mistake in 6.2.2
Last edited:
R
rmco2003
Guest
I guess this is where my INI module comes in handy
So much easier to record entries in an ini file than in a text log :wink:
Code: [Select]
[EDIT] I'm up to the point where I'm adding compressed data to the SPRI files. I can generate the files perfectly and add data to these files, but I'm having some issues with manipulating your code to compress one scanline. One of the problems is that the data is too small after compression to be realistic, think from something like 20k down to 2k, and when viewing the data there's a lot of blank space in between very small chunks of data. I'm just passing through to the files like this:
Code: [Select]
I really doubt that code is right now.. maybe it's to do with the array size? I just saw the text "Worst case Width * 3 / 2" so I thought to put that there.
I'm also having some trouble figuring out how to convert the pixels from 24bpp to 16bpp, your functions require quite a few different variables, and I'm assuming I have to convert it all to RGB and then to 16bpp, and visual basic won't allow me to do Function1(Function2 each being converson functions of yours.
Perhaps I'm approaching this from the wrong angle, I'll have to take a deeper look into it tomorrow.
So much easier to record entries in an ini file than in a text log :wink:
Code: [Select]
Code:
[data]signature=DCSPRITE10imagecount=2[measure]width0=212height0=330width1=212height1=330[output]image0=D:\Documents and Settings\Rhys\Desktop\dr2_sub_001_0000_i0.bmpimage1=D:\Documents and Settings\Rhys\Desktop\dr2_sub_001_0000_i1.bmpCode: [Select]
Code:
Put 3, , subblocksFor arraypos = 0 To (Width * 3 / 2) Put 3, , compressed_row(arraypos)Next arrayposI'm also having some trouble figuring out how to convert the pixels from 24bpp to 16bpp, your functions require quite a few different variables, and I'm assuming I have to convert it all to RGB and then to 16bpp, and visual basic won't allow me to do Function1(Function2 each being converson functions of yours.
Perhaps I'm approaching this from the wrong angle, I'll have to take a deeper look into it tomorrow.
Last edited:
T
Tonberry
Guest
It's nice to see you've already come this far.
9/226 = 3.98%
2/20 = 10%
That means you are getting less compression than you could achieve.
To tell the truth, the compression depends a lot on how many pixels of mask there are in the image. If the image has no mask, you should expect a compression to about 67% (16bpp/24bpp) the size of the BMP. If you have a scanline with 320 pixels (960 bytes) as mask, assuming the width of the image is also 320 pixels, the algorithm for version 10 will encode it with only 2 bytes.
In that example you are writing the value of 'subblocks' with a length of 4 bytes because 'subblocks' is a Long, but you should write only 2 bytes to conform to the SPR format. Use 'Call Write2(3, subblocks)' instead.
The same goes for the element of 'compressed_row'; just change it to 'Call Write2(3, compressed_row(arraypos))'.
That will also make the SPRI smaller.
You have to write only the elements of 'compressed_row' that go from 0 to 'compressed_x - 1'. The variable 'compressed_x' tells the number of elements in the compressed row.
The value 'width*3/2' is the maximium lenght a compressed row can have. I didn't really make the calculation so I may be wrong with that, but I think the worst case of compression is when a row has a sequence such as 'color-mask-color-mask-color-mask...'. In that case the algorithm doesn't compress the data, but expands it because it uses 2 values to encode the color pixel and 1 value to encode the mask. That's a total of 3 values for what was stored in only 2.
That bit of code should read something like this:
Code: [Select]
Code: [Select]
The first layer of the first image of "npc_priz_card.spr" has a compressed size of approx. 9KB. When extracted to a 24bpp BMP the size is 226KB.
9/226 = 3.98%
2/20 = 10%
That means you are getting less compression than you could achieve.
To tell the truth, the compression depends a lot on how many pixels of mask there are in the image. If the image has no mask, you should expect a compression to about 67% (16bpp/24bpp) the size of the BMP. If you have a scanline with 320 pixels (960 bytes) as mask, assuming the width of the image is also 320 pixels, the algorithm for version 10 will encode it with only 2 bytes.
Avoid using "Put" when writing to a binary file (in this application); use the functions "Write1", "Write2" and "Write4" instead. You can find them in 'AuxFileIO.BAS'.
In that example you are writing the value of 'subblocks' with a length of 4 bytes because 'subblocks' is a Long, but you should write only 2 bytes to conform to the SPR format. Use 'Call Write2(3, subblocks)' instead.
The same goes for the element of 'compressed_row'; just change it to 'Call Write2(3, compressed_row(arraypos))'.
That will also make the SPRI smaller.
You have to write only the elements of 'compressed_row' that go from 0 to 'compressed_x - 1'. The variable 'compressed_x' tells the number of elements in the compressed row.
The value 'width*3/2' is the maximium lenght a compressed row can have. I didn't really make the calculation so I may be wrong with that, but I think the worst case of compression is when a row has a sequence such as 'color-mask-color-mask-color-mask...'. In that case the algorithm doesn't compress the data, but expands it because it uses 2 values to encode the color pixel and 1 value to encode the mask. That's a total of 3 values for what was stored in only 2.
That bit of code should read something like this:
Code: [Select]
Code:
Call Write2(3, subblocks)For arraypos = 0 To compressed_x - 1 Call Write2(3, compressed_row(arraypos))Next arrayposHow strange... I thought I'd put a function to do that, but it seems I forgot. Add this to 'Color.BAS': (I didn't test it.)
Code: [Select]
Code:
' Convert 24bpp to 16bpp.Public Function Convert24bppTo16bpp(bpp24 As Long) As Long Dim R as Long Dim G As Long Dim B as Long Call Convert24bppToRGB(bpp24, R, G, B) Convert24bppTo16bpp = ConvertRGBTo16bpp(R, G, B)End Function
Last edited:
R
rmco2003
Guest
I realised that my problem is that I was loading the BMP for read access, but I wasn't actually reading the rows into the array. I think I need to use a seek command then something like read4? The problem is I don't know where to seek to..
T
Tonberry
Guest
According to the Wikipedia link, you can get the starting address of the bitmap from offsets 11-14 (base 1, so in VB do a seek to 11 and use Read4). The address you get will be base 0 so add 1 to it and do another seek to get to that address. (You'll probably end up at offset 55, base 1.)
There you'll have to read, using Read1, the three components for every pixel and convert them from RGB to 24bpp. The first '3*width' bytes have the pixels for the first row (the last one really, as BMP stores rows from bottom to top), then you'll have to check if '3*width' is divisible by 4 and if it's not, then read (and discard) as many bytes as necessary to make it divisible by 4. Look at what I did with the variable 'complete_row' in 'ImageBufferToBMP', but instead of writing, read. After that, process the next row.
There you'll have to read, using Read1, the three components for every pixel and convert them from RGB to 24bpp. The first '3*width' bytes have the pixels for the first row (the last one really, as BMP stores rows from bottom to top), then you'll have to check if '3*width' is divisible by 4 and if it's not, then read (and discard) as many bytes as necessary to make it divisible by 4. Look at what I did with the variable 'complete_row' in 'ImageBufferToBMP', but instead of writing, read. After that, process the next row.
R
rmco2003
Guest
So if I use
Code: [Select]
To read the rows, then it should work?
Also what do I do about this?
Code: [Select]
Is this a read too? Or do I do something else instead?
I'm just replicating your function and switching things around to make it follow your instructions.
Some sudo code or something would be extremely helpful for doing all of this seeking, and need to know things like are the images going to be upside down and all of the rest of it, which I'd probably end up doing seeing as I don't know the first thing about working with files in this way.
The code above is all I've been able to do so far, I've also seen you're making a new image buffer when making a BMP so I added that code to the loop I've made to process the compression code for each image so it makes a new buffer for each image.
I'm really confused now.
Code: [Select]
Code:
 For row = image_buffer.Height - 1 To 0 Step -1  For column = 0 To image_buffer.Width - 1   Call Read1(fh, blue)   Call Read1(fh, green)   Call Read1(fh, red)   Call mdlColor.ConvertRGBTo24bpp(image_buffer.Color(column, row), red, green, blue)  Next columnAlso what do I do about this?
Code: [Select]
Code:
  For i = 1 To complete_row   Call Write1(fh, 0)  Next iI'm just replicating your function and switching things around to make it follow your instructions.
Some sudo code or something would be extremely helpful for doing all of this seeking, and need to know things like are the images going to be upside down and all of the rest of it, which I'd probably end up doing seeing as I don't know the first thing about working with files in this way.
The code above is all I've been able to do so far, I've also seen you're making a new image buffer when making a BMP so I added that code to the loop I've made to process the compression code for each image so it makes a new buffer for each image.
I'm really confused now.
Last edited:
T
Tonberry
Guest
Try something like this:
Code: [Select]
The 'For' that uses 'complete_row' is used to complete the rows with 00s to make it divisible by 4 bytes, as requiered by BMPs.
Don't forget to assign value to 'complete_row' as I did in 'ImageBufferTopBMP'.
Mmmm... I smell despair. :wink: Maybe I'm not that good explaining or you still need a little more practice programming, or both. If it's a real pain to you and you can wait some time, I'll complete it for you.
Please, don't misunderstand me, I have no problem explaining the details to you, but you stated your objective is to translate the images. Maybe you prefer to skip the programming. Let me know what you decide.
Code: [Select]
Code:
For row = image_buffer.Height - 1 To 0 Step -1 For column = 0 To image_buffer.Width - 1 blue = Read1(fh) green = Read1(fh) red = Read1(fh) image_buffer.Color(column, row) = mdlColor.ConvertRGBTo24bpp(red, green, blue) Next column For i = 1 To complete_row discard = Read1(fh) Next i Next rowDon't forget to assign value to 'complete_row' as I did in 'ImageBufferTopBMP'.
I know it seems hard, but as I said before, it'd be better if you try to understand what the function is suposed to do and write it in your own terms. The code I wrote is simply an example and it may not do the things the way you intend them to, that's why it's important you use it simply as a guideline.
The images won't appear upside down because you started storing the first row of the BMP (the bottom row) in the last row of the image buffer. When saving the compressed rows just do the 'for' from 0 to 'height-1'.
Mmmm... I smell despair. :wink: Maybe I'm not that good explaining or you still need a little more practice programming, or both. If it's a real pain to you and you can wait some time, I'll complete it for you.
Please, don't misunderstand me, I have no problem explaining the details to you, but you stated your objective is to translate the images. Maybe you prefer to skip the programming. Let me know what you decide.
- Status