open-goal / jak-project

Reviving the language that brought us the Jak & Daxter Series
https://opengoal.dev
ISC License
2.74k stars 164 forks source link

OpenGLTexturePool died #3165

Open Melechtna opened 8 months ago

Melechtna commented 8 months ago

Acknowledgements

Describe the Bug

I'm trying to make a texture pack for Jak2, only a few textures reach or go above 256x256 with the method I'm using, but I get this in the logs.

[53:22:786] [die] OpenGLTexturePool needs more entries for 256 x 256

While I can reduce the texture upscaling I'm using, this is obviously not ideal, otherwise it compiles and replaces everything fine. Plus some of the textures are already above 256x256 without upscaling.

I'd like to further note, I'm currently trying to use the logs to get an understanding of what textures I can and can't keep, as I'm not entirely sure which Sky, Cloud, and Eye textures would be an issue, I was going to get into the Discord, but I'm not giving Discord my number when I already barely trust it for communication as far as I can throw it.

How To Reproduce

Apply an ESRGAN'd texture pack (with the default 4x upscaling)

Does this problem occur on original hardware or PCSX2?

Yes, it's unique to OpenGOAL

Expected Behavior

It would simply load like it does with Jak and Daxter without complaint.

Environment Information

NixOS, you know the drill by now, can't do that.

Game Version

NTSC Greatest Hits version (red label)

Have you set the game to something other than 60fps?

No

water111 commented 8 months ago

This error is specific to the animated textures, which are listed here: https://github.com/open-goal/jak-project/blob/master/decompiler/config/jak2/ntsc_v1/inputs.jsonc#L465 If you leave these textures alone, I think the error message should go away. I'm not exactly sure why this error would show up off the top of my head, but I think that doing texture replacements for any of these textures will break.

In the original game, these textures don't contain RGBA data, but instead store an index into a color palette. The texture animations might do things like change the colors in the palette to add an effect. (The decompiler exports plain RGBA .pngs, but internally the PC port does not use these - it keeps using the original game format data for these textures only)

If you do want to poke around, the code for animating textures is here: https://github.com/open-goal/jak-project/blob/master/game/graphics/opengl_renderer/TextureAnimator.cpp#L78

Melechtna commented 8 months ago

This error is specific to the animated textures, which are listed here: https://github.com/open-goal/jak-project/blob/master/decompiler/config/jak2/ntsc_v1/inputs.jsonc#L465 If you leave these textures alone, I think the error message should go away. I'm not exactly sure why this error would show up off the top of my head, but I think that doing texture replacements for any of these textures will break.

In the original game, these textures don't contain RGBA data, but instead store an index into a color palette. The texture animations might do things like change the colors in the palette to add an effect. (The decompiler exports plain RGBA .pngs, but internally the PC port does not use these - it keeps using the original game format data for these textures only)

If you do want to poke around, the code for animating textures is here: https://github.com/open-goal/jak-project/blob/master/game/graphics/opengl_renderer/TextureAnimator.cpp#L78

I was actually just looking for where the texture pool was called, but that first list tells me exactly what I need to kick out to get this process going, thank you so much for both of these links!

Zedb0T commented 8 months ago

Also I saw your comment on YT, There is a flag to flip to export the textures during a decompile, so you can reference the texture names

Melechtna commented 8 months ago

Also I saw your comment on YT, There is a flag to flip to export the textures during a decompile, so you can reference the texture names

Those comments were about porting a PCSX2 pack to OpenGOAL, and I've given up on that, because the formats are way to different to be worth the effort. So I dumped it and upscaled it myself. The pack in question was easy enough to convert from DDS to PNG, but the names looked like reference pointers for PCSX to use to replace the textures, so completely useless for identifying things, and it had to be done by eye, which again, different layout, completely hopeless, but I can work ESRGAN, so just did it myself.

Melechtna commented 8 months ago

So, something curious that I'll note here, maybe a fix could be implemented, maybe not, the fonts, the letters themselves seem to be scrunched just barely too close together. Obviously moving them out a few pixels from one another should remove the odd "borders" that show up on a few select letters would resolve the issue, but the engine would have to be adjusted to compensate. I don't entirely know if I should even create an issue for it, because it's such a minor issue, maybe shaving a few pixels off the letters that clip in would work?