Blood MSDOS port for Wii is possible?

[0arsoluto]

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

g

 

[Disorarara]

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

If it's SDL based it can be ported yes

 

[0arsoluto]

If it's SDL based it can be ported yes

Let's see if a kind soul can port it

 

[SaulFabre]

Have you tried playing this in the @retro100 version of DOSBox Wii with PPC dynarec?
https://github.com/retro100/dosbox-wii/releases

Beware that in here you can't key mapping to Wiimote, but on this early mod of @Wiimpathy before retro100's changes of DOSBox Wii you can map them:
https://gbatemp.net/threads/wiiflow-lite.422685/page-76#post-8580238
Tutorial (in portuguese, thanks @rogerioronin): https://mundowiihack.wordpress.com/...etamente-no-wii/comment-page-1/#comment-31181

 

[nitr8]

0arsoluto

Just to let you know:

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.

Sorry to tell you that.

 

[Disorarara]

0arsoluto

Just to let you know:

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.

Sorry to tell you that.

I mean surely someone here would like to take a look at it and maybe contribute some ideas or fixes?

 

[SylverReZ]

If somebody could pull it off, then I guess. But nonetheless, you're stuck with using DOSBox for now.

Speeds aren't so great for intensive 3D games on a console that is over 18-years old now.

 

[N7Kopper]

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.

 

[nitr8]

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.

Let's revive Caleb one more time...

 

[nitr8]

======
Update
======

Current state:
--------------------

- 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: Sep 9, 2024

========
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).

 

[nitr8]

Well...

 

[linuxares]

Well...

OOoh!

I noticed some textures at the hud doesn't seem to work yet, but great progress!
I still love the lil old wii still get love

 

[nitr8]

OOoh!

I noticed some textures at the hud doesn't seem to work yet, but great progress!
I still love the lil old wii still get love

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".

 

[nitr8]

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.

 

[Latiodile]

i'm surprised this hasn't been done already tbh

 

[nitr8]

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...

 

[0arsoluto]

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

 

[nitr8]

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.