R
rmco2003
Guest
Well I know for a fact that my knowledge in programming is insufficient :wink: but I'll still give it a shot and see if I can get any further. I think dispair would be accurate :|
Last edited:
- Status
T
Tonberry
Guest
OK, let's continue then. 
About the pseudocode for seeking the start of the bitmap (that I didn't explain it in the previous post):
1) Seek to the position in the header of the BMP where it has a pointer to the start of the bitmap. (Thats offset 11, base 1.)
2) Read 4 bytes using 'Read4'. (Notice the value you read will probably be 54, because according to Wikipedia that's the first offset after the header.)
3) Add 1 to the value you read in (2) to change it from base 0 (specified by BMP format) to base 1 (used by VB6).
4) Do another seek to the offset given by the value you got from step (3) to jump to the start of the bitmap.
That should complete the loading of the BMP. I recommend you test the code that loads the BMP before continuing with the compression as it will make things easier if you find problems later.
To test the loading function, just write the image buffer you just generated to another BMP. You already have a function to write the header of a BMP and another function to write the bitmap from an image buffer and you know they work fine; if there is any error, it will be in the loading.
If the new BMP looks fine, then go on to the compression. If it doesn't, it's best to correct that before adding the compression.
Oh... and test it with BMPs of different sizes.
About the pseudocode for seeking the start of the bitmap (that I didn't explain it in the previous post):
1) Seek to the position in the header of the BMP where it has a pointer to the start of the bitmap. (Thats offset 11, base 1.)
2) Read 4 bytes using 'Read4'. (Notice the value you read will probably be 54, because according to Wikipedia that's the first offset after the header.)
3) Add 1 to the value you read in (2) to change it from base 0 (specified by BMP format) to base 1 (used by VB6).
4) Do another seek to the offset given by the value you got from step (3) to jump to the start of the bitmap.
That should complete the loading of the BMP. I recommend you test the code that loads the BMP before continuing with the compression as it will make things easier if you find problems later.
To test the loading function, just write the image buffer you just generated to another BMP. You already have a function to write the header of a BMP and another function to write the bitmap from an image buffer and you know they work fine; if there is any error, it will be in the loading.
If the new BMP looks fine, then go on to the compression. If it doesn't, it's best to correct that before adding the compression.
Oh... and test it with BMPs of different sizes.
R
rmco2003
Guest
I can't get my head round this now, and I'm starting to get confused by my own code 
This is getting pretty hopeless now... I've put in your pseudocode but I don't even know what I'm meant to do with that offset I'm getting. I don't mind waiting if you can complete it :|
This is getting pretty hopeless now... I've put in your pseudocode but I don't even know what I'm meant to do with that offset I'm getting. I don't mind waiting if you can complete it :|
Last edited:
T
Tonberry
Guest
All that seeking had the purpose to find the offset where the "real" information of the image is stored. That's the offset where you'll find the data (component colors) for the first pixel of the image, and after that, for the next pixel and so on. So, after getting to that offset you have to start reading the pixels with the code...
Code: [Select]
... which I haven't tested, so it may have some mistakes.
After that you'll get the image in the image buffer. Before adding the part that compresses the image to make it SPR compatible, test that the image you loaded into 'image_buffer' is fine. To test it simply write it to a new BMP using the functions you have to write BMPs. Compare the original BMP to the new one.
Once you are sure the image is loading fine, delete or (better) comment the code that tests the BMP is fine and start adding the SPR compression.
--------
As a side note, I'll tell you all that previous seeking is needed because the BMP is composed of a header+image_data. The usual way to read them is to read the header into a memory structure first, get the width, height, bits per pixels, offset where image_data starts, etc. Once all those values are known, it's time to get the image_data (that is, the colors of the pixels).
There's the possibility that an application that writes BMPs adds some info between the usual header and the image_data, making the header bigger, so you can't just jump to the image_data. First you have to find where it's located.
As a bigger side note and completelly offtopic, I'll comment that to better understand all this jumping it's better if you learn some programming language that allows the use of pointers; something like C or Pascal. Learning how to implement common data structures such as lists, double-linked lists, queues, stacks and trees using pointers is helful too. There was a book (probably many) by an author named Aho that had good examples in Pascal.
You can do the same with VB6, VB .Net, C#, Java or some other programming languages that allows for references instead of pointers, but it's not as instructive as using pointers (in my opinion.)
Also, keep in mind that VB6 is a much higher-level language than C and although it makes a lot of generic things easier (GUI, reports, database management, etc.), when you have to implement something too specific it's a real pain and you end up using Windows APIs or linking to code written in C or C++.
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 rowAfter that you'll get the image in the image buffer. Before adding the part that compresses the image to make it SPR compatible, test that the image you loaded into 'image_buffer' is fine. To test it simply write it to a new BMP using the functions you have to write BMPs. Compare the original BMP to the new one.
Once you are sure the image is loading fine, delete or (better) comment the code that tests the BMP is fine and start adding the SPR compression.
--------
As a side note, I'll tell you all that previous seeking is needed because the BMP is composed of a header+image_data. The usual way to read them is to read the header into a memory structure first, get the width, height, bits per pixels, offset where image_data starts, etc. Once all those values are known, it's time to get the image_data (that is, the colors of the pixels).
There's the possibility that an application that writes BMPs adds some info between the usual header and the image_data, making the header bigger, so you can't just jump to the image_data. First you have to find where it's located.
As a bigger side note and completelly offtopic, I'll comment that to better understand all this jumping it's better if you learn some programming language that allows the use of pointers; something like C or Pascal. Learning how to implement common data structures such as lists, double-linked lists, queues, stacks and trees using pointers is helful too. There was a book (probably many) by an author named Aho that had good examples in Pascal.
You can do the same with VB6, VB .Net, C#, Java or some other programming languages that allows for references instead of pointers, but it's not as instructive as using pointers (in my opinion.)
Also, keep in mind that VB6 is a much higher-level language than C and although it makes a lot of generic things easier (GUI, reports, database management, etc.), when you have to implement something too specific it's a real pain and you end up using Windows APIs or linking to code written in C or C++.
R
rmco2003
Guest
I don't think it's worth me trying to code this thing anymore, it's just not working out. I'm just getting more confused and I don't know if what I'm doing is even going to help at all. If you have any spare time to work on this for me I'd greatly appreciate your help, otherwise I'm just going to have to give up on making these files.
T
Tonberry
Guest
OK, sorry. I'll try to complete it this week, just don't expect a complete application. I think I'll make a function to do the extraction and other to build the SPR back, following the same idea as above; that way you won't have to worry about the internals of the files.
R
rmco2003
Guest
That'd be great if you could. I can do things like opening and saving with common dialogs, GUI related things, and the like quite easily.
T
Tonberry
Guest
I posted a new version of the code to Mirex's trashbin (http://bin.mypage.sk/FILES/SPRExport2.zip). I made a few changes to some of the functions that already existed and added two new public functions to work with SPRs:
- SPR_Export
Given the name of a SPR file, the name of a SPR definition file and the color to use for the mask, creates the definition file and a BMP file for each image in the SPR.
- SPR_Build
Given the name of a SPR definition file, the name of a SPR file and the color to use for the mask, creates the SPR file.
You can find some examples on how to use the new functions in Form1. The concept is similar to what we discussed in previous posts, but I changed it a little bit, as now all the images are extracted in one step (more or less) and the rebuilding process does not use any auxiliary files to store the compressed data.
It's not complete yet, as I've found a little problem. My idea was to create a couple of functions, one the inverse of the other: one to extract the images and the other to rebuild an identical SPR to the original one. The problem is that some SPRs end with a sequence of zeros, but the amount of zeros isn't allways the same. There are some cases where the amount of zeros seem to be related to the number of images and others where they don't seem related.
Despite that problem, the rest of the data is the same, so I'll ask you to get some SPRs, extract the images, rebuild the SPRs and try the ones that have a different size than the original with the game.
If you find any problem, just let me know.
Hope it works.
- SPR_Export
Given the name of a SPR file, the name of a SPR definition file and the color to use for the mask, creates the definition file and a BMP file for each image in the SPR.
- SPR_Build
Given the name of a SPR definition file, the name of a SPR file and the color to use for the mask, creates the SPR file.
You can find some examples on how to use the new functions in Form1. The concept is similar to what we discussed in previous posts, but I changed it a little bit, as now all the images are extracted in one step (more or less) and the rebuilding process does not use any auxiliary files to store the compressed data.
It's not complete yet, as I've found a little problem. My idea was to create a couple of functions, one the inverse of the other: one to extract the images and the other to rebuild an identical SPR to the original one. The problem is that some SPRs end with a sequence of zeros, but the amount of zeros isn't allways the same. There are some cases where the amount of zeros seem to be related to the number of images and others where they don't seem related.
Despite that problem, the rest of the data is the same, so I'll ask you to get some SPRs, extract the images, rebuild the SPRs and try the ones that have a different size than the original with the game.
If you find any problem, just let me know.
Hope it works.
R
rmco2003
Guest
Awesome, finished on my birthday too 
great timing :wink:
[EDIT] The spr creation functions work perfectly, I've already inserted some of my modified images fine and they operate just like the originals.
Thanks for all of your help tonberry, I couldn't of done it without you.
great timing :wink:[EDIT] The spr creation functions work perfectly, I've already inserted some of my modified images fine and they operate just like the originals.
Thanks for all of your help tonberry, I couldn't of done it without you.
Last edited:
T
Tonberry
Guest
Happy birthday! 
It's nice to know it's working, thanks.
It's nice to know it's working, thanks.
R
rmco2003
Guest
Thanks again tonberry for your help, I was just wondering if anyone could spare some time to help me with some other file formats? There's some more formats for the game that I need help decoding, but mainly the ANI files that accompany the SPR files. I'd like to put together some sort of viewer for the game's various files so if anyone has some spare time could they look at these different formats?
There are 3 formats for the maps, named
.MAP
.OBJ
.TIL
and then there's the .ANI files for the sprites.
I'll start with what I have found, which is basically signatures.
In the .MAP files, it starts off with the text string "MAP1", followed by another text string which seems to be related maybe to other .MAP files that it requires.
In the .OBJ files, it starts off with the signature "DCOBJECT0.01", it is then padded by 14 bytes of the value "00", then there is data relating to the file for 8 bytes, and then there is further padding with the value "01", however it often has the value "00" mixed in with this padding too.
In the .TIL files, it starts off with the signature "DCTITLE0.03" followed by 2 bytes of padding with the value "00". There is then 6 bytes of data relating to the file, and then padding follows with the value "00004000".
In the .ANI files, it starts off with the signature "DCANIMATION0.5" followed immediately by the name of the SPR file it is related to, with no padding in between. It then has either data seperated by padding, or the whole thing is padding, but there is some repeating data after this.
I've uploaded samples of the files, and I've included the SPR files that relate to the ANI files.
The link to download the samples is from http://bin.mypage.sk/FILES/sub.zip
I'd really appreciate some help, mirex you said you looked briefly at the ANI files, do you think you could help with them?
[EDIT]
Could someone help me out please?
There are 3 formats for the maps, named
.MAP
.OBJ
.TIL
and then there's the .ANI files for the sprites.
I'll start with what I have found, which is basically signatures.
In the .MAP files, it starts off with the text string "MAP1", followed by another text string which seems to be related maybe to other .MAP files that it requires.
In the .OBJ files, it starts off with the signature "DCOBJECT0.01", it is then padded by 14 bytes of the value "00", then there is data relating to the file for 8 bytes, and then there is further padding with the value "01", however it often has the value "00" mixed in with this padding too.
In the .TIL files, it starts off with the signature "DCTITLE0.03" followed by 2 bytes of padding with the value "00". There is then 6 bytes of data relating to the file, and then padding follows with the value "00004000".
In the .ANI files, it starts off with the signature "DCANIMATION0.5" followed immediately by the name of the SPR file it is related to, with no padding in between. It then has either data seperated by padding, or the whole thing is padding, but there is some repeating data after this.
I've uploaded samples of the files, and I've included the SPR files that relate to the ANI files.
The link to download the samples is from http://bin.mypage.sk/FILES/sub.zip
I'd really appreciate some help, mirex you said you looked briefly at the ANI files, do you think you could help with them?
[EDIT]
Could someone help me out please?
Last edited:
- Status