.GDT Image Format

[NightWolve]

http://www.hardcoregaming101.net/46okun ... box-jp.jpg

https://web.archive.org/web/20160202075 ... box-jp.jpg

That's not too bad for that classic style (Had to use WayBack, HG101 is down for the count apparently for me). But blue-haired girl, eh, something iffy about it. Carry on though!

[hollowaytape]

Looks great, thanks again!!

I don't notice anything objectionable about Gaia, but she did have green hair (NSFW-ish) in this game rather than blue.

[NightWolve]

green hair (NSFW-ish)

OH MY!

[SkyeWelse]

So while exploring the sister thread for this romhacking project over at Romhacking.net I saw that a member named Raccoon Sam had come up with a better mockup of the E.V.O. title screen letters which I liked a lot more than the one I did. So after talking with him, he gave me a good start for being able to import his design into the cleaned up space background graphic and we now have a new Title Screen for E.V.O. The Theory of Evolution!



I think it looks a lot better, what do you all think?

HollowayTape, I wasn't sure how you were planning to do the credits for those who worked on the project, but I definitely think Raccoon Sam should be listed as equal credit on the Title Screen graphic. He did most of the hard work.

-Thomas

[NightWolve]

So this was your previous version below ?



Yeah, as a matter of subjective taste, I would say that I also like his font choice, extra 3D use, lesser height, etc. a little better versus yours above.

[SkyeWelse]

Yeah, Raccoon Sam's version turned out a lot better. Mine was passable compared to his work, so I thought we should use his version. I also enjoy the font more. The "O" in particular looks like a stone wheel which reminds of a per-historic time period as well.

-Thomas

[hollowaytape]

M_bot, do you have the interest/time to work on this any more? I'm having a tough time reinserting the title screen, and that's one of the last things I need to do.

In particular, do you know what's happening when the .GDT -> .BMP decoder fails with the message "Index was outside the bounds of the array"? The original title screen, AV04B.GDT, fails to decode a few blocks into the stars with that message. Additionally, the edited title screen, encoded into a .GDT with the simplest flags, also fails at the same place with the same message. Finally, the game fails to interpret the image correctly around this point, too - it just becomes a smear of colors.

Since the array index error happens even in the images I'm encoding to GDT, it probably doesn't have to do with the flags you haven't figured out.

I've attached the original image and the edited BMP I'm trying to reinsert.

[M_bot]

I will look at it tomorrow (maybe today) and get back to you then. If it is something overly complicated then I can work on it this weekend. I'm definitely still interested just have been fairly busy.

The error you are getting is a generic C# error, I don't know how much experience you have with C# but I would suggest opening the debugger and stepping through the code in the areas where the code uses arrays.

[M_bot]

This just a preliminary look since it might take me awhile to remember what all my code means.
The error that the original title screen and the new one get are happening on different flags. I don't know about the original one, but the new one I believe either my or your interpretation of the 0x8N flag is wrong. Since the game also has difficulty interpreting what you encoded, its possible that it encoded a specific value that is an exception which encodes not what you meant but some other sub-flag like instruction.

The error when decoding happens when it tries to write data beyond the screen, I'm fairly certain the game/emulator doesn't care if you do this and then incorrectly reads the next byte as a flag causing the random colors. The decoder however will throw that error since I haven't specifically forced it to continue decoding.

I will continue looking at it. Also I really like your code, very neat and commented.
------------------
Found a problem, I think there's more though. For RLE you are not allowed to encode 0xCN as a length. The 1st block, 2nd plane, it encodes 04 00 C8, which my program treats as an exception (and the game does too). I'm not entirely sure what 0xCN does but it seems like some type of rotate/shift thing. Also you could avoid the problem entirely by encoding that plane as 00. I haven't tested a fixed version with the game yet though.
------------------
Follow up, the overall problem with the encoder is that its keeps encoding lengths beyond the defined range. For equal nibble runs you are only allowed to encode up to 7D, from there onward you need to encode the length as 7E XX. It's possible that this actually supposed to be 0111 111X XXXX XXXX but there would never be a need for that since the screen size isn't that big. So for C8 as a length it would need to be 7E C8.

[hollowaytape]

Oh, cool! I'll try to avoid 0xCn in RLE then, and see if it gets any further.

I can also open up a pull request at any point if that makes things easier for you. I don't think I've touched your decoding code at all (except to add some comments).

[M_bot]

Looks like I was editing my post as you came by so posting to make sure you see this.

Follow up, the overall problem with the encoder is that its keeps encoding lengths beyond the defined range. For equal nibble runs you are only allowed to encode up to 7D, from there onward you need to encode the length as 7E XX. It's possible that this actually supposed to be 0111 111X XXXX XXXX but there would never be a need for that since the screen size isn't that big. So for C8 as a length it would need to be 7E C8.

Specifically there's a lot of lengths around 0x8N that keep throwing the program off. That also happens to be a special instruction, the one you know of is FF 84 but there's a couple more.

[hollowaytape]

Excellent. I've implemented the 0x7e byte in front of the run-lengths 0x7e and higher, and started encoding empty blocks as 0x00, and that appears to have taken care of a lot of what was going wrong.

(I wrote some code to avoid 0xCn lengths too, but after encoding empty blocks as 0x00 there weren't any showing up in this image, so the code is commented out.)

Looks like there are at least two things going wrong in the latest version of my encoder:
1) Something goes wrong in-game starting around block 5 (pixel 40), and stuff gets encoded into the wrong color planes after that. When I decode the GDT file with your decoder, I get an index-outside-bounds error too, at block 5, blue plane.
2) Something nefarious is up somewhere past block 66 (pixel 528). I can crop the image to this point and get pretty good results (with the weird colors, of course), but after that column, something I'm encoding is crashing the game.

I'm new to debuggers, so I'll try to take a look, but maybe you have some idea of what's going on?

[M_bot]

The reason why it stops at block 5 is because you forgot to encode 0x7E for the last run since your loop doesn't catch it.

Looking into the other error. I'm not sure about that one since my decoder doesn't seem to care, probably another pesky exception.

[hollowaytape]

Ah of course. Fixed that, and the colors are great now.

I'll look at the second error too. Looks like it goes wrong specifically in block 69, pixels 552-560. block 68, pixels 544-552. (EDIT: It's in the first/blue plane, too.) I'll look for suspicious values.

---
Another EDIT: I couldn't really find anything wrong. If I took the right half of the image and just encoded that, it would show up in the game just fine. I could take pretty big chunks of the image, like everything from pixel 48 rightward, and encode that successfully. I think it may be a matter of file size limits - the full image GDT is 16.5KB, and the largest GDT in the original game is 15.6KB.

I was able to letterbox the title screen just a little bit more than it already is, slimming the file size down to 15.5KB, and it shows up perfectly. And I think that may be good enough for me.

Thanks for all your help, M_bot!!

[SkyeWelse]

Thank you both for your help on getting the graphics to display. The Title screen looks great in-game now!

-Thomas