Support for TNT Evilution and the Plutonia Experiment

[kilograham]

Running these games currently experience the following problems below.

None of the problems are particularly insurmountable, and I have a branch that hacks past them to make the games runnable; the question is whether we actually have enough RAM to play these games in general. This is the main reason I haven't actually made the effort to fix these things yet. That said, there is certainly more RAM we can reclaim, and multiple levels seem to play fine, so it is probably doable. Note also that certain levels do run out of "render columns" so do not render correctly (black areas)

• The block maps exceed the limits of whd_gen block map compression. Turning the block map compression off is a workaround.

• The Plutonia Experiment WHD does not fit in 8M with or without the above, the TNT Evilution WHD does. Basically more effort will have to be put into compression (or making the super-tiny compression work with fewer constraints) if we want to support TNT in 8M.

• Oversized textures; these are up to 1024x128. These are used for

  • Sky textures
  • Hackery for animated textures (see further below)

  The RP2040 Doom code only has 8 bits available for column offsets at the pd_render stage, however it should be possible to mark these few wide texture numbers in the WHD, and actually split them into separate 256 pixel wide textures, with the high level r_segs drawing code picking amongst these "sub" textures based on the actual column number.

• "Hack?" to add more texture/flat animations. The Doom code base has texture/flat names in p_spec.c e.g. TEXANIM_DEF(BLODGR4, BLODGR1, 8) which says that textures between "BLODGR4" and "BLODGR1" are animated. In RP2040 Doom, I converted these names to fixed numbers (in whddata.h) and whd_gen renumbers the textures accordingly. The list of animated textures and flats in p_spec.c are fixed though, so I guess TNT Evilution and Plutonia expirment level designers needed to reuse the existing ones for more, and longer animations. This leads to two things:

  • Super-wide textures, with each texture containing one frame of multiple animated textures (this way the same animation definition can be used)
  • The number of textures/flats in an animation being different from what I have in whddata.h based on what was true in all the original Id WADs.

  The fix here is pretty simple, which is simply to store the animation ranges in the WHD rather than in the code.