Replace textures loaded by the 3D GPU

[vitor251093]

All textures need to be replaced with high resolution ones. This includes menu textures, character textures, the ingame fonts, everything.

We already started gattering some textures, but we need to wait until texture replacement is fully implemented in melonDS so this can be done.

https://melonds.kuribo64.net/comments.php?id=182

[vitor251093]

By creating a branch based in melonDS's compute-shader-renderer branch, I've managed to achieve texture replacement. Although, I still can't detect which texture is which so...

Welcome to texture hell

[CpazR]

Honestly, I think some of the texture filtering for characters and environments, while not the best, do a good enough job for the time being.

The menu's are where I'd focused efforts first imo. If nothing else than to make them wide-screen compatible.

[vitor251093]

I actually managed to extract some of the textures from the main menu using the other branch, and technically I am even capable of replacing them already.

The current problem is that the extracted images don't look exactly like they should. I can swap them around, like in the print, and they will still be used by the game properly, but if you open them with an image viewer, you will notice them are extremely transparent.

It may be related with RGB conversions, but I haven't checked that possibility yet

[sandwichwater]

i think this is probably another windows issue , but i cant seem to build the compute shader branch , very very last step in the compiling process always stops , something to do with ninja failing , though off the top of my head the first thing that comes to mind when you say the textures are transparent is that the same thing happens when you extract the textures in the ps2 kh games , the game stacks them when rendering the textures for some sort of pseudo antialiasing , though in the ds kh games there is none , so i cant think of any reason why theyd be transparent

[vitor251093]

i think this is probably another windows issue , but i cant seem to build the compute shader branch , very very last step in the compiling process always stops , something to do with ninja failing

Well, the compute shader branch still wasn't merged with the master branch, so it probably has problems that they are still dealing with. I hope the texture replacement system isn't that much affected by later fixes, but in any case, it should be useful to test replacement textures nonetheless.

though off the top of my head the first thing that comes to mind when you say the textures are transparent is that the same thing happens when you extract the ps2 kh games , the game stacks them for some sort of pseudo antialiasing , though in the ds kh games there is none , so i cant think of any reason why

Interesting. I didn't know about that KH2 fact. Since they reused some assets from KH2 in Days, you may be on to something.

Is there any recommended way to handle KH2 textures when it comes to replacing them?

[sandwichwater]

it probably has problems that they are still dealing with

id think so too , though i can build their compute shader branch just fine without issues , and i can almost build this branch , its just that where normally it would give a success message it gives a failed message

Is there any recommended way to handle KH2 textures when it comes to replacing them?

what ive always done is decrease the transparency value so i have a fully solid texture , edit it , then change the transparency value back to what it was originally . though oddly enough it only happens for ui and menu textures in the ps2 games , does it happen for all textures here ¿

[vitor251093]

id think so too , though i can build their compute shader branch just fine without issues , and i can almost build this branch , its just that where normally it would give a success message it gives a failed message

Which is the error message exactly?

what ive always done is decrease the transparency value so i have a fully solid texture , edit it , then change the transparency value back to what it was originally . though oddly enough it only happens for ui and menu textures in the ps2 games , does it happen for all textures here ¿

Yup, at least all the textures from the scene in the screenshot. It may be unrelated to KH2 then...

[sandwichwater]

Which is the error message exactly?

halfway through the final compiling step i get "FAILED: src/CMakeFiles/core.dir/GPU3D_TexcacheOpenGL.cpp.obj"

then at the very end i get "ninja: build stopped: subcommand failed."

there are no other error messages but if itll help i can give the full output as well

[vitor251093]

The lines between those two may be useful

[sandwichwater]

sure :

FAILED: src/CMakeFiles/core.dir/GPU3D_TexcacheOpenGL.cpp.obj D:\msys64\mingw64\bin\c++.exe -DARCHITECTURE_x86_64=1 -DJIT_ENABLED -DKHDAYSMM_VERSION=\"0.1.1\" -DO GLRENDERER_ENABLED -ID:/msys64/home/User/KHDays_FM/src/teakra/src/../include -O3 -DNDEBUG -std=gnu+ +17 -flto=auto -fno-fat-lto-objects -MD -MT src/CMakeFiles/core.dir/GPU3D_TexcacheOpenGL.cpp.obj -MF src\CMakeFiles\core.dir\GPU3D_TexcacheOpenGL.cpp.obj.d -o src/CMakeFiles/core.dir/GPU3D_TexcacheOpe nGL.cpp.obj -c D:/msys64/home/User/KHDays_FM/src/GPU3D_TexcacheOpenGL.cpp D:/msys64/home/User/KHDays_FM/src/GPU3D_TexcacheOpenGL.cpp: In member function 'void GPU3D::Texcach eOpenGLLoader::UploadTexture(u32, GLuint, u32, u32, u32, void)': D:/msys64/home/User/KHDays_FM/src/GPU3D_TexcacheOpenGL.cpp:30:38: error: cannot convert 'const std: :filesystem::__cxx11::path::value_type' {aka 'const wchar_t'} to 'const char' in initialization 30	const char* path = fullPath.c_str();	~~~~~~^~
const std::filesystem::__cxx11::path::value_type* {aka

const wchar_t} [55/138] Building CXX object src/CMakeFiles/core.dir/ARMJIT_x64/ARMJIT_Branch.cpp.obj In file included from D:/msys64/mingw64/lib/gcc/x86_64-w64-mingw32/13.1.0/include/stddef.h:1, from D:/msys64/mingw64/include/stdint.h:32, from D:/msys64/mingw64/lib/gcc/x86_64-w64-mingw32/13.1.0/include/stdint.h:9, from D:/msys64/home/User/KHDays_FM/src/types.h:22, from D:/msys64/home/User/KHDays_FM/src/dolphin/BitSet.h:8, from D:/msys64/home/User/KHDays_FM/src/dolphin/x64Emitter.h:16, from D:/msys64/home/User/KHDays_FM/src/ARMJIT_x64/ARMJIT_Compiler.h:22, from D:/msys64/home/User/KHDays_FM/src/ARMJIT_x64/ARMJIT_Branch.cpp:19: D:/msys64/home/User/KHDays_FM/src/ARMJIT_x64/ARMJIT_Branch.cpp: In member function 'void ARMJIT::Co mpiler::Comp_JumpTo(u32, bool)': D:/msys64/home/User/KHDays_FM/src/ARMJIT_x64/ARMJIT_Branch.cpp:62:42: warning: 'offsetof' within no n-standard-layout type 'ARMv5' is conditionally-supported [-Winvalid-offsetof] 62 | MOV(32, MDisp(RCPU, offsetof(ARMv5, RegionCodeCycles)), Imm32(regionCodeCycles)) ; | ^ D:/msys64/home/User/KHDays_FM/src/ARMJIT_x64/ARMJIT_Branch.cpp:109:42: warning: 'offsetof' within n on-standard-layout type 'ARM' is conditionally-supported [-Winvalid-offsetof] 109 | MOV(32, MDisp(RCPU, offsetof(ARM, CodeRegion)), Imm32(codeRegion)); | ^ D:/msys64/home/User/KHDays_FM/src/ARMJIT_x64/ARMJIT_Branch.cpp:110:42: warning: 'offsetof' within n on-standard-layout type 'ARM' is conditionally-supported [-Winvalid-offsetof] 110 | MOV(32, MDisp(RCPU, offsetof(ARM, CodeCycles)), Imm32(codeCycles)); | ^ D:/msys64/home/User/KHDays_FM/src/ARMJIT_x64/ARMJIT_Branch.cpp:144:38: warning: 'offsetof' within n on-standard-layout type 'ARM' is conditionally-supported [-Winvalid-offsetof] 144 | MOV(32, MDisp(RCPU, offsetof(ARM, R[15])), Imm32(newPC)); | ^ D:/msys64/home/User/KHDays_FM/src/ARMJIT_x64/ARMJIT_Branch.cpp:148:38: warning: 'offsetof' within n on-standard-layout type 'ARM' is conditionally-supported [-Winvalid-offsetof] 148 | ADD(32, MDisp(RCPU, offsetof(ARM, Cycles)), Imm8(cycles)); | ^ [57/138] Building CXX object src/CMakeFiles/core.dir/ARMJIT_x64/ARMJIT_Compiler.cpp.obj In file included from D:/msys64/mingw64/lib/gcc/x86_64-w64-mingw32/13.1.0/include/stddef.h:1, from D:/msys64/mingw64/include/stdint.h:32, from D:/msys64/mingw64/lib/gcc/x86_64-w64-mingw32/13.1.0/include/stdint.h:9, from D:/msys64/home/User/KHDays_FM/src/types.h:22, from D:/msys64/home/User/KHDays_FM/src/dolphin/BitSet.h:8, from D:/msys64/home/User/KHDays_FM/src/dolphin/x64Emitter.h:16, from D:/msys64/home/User/KHDays_FM/src/ARMJIT_x64/ARMJIT_Compiler.h:22, from D:/msys64/home/User/KHDays_FM/src/ARMJIT_x64/ARMJIT_Compiler.cpp:19: D:/msys64/home/User/KHDays_FM/src/ARMJIT_x64/ARMJIT_Compiler.cpp: In constructor 'ARMJIT::Compiler: :Compiler()': D:/msys64/home/User/KHDays_FM/src/ARMJIT_x64/ARMJIT_Compiler.cpp:287:75: warning: 'offsetof' within non-standard-layout type 'ARM' is conditionally-supported [-Winvalid-offsetof] 287 | MOV(32, R(RSCRATCH3), MComplex(RCPU, RSCRATCH2, SCALE_4, offsetof(ARM, R_FIQ))); | ^ D:/msys64/home/User/KHDays_FM/src/ARMJIT_x64/ARMJIT_Compiler.cpp:290:75: warning: 'offsetof' within non-standard-layout type 'ARM' is conditionally-supported [-Winvalid-offsetof] 290 | MOV(32, R(RSCRATCH3), MComplex(RCPU, RSCRATCH2, SCALE_4, offsetof(ARM, R_IRQ))); | ^ D:/msys64/home/User/KHDays_FM/src/ARMJIT_x64/ARMJIT_Compiler.cpp:293:75: warning: 'offsetof' within non-standard-layout type 'ARM' is conditionally-supported [-Winvalid-offsetof] 293 | MOV(32, R(RSCRATCH3), MComplex(RCPU, RSCRATCH2, SCALE_4, offsetof(ARM, R_SVC))); | ^ D:/msys64/home/User/KHDays_FM/src/ARMJIT_x64/ARMJIT_Compiler.cpp:296:75: warning: 'offsetof' within non-standard-layout type 'ARM' is conditionally-supported [-Winvalid-offsetof] 296 | MOV(32, R(RSCRATCH3), MComplex(RCPU, RSCRATCH2, SCALE_4, offsetof(ARM, R_ABT))); | ^ D:/msys64/home/User/KHDays_FM/src/ARMJIT_x64/ARMJIT_Compiler.cpp:299:75: warning: 'offsetof' within non-standard-layout type 'ARM' is conditionally-supported [-Winvalid-offsetof] 299 | MOV(32, R(RSCRATCH3), MComplex(RCPU, RSCRATCH2, SCALE_4, offsetof(ARM, R_UND))); | ^ D:/msys64/home/User/KHDays_FM/src/ARMJIT_x64/ARMJIT_Compiler.cpp:329:61: warning: 'offsetof' within non-standard-layout type 'ARM' is conditionally-supported [-Winvalid-offsetof] 329 | MOV(32, MComplex(RCPU, RSCRATCH2, SCALE_4, offsetof(ARM, R_FIQ)), R(RSCRATCH3)); | ^ D:/msys64/home/User/KHDays_FM/src/ARMJIT_x64/ARMJIT_Compiler.cpp:333:61: warning: 'offsetof' within non-standard-layout type 'ARM' is conditionally-supported [-Winvalid-offsetof] 333 | MOV(32, MComplex(RCPU, RSCRATCH2, SCALE_4, offsetof(ARM, R_IRQ)), R(RSCRATCH3)); | ^ D:/msys64/home/User/KHDays_FM/src/ARMJIT_x64/ARMJIT_Compiler.cpp:337:61: warning: 'offsetof' within non-standard-layout type 'ARM' is conditionally-supported [-Winvalid-offsetof] 337 | MOV(32, MComplex(RCPU, RSCRATCH2, SCALE_4, offsetof(ARM, R_SVC)), R(RSCRATCH3)); | ^ D:/msys64/home/User/KHDays_FM/src/ARMJIT_x64/ARMJIT_Compiler.cpp:341:61: warning: 'offsetof' within non-standard-layout type 'ARM' is conditionally-supported [-Winvalid-offsetof] 341 | MOV(32, MComplex(RCPU, RSCRATCH2, SCALE_4, offsetof(ARM, R_ABT)), R(RSCRATCH3)); | ^ D:/msys64/home/User/KHDays_FM/src/ARMJIT_x64/ARMJIT_Compiler.cpp:345:61: warning: 'offsetof' within non-standard-layout type 'ARM' is conditionally-supported [-Winvalid-offsetof] 345 | MOV(32, MComplex(RCPU, RSCRATCH2, SCALE_4, offsetof(ARM, R_UND)), R(RSCRATCH3)); | ^ D:/msys64/home/User/KHDays_FM/src/ARMJIT_x64/ARMJIT_Compiler.cpp: In member function 'void ARMJIT:: Compiler::LoadCPSR()': D:/msys64/home/User/KHDays_FM/src/ARMJIT_x64/ARMJIT_Compiler.cpp:479:44: warning: 'offsetof' within non-standard-layout type 'ARM' is conditionally-supported [-Winvalid-offsetof] 479 | MOV(32, R(RCPSR), MDisp(RCPU, offsetof(ARM, CPSR))); | ^ D:/msys64/home/User/KHDays_FM/src/ARMJIT_x64/ARMJIT_Compiler.cpp: In member function 'void ARMJIT:: Compiler::SaveCPSR(bool)': D:/msys64/home/User/KHDays_FM/src/ARMJIT_x64/ARMJIT_Compiler.cpp:486:38: warning: 'offsetof' within non-standard-layout type 'ARM' is conditionally-supported [-Winvalid-offsetof] 486 | MOV(32, MDisp(RCPU, offsetof(ARM, CPSR)), R(RCPSR)); | ^ D:/msys64/home/User/KHDays_FM/src/ARMJIT_x64/ARMJIT_Compiler.cpp: In member function 'void ARMJIT:: Compiler::LoadReg(int, Gen::X64Reg)': D:/msys64/home/User/KHDays_FM/src/ARMJIT_x64/ARMJIT_Compiler.cpp:495:52: warning: 'offsetof' within non-standard-layout type 'ARM' is conditionally-supported [-Winvalid-offsetof] 495 | MOV(32, R(nativeReg), MDisp(RCPU, offsetof(ARM, R) + reg4)); | ^ D:/msys64/home/User/KHDays_FM/src/ARMJIT_x64/ARMJIT_Compiler.cpp: In member function 'void ARMJIT:: Compiler::SaveReg(int, Gen::X64Reg)': D:/msys64/home/User/KHDays_FM/src/ARMJIT_x64/ARMJIT_Compiler.cpp:502:34: warning: 'offsetof' within non-standard-layout type 'ARM' is conditionally-supported [-Winvalid-offsetof] 502 | MOV(32, MDisp(RCPU, offsetof(ARM, R) + reg4), R(nativeReg)); | ^ D:/msys64/home/User/KHDays_FM/src/ARMJIT_x64/ARMJIT_Compiler.cpp: In member function 'void ARMJIT:: Compiler::Comp_SpecialBranchBehaviour(bool)': D:/msys64/home/User/KHDays_FM/src/ARMJIT_x64/ARMJIT_Compiler.cpp:675:36: warning: 'offsetof' within non-standard-layout type 'ARM' is conditionally-supported [-Winvalid-offsetof] 675 | OR(8, MDisp(RCPU, offsetof(ARM, IdleLoop)), Imm8(0x1)); | ^ D:/msys64/home/User/KHDays_FM/src/ARMJIT_x64/ARMJIT_Compiler.cpp:683:42: warning: 'offsetof' within non-standard-layout type 'ARM' is conditionally-supported [-Winvalid-offsetof] 683 | ADD(32, MDisp(RCPU, offsetof(ARM, Cycles)), Imm32(ConstantCycles)); | ^ D:/msys64/home/User/KHDays_FM/src/ARMJIT_x64/ARMJIT_Compiler.cpp: In member function 'void ( ARMJI T::Compiler::CompileBlock(ARM, bool, ARMJIT::FetchedInstr, int, bool))()': D:/msys64/home/User/KHDays_FM/src/ARMJIT_x64/ARMJIT_Compiler.cpp:750:42: warning: 'offsetof' within non-standard-layout type 'ARM' is conditionally-supported [-Winvalid-offsetof] 750 | MOV(32, MDisp(RCPU, offsetof(ARM, R[15])), Imm32(R15)); | ^ D:/msys64/home/User/KHDays_FM/src/ARMJIT_x64/ARMJIT_Compiler.cpp:753:46: warning: 'offsetof' within non-standard-layout type 'ARM' is conditionally-supported [-Winvalid-offsetof] 753 | MOV(32, MDisp(RCPU, offsetof(ARM, CodeCycles)), Imm32(CurInstr.CodeCycles)); | ^ D:/msys64/home/User/KHDays_FM/src/ARMJIT_x64/ARMJIT_Compiler.cpp:754:46: warning: 'offsetof' within non-standard-layout type 'ARM' is conditionally-supported [-Winvalid-offsetof] 754 | MOV(32, MDisp(RCPU, offsetof(ARM, CurInstr)), Imm32(CurInstr.Instr)); | ^ D:/msys64/home/User/KHDays_FM/src/ARMJIT_x64/ARMJIT_Compiler.cpp:845:38: warning: 'offsetof' within non-standard-layout type 'ARM' is conditionally-supported [-Winvalid-offsetof] 845 | ADD(32, MDisp(RCPU, offsetof(ARM, Cycles)), Imm32(ConstantCycles)); | ^ D:/msys64/home/User/KHDays_FM/src/ARMJIT_x64/ARMJIT_Compiler.cpp: In member function 'void ARMJIT:: Compiler::Comp_AddCycles_C(bool)': D:/msys64/home/User/KHDays_FM/src/ARMJIT_x64/ARMJIT_Compiler.cpp:868:38: warning: 'offsetof' within non-standard-layout type 'ARM' is conditionally-supported [-Winvalid-offsetof] 868 | ADD(32, MDisp(RCPU, offsetof(ARM, Cycles)), Imm8(cycles)); | ^ D:/msys64/home/User/KHDays_FM/src/ARMJIT_x64/ARMJIT_Compiler.cpp: In member function 'void ARMJIT:: Compiler::Comp_AddCycles_CI(u32)': D:/msys64/home/User/KHDays_FM/src/ARMJIT_x64/ARMJIT_Compiler.cpp:880:38: warning: 'offsetof' within non-standard-layout type 'ARM' is conditionally-supported [-Winvalid-offsetof] 880 | ADD(32, MDisp(RCPU, offsetof(ARM, Cycles)), Imm8(cycles)); | ^ D:/msys64/home/User/KHDays_FM/src/ARMJIT_x64/ARMJIT_Compiler.cpp: In member function 'void ARMJIT:: Compiler::Comp_AddCycles_CI(Gen::X64Reg, int)': D:/msys64/home/User/KHDays_FM/src/ARMJIT_x64/ARMJIT_Compiler.cpp:894:38: warning: 'offsetof' within non-standard-layout type 'ARM' is conditionally-supported [-Winvalid-offsetof] 894 | ADD(32, MDisp(RCPU, offsetof(ARM, Cycles)), R(RSCRATCH)); | ^ D:/msys64/home/User/KHDays_FM/src/ARMJIT_x64/ARMJIT_Compiler.cpp:899:38: warning: 'offsetof' within non-standard-layout type 'ARM' is conditionally-supported [-Winvalid-offsetof] 899 | ADD(32, MDisp(RCPU, offsetof(ARM, Cycles)), R(i)); | ^ D:/msys64/home/User/KHDays_FM/src/ARMJIT_x64/ARMJIT_Compiler.cpp: In member function 'void ARMJIT:: Compiler::Comp_AddCycles_CDI()': D:/msys64/home/User/KHDays_FM/src/ARMJIT_x64/ARMJIT_Compiler.cpp:937:42: warning: 'offsetof' within non-standard-layout type 'ARM' is conditionally-supported [-Winvalid-offsetof] 937 | ADD(32, MDisp(RCPU, offsetof(ARM, Cycles)), Imm8(cycles)); | ^ D:/msys64/home/User/KHDays_FM/src/ARMJIT_x64/ARMJIT_Compiler.cpp: In member function 'void ARMJIT:: Compiler::Comp_AddCycles_CD()': D:/msys64/home/User/KHDays_FM/src/ARMJIT_x64/ARMJIT_Compiler.cpp:981:38: warning: 'offsetof' within non-standard-layout type 'ARM' is conditionally-supported [-Winvalid-offsetof] 981 | ADD(32, MDisp(RCPU, offsetof(ARM, Cycles)), Imm8(cycles)); | ^ [59/138] Building CXX object src/CMakeFiles/core.dir/ARMJIT.cpp.obj In file included from D:/msys64/mingw64/include/stdint.h:32, from D:/msys64/mingw64/lib/gcc/x86_64-w64-mingw32/13.1.0/include/stdint.h:9, from D:/msys64/home/User/KHDays_FM/src/types.h:22, from D:/msys64/home/User/KHDays_FM/src/ARMJIT.h:22, from D:/msys64/home/User/KHDays_FM/src/ARMJIT.cpp:19: D:/msys64/home/User/KHDays_FM/src/ARMJIT.cpp:51:24: warning: 'offsetof' within non-standard-layout type 'ARM' is conditionally-supported [-Winvalid-offsetof] 51 | static_assert(offsetof(ARM, CPSR) == ARM_CPSR_offset, ""); | ^ D:/msys64/home/User/KHDays_FM/src/ARMJIT.cpp:52:24: warning: 'offsetof' within non-standard-layout type 'ARM' is conditionally-supported [-Winvalid-offsetof] 52 | static_assert(offsetof(ARM, Cycles) == ARM_Cycles_offset, ""); | ^ D:/msys64/home/User/KHDays_FM/src/ARMJIT.cpp:53:24: warning: 'offsetof' within non-standard-layout type 'ARM' is conditionally-supported [-Winvalid-offsetof] 53 | static_assert(offsetof(ARM, StopExecution) == ARM_StopExecution_offset, ""); | ^ ninja: build stopped: subcommand failed.

[vitor251093]

This seems to be the real issue:

D:/msys64/home/User/KHDays_FM/src/GPU3D_TexcacheOpenGL.cpp:30:38: error: cannot convert 'const std: :filesystem::__cxx11::path::value_type' {aka 'const wchar_t'} to 'const char' in initialization 30 | const char path = fullPath.c_str();

That doesn't give any issues in my computer, but it may be due to a different version of C++, or something like that. Let me create a pull request to master. That will be enough to trigger a GitHub build, and it may give us some light.

[sandwichwater]

huh , seems to give an error here too , with the same "FAILED: src/CMakeFiles/core.dir/GPU3D_TexcacheOpenGL.cpp.obj" message too

[vitor251093]

Indeed. For some confusing reason, that casting works on Linux, but not on Windows. I'm gonna need to investigate it further

[vitor251093]

I just discovered that the alpha value in those images is 31, while the usual max for a PNG is 255.

I thought "maybe the NDS only supports an alpha value between 0 and 31 (5 bits) instead of the usual 0 to 255 (8 bits)?", and tried ccomparing the bits of the exported images when compared to screenshots of the game.

Turns out that was the case. R, G and B have 6 bits, while alpha has 5 bits.

I've made the adjusts manually, while loading and exporting, and that was the result:

So, yeah... I think we can now try to replace the textures with new ones.

[sandwichwater]

thats great news , is the windows version still bugged ¿

[vitor251093]

The last Windows build did complete, so it should be fixed by now.

During my tests, I've managed to edit textures and see the changes reflected ingame (like turning the small crown in the intro red), but I've only managed to replace textures from the intro if they have the exact same size. If the size is different, it doesn't work.

It might be related with the shader, but I'm not sure.

[vitor251093]

I also didn't manage to extract textures from 2D scenes yet. Only from 3D ones.

Because of that, the only textures I had acccess to from the intro were the ones from the game logo animation.

[vitor251093]

The last Windows build did complete, so it should be fixed by now.

Nevermind that. The method was broken. I still need to fix it

[sandwichwater]

ah no worries , best to have it functional without the texture limit than to rush it , its super exciting either way

[vitor251093]

Good news: I managed to replace textures with new ones with different resolutions. As far as I can say, any size should work.

Although, I'm having problems with some transparency levels. I think the logic behind the transparency values may be more complicated then what I originally presumed.

Still, the ingame textures that are loaded in 3D scenes can already be replaced with new ones. At first I was trying to replace the images from the intro, but those are hard to take a good screenshot to show, so I will replace part of the ingame HUD.

[sandwichwater]

that is huge news , thats honestly really exciting , though im guessing the windows build is still having issues ¿

[vitor251093]

My last commit may fix the Windows issue, but I won't be able to test it myself.

Create a folder called "textures" in the project folder (alongside the README.md file), and it should work normally.

Regarding the texture replacement, unfortunately my fix doesn't seem to work on every single situation. Some textures are replaceable with textures with a bigger size (like the intro textures) and some are not (like the counter on the top left of the screen, while doing a mission).

I suppose this depends on the kind of texture, but still, it's just a matter of time until we can figure out how to cover all the scenarios.

[vitor251093]

The game intro, with high resolution crown and high resolution "Kingdom Hearts", but with poor transparency detection.

[sandwichwater]

so , it does work (yippee) , though replaced textures dont seem to be correctly placed , for example if i edit one texture itll get replaced , just with another texture in the folder , and seems to get randomized every time the scene is reloaded as well

also doesnt seem like 2d elements get dumped yet , just 3d ones or ones that are in a 3d space (panels , menu logo , models , heart points , days counter , off the top of my head)

[sandwichwater]

for example if i edit one texture itll get replaced , just with another texture in the folder , and seems to get randomized every time the scene is reloaded as well

did a bit of testing and it seems like its because its because every texture is assigned a different hash each time the texture//game is loaded , ive edited the kingdom key texture three times now with three different hashes and every time i reload the game the ds res texture gets dumped with a completely different hash as the others . this is also why other custom textures are randomized , for example the kingdom key texture is assigned to roxas hair textures

also experiencing some crashes when trying to load textures , i almost guessed it was memory issues but that doesnt seem to be the case as i replaced the kingdom key texture just fine with no crashes . whatever the case is , its still a work in progress so its understandable

[vitor251093]

also doesnt seem like 2d elements get dumped yet , just 3d ones or ones that are in a 3d space (panels , menu logo , models , heart points , days counter , off the top of my head)

Yup, this is what I was refering to before when I said "I also didn't manage to extract textures from 2D scenes yet. Only from 3D ones.". That didn't change unfortunately.

did a bit of testing and it seems like its because its because every texture is assigned a different hash each time the texture//game is loaded

Yeah, I guess using the "key" value as the identifier wasn't the best idea. I just replaced it with a hash of the bytes of the original texture, so that may be fine grained enough.

also experiencing some crashes when trying to load textures , i almost guessed it was memory issues but that doesnt seem to be the case as i replaced the kingdom key texture just fine with no crashes . whatever the case is , its still a work in progress so its understandable

Weird. That's an issue I didn't face. Was there any specific texture that caused that?

[sandwichwater]

Yup, this is what I was refering to before when I said "I also didn't manage to extract textures from 2D scenes yet. Only from 3D ones."

ohhh i understand now , thought you meant for just the 2d cutscenes , my apologies then

Was there any specific texture that caused that?

nope , happened for most of the textures i replaced , on the off chance it did actually load it didnt load the correct texture

[vitor251093]

The latest build should be more stable regarding texture replacement. Also, I managed to replace textures from 3D scenarios, like keyblades, even with different sizes.

I still didn't solve the alpha bug though. That will be my priority right now.

[vitor251093]

Alpha channel bug fixed. I was calculating the 5-bit value of alpha like this: (alpha + 1 >> 3) - 1

But it turns out this causes an integer overflow if the value is below 8. I honestly don't know why I made that calculation so complicated. Now it's like this: alpha >> 3

So with the exception of some UI elements, which seem to be cropped, the textures in 3D scenarios can be properly replaced now.

[vitor251093]

Now that's more like it

The "Kingdom Hearts" logo isn't perfectly cropped (I'm no designer, just did the best I could with the resources I could find), but it's a step in the right direction

[vitor251093]

I've added both those images (the crown and the "Kingdom Hearts" logo) to the repository, so now anyone can reproduce this result.

I've also split the texture folder that is loaded by the game from the one where the exported textures are placed, so now it's easier to determine which textures are being overriden.

I've also added a placeholder file to the tmp folder, so the folder is automatically created.

[sandwichwater]

hmm ... still crashing after i add textures , if it makes any difference , theyre twilight town world textures

[sandwichwater]

actually , it seems like its just any world texture , i can replace model and item textures just fine , but when it comes to world textures the game just crashes if its over native res

[vitor251093]

Well, I haven't tried to replace world textures yet, so I can't say for sure if I can replicate that issue. With that said...

Who wants a remastered Kingdom Key?

[sandwichwater]

honestly remastered kingdom key was the first thing i did too😅 looks so natural and makes the texture look less flat as opposed to its native res texture

[vitor251093]

actually , it seems like its just any world texture , i can replace model and item textures just fine , but when it comes to world textures the game just crashes if its over native res

Well, I did manage to replace the texture of a wall from the map above, but it was glitching.

Also, important warning: from what I can tell, both the image width and height MUST be multiples of two (and two only), and they MUST be at least 8x8. So the width/height can only be 8, 16, 32, 64, 128, 256, 512 or 1024 (I also have my reasons to believe that a number bigger than 1024 may also fail, but honestly I didn't try).

[sandwichwater]

from what I can tell, both the image width and height MUST be multiples of two (and two only), and they MUST be at least 8x8. So the width/height can only be 8, 16, 32, 64, 128, 256, 512 or 1024 (I also have my reasons to believe that a number bigger than 1024 may also fail, but honestly I didn't try).

thats good to know actually , ill have to check the dimensioms of the textures i was trying when i get home and see if it still causes crashes

[vitor251093]

A reminder for myself: the font used in the Day Counter scenes is very close to (if not the same as) Garamond Medium Extra Narrow Oblique.

https://www.myfonts.com/products/urw-garamond-t-medium-extra-narrow-oblique-garamond-333576

It should be easy to get high quality renderings of the numbers.

EDIT: And here it is. In game font:

High quality font:

[vitor251093]

Done. The Day Counter now has high quality numbers.

[sandwichwater]

from what I can tell, both the image width and height MUST be multiples of two (and two only), and they MUST be at least 8x8. So the width/height can only be 8, 16, 32, 64, 128, 256, 512 or 1024 (I also have my reasons to believe that a number bigger than 1024 may also fail, but honestly I didn't try).

thats good to know actually , ill have to check the dimensioms of the textures i was trying when i get home and see if it still causes crashes

so im back and was able to test this , tried replacing a 32x32 texture with a 64x64 one and still crashes , very odd

[vitor251093]

Very weird indeed. Maybe it's a Windows only issue?

Does any of textures that I've included in the repo also cause a crash?

[sandwichwater]

nope , which is even weirder , just seems to be environmental textures

[vitor251093]

I won't be able to make more progress today, but I will update this issue so it's specifically focused in textures from the DS 3D renderer, and create a new one for the textures being loaded by the 2D renderer, since the 3D ones no longer require a melonDS update.

EDIT: New issue for textures loaded by the 2D GPU: https://github.com/vitor251093/KHDays_FM/issues/26

[vitor251093]

nope , which is even weirder , just seems to be environmental textures

Can you give me an example of a file that is causing that? If I can reproduce it, I may be able to fix it

[sandwichwater]

sure , these were the files i used ripped from kh2 :

ive also encountered another issue when replacing gems , some sort of transparency issue ¿

even though transparency with munny and hp works just fine

[vitor251093]

It tried replacing the welcome poster, but first made a comparison with the ingame texture.

I'm not sure if that was the cause of the error, but by simple leaving the orange block untouched, the poster was properly recognized.

Although, for some reason, that caused some issue with the heart on the top left corner.

[sandwichwater]

interesting , i just tried it again and youre right the poster atleast does work . mustve just assumed it didnt work as i did try it in a group of others which caused crashes , did the other textures give any issue ¿

Although, for some reason, that caused some issue with the heart on the top left corner.

ive noticed this happens too based on where youre looking oddly enough , i can upload a video showing what exactly is happening too

[vitor251093]

did the other textures give any issue ¿

I didn't try any of the others yet. That grass is from the secret passage in Twilight Town, right?

ive noticed this happens too based on where youre looking oddly enough , i can upload a video showing what exactly is happening too

Sure. I think this is directly related to multiple replacement textures with the same size being on screen at the same time (in that case, 256x256 textures), but I'm not sure.

[sandwichwater]

That grass is from the secret passage in Twilight Town, right?

yep , and the forest and mansion areas

[vitor251093]

With this one, I could reproduce the crash. Analysing that scenario.