Hacking Wii U Hacking & Homebrew Discussion

[[Truth]]

If they made it open source we would have had it ages ago, I called closed source selfish, no different to console emulators

Sent from my SM-G900F using Tapatalk

You know nothing about anything, you didn´t even read the posts by the devs of the last pages.
Please go away.

 

[Zulnoth]

Can confirm guys, paper Mario color splash (at least in the Australian market) is our first 5.5.1 game disc update.

 

[shinyquagsire23]

My GX2 texture2D sample has been updated to allow for per-vertex colors (repo at https://github.com/shinyquagsire23/gx2texture2D), big thanks to @ExJam for doing the modifications to texture2D.gsh to make this possible. Basically this means that you can now do things like this with a single texture:

In practicality, it allows for colored bitmap fonts, better transitions due to being able to set alpha transparency, etc. Making a basic 2D game or application using this is fairly trivial. I also added templates for code/ and meta/ to the repo, so building a Loadiine and native-ready applications should be fairly straightforward when other things drop.

 

[dimok]

I took a quick peek into the source code of the new texture2D example and I am sorry to say that but changing the attribute during the render process on each frame, flushing it and passing it over to the GPU isn't very efficient. I don't think it is intended to be used like that. I am not sure how much you can scale that concept up and how many textures you would be able to draw at the same time before frame rate starts to drop quickly. The problem in that are mainly the GX2Invalidate calls which halt the CPU until the memory is flushed out and the GPU can't use that memory before its out of the CPU cache either and you cant go around those calls. But texture2D.gsh does not offer a uniform for it so I understand why you have to do it that way. Though I think I found a better shader that can be freely used and it's right under our nose in mii maker. I think it could offer us all we need judging by the shader parameter names and types. I did not yet use it though so I can't say I am 100% sure but it looks promising.

Anyway. I had a bit of time on the weekend and ported the HBL source code to use the WUT toolchain and be build as RPX. I had to modify several parts of the toolchain though. Mostly small things though.

The first thing that went wrong is that the LIBPATH gets overwritten by WUT, so I made a workaround that with a 2nd env variable.

The second thing that went wrong is the following part:

/opt/devkitPPC/bin/../lib/gcc/powerpc-eabi/4.8.2/../../../../powerpc-eabi/bin/ld: section .gcc_except_table loaded at [01000000,010015a3] overlaps section .lib.rplLibs loaded at [01000000,0100003b]
/opt/devkitPPC/bin/../lib/gcc/powerpc-eabi/4.8.2/../../../../powerpc-eabi/bin/ld: section .got loaded at [01000040,0100004f] overlaps section .gcc_except_table loaded at [01000000,010015a3]
/opt/devkitPPC/bin/../lib/gcc/powerpc-eabi/4.8.2/../../../../powerpc-eabi/bin/ld: section .gcc_except_table._ZN7CThreadD2Ev loaded at [010015a4,010015a7] overlaps section .rela.dyn loaded at [010002a0,01004dc3]
/opt/devkitPPC/bin/../lib/gcc/powerpc-eabi/4.8.2/../../../../powerpc-eabi/bin/ld: section .rela.rodata loaded at [01004de0,010111cf] overlaps section .gcc_except_table._ZNSt13basic_fstreamIwSt11char_traitsIwEEC1ERKSsSt13_Ios_Openmode loaded at [01004dc9,01004de8]
/opt/devkitPPC/bin/../lib/gcc/powerpc-eabi/4.8.2/../../../../powerpc-eabi/bin/ld: section .gcc_except_table._ZNSt13basic_fstreamIwSt11char_traitsIwEED2Ev loaded at [01004de9,01004dec] overlaps section .rela.rodata loaded at [01004de0,010111cf]

The C++ exception table section is missing. That isnt very surprising as you already said that you only use C. So that could happen of course. Once I added that section to the linker file the ELF file compiled and I got an elf2rpl issue. Paddings of libs or C++ were causing issues and i get unexpected rela.dyn type errors. So I added an ignore in there for the elf::R_PPC_NONE case. That made the RPX finally compile. Once I tried to load it I had loader issues, mainly 160-2203, linking issues. Checking what's wrong I found out that nsysnet has several bugs in it. Fixing those finally got the RPX to boot.

I will fork WUT and do a pull request tommorow in the evening as I didnt have time for it today. All in all I must say the way that the libraries are linked is really nice made and the elf2rpl tool is some great tool exjam made. No more 3 instructions function calls ! Though there are some changes I would like to suggest in the linker file and the default/include make files. For example I am not sure why it does not discard unneeded sections and does a garbage collection or why the header dependencies are not activated and you have clean to recompile changes done in headers. Those parts I would rather discuss elsewhere though.

So thats about it and now I have HBL as RPX which works great. The next step is to add actual RPX booting from the RPX HBL ;-).

 

[shinyquagsire23]

I took a quick peek into the source code of the new texture2D example and I am sorry to say that but changing the attribute during the render process on each frame, flushing it and passing it over to the GPU isn't very efficient. I don't think it is intended to be used like that. I am not sure how much you can scale that concept up and how many textures you would be able to draw at the same time before frame rate starts to drop quickly. The problem in that are mainly the GX2Invalidate calls which halt the CPU until the memory is flushed out and the GPU can't use that memory before its out of the CPU cache either and you cant go around those calls. But texture2D.gsh does not offer a uniform for it so I understand why you have to do it that way. Though I think I found a better shader that can be freely used and it's right under our nose in mii maker. I think it could offer us all we need judging by the shader parameter names and types. I did not yet use it though so I can't say I am 100% sure but it looks promising.

Anyway. I had a bit of time on the weekend and ported the HBL source code to use the WUT toolchain and be build as RPX. I had to modify several parts of the toolchain though. Mostly small things though.

The first thing that went wrong is that the LIBPATH gets overwritten by WUT, so I made a workaround that with a 2nd env variable.

The second thing that went wrong is the following part:

/opt/devkitPPC/bin/../lib/gcc/powerpc-eabi/4.8.2/../../../../powerpc-eabi/bin/ld: section .gcc_except_table loaded at [01000000,010015a3] overlaps section .lib.rplLibs loaded at [01000000,0100003b]
/opt/devkitPPC/bin/../lib/gcc/powerpc-eabi/4.8.2/../../../../powerpc-eabi/bin/ld: section .got loaded at [01000040,0100004f] overlaps section .gcc_except_table loaded at [01000000,010015a3]
/opt/devkitPPC/bin/../lib/gcc/powerpc-eabi/4.8.2/../../../../powerpc-eabi/bin/ld: section .gcc_except_table._ZN7CThreadD2Ev loaded at [010015a4,010015a7] overlaps section .rela.dyn loaded at [010002a0,01004dc3]
/opt/devkitPPC/bin/../lib/gcc/powerpc-eabi/4.8.2/../../../../powerpc-eabi/bin/ld: section .rela.rodata loaded at [01004de0,010111cf] overlaps section .gcc_except_table._ZNSt13basic_fstreamIwSt11char_traitsIwEEC1ERKSsSt13_Ios_Openmode loaded at [01004dc9,01004de8]
/opt/devkitPPC/bin/../lib/gcc/powerpc-eabi/4.8.2/../../../../powerpc-eabi/bin/ld: section .gcc_except_table._ZNSt13basic_fstreamIwSt11char_traitsIwEED2Ev loaded at [01004de9,01004dec] overlaps section .rela.rodata loaded at [01004de0,010111cf]

The C++ exception table section is missing. That isnt very surprising as you already said that you only use C. So that could happen of course. Once I added that section to the linker file the ELF file compiled and I got an elf2rpl issue. Paddings of libs or C++ were causing issues and i get unexpected rela.dyn type errors. So I added an ignore in there for the elf::R_PPC_NONE case. That made the RPX finally compile. Once I tried to load it I had loader issues, mainly 160-2203, linking issues. Checking what's wrong I found out that nsysnet has several bugs in it. Fixing those finally got the RPX to boot.

I will fork WUT and do a pull request tommorow in the evening as I didnt have time for it today. All in all I must say the way that the libraries are linked is really nice made and the elf2rpl tool is some great tool exjam made. No more 3 instructions function calls ! Though there are some changes I would like to suggest in the linker file and the default/include make files. For example I am not sure why it does not discard unneeded sections and does a garbage collection or why the header dependencies are not activated and you have clean to recompile changes done in headers. Those parts I would rather discuss elsewhere though.

So thats about it and now I have HBL as RPX which works great. The next step is to add actual RPX booting from the RPX HBL ;-).

Yeah I know like, very little with GPU stuff to be honest, not really my thing but I needed it to make things run decent. In my current installer deal I'm rendering about 300 quads (not really quads but idk what else to call it) on average and it can keep 60FPS, so it's not awful to be honest. I looked around at other shaders but a lot of it is over my head and I just wanted something basic.

As for elf2rpl, I don't think it's been tested with C++ at all, and very few people have messed with it with more complex applications. The whole thing is an awful hack though, has to work around a crapton of stuff between GCC and what loader.elf wants. The rewrite branch is nicer since it takes a lot of what elf2rpl does with imports and exports and handles it with another tool, but there's no good way to get GCC to do what is needed for actually generating relocations and other things. I think Clang was being looked at for a bit since it's more flexible, but hasn't happened yet. Still better than .elf in my opinion, but not the best. Changes with the current branch are still good though because I don't think the rewrite branch will get merged for a while.

 

[dimok]

Yeah I know like, very little with GPU stuff to be honest, not really my thing but I needed it to make things run decent. In my current installer deal I'm rendering about 300 quads (not really quads but idk what else to call it) on average and it can keep 60FPS, so it's not awful to be honest. I looked around at other shaders but a lot of it is over my head and I just wanted something basic.

As for elf2rpl, I don't think it's been tested with C++ at all, and very few people have messed with it with more complex applications. The whole thing is an awful hack though, has to work around a crapton of stuff between GCC and what loader.elf wants. The rewrite branch is nicer since it takes a lot of what elf2rpl does with imports and exports and handles it with another tool, but there's no good way to get GCC to do what is needed for actually generating relocations and other things. I think Clang was being looked at for a bit since it's more flexible, but hasn't happened yet. Still better than .elf in my opinion, but not the best. Changes with the current branch are still good though because I don't think the rewrite branch will get merged for a while.

Nice 300 quads is not too bad actually. It's not much but for a 2D GUI and some 2D games that could be enough. It's really hacky though what you guys though of haha. Btw that other shader I was talking about was in FFLShader.gsh in mii maker. Actually it has quite a lot of shaders in it from what I saw but there is one pair of vertex and pixel shader that can be used together that looked very promising. There was a projection and modelview matrix as uniform in there and a few color vector uniforms for the pixel shader. So this would allow even 3D rendering. The attributes offer more than actually needed. I saw tangents and normals in there, so I think we can actually do some basic lighting effects with it but well I am not a 3D graphics programmer as well and thats something I am not very familiar with yet either and I would need to look at how that is done on opengl first too. But that is something for a future project maybe, first thing would be to actually do the basic rendering with it .

 

[the_randomizer]

I just wish that emulator porting would catch the interest of others, or that the Wii U wasn't such a pain in the arse to code for when it comes to porting; Snes9x 1.54 was just released, I have no doubts that the Wii U can handle that version without a hitch given its increase in accuracy. The problem again, lack of interest and/or the sheer complexity of porting it over

 

[VinsCool]

I just wish that emulator porting would catch the interest of others, or that the Wii U wasn't such a pain in the arse to code for when it comes to porting; Snes9x 1.54 was just released, I have no doubts that the Wii U can handle that version without a hitch given its increase in accuracy. The problem again, lack of interest and/or the sheer complexity of porting it over

Don't worry foxman. It will come, someday

 

[proflayton123]

Don't worry foxman. It will come, someday

Once IOSU-senpai is exploited, I'm sure to see people having interest in things


Sent from my iPhone using Tapatalk

 

[the_randomizer]

Don't worry foxman. It will come, someday

But how do we know? The RetroArch devs sure as heck don't have interest in porting it over to the Wii U, they said so themselves on the Libretro forums There's little to no interest in emulator development for the Wii U; there's so much potential, it can run DS emulators full speed, PSP wouldn't be too far off, but...I just don't know. C'est la vie.

Once IOSU-senpai is exploited, I'm sure to see people having interest in things


Sent from my iPhone using Tapatalk

Contrary to belief, one doesn't need IOSU to get full kernel access for emulators, this can already be done. It would make it somewhat easier, but it's not required.

 

[DeslotlCL]

But how do we know? The RetroArch devs sure as heck don't have interest in porting it over to the Wii U, they said so themselves on the Libretro forums There's little to no interest in emulator development for the Wii U; there's so much potential, it can run DS emulators full speed, PSP wouldn't be too far off, but...I just don't know. C'est la vie.



Contrary to belief, one doesn't need IOSU to get full kernel access for emulators, this can already be done. It would make it somewhat easier, but it's not required.

Homebrew emulators aren't the top priority right now, since you can already run injected roms on the nintendo's official vc emulators.

 

[the_randomizer]

Homebrew emulators aren't the top priority right now, since you can already run injected roms on the nintendo's official vc emulators.

Which are subpar IMHO, the GBA and DS emulators are fantastic and highly compatible; the Snes, NES, N64 are pretty dismal compat-wise; emulation inaccuracies aside, they don't work with a lot of games, have bad color palettes, filtering issues, no SuperFX or HiROM support, the list goes on. Snes emulation on the Wii U is pretty garbage, N64 can't even get DK64's sound right. Snes9x would be ideal, RA would be as well.

 

[DeslotlCL]

Which are subpar IMHO, the GBA and DS emulators are fantastic and highly compatible; the Snes, NES, N64 are pretty dismal compat-wise; emulation inaccuracies aside, they don't work with a lot of games, have bad color palettes, filtering issues, no SuperFX or HiROM support, the list goes on. Snes emulation on the Wii U is pretty garbage, N64 can't even get DK64's sound right. Snes9x would be ideal, RA would be as well.

I know, but is still one of the reasons. I hate to say this, but IOSU is the last hope to keep the scene alive and the thing is, that almost all of that support will come from dirty entitled pirates.

 

[proflayton123]

I know, but is still one of the reasons. I hate to say this, but IOSU is the last hope to keep the scene alive and the thing is, that almost all of that support will come from dirty entitled pirates.

"Dirty entitled pirates" well some of those pirates make it quite a useful thing in the long run


Sent from my iPhone using Tapatalk

 

[FlappyFalco]

I know, but is still one of the reasons. I hate to say this, but IOSU is the last hope to keep the scene alive and the thing is, that almost all of that support will come from dirty entitled pirates.

They're not "dirty entitled pirates" if they contribute!

 

[proflayton123]

They're not "dirty entitled pirates" if they contribute!

Exactly


Sent from my iPhone using Tapatalk

 

[Quantumcat]

Which are subpar IMHO, the GBA and DS emulators are fantastic and highly compatible; the Snes, NES, N64 are pretty dismal compat-wise; emulation inaccuracies aside, they don't work with a lot of games, have bad color palettes, filtering issues, no SuperFX or HiROM support, the list goes on. Snes emulation on the Wii U is pretty garbage, N64 can't even get DK64's sound right. Snes9x would be ideal, RA would be as well.

What's wrong with N64 injects? Emulation on the Wii is terrible, DK64 can't get past the title screen and Banjo-Kazooie had random white textures and laggy sound. As an inject it runs perfectly, just as good as the original running on an N64. And even better really - I'd prefer to play it on Wii U with save states. Means in Banjo-Kazooie I only have to visit each world once to get all puzzle pieces and notes!! (Curse my dad for marching into the loungeroom at 6pm on the dot every evening and switching off the N64 and never giving us a chance to save...... Even though he could easily leave it on while he watched the news....)

 

[pedro702]

What's wrong with N64 injects? Emulation on the Wii is terrible, DK64 can't get past the title screen and Banjo-Kazooie had random white textures and laggy sound. As an inject it runs perfectly, just as good as the original running on an N64. And even better really - I'd prefer to play it on Wii U with save states. Means in Banjo-Kazooie I only have to visit each world once to get all puzzle pieces and notes!! (Curse my dad for marching into the loungeroom at 6pm on the dot every evening and switching off the N64 and never giving us a chance to save...... Even though he could easily leave it on while he watched the news....)

compatibility is crap, while some games work perfectly most games dont work at all.

 

[DeslotlCL]

You guys know what i'm saying. Obviously there will be that small group of developers that will actually make and release cool stuff, but you cant denny this forum will be invaded with people asking for backups or how even can they get them to work.

 

[the_randomizer]

What's wrong with N64 injects? Emulation on the Wii is terrible, DK64 can't get past the title screen and Banjo-Kazooie had random white textures and laggy sound. As an inject it runs perfectly, just as good as the original running on an N64. And even better really - I'd prefer to play it on Wii U with save states. Means in Banjo-Kazooie I only have to visit each world once to get all puzzle pieces and notes!! (Curse my dad for marching into the loungeroom at 6pm on the dot every evening and switching off the N64 and never giving us a chance to save...... Even though he could easily leave it on while he watched the news....)

The games themselves work fine, but compatibility is low and most injects don't work well; DK64 runs fine too, the problem is the emulator uses linear audio interpolation, whereas other emulators, even PJ64 gets it right; the audio sounds raspy in Rare games. They use Gaussian interpolation in the real hardware, not linear, bad choice on their part. The forced 4:3 is something I don't like, I should be able to force-stretch it to fill the black borders; Mupen 64 would be so much better. 512 mbit ROMs don't even work on Wii U.