Homebrew Citro3DS texture format

[Urbanshadow]

Hi all!

I was digging into citro3d lately and I'm finding problems converting image data to the bin format required for citro3d. I used some tools and scripts for this but the texture always looks bugged. I wrote a converting tool myself with lodepng and at least I got the colors right, but looks scrambled (has something to do with the tiled texture format, which I tried to reproduce, without much success).

Does anyone know a tool/way to convert textures to the citro3ds texture format? Bonus points for alpha support.

 

[TheCruel]

I started a small texture convert tool project (which I currently only use for ETC1 texture conversion) that I should probably put on github sometime. Would be nice to have a texture converter in toolchain. Anyways, don't now have time for that, and it doesn't support most formats, so it wouldn't be useful yet.

In the meantime, everyone seems to be doing texture conversion during runtime, see the example.

What you're probably looking for is the "C3D_SafeDisplayTransfer" with the appropriate flags that tile the image for you.

EDIT: also, it's just called "citro3d"

 

[Urbanshadow]

I started a small texture convert tool project (which I currently only use for ETC1 texture conversion) that I should probably put on github sometime. Would be nice to have a texture converter in toolchain. Anyways, don't now have time for that, and it doesn't support most formats, so it wouldn't be useful yet.

In the meantime, everyone seems to be doing texture conversion during runtime, see the example.

What you're probably looking for is the "C3D_SafeDisplayTransfer" with the appropriate flags that tile the image for you.

EDIT: also, it's just called "citro3d"

Uhmm. I tried it with GX_DISPLAYTRANSFER, like it is used by the graphics/gpusprites example from devkitpro and citra crashed. I'll try this one.

And yeah, I keep making that typo. Idk. Thanks for pointing it.

EDIT: Well, i have updated libctru and citro3d to the last commit and I got this C3D_SafeDisplayTransfer available but it still crashes citra. The system does not crash, but the texture won't show up at all. uhm...

 

[TheCruel]

Well, if you compile and run the gpusprite example, I'm sure it works. Use that as a reference to figure out what's wrong. You're probably doing something else wrong, I have no way of telling.

 

[elhobbs]

Well, if you compile and run the gpusprite example, I'm sure it works. Use that as a reference to figure out what's wrong. You're probably doing something else wrong, I have no way of telling.

Or citra has not implemented tiled texture in the transfer engine for texture copies. Citra is in development - there is tons of stuff that either works when it should not or does not work when it should.

 

[TheCruel]

Or citra has not implemented tiled texture in the transfer engine for texture copies. Citra is in development - there is tons of stuff that either works when it should not or does not work when it should.

I pretty sure it does have that, but you're right that there are tons of things that don't work on citra. Regardless, he says the textures doesn't show up on his console either, so something's wrong, but could be several things.

 

[Urbanshadow]

I pretty sure it does have that, but you're right that there are tons of things that don't work on citra. Regardless, he says the textures doesn't show up on his console either, so something's wrong, but could be several things.

Yeah the example actually runs "well" (low fps) on citra. I think I'm having positional problems or letting something uninitialized. I'd really like to skip texture translation though...

 

[elhobbs]

Yeah the example actually runs "well" (low fps) on citra. I think I'm having positional problems or letting something uninitialized. I'd really like to skip texture translation though...

Does loadpng support the format you are using to store your png files? I want to say I have seen some loadpng code around (maybe something from smea) that only worked with 24bit pngs.

 

[Urbanshadow]

Does loadpng support the format you are using to store your png files? I want to say I have seen some loadpng code around (maybe something from smea) that only worked with 24bit pngs.

I'm using the ballsprites.png provided with the gpusprites example. The gpusprites example uses the lodepng code to load the texture and since the example runs ok on citra I assume that particular file has a correct format. I know for sure it expects alpha channel. The bit depth may be 24 bits, I'm not sure.

 

[elhobbs]

I'm using the ballsprites.png provided with the gpusprites example. The gpusprites example uses the lodepng code to load the texture and since the example runs ok on citra I assume that particular file has a correct format. I know for sure it expects alpha channel. The bit depth may be 24 bits, I'm not sure.

Sounds like you have that issue covered.
With the qt version of citra you can set pica break points on events. Did you try verifying that the correct vertex attributes are being received. You can also double check the texture with the command list capture - though that is a little trickier to use.

 

[Urbanshadow]

Sounds like you have that issue covered.
With the qt version of citra you can set pica break points on events. Did you try verifying that the correct vertex attributes are being received. You can also double check the texture with the command list capture - though that is a little trickier to use.

I'm not really sure the problem is in the pica part, but can be useful. I might try.

 

[Urbanshadow]

Wellp, I'm about to give up on this. It's just nonsense and I'm tired and angry.

I got C3D_SafeDisplayTransfer to magicly work once. Then, after some refactoring to clean up the mess it started to fail again. I'm just running the example code byte by byte, in a friendly context. Citra crashes with failed memory conversions. No matter what I change right now, it just keeps crashing and mumbling nonsense at my face so either I am a stupid brickhead (most probably this) or some part of these libraries is built upon happy paths.

EDIT: Just for the record... The call made in different places produces the same errors in different memory locations.

[   0.302160] HW.Memory <Error> core\memory.cpp:Memory::VirtualToPhysicalAddress:653: Unknown virtual address @ 0x00000007
[   0.304190] HW.Memory <Error> core\memory.cpp:Memory::PhysicalToVirtualAddress:671: Unknown physical address @ 0x80000000
[   0.306600] HW.Memory <Error> core\memory.cpp:Memory::GetPointer:279: unknown GetPointer @ 0x80000000

 

[TarableCode]

Paste your code so we can have a look, sometimes a fresh pair of eyes can see things that get skipped over.

 

[Urbanshadow]

After three or so hours of sleep and two more hours line by line debugging I found some non-trivial linking issues between polymorphed classes with static content declared that somehow, made C3D_SafeDisplayTransfer and GX_DisplayTransfer fail badly. It was little enough of a problem to slip between the compiler checks and actually link and build properly, but I guess the construction was flawed.

That was a hell of a problem because all syntax, semantics and construction looked fine and straightforward in two sources, yet the call to these functions failed on one and succeeded on the other. I had reached a point where the code was the same end to end, in the same order of execution and the only difference was the code architecture. Then I knew something fishy was with either the compiler or the linker with my code arch. I juggled it a bit and everything started working. I feel puzzled.