RAM limitations

[azihassan]

According to this reply and this one, the game requires 32 MB of RAM. The Dreamcast has 16 MB and 8 MB of VRAM, so I'm not sure if it's enough to meet the requirements.

So far, the game crashed with an out of memory error once when I was storing save files in RAM. It didn't crash when I retried, probably because it generated a less ambitious level, but I estimate that the save files were using about 1 MB of RAM at that point.

I tested the first hell level on emulator (in multiplayer mode) and it didn't crash in the loading screen, but more tests need to be conducted to make sure that the game is playable in its entirety.

[AJenbo]

Multiplayer uses more run time memory where singeplayer use larger save games (they are sued as swap files for level info). Of cause if you don't have much space for saving that isn't really any help :)

[azihassan]

Update: I played through the hell levels on Flycast but it eventually OOMed on the 16th level. I'll try again without sound

hell-16.mp4

[AJenbo]

sooo close

[azihassan]

I changed trigs.cpp to get the hell entry to throw me right into level 16 to make testing easier. After narrowing down the crash to InitAllMonsterGFX, I sprinkled some RAM logging statements thanks to ian micheal's logging module from Discord. malloc_stats only reports 10 MBs (in max system bytes below) during the crash which made it unreliable. Never mind the PVR part in the logs, I disabled it because I didn't want to accidentally mess with SDL:

INFO: Loading monster graphics: golem\golem     x1

---------
RAM stats (MB):
Total: 16.00, Free: 3.17, Used: 12.83, PVR: 0.00
---------
max system bytes =   10199744
system bytes     =   10199744
in use bytes     =    9763312
INFO: 



INFO: Loaded monster graphics: golem\golem      297 KiB   x1

---------
RAM stats (MB):
Total: 16.00, Free: 2.88, Used: 13.12, PVR: 0.00
---------
max system bytes =   10506944
system bytes     =   10506944
in use bytes     =   10067672
INFO: 



INFO: Loading monster graphics: diablo\diablo   x1

---------
RAM stats (MB):
Total: 16.00, Free: 2.88, Used: 13.12, PVR: 0.00
---------
max system bytes =   10506944
system bytes     =   10506944
in use bytes     =   10067672
INFO: 



Out of memory. Requested sbrk_base 0x8d06a000, was 0x8cd1f000, diff 3452928
terminate called after throwing an instance of 'std::bad_alloc'
  what():  std::bad_alloc
arch: aborting the system

It reaches the limit when it attempts to load the diablo*.clx files, which occupy 3.3ish megs:

# https://www.baeldung.com/linux/sum-the-size-of-files#1-using-awk-to-sum-file-sizes
$ ls -l build/data/diabdat/monsters/diablo/*.clx | awk '{ sum += $5 } END{ print sum/1024/1024 }'
3.29322

The diablo walking animation (diablow.clx) is the smallest one at 236 kB. I replaced all the other animations with it (1.6 megs total) and the level loaded, but for some reason I got instakilled by a large horde of monsters. I think it's because I messed with the triggers, I suspect it's loading monsters from levels 15 and 14 as well because this issue didn't happen when I restored the trigger and loaded the game with the 32 MB extension enabled on Flycast.

The next thing I'm gonna try is to look for a way to downgrade the animations to make them smaller in size. Another option is to try and skip the death/win initially (diablod.clx, 817 kB and diablon.clx I think, 648 kB), and load them when the time is right (after freeing the regular walk/attack/spell animations ones). This way we gain 1.4 megs without degrading the quality, but I think that change might be too invasive.

Edit: turns out diablon.clx is an idle animation, I thought it was a little dance Diablo does after killing the player 🤦‍♂️

[azihassan]

@AJenbo I looked into the animations with https://github.com/diasurgical/d1-graphics-tool. I was initially thinking of keeping half the sprites in each animation (keep 1/x, skip 2/x, keep 3/x), would this have an effect on game logic? I'm worried about it affecting things like hitboxes

[AJenbo]

The game originally didn't use the graphics for hitbox at all and instead used tiles and a set number for each monster type. It's only something we are adding in the next release for mouse select and dropping frames won't have a negative on it.

The engine does support playing animations at different speeds.

Dropping half the frames is also on of the cuts the PlayStation did.

[azihassan]

I ended up changing the standby and death animations of Diablo (diablon.clx, diablod.clx and monstdat.tsv) as well as the death animations of the blackd.clx file. I noticed that the "knight" death animation looks similar (edit: but not identical) regardless of their orientation so I only kept the south facing one, and made sure the knights are turned to face south before the animation is triggered. The downside is that their corpses are all facing south. Here's what it looks like (please ignore the cheap tactic of spamming holy hadoukens):

diablo-death.mp4

I'm gonna have to try again in normal speed because I can't really tell if there's a difference here

[AJenbo]

What about the mages I thought it looked like they might all be the same animation regardless of angle, but I'm not 100% sure.

[azihassan]

Thanks, nice catch! The knight death animations were similar but not identical, but the mages have the same ones frame for frame.

I forgot to mention this but at some point in the loading screen of level 15 or 14, the game complains about a missing snakb.trn and crashes. It wasn't available in my diabdat.mpq, at least not in the unpacked version. Any idea why? I copied the existing snakbl.trn into snakb.trn to bypass the error in the meantime.

Edit: forgot that I'm behind upstream, I should probably update the fork and test it again

[AJenbo]

snakb is used for the Azure Drake, looks like it was a bug in the script that removes unused content when creating the unpacked data: diasurgical/devilutionx-asset-optimizer@f4aa8b1

[azihassan]

Quick update, after changing blackd.clx and maged.clx it turns out that there's no need to downgrade the Diablo animations for the last level to load (at least with NOSOUND). However, it has just occurred to me that I'm probably not allowed to distribute the changed clx files because they are part of diabdat.mpq

@AJenbo I made a command line tool that automates the process of removing animations from the CLX files. I was wondering, what would be the recommended approach to integrate this into the project?

• Run it after running unpack_and_minify_mpq
• Refactor the tool to do it at runtime by (somehow) loading only the first group from blackd.clx and maged.clx and disregarding the rest

[AJenbo]

Run it after running unpack_and_minify_mpq

I think this sounds like a fine solution, unless you think integrating it would make it easier.