hello. Is it possible to port the MSDOS game Blood on Wii? I don't know if it could really be done directly through the MSDOS emulator for Wii or using the NBlood engine - Blood port based on EDuke32. Since the Wii I was able to use this eduke engine and takin advantage of the port created of the blood game for it. thank you. all the best
hello. Is it possible to port the MSDOS game Blood on Wii? I don't know if it could really be done directly through the MSDOS emulator for Wii or using the NBlood engine - Blood port based on EDuke32. Since the Wii I was able to use this eduke engine and takin advantage of the port created of the blood game for it. thank you. all the bestView attachment 432000View attachment 431999gView attachment 432001
1.) I personally DO have a running version of Blood for the Wii since over a year.
2.) It's based on NBlood.
3.) It's a special checkout from NBlood's GitHub repo due to some devkitPro limitation.
4.) It's buggy (may crash at random due to some yet unknown reason).
5.) It would run with full sound, music and Wii Classic Controller support.
6.) NBlood (as of STOCK) requires more than 90MB of RAM to run (which is quite too much the Wii can handle).
7.) The original version of BLOOD for DOS requires "only" 36MB by default.
8.) My Wii port of It would run with less than 90MB of memory but I just can't tell if that's the reason for it crashing at random.
9.) I therefore NEVER released it to the public and I most likely never will before the game won't run stable.
10.) I do remember the reason being something related to Blood's "eventq" handler but never found the origin of the bug.
1.) I personally DO have a running version of Blood for the Wii since over a year.
2.) It's based on NBlood.
3.) It's a special checkout from NBlood's GitHub repo due to some devkitPro limitation.
4.) It's buggy (may crash at random due to some yet unknown reason).
5.) It would run with full sound, music and Wii Classic Controller support.
6.) NBlood (as of STOCK) requires more than 90MB of RAM to run (which is quite too much the Wii can handle).
7.) The original version of BLOOD for DOS requires "only" 36MB by default.
8.) My Wii port of It would run with less than 90MB of memory but I just can't tell if that's the reason for it crashing at random.
9.) I therefore NEVER released it to the public and I most likely never will before the game won't run stable.
10.) I do remember the reason being something related to Blood's "eventq" handler but never found the origin of the bug.
It seems like it probably is a RAM issue. Making the port fit in MEM1 would bring it under 66 MB, and that would likely mean more granular asset streaming. Modern ports of old stuff usually throw such concerns by the wayside - anything even remotely modern could load the whole game into RAM no problem if it wanted.
I'm working on this again.
I was just wrong about the time when I had the first running prototype for the Wii.
It was 2 years ago, not 1.
Anyway... I might get rid of NBlood completely, throwing away the whole current work on it.
I'm going to pull the original and very basic DOS decompilation of the source code, then import SDL into it, trying to make it first run within Linux. If that works out, then port it over to the Wii as this would be the best and easiest way.
I'll keep you updated. I have ported several games to the Wii in the past and seeing a running BLOOD port on this console would be the greatest things ever done.
- No sound yet
- No startup videos yet (like the MONOLITH or GT logo)
- ONLY windowed video mode (SDL2 relation...???)
- No controls yet
- Currently runs "ONE UNIT WHOLE BLOOD"
USBGecko DEBUG output:
[16:44:10:483] [__lwp_wkspace_init]: Initialized HEAP @ 80601f40 till 80701f3c (1048572 bytes) with page size 8
[16:44:10:483] [iosCreateHeap]: Initialized HEAP @ 933e0000 till 933e1000 (4096 bytes) with page size 32
[16:44:10:483] [iosCreateHeap]: Initialized HEAP @ 933e1000 till 933e1800 (2048 bytes) with page size 32
[16:44:10:731] [iosCreateHeap]: Initialized HEAP @ 933e1800 till 933e2800 (4096 bytes) with page size 32
[16:44:10:808] [iosCreateHeap]: Initialized HEAP @ 933e2800 till 933e6800 (16384 bytes) with page size 32
[16:44:10:808] [iosCreateHeap]: Initialized HEAP @ 933e6800 till 933e7800 (4096 bytes) with page size 32
[16:44:10:808] [iosCreateHeap]: Initialized HEAP @ 933e7800 till 933e8c00 (5120 bytes) with page size 32
[16:44:10:958] [USBStorage_Initialize]: Initialized HEAP @ 933c6f60 till 933cb760 (18432 bytes) with page size 32
[16:44:11:022] Using usb: device for game data source
[16:44:13:134] Added sd:/ to search path.
[16:44:13:134] Added usb:/apps/WiiBlood/gamedata/ to search path.
[16:44:13:151]
[16:44:13:151] SDL2 system interface (compiled with SDL version 2.28.5, runtime version 2.28.5)
[16:44:13:183] Initializing OSD...
[16:44:13:359] Initializing Build 3D engine
[16:44:13:359] Initializing engine
[16:44:13:375] Loading palettes
[16:44:13:399] Loading translucency table
[16:44:13:399] Loading gamma correction table
[16:44:13:399] Creating standard color lookups
[16:44:13:399] Loading tiles
[16:44:13:479] initcache(): Initialised with 16777200 bytes
[16:44:13:575] Loading cosine table
[16:44:13:591] Initializing view subsystem
[16:44:13:591] Initializing status bar
[16:44:13:623] Initializing dynamic fire
[16:44:13:815] Initializing weapon animations
[16:44:13:831] There are 0 demo(s) in the loop
[16:44:13:831] Loading control setup
[16:44:13:850] CONTROL_Startup: Mouse Present
[16:44:13:850] Initializing network users
[16:44:13:850] Setting video mode 320x240 (8-bpp windowed)
[16:44:13:889] Initializing sound system
[16:44:13:889] FX driver is SDL
[16:44:13:889] Format is 22050Hz 8-bit 2-channel
[16:44:13:889] CD error: SDL CD is not supported
[16:44:13:889] Music driver is No Sound
...and... yeah - I'm actually compiling and debugging this within ECLIPSE using a USBGecko as a HARDWARE DEBUGGER (realtime debugging with stepping etc.).
I'll continue my work on this and keep you updated.
Post automatically merged:
========
Update 2:
========
- No more mouse cursor (disabled by just returning from SDL2 function "void OGC_draw_cursor(_THIS)")
- FAKE "fullscreen mode" by setting WINDOWED video mode 320x240 to 640x480
(USBGecko reply on console: "[18:30:45:184] Setting video mode 640x480 (8-bpp windowed)")
NOTE: I just realized that this makes some bits of the actual game screen disappear.
There is stuff "cut off" the visual screen field and I need to fix that (which I previously did for SDL v1.2 on the Wii but not for SDL2 by now).
It's not what you would expect but the "screen size" in this video is the original HUD "+1" so you only see what you actually need. The original HUD is still available at HUD "0".
Please make sure you read the description within the video. This has ALWAYS been a problem with NBlood and I personally think it's related to the size of cache being used for the main game. The thing is, everything is normal up until some point where more and more textures get borked the longer you run / play the game.
From seeing within the debug output, the cache entries get increased during running the game, which results in output like this:
[18:42:25:397] Cache object array initialized with 1024 entries.
[18:42:39:638] Cache increased from '1024' to '2048' entries.
[18:46:52:300] Cache increased from '2048' to '3072' entries.
[20:11:21:311] Cache increased from '3072' to '4096' entries.
The last entry (increasing cache entries from 3072 to 4096) is happening running this particular map (E2M4) and that is where those glitches happen.
Now I figured that the problem with those graphical glitches is related to the size of Cache being used (not enough).
Here's what I'm facing with:
The game uses HEAP and Cache from MEM2 (only up to 52MB are actually usable for the game before it starts crashing).
The code I'm using works like a slider between usable HEAP region and usable Cache region.
The more Cache I'm trying to allocate, the less HEAP will be available.
So once I use more than 16MB for Cache, the game will most likely exit once it tries to load one of the cutscenes at the end of an episode due to (the message over a USB GEcko) being "Out of memory".
Anyway, the thing is that each map of the game requires like ~211 KB of Cache.
The whole game ("One Unit: Whole Blood") has 42 maps.
So 42 maps * 211KB mapdata = 8862KB (~9MB Cache).
The game starts with texture data being precached which is an additional ~7MB of Cache.
In total, this makes about 16MB of Cache which need to be allocated.
But yet that still is not enough...
During gameplay, the game will ALWAYS precache textures.
Trying to run the game with 24MB of Cache and 24MB of HEAP made it exit at the end of episode 1 trying to play the cutscene with the "Out of memory" message.
I'm not sure if it's possible to (somehow) clear the cache area above block 1024 as this is what the game starts with (1024 blocks of precached textures etc.). If (once starting a new episode) clearing anything beyond block 1024 is possible, this could probably help getting around the "low memory" problem which the Wii actually has.
What would be good to know is this:
I saw that NBlood was ported to the PSVIta.
A look at the source code used for it made it clear that for the PSVIta, only 8MB of HEAP are actually used.
Compared to the Wii this would mean there would be 44MB of Cache available for the game which should be just enough for it to run all episodes in a row.
What I'm not sure about is this:
Does the PSVita port run with cutscenes enabled?
Aside from the situation mentioned above, I've been stress-testing the game (running through all the maps of episode 1 and half of episode 2 with a Napalm launcher causing as much "trouble" as possible and it basically runs really fine). The only culprit is the low memory the Wii has free for use...
Now I figured that the problem with those graphical glitches is related to the size of Cache being used (not enough).
Here's what I'm facing with:
The game uses HEAP and Cache from MEM2 (only up to 52MB are actually usable for the game before it starts crashing).
The code I'm using works like a slider between usable HEAP region and usable Cache region.
The more Cache I'm trying to allocate, the less HEAP will be available.
So once I use more than 16MB for Cache, the game will most likely exit once it tries to load one of the cutscenes at the end of an episode due to (the message over a USB GEcko) being "Out of memory".
Anyway, the thing is that each map of the game requires like ~211 KB of Cache.
The whole game ("One Unit: Whole Blood") has 42 maps.
So 42 maps * 211KB mapdata = 8862KB (~9MB Cache).
The game starts with texture data being precached which is an additional ~7MB of Cache.
In total, this makes about 16MB of Cache which need to be allocated.
But yet that still is not enough...
During gameplay, the game will ALWAYS precache textures.
Trying to run the game with 24MB of Cache and 24MB of HEAP made it exit at the end of episode 1 trying to play the cutscene with the "Out of memory" message.
I'm not sure if it's possible to (somehow) clear the cache area above block 1024 as this is what the game starts with (1024 blocks of precached textures etc.). If (once starting a new episode) clearing anything beyond block 1024 is possible, this could probably help getting around the "low memory" problem which the Wii actually has.
What would be good to know is this:
I saw that NBlood was ported to the PSVIta.
A look at the source code used for it made it clear that for the PSVIta, only 8MB of HEAP are actually used.
Compared to the Wii this would mean there would be 44MB of Cache available for the game which should be just enough for it to run all episodes in a row.
What I'm not sure about is this:
Does the PSVita port run with cutscenes enabled?
Aside from the situation mentioned above, I've been stress-testing the game (running through all the maps of episode 1 and half of episode 2 with a Napalm launcher causing as much "trouble" as possible and it basically runs really fine). The only culprit is the low memory the Wii has free for use...
What resolution does the game work at? Is there an option for 240p? If it were done at 240p would it work better as it is a lower resolution or does it not matter? thanks my friend. all the best
What resolution does the game work at? Is there an option for 240p? If it were done at 240p would it work better as it is a lower resolution or does it not matter? thanks my friend. all the best
I'm running the game at 320x240 8bpp by default.
That's the only supported (8bpp) pixel format and the fastest (320x240 pixels) setting.
Anything beyond that will either break (bpp > 8) or run horribly slow (640x480 pixels).
Whereby: I also figured that the more memory is available for HEAP, the smoother the game will run and the less is the load time between changing maps.
So, after weeks of working on my previous project regarding bringing the DOS classic "BLOOD" to the Wii, I'm finally heading towards a release.
Lot's of work has been done and I really have to mention one of the NBLOOD maintainers over at GitHub (which this port is related to) by the name of "tmyqlfpir". Without this user's help, most of what was done to get it to the current state would have been out of focus as the code base to the Wii port is from Oct., 2nd 2021 before some major changes were made which made the whole code not compile with devkitPro.
Currently, the game runs at 50fps most of the time, which is really impressive and is the outcome of also updating the original "SDL for Wii" source code base used for this game to the changes @mudrik published over at his own GitHub repo.
Yet, there still are 2 major flaws with the whole port:
Once I've released the code to it, anyone should be able to recompile this using devkitPro r27 (which is important).
The struggle I've been facing with is that (if ALL the code) is compiled using flag "-DDEMO_ENGINE_TEST" the game is supposed to run like a stress test. At some time (even after several hours) the game might freeze. This freeze can happen at any time while playing the real game and is related to the sound code (which might be caused by libOGC's code as of file "audio.c" or the underlying SDL code (which I had to backport from the code used by @mudrik due to performance (stuttering) to the original "SDL for Wii" code)).
Graphical glitches may occur due to memory limitations as NBLOOD (based on the EDUKE source code) usually expects 92 MB of RAM for cache to run. Currently, (when it comes to the Wii) this is done using only 20 MB of cache and might be a problem at some point. I'll have a look into this furthermore.
Right at this moment I can just tell that I'm proud of the overall outcome.
Regarding those flaws mentioned above I have to admit that BLOOD (even when running it on a real PC using DOS) had dozens of bugs and having the game run for several hours on a Wii compared to the DOS version is pretty more than "good" compared to all the work that had to be done to get it into the current state.
Post automatically merged:
...it also doesn't look too bad when running it at screen solution 640x480x8bpp...
So, after weeks of working on my previous project regarding bringing the DOS classic "BLOOD" to the Wii, I'm finally heading towards a release.
Lot's of work has been done and I really have to mention one of the NBLOOD maintainers over at GitHub (which this port is related to) by the name of "tmyqlfpir". Without this user's help, most of what was done to get it to the current state would have been out of focus as the code base to the Wii port is from Oct., 2nd 2021 before some major changes were made which made the whole code not compile with devkitPro.
Currently, the game runs at 50fps most of the time, which is really impressive and is the outcome of also updating the original "SDL for Wii" source code base used for this game to the changes @mudrik published over at his own GitHub repo.
Yet, there still are 2 major flaws with the whole port:
Once I've released the code to it, anyone should be able to recompile this using devkitPro r27 (which is important).
The struggle I've been facing with is that (if ALL the code) is compiled using flag "-DDEMO_ENGINE_TEST" the game is supposed to run like a stress test. At some time (even after several hours) the game might freeze. This freeze can happen at any time while playing the real game and is related to the sound code (which might be caused by libOGC's code as of file "audio.c" or the underlying SDL code (which I had to backport from the code used by @mudrik due to performance (stuttering) to the original "SDL for Wii" code)).
Graphical glitches may occur due to memory limitations as NBLOOD (based on the EDUKE source code) usually expects 92 MB of RAM for cache to run. Currently, (when it comes to the Wii) this is done using only 20 MB of cache and might be a problem at some point. I'll have a look into this furthermore.
Right at this moment I can just tell that I'm proud of the overall outcome.
Regarding those flaws mentioned above I have to admit that BLOOD (even when running it on a real PC using DOS) had dozens of bugs and having the game run for several hours on a Wii compared to the DOS version is pretty more than "good" compared to all the work that had to be done to get it into the current state.
Post automatically merged:
...it also doesn't look too bad when running it at screen solution 640x480x8bpp...
Here it is, a significant update for the Nintendo Switch. System software update v20.0.0 has released as of today. This firmware version adds some of the newer...
The Wii Homebrew Channel has been a staple of open source homebrew software for years now. And now, development has ended on the project, with the repository now...
While preparation for the upcoming Switch 2 are at full swing, Nintendo has also been updating their online and account services, and this week they have updated...
Earlier this month we looked and the ins and outs of Game Key Cards for the Switch 2. In basic terms for those who skipped that one, you can think of these as a...
In late 2024, GameFreak was breached, and the person responsible for it was able to access well over 1TB of data from the company, including beta builds of Pokemon...
After taking some time to discuss the United States' current market instabilities, Nintendo has re-announced the pre-order window for the Nintendo Switch 2. The...
We're seeing price increases around the world, and Microsoft has finally joined the fray. Announced by the company today were major price increases to Xbox games...
Pocket Pair's battle against the Japan gaming giant, Nintendo, continues today with an unfortunate update by Pocket Pair, as well as an in-game update that modifies...
Last year, a brand new tool for static recompilation of Nintendo 64 games called N64 Recompiled appeared, which would facilitate the conversion of N64 games to C...
Nintendo is bringing us more information about one of the Switch 2 titles, in the form of a Nintendo Direct solely focused on Mario Kart World. This 15-minute video...
While preparation for the upcoming Switch 2 are at full swing, Nintendo has also been updating their online and account services, and this week they have updated...
The Wii Homebrew Channel has been a staple of open source homebrew software for years now. And now, development has ended on the project, with the repository now...
Here it is, a significant update for the Nintendo Switch. System software update v20.0.0 has released as of today. This firmware version adds some of the newer...
Earlier this month we looked and the ins and outs of Game Key Cards for the Switch 2. In basic terms for those who skipped that one, you can think of these as a...
Pocket Pair's battle against the Japan gaming giant, Nintendo, continues today with an unfortunate update by Pocket Pair, as well as an in-game update that modifies...
We're seeing price increases around the world, and Microsoft has finally joined the fray. Announced by the company today were major price increases to Xbox games...
Hot on the heels of the delay announcement, Rockstar is attempting to appease its fans with a brand new trailer for Grand Theft Auto VI. The second official trailer...
To the surprise of absolutely no one, Rockstar Games have today announced a delay to the release date of Grand Theft Auto VI.
Originally targetting a non-specific...
In late 2024, GameFreak was breached, and the person responsible for it was able to access well over 1TB of data from the company, including beta builds of Pokemon...
Since the price of Switch 2 games were quietly announced after the April 2nd Direct, the internet has been whipped into a frenzy. For those who have been happily...
g
