Homebrew [RELEASE] Wii-DOOM / Wii-HERETIC / Wii-HEXEN / Wii-STRIFE (ALL-IN-ONE) *PROPER*

[nitr8]

Itz possible to make these ports run on WiiU gamepad?

Unfortunately, I have no Wii U to work with... I once had one, but sold it about 2 years ago...

 

[nitr8]

nitr8 Don't know if you could do this but could you make a version of Wolfenstein 3D for the Wii? I know there is one already available but it's unfinished. If doesn't have music or some other sounds, it doesn't support classic controller, the wiimote with nun chuck controls are bad. It looks like the creator of that is done and hasn't updated it in 3 years.

Using SDL implementation, it should be possible to get it done. That would require the current source code base.

 

[nitr8]

This is the current state of the NDEV (finally arrived in germany, but not at my location for the moment).

I think, I still have to wait over the weekend.

 

[XDel]

Unfortunately, I have no Wii U to work with... I once had one, but sold it about 2 years ago...

Gesendet von meinem BLA-L29 mit Tapatalk

I have a spare Wii U, tablet and all. You can have it, free shipping.

 

[nitr8]

The package just arrived. I got it in my hands...

 

[nitr8]

I have a spare Wii U, tablet and all. You can have it, free shipping.

What would be the price?
From where are you shipping?
Is it possible to run homebrew?

 

[XDel]

What would be the price?
From where are you shipping?
Is it possible to run homebrew?

Gesendet von meinem BLA-L29 mit Tapatalk

Ohio, Free, and Yes.

I can afford to ship internationally and have before back in the day for the sake of nxDOOM for the Dreamcast, amongst other projects.

 

[nitr8]

Update to my NDEV and my DOOM port to the Wii:

I have been able to set everything up using the SDK that Ninty used for Wii programming. Unfortunately, it's really, REALLY hard to use and progress is very, VERY slow...

Though, I got my own code to compile using the SDK after fixing most of the errors, it fails at linking the objects due to the fact that libraries like SDL which has been ported to the Wii, need to be completely rewritten for use with the NDEV as those libraries are not compatible because they were compiled using devkitPro. Recompiling them with the official SDK is impossible as the official SDK users different function names that the devkitPro doesn't have.

The best solution would be to completely drop SDL support but would also mean that large parts of the code of my ports would have to be completely rewritten.

My primary goal was to be able to use my compiled devkitPro (devkitPPC) ELF with the NDEV to find out where the bugs are located so I would have been able to fix those. That means I need to find a way to get the NDEV libraries which are required for debugging via "SERIAL" connection and "USB DEBUG" convection, compiled with the devkitPro in some way somehow. I'm currently out of the most ideas that I had.

Is anyone here who ever tried using a NDEV for only debugging homebrew stuff?

The best feature of the official SDK is that it's possible to compile the code while keeping function names inside the binary. This would be a great advantage upon debugging.

Any help would be great.

 

[nitr8]

Regarding NDEV:

boot0 dumped
boot1 dumped (and decrypted)
boot1 SHA-hash dumped (it's all zeroes)
NAND dumped (and decrypted)
NAND HMAC dumped
NAND Keys dumped
ECC Private Key dumped
RNG Key dumped
OTP Base dumped
Console Serial dumped
Common Key dumped (it differs from the Wii)
Unknown Key dumped (dunno what it is for)
SEEPROM Base dumped
Korean Key dumped (it's all zeroes)
NG ID dumped
Master ID dumped
Counter 1 (#1 - #5) dumped
Counter 2 (#1 - #3) dumped
Certificate ID dumped
Root Key dumped (public half)

boot2 is still missing.

I had to use custom code for some of the dumps.
I have been able to compile Skyeye-Starlet and emulate a Wii Bootup till IOS reading from NAND. But the NDEV Bootup doesn't work this way. It crashes when trying to read from boot1 / NAND. I need to figure out, why...

Also, the SD card slot on my NDEV was broken so I had to solder some wires to the pinouts of the slot on the PCB.
It took a long time till I figured out, that the port was broken and in the first place I didn't want to open up the case of the console. But I finally did and got it solved for the time being.

See for yourself:

 

[TheDimensioner]

Nice to see this being updated! But I have a request: any chance of adding 240p support on a future update? It would be great for playing on a CRT that only has 480i support, since DOOM really doesn't look right playing like that...

I've managed 200p on a PC CRT monitor, so I can say that DOOM looks great with scanlines:

Spoiler

It would definitely look greater on a CRT TV!

 

[nitr8]

That scanlines were once featured by the Chocolate DOOM source port as far as I can remember from looking at the code...

Anyway, there's currently lots of work to do:
I'm really busy every day and working on porting the OGC library to the RVL SDK.
Though I have to admit that I'm NOT GOING TO RELEASE my work afterwards as that would most likely break some rules with Ninty.

My primary goal is getting SDL to work with the RVL SDK but that requires OGC in the first place. I've seen on some Google research someone saying in a forum that porting OGC from devkitPro / devkitPPC to the RVL SDK takes about a week - and he's definitely right. I for myself spend 8 hours each day in order to get it done. Let's just see where this leads to...

If porting over OGC, SDL and some other libraries is done, the real debugging of my Chocolate ports can start on the NDEV as I can get real code dumps then via SERIAL FT232RL connection hooked up to my development station.

Maybe I will release the ported OGC code so someone else can also compile it using the RVL SDK but i definitely won't release any precompiled binaries.

 

[TheDimensioner]

That scanlines were once featured by the Chocolate DOOM source port as far as I can remember from looking at the code.

Well, those scanlines are actually "real", since the picture was taken directly from my CRT monitor, set at [email protected] I also have a video showing the "resolution change", although this is from DOOM 3 BFG's Classic DOOM port:



Like I said on an older post, I actually don't know if the original DOOM was supposed to look like this XD. But I just love how the image looks sharp and neat, with the added bonus of no input lag whatsoever, since it's a CRT.

It's sad that you won't be able to release the work done on the devkit, but I do love what you did already with the current release. I take the Wii as a machine that "can do everything", and being able to play DOOM so smoothly already proves that point for me. But, if somehow you get to fiddle with resolution options and whatnot, please look at 240p as a possibility for it XD!

 

[ShadowOne333]

That scanlines were once featured by the Chocolate DOOM source port as far as I can remember from looking at the code...

Anyway, there's currently lots of work to do:
I'm really busy every day and working on porting the OGC library to the RVL SDK.
Though I have to admit that I'm NOT GOING TO RELEASE my work afterwards as that would most likely break some rules with Ninty.

My primary goal is getting SDL to work with the RVL SDK but that requires OGC in the first place. I've seen on some Google research someone saying in a forum that porting OGC from devkitPro / devkitPPC to the RVL SDK takes about a week - and he's definitely right. I for myself spend 8 hours each day in order to get it done. Let's just see where this leads to...

If porting over OGC, SDL and some other libraries is done, the real debugging of my Chocolate ports can start on the NDEV as I can get real code dumps then via SERIAL FT232RL connection hooked up to my development station.

Maybe I will release the ported OGC code so someone else can also compile it using the RVL SDK but i definitely won't release any precompiled binaries.

There's always those ISO sites

 

[nitr8]

There's always those ISO sites

That definitely doesn't belong here as I don't support piracy.

 

[AzzidReign]

- copy all of the directories to the "APPS" folder on your USB device

- if you want, you can install the FORWARDER WAD's corresponding to your console using YAWMM

- the main game IWAD for each game is required as well in order to get each game to run

- DO NOT RENAME THE GAME DIRECTORIES AS THESE ARE SPECIFIC TO THE SOURCE CODE

- DO NOT MOVE OR RENAME ANY OF THE FILES IN THE GAME DIRECTORIES THAT CAME WITH THIS RELEASE
(the RESOURCE PWAD's are named "psp....wad" because i re-used them from my PSP / PS VITA ports)

I think I'm missing something here. Is this what you meant?

If that's the case (don't mind this screenshots apps > apps, I took this before I made the above changes so hopefully it is correct):

I've placed my doom1/2/3.wads in the IWAD folder. And nothing is in the PWAD folder, that will be handled by your app, correct?

Really sorry, it seems others are figuring it out and I can't. So I launched HBC, pressed 1 to load from USB, clicked on the Doom app and then I get this:

Spoiler

I know I'm probably way off base with all of this and I'm missing something the others in this thread have clearly figured out. Could my problem be that I haven't installed the original Doom1.wad (I assumed no and that that's what your app was basically doing but I'm probably wrong)? Your instructions say
"GET THE GAMES RUNNING

- whenever you start one of these games, you have to point it to the main game's IWAD file"

Am I going about starting up the game wrong? HBC > select USB > Select Doom > Load (then that error above - it's trying to read from the SD rather than the USB, did I miss some sort of setting I needed to change?)

I know I'm being dumb and I really apologize for this but I've been trying to figure this out for about 2 hours now, exhausting all my trial and error (mostly error) before I'm even posting this since I hate seeing all support questions asked 100x.

I'm up to date with my IOS's, HBC, using YAWMM (and have tried MMM), using this 128gb flash drive. When I've tried selecting the USB mass storage as "Select source device" in YAWMM, I get the same error as the above screen shot (ret=-1).

 

[nitr8]

Another update:

I just compiled libOGC using the RVL_SDK but the compiler and linker sometimes they don't message back the missing errors upon missing functions. So I figured out that I need to compile everything from the base. What was missing here are libraries like libiberty and libsysbase which I'm currently porting. After that I may have a better chance in compiling libOGC and many more. Now I more and more get into the point why game developers rejected development for the Wii in the past.

Gesendet von meinem BLA-L29 mit Tapatalk

 

[nitr8]

Surprise...

Gesendet von meinem BLA-L29 mit Tapatalk

 

[ShadowOne333]

Surprise...

Gesendet von meinem BLA-L29 mit Tapatalk

Congrats on the compile with the devkit, dude

 

[XDel]

This is big!

 

[nitr8]

Slow progress, but in the end this works for me...

Gesendet von meinem BLA-L29 mit Tapatalk