32MB support now merged into KOS official

[maslevin]

Hey all,

32MB support patches I worked on were officially merged into KallistiOS earlier this evening. This same support enables easy 32MB support for homebrew on both NAOMI and modded Dreamcast consoles. This also means that if DreamShell is updated against the latest KOS, DreamShell will also automatically get 32MB support.

For developers, a DBL_MEM macro is provided to get a true or false value, so it's extremely easy to make decisions in your games/applications about whether or not to allocate more or less memory. You can easily do simple things on day 1 like choose to keep certain areas of your map cached in memory for 32MB users for better loading times just based off of that.

Additionally, I adapted tsowell's memory tester utility and included it in the KOS examples folder as well. It'd be worthwhile to look at the source if you're interested in using this in your code.

On top of that, yesterday cepawiel wrote a patch which kazade merged yesterday enabling 32MB support in the lxdream-nitro emulator. You can now build it with support by using the -DMOD_32MB_RAM=true option when building lxdream-nitro. Details for this are on the bottom of the lxdream-nitro page:
https://gitlab.com/simulant/community/lxdream-nitro

I was also able to get NetBSD/Dreamcast built with 32MB support extremely easily as well. Details for this and the current state of 32MB Dreamcast support is listed on dreamcast.wiki here.

[GyroVorbis]

Hey, guys! Darc and I have been super passionate about this mod for awhile. He was kind enough to install it onto my DC, and I have gotten so much out of it as a developer. I'm reposting this here from the Simulant Discord, because I hope other developers might be reading:

Btw for everyone following along who is probably thinking "I don't care about special code for extra RAM for a small percentage of the population when the stock DC only has 16MB." First of all, just for you, as a developer, you can get a lot of use out of it adding extra code, metadata, allocation tracking/profiling, debug symbols, etc using it just for debug builds during development locally. Secondly, I would argue that there are definitely trivial scenarios for an indie game or for an emulator to easily leverage the extra RAM without having to go do a bunch of extra work for it... Like in our engine, we actually cache the previous 3 visited areas on PC so if you just backtrack quickly there's no reloading assets from disk.

On DC, we couldn't cache anything. Now I can trivially at least cache another area. Also there are things like particle buffers or dead body remnants on the map that are coming from a pool which have to be recycled but could be using a deeper buffer on 32MB.

A friendly reminder, @darc made it this freaking easy to leverage on purpose:

Code: Select all

Particles* pParticlePool = new Particles[DBL_RAM? 20000 : 10000];

Furthermore what was added to KOS was just a single global variable, populated at startup, holding the start location of the stack, which is referenced now by the code rather than having a fixed value. It's as lightweight and nonintrusive as it could get, imo.

The only thing is in order to leverage 32MB, the toolchain has to be updated with KOS. You don't have to, you'll just get a message if you don't, but maaaaybe you'll like it if you do. lol.

[|darc|]

This also means that if DreamShell is updated against the latest KOS, DreamShell will also automatically get 32MB support.

It got updated today