Textures are done

After a total of 8 days of trial and hardship, ladies and gentlemen, I present to you 8-bit paletted textures!!

Stupidity

I am a victim of my own idiocy. In my rush to try and implement palettes and the 8-bit textures, I neglected to see that the palette needed to be rearranged... Alex has got it done.. Textures work with no noise now and I can finally stop obsessing over 768KiB pieces of shit and get on with my life (and sleep).

Pictures tomorrow.

Updating

So me, having the short attention span that I have (in regards to programming), decided to take a bit of break from sh3redux and work on a small auto-updater that I plan to distribute with my builds of sh3r when it's done.

I'm using wxWidgets for the user interface, and while it's really good, at the same time I hate it because of some of the really weird things, like having a macro for the main function...

Nonetheless, I have a small frame with two buttons that can connect to the Palm Studios github page and send a GET request, though I'm going to have to work out a way to check if the versions are the same. Shouldn't take me too long, and is a pretty fun side project!

"IT'S WORKING! IT'S WOOORKING!"

WORRRRKINNNNGGG
No but seriously, the 8-bit textures work perfectly (well, the palette is still a little bit weird, but we can tweak that). We can now successfully load up 8-bit textures and dump them to disk, or bind them to the GPU. Thank you so much de_lof (and the rest of the SILENT HILL 3 Modding community!!!).
It didn't work initially because it turns out I had an entire section of code inside the for loop when it should have been outside of it...

I spent a full day debugging this...

Encryption

Still working on Paletted textures, but I've hit a bit of a snag... It seems that the textures are 'encrypted' or packed in a really weird way (probably encryption). The loader I have by de_lof handles all of this, (though the output is corrupt) but the code is extraordinarily hard to read, and there is hardly any explanation on what the encryption actually is. This is going to take a while, but hopefully we can get some actual goddamned textures loaded soon.. Grabbing colours from the colour palette works 100% though, which is a start. The only issue is that converting the textures inflates them from (for example), 512*512 bytes (256KiB) to a whopping 768KiB, close to a megabyte! Hopefully we can reuse textures and don't need to load in more than a hundred of so per scene, if so, we're in for a very VRAM hungry game..

Textures (again)

So, I've decided to redo the entire texture Load() function, as I've realised there isn't just 24-bit and 8-bit textures... I came across some code where someone had figured out where the colour palettes are stored, how they are stored and the fact that some textures are RLE compressed. There isn't apparently some form of 'encryption', but I have't seen any of this so far. Anyways, I've managed to dump the palette of sys_konami.tex, and by the looks of it, this is all the colours used in the original konami logo. The palette is below (there's a lot of different types of orange and grey, who knows what they are for). Now I have to actually dump the texture are stepping through the palette and copying each colour into a buffer!! Progress!!

TEAM SILENT Bullshittery

Yes, I know bullshittery isn't a word, but I don't seem to have any words for some of the bizarre things I'm seeing the more and more we comb through the files of this failed abortion (just kidding, the SH3 engine holds up pretty well by today's standards). For reasons that elude me, before some textures in pic.arc, there exists 40 bytes of what seems to be nothing. This interferes with texture loading, because now a texture has a width and height of 0.... Fantastic! Now you might be thinking, "well, just add std::uint8_t[40] in your texture header... DUHHH". I wish I could... It seems that not all .tex files contain these 40 bytes. We're probably going to have dump the entirety of pic.arc and comb through each file. I might have to email Mike again (the creator of the fantastic SH2/3/4 level and model viewer). As for anyone reading this that has any idea, here's a pic (hahahahaha) of the data in a hex editor. If you know anything about this, open an issue here or just directly comment your solution here!

Shaders

For the past 3 weeks or so, we've been working a lot on Graphics, which is basically porting a lot of Mike's old code to our codebase (and cleaning it up). So far all we have to show for it is a quad, but that's good, because we've finally worked out Modern OpenGL (with VAOs and VBOs). I haven't been able to get indexing to work so far (I'm scared to even try it on complex meshes like Heather), but for a quad with 6-vertices, it'd probably actually take more system memory to get working than the 24-bytes of VRAM we're consuming! Here's a photo of the vertex and fragment shader in action.