Cache using way too much memory

[derek57]

It was 2 years ago when I started porting NBlood to a device with only 52MB of usable memory and experienced that BLOOD eats up a lot of memory (cache). Back then, I aborted doing anything more to it whereby I had a fully running game.

NBlood itself has issues with the size of HEAP compared to performance.
Let's say, I had a look into this and figured that the best size for HEAP for it would be at least 24MB to make the game run fluent.
So 52MB minus 24MB = 28MB for Cache.

Now, when I run the first map of episode 1 of BLOOD, already around ~6.7MB of Cache are used.

When I go "NEW GAME" and run each new episode one after another (just starting the first map), the Cache used will be increased to ~14MB. Each further map for each episode makes use of even more Cache. It's clear that for only 28MB of free Cache being available, the game sooner or later will bail out due to error message "Out of memory". Or (also already happened) it would fail loading the cutscene at the end of an episode because of low-memory. The exit error would be just the same. Another unwanted effect of low memory is that (once the Cache is full) you get weird texture issues.

My idea here would be to clear the Cache area on each start of a new episode.
This should work for low-memory devices in theory but I can't tell if it's possible to implement it that easy.
It would just be great to optionally allow enabling a special preprocessor definition like "-DLOW_MEMORY_DEVICE" to allow clearing the USED Cache.

As I've seen, DOS BLOOD "only" uses 36MB of memory running it within DOSBox (OUWB) on a 64MB environment.
If the main memory available is less than 64MB (like only 32MB), starting DOS BLOOD throws a warning about "the user may experience issues when running it on low memory".

NBlood usually makes use of 96MB of memory just for Cache as seen according to variable "MAXCACHE1DSIZE" in file "tile.cpp". Compared to DOS BLOOD that's alot when running the main game with nothing more than just a software renderer at 320x240x8bpp and absolutely no specials.

I hope there is a way to implement this somehow.

[tmyqlfpir]

Ideally this project may be more suited for your requirement as much of EDuke32 assumes hardware has at least 512MB of RAM

[derek57]

Sorry, but that (imo) is not even an option.

1.) It is unknown of which state repo "NBlood-Amiga" is regarding the commit once it was "forked" from this repo right here.
2.) It uses SDL2 instead of SDL which is just not available for the device I'm cross-compiling this repo right here for...

Other than that, it's not a problem related to EDuke32 as you mentioned it, as EDuke32 (Duke Nukem 3D) itself was once cross-compiled for that device years ago (r2685) and it was working there without a problem.

[tmyqlfpir]

1.) It is unknown of which state repo "NBlood-Amiga" is regarding the commit once it was "forked" from this repo right here.

Last upstream merge was of March 2023.

2.) It uses SDL2 instead of SDL which is just not available for the device I'm cross-compiling this repo right here for...

That fork is also used for the vita port which appears to link to SDL2.

Only reason I suggested this was because NBlood-Amiga uses JFBuild, which is far less complex than EDuke32. It also is a working codebase, and may be easier to port.

Other than that, it's not a problem related to EDuke32 as you mentioned it, as EDuke32 (Duke Nukem 3D) itself was once cross-compiled for that device years ago (r2685) and it was working there without a problem.

EDuke32's codebase has changed much since r2685 (2013 if I am reading that right), and I can't confirm if any of the cross platform code still works beyond compiling.
For example there are a few GEKKO platform defines in NBlood, but I don't believe anyone has attempted to target or fix the existing Wii devkitPro platform support - much of that code hasn't been changed for years.

There is a EDuke32 project which backported to DOS using an open source toolchain. I'm not sure what value this could have, but it did require 128MB of RAM - and this was after considerable optimizations. That was built off a more modern revision of EDuke32 (2487f27).

Best of luck in your progress.

Edit: Added on discord

[derek57]

Last upstream merge was of March 2023.

That is good to know, but due to...

That fork is also used for the vita port which appears to link to SDL2.

...no way to go for as I simply won't port the whole SDL2 library for the device I'm working on.

BTW: Is there any chance to talk in private somehow?

[tmyqlfpir]

This issue was solved by rerouting cache to use Blood's resource system allocation, which is exactly what DOS Blood does instead of relying on Build's native cache system.