It was working for me - have a look at the doom-music.cfg file as it should be in there with the previous release.
The files are listed E5M*
I just had to re-encode to Wii format, dropped the files in, wrote the code for the CFG, compiled the binary and run it: tada, OGG music for SIGIL.
Running smooth. It's incredible how much that great heavy metal OST does for the pace of the game.
Running smooth. It's incredible how much that great heavy metal OST does for the pace of the game.
Just wanted to share this cool news with some of the Doom fans here:
https://realotakugamer.com/doom-64-to-have-a-new-chapter-new-options-and-more
https://realotakugamer.com/doom-64-to-have-a-new-chapter-new-options-and-more
Freelook is included within the Wii-HERETIC binary. cou can activate from within the Controls Settings.
Ok thanks, it was disabled. My bad. it's working now.
I'd have another little request, if it's not too much trouble for you:
- can you add an option to swap the d.pad with the left stick? I find a little uncomfortable using the analog stick for walking and strafing.
If possible I'd like to have this feature for all these ports, not just Wii-Heretic.
I'd have another little request, if it's not too much trouble for you:
- can you add an option to swap the d.pad with the left stick? I find a little uncomfortable using the analog stick for walking and strafing.
If possible I'd like to have this feature for all these ports, not just Wii-Heretic.
At least that "feature" would require some massive effort in rewriting code to the controls to all of these ports as I don't even use SDL for input while those games do use SDL. I had massive problems getting SDL controls to work. Must be the SDL Wii port that isn't finished at all. The day SDL for Wii was released, only minor features actually worked - like graphics and sound. For the Wii-HEXEN II port, the graphics didn't even work and i had to fall back to some arbitrary code instead.
It wouldn't even make much sense for the amount of controls to bind for games like STRIFE. You would loose at least 4 buttons to be able to bind to some function of the game.
Last edited by nitr8,
The thing is, that Chocolate DOOM is the base for all those 4 ports.Ok nevermind then
After compiling it the first time for the Wii back in 2014 with only video and sound output, the controls didn't work and i have never figured out just why.
From what i remember, i had to drop the whole joystick code of Chocolate.
Last edited by nitr8,
That's the reason there's no support for gamecube controllers, i imagine? (hence no Gamecube port)
No.
While having that NDEV and trying to port things over to the RVL-SDK for the last 1.5 years, i came to the point and even realized fataly, that libOGC's Gamecube functionality is buggy. When reading the Gamecube PAD Status, the game will crash at some random point.
When this situation appeared for the first time, I even had it at least another second time using GCC to compile code. It even crashed there so i finally dropped it completely as i wanted to have gaming experience and no frustrating "play, crash - 'oh well...', debug, play, crash..." and so on. I didn't find the real reason for it but it seems to be some generic problem. If it would work without this crashing, I would have it implemented so I instead disabled the Gamecube code all over the libraries as well as the games where it was once included.
Last edited by nitr8,
Yeah, i can imagine. I still use old libogc versions, newer doesn't always means better or more stable.
Well, i don't even use the newest devkitpro / devkitPPC release as when i came back to porting stuff 2 years ago, i first tried to compile Wii-DOOM using the latest devkitpro / devkitPPC release at that time and it didn't even get that far to display anything on the screen.
After some research i figured out, that between release 27 and release 28, devkitPPC's headers have been patched in some non-understandable manner. Everything - every homebrew compiled up to this point was working flawlessly until there was a change on INTEGERS & LONGS within those header files.
This change made all previously working homebrew unable to work anymore when you compled them on newer releases of devkitPPC.
And the absolutely frustrating statement Wintermute therefore made, was, "UPDATE YOUR CODE". I for myself thought "F*CK YOU".
So i am currently STILL at devkitPPC release 27 with libOGC 1.8.12 and even libFAT a rather old version as well as some others. Those are old, i know - but they are running stable. So i have no reason to update anything.
NEVER TOUCH A RUNNING SYSTEM.
If you want to know something more about that change to the header variables between Release 27 and Release 28, read this:
https://devkitpro.org/viewtopic.php?f=40&t=8681
and this:
https://sourceware.org/git/gitweb.c...it;h=9bd3bcc6422473bc072d392d3e9545186b7f2211
It fatally made everything go downwards.
And i even DO understand that this makes developers upset upon Wintermute. So i DO understand even @JoostinOnline's behaviour on that thread as it also pissed me off. You would have to go through tons of code and change everything to HOPEFULLY make it work in the end.
Last edited by nitr8,
Okay, i think i finally fixed that OGG music playback "loop pause" situation. Though, the official patch to it was released by someone else posting a commit over at Chocolate DOOM's GitHub repository. That fix usually requires SDL2 v2.0.5 - or the mixer at least.
But... seemingly, it works with our Wii ports as well, which use SDL v1.2 instead.
I need to check but from what i have "heard", it's "ready-to-go".
But... seemingly, it works with our Wii ports as well, which use SDL v1.2 instead.
I need to check but from what i have "heard", it's "ready-to-go".
Similar threads
-
Xdqwerty
what are you looking at? - S salazarcosplay
-
-
-
-
-
-
-
@
Mondooooo:
and my right eye is bloodshot from lack of sleep but damn. the full moon with the clouds is beautiful -
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
