[GEC] Master Edition PSX Doom for the PlayStation. Beta 4 Released [11/16/2022]

Here two videos, showing the results, still do not have the sounds.

Also here is the GEC Discord Channel: https://discord.gg/aEZD4Y7

7 hours ago, Deⓧiaz said:

P.S.: Glad to see you've fixed a discovered problem with "wrong using memory in code". So how it's affects mapping? I mean, already used textures and monster on maps? Does those guys replace something existing like in Dehacked? Or it's a new things? Got too many questions about this.

All enemies are new actor inputs, only the Archvile that changes the doomenum to 91 instead of 64, since it was used in PsxDoom for decoration.

Fantastic progress!

A data of high interest, the Archvile only consumes (262.3Kb) of RAM

cube spawn = 3648      (3.68Kb)
boss brain   = 4864      (4.86Kb)
keen           = 7232      (7.23Kb)
wolfss         = 40032    (40.03Kb)
archi           = 262340  (262.34Kb)
archi fire     = 6692      (6.69Kb)

4 hours ago, Erick194 said:

In the current PSXDOOM-RE these changes will not be incorporated, there are still things to verify in PsyDoom and PSXDOOM-RE, this I will incorporate in a new branch for this project "Master Edition".

That’s awesome, thanks! I’ll keep an eye out for that when the time comes around. All those other tools as well sound like they will be super useful for people modding the game.

4 hours ago, Gez said:

IIRC, Aubrey's arch-vile sounds are "raw" and not filtered/pitch-shifted/otherwise processed to be suitably monster growls. As in, they just plain don't work. You'd need an audio engineer to finish them properly.

Makes sense, can’t imagine he spent any time polishing/iterating on those once word got out that the arch-vile was being canned. I guess worst case scenario is that the PC sounds can be used, if acceptable results can’t be gotten from the work that was scrapped. Or we all get creative and come up with new ones - would be nice/consistent to have a PSX twist on this enemy’s audio, like everything else in the game.

If someone can provide me the sound files for Aubrey's attempt at the archvile, I can probably make them sound demonic.

https://www.doomworld.com/forum/post/1828557

10 hours ago, intacowetrust said:

 

Just to clarify a few things about memory limits on the PS1 which may be helpful for mappers to bear in mind:

• Main RAM is actually 2 MiB in size, VRAM is 1 MiB. A large chunk of your main RAM however is used up by the .EXE itself and the global variables it declares, as well as 64 KiB reserved by the BIOS. In the greatest hits version of DOOM all this leaves 1,368,380 bytes available for the program via Z_Malloc (usable heap space).
• The 2 screen framebuffers (front & back) consume only VRAM, not main memory. They always consume (except during screen fade transitions) a fixed 256 KiB of VRAM. Palette colors are also squeezed into otherwise unused parts of this 256 KiB too.
• Wall and flat textures only temporarily occupy main RAM during level loading, after that they are promptly evicted once they are uploaded to VRAM. Therefore these types of textures do not count towards your main memory budget during gameplay.
• 64 KiB of VRAM is used at all times during gameplay for the STATUS graphic lump (UI and fonts etc.)
• 64 KiB of VRAM (a 256x256 pixel texture 'page') is reserved for flats used by the level, not matter how many flats are actually used. This limits you to 16 64x64 flats per level but since the amount used is fixed, reducing the flat texture count does not impact memory usage.
• A fixed 192 KiB of VRAM (3 256x256 pixel texture pages) is reserved exclusively for wall and sky textures by the engine during gameplay. The engine supports textures with widths of 128, 64 and 16 pixels only (except for regular skies which are 256x128). This translates to a theoretical maximum of 12 128x128 textures, 24 64x128 and 96 16x128 textures which can be used during a level. The (previously hidden) VRAM viewer can be helpful to visualize where each texture is going into VRAM.
• As I identified earlier in the thread, there is a 256x256 pixel (64 KiB) texture page unused by the engine during gameplay. This further eats into the VRAM budget but could potentially be unlocked for use by @Erick194 to help make texture cache overflows less likely.
• After all of these things eating into VRAM, you have 6 256x256 pixel texture pages (384 KiB) leftover for sprites in VRAM.
• Sprites are uploaded to VRAM on each frame, depending on what is visible. Therefore they must kept loaded in main RAM at all times, as well as occupying VRAM when they are being drawn. The sprite lumps are stored compressed in main RAM however, therefore more effective compression could in theory reduce this main memory overhead.
• If the number of unique sprites being rendered in a particular frame exceeds the 384 KiB VRAM budget for sprites mentioned above, you get a "texture cache overflow" error.

 

 

Again just to reiterate, your texture cache overflow error is caused by the fixed 384 KiB of VRAM dedicated to sprites being exceeded in a particular frame - it has nothing to do with running out of main memory. Changing the sky texture would also not help this issue, because the areas of VRAM dedicated to sprites, flats and textures are fixed and separate to each other. 

 

There are a couple of things you can do to try and reduce the VRAM usage by sprites on a particular frame:

 

(1) Use less types of monsters and sprites.

(2) Use monsters and sprites with smaller graphics.

(3) Have less monsters and sprites onscreen at the same time by partitioning up the level with solid walls, using less monsters in individual encounters etc. This can be easily overlooked but the key thing to remember with the texture cache overflow is that it's the number of unique sprites that are visible at the same time (and their size) which contributes towards the error. For example 4 imps could use as much VRAM memory for a particular frame as 4 different types of monsters, because each of those imps could be showing a different frame/pose. The more monsters you have onscreen the more likely each one will be showing something different, so this can add to the strain too... It's the reason why levels such as 'The Suburbs' can experience overflows due to the very large amounts of onscreen monsters, even though in theory they might be using the same level of monster variety as other levels.

 

I realize that with a level like 'Dis' your hands might be a bit tied for using some of those options, so perhaps @Erick194 might be able to help out with engine changes. Right off the bat there's that unused 64 KiB of VRAM which I've identified, which could be put to good use. He could also make it so that the texture cache overflow is not treated as a fatal error in the release version of the game and deal with the problem in one of two ways:

• Allow VRAM already being used for sprites in a frame to be overwritten and suffer the resulting (temporary) graphical glitches that follow. It might look funky for a few frames but probably much more preferable to a hard crash?
• Force the GPU to finish all current drawing, clear all sprites from the texture cache and allow it to be filled again. This would probably come with a large FPS drop, but still probably much preferable to crashing. In fact, I plan on doing this for PsyDoom and banishing texture cache overflows entirely since there isn't really much of a performance penalty in that case.

 

 

This is indeed possible, it would take a long time though. The game will outright refuse to launch a level (crashes with 'P_SetupLevel: not enough free memory') if it doesn't have at least 48 KiB of main memory free in the heap after everything is loaded. This 48 KiB is reserved for things that spawn during runtime, like bullet puffs, blood and spawned lost souls etc. so you are always guaranteed to have that amount of main RAM leftover on starting a level.

 

Given that a the size of a thing allocation at runtime is 172 bytes (including zone allocator overhead), this allows you to spawn approximately 285 map objects at runtime at a minimum - possibly more if the map doesn't require as much main RAM. There are a few other allocations (like thinkers for map changes/effects) that eat into heap space, but that should give you an idea of the kinds of limits you are playing with. You are much more likely to run into the VRAM limits with texture cache overflows (caused by lots of souls being active) than hitting the main RAM limit most of the time.

 

Thanks for the technical breakdown.

Yeah, I obviously made sure my level runs, and doesn't bomb out on respawn or anything like that (part of my basic testing). As you said, I am kind of limited on options in terms of reducing stuff for an overflow, since I went in with some basic design goals:

1. Make the fight, well, a fight (done by moving the Spider to the center so it can dominate the map and force the player to rely more on infighting),
2. Since this is a Doom 1 map, make sure there's the PSX-exclusive "Doom II in Doom 1 maps" thing on Ultra-Violence, and
3. Get a little evil with the player on UV since this is supposed to be an arena fight.

I do think it would take awhile for the game to bomb out due to the overflow, but admittedly I never ran into it while testing myself. There are some alternatives, but all of them come with drawbacks, as I said in my last post. Ultimately the Pain Elemental (via the Lost Souls) fit the bill great: It forces you to keep on moving (so you can't just cheese the Spider Mastermind), it's got a good pest factor that won't rely on Line-of-Sight, and it fits all the bills of the other major points.

Basically, as long as it's not something that the player would run into on "regular" play, I think it's permissible. If you have to sit there and wait awhile for the overflow to happen, then it's kind of a case where you're purposely trying to overload it. A normal player would almost certainly work on blowing up the PEs or killing the Barons, and once they're dead, the overflow likely becomes impossible to happen, or at least very unlikely.

17 minutes ago, Deⓧiaz said:

https://www.doomworld.com/forum/post/1828557

@Erick194 Almost forgot, I've done in 2018 sounds for ScottGray PSX levelpack project for Arch-vile attack sound:

https://www.mediafire.com/file/7astlmsc71ztyz1/VileAttackSounds.7z/file

Don't know which is better, so I've included all variations

The originals should be there: http://www.aubreyhodges.com/doom-playstation-arch-vile-sounds/

Also, Blastfrog's edits are still around: https://www.dropbox.com/s/ctpa7l9d38azhx4/soda_psx_archvile_edits.zip?dl=1

Maybe we should try doing some alternate mixes, and see if any good ones can be come up with? Not like we just have to stick to old ones.

@Erick194

Also, in Invisible Monsters mod I've used PSX sounds for monsters. But for Nazi SS I've also added new sounds from another Wolf3D release:

https://www.mediafire.com/file/0tjcgvc7sbu5a0j/Invis_Wolf.7z/file

I can't say this is the best variant of Nazi SS voiceover for PSX Doom, but can be reviewed, at least.

Still, for Archvile I prefer my own mix which is "non pitched" (Aubrey Hodges version with echo and reverberation effects).

UPD: My friend SCD also wants to provide an alternate archive with sounds (he is not registered on Doomworld but he does reading this thread). The different are Wolfenstein SS screams and Flame sound. Vile's attacking and screming sounds are same as mine.

https://www.mediafire.com/file/zms7g5zkt7cgt65/PSX_style_sounds_for_the_Arch-Vile__%26_the_Wolfenstein_SS_Soldier_(1).zip/file

I never realized about removing the reverb from every outdoor section until now

19 minutes ago, RonLivingston said:

I never realized about removing the reverb from every outdoor section until now

You will most definitely want to do that in any sector that's basically open to sky.

15 hours ago, Deⓧiaz said:

https://www.doomworld.com/forum/post/1828557

Might want to remove the alternative sendspace links for the wav versions.   My virus scanner blocked and warned me of something while the file was missing anyway.   The Mega links were fine.   Awesome stuff!

2 hours ago, Dark Pulse said:

You will most definitely want to do that in any sector that's basically open to sky.

I'am testing the map with the PSX emulator, but i need a reminder to patch the iso correctly because its been long since i did that

Outstanding! I knew the PSX engine could be further improved... with Erick's knowledge!

I need to get back to posting my Video Content here 

Quote

PsxDoom with PsxHexen Wall render

OMFG

Wait, what?!

Quote

PsxDoom: player looks up and down.

F*CK ME, THAT'S SO SICK.

Ok, getting serious.

What's the Hexen's height limit? I never played PSX Hexen, sorry.

7 hours ago, Erick194 said:

Greetings guys, I was wondering why playstation hexen managed to get high heights in the game and Psx Doom didn't?
Well I made reverse engineering of Psx Hexen in the rendering functions, to my surprise it uses the same rendering as Psx Doom, I managed to implement that code in PsxDoom and here some results, enjoy the video.

Nice work! That removes a very annoying limitation for mapping and the need for hacks like razor thin 'steps' to give the illusion of higher walls (like in the 'O Of Destruction').

Does Hexen split up the wall columns the same way that PSX Doom was forced to do for the floor spans, to get around the hardware texture coordinate limitations? I always wondered why PSX Doom never attempted to extend that idea to wall columns, might have saved the mappers a lot of trouble in various levels. Perhaps a product of tight deadlines or concerns over performance (due to added draw primitives) - who knows...

3 hours ago, intacowetrust said:

 

Nice work! That removes a very annoying limitation for mapping and the need for hacks like razor thin 'steps' to give the illusion of higher walls (like in the 'O Of Destruction').

 

Does Hexen split up the wall columns the same way that PSX Doom was forced to do for the floor spans, to get around the hardware texture coordinate limitations? I always wondered why PSX Doom never attempted to extend that idea to wall columns, might have saved the mappers a lot of trouble in various levels. Perhaps a product of tight deadlines or concerns over performance (due to added draw primitives) - who knows...

Erick said in the GEC Discord that it did sub-clipping. If that answers your question, then there you go.

As for why it didn't? PSX Doom was a pretty early title, don't forget (so early it was originally a big box game). The hardware was relatively new and not quite fully tapped. My guess is that by the time PSX Hexen came around, devs had a better handle on what it could do and how to manage things.

Incredible developments!

Interestingly, it was possible to take useful stuff from the PSX Hexen, and it works.

Also I just mention that it would be more advisable to release a new version of tools and test build before Beta 4, so that mappers can determine which levels may fits arch-vile or make any other changes.

Does PSX Hexen have any speed or memory optimisations?

11 hours ago, Dark Pulse said:

Erick said in the GEC Discord that it did sub-clipping. If that answers your question, then there you go.

 

Cool, yeah that sounds more or less like what I was describing.

11 hours ago, Dark Pulse said:

As for why it didn't? PSX Doom was a pretty early title, don't forget (so early it was originally a big box game). The hardware was relatively new and not quite fully tapped. My guess is that by the time PSX Hexen came around, devs had a better handle on what it could do and how to manage things.

Yeah I'm aware of that. My point was that they already solved more or less the exact same problem for floor spans (see visualization here of the floor span splitting) so I was curious why they didn't just apply the same solution to wall columns also. Either it was extreme time limitations or the devs were concerned about potentially doubling or tripling (or more) the number of triangles being thrown at the GPU for walls in certain scenes - that already seemed like a bottleneck as it was given the way the renderer works.

Hexen on the PSX from what I've read was also pretty poorly optimized and suffered from a lot of frame rate issues - so probably not a shining example of pushing the hardware to it's limits for later titles. Certainly not when you compare it to something like Hammerhead's superb port of Quake 2, for example.

Just now, intacowetrust said:

Hexen on the PSX from what I've read was also pretty poorly optimized and suffered from a lot of frame rate issues - so probably not a shining example of pushing the hardware to it's limits for later titles. Certainly not when you compare it to something like Lobotomy's superb port of Quake 2, for example.

Considering I owned both games, it's most definitely nowhere near close to PSX Quake 2, lol. And yes, PSX Hexen was the worst of the three contemporary ports (the N64 one is generally held as best, with Sega Saturn somewhere inbetween).

Though I think you made an oopsie - Lobotomy did Saturn Quake 1; Quake 2 never made it to Saturn. PSX Quake 2 was done by Hammerhead.

31 minutes ago, Dark Pulse said:

Though I think you made an oopsie - Lobotomy did Saturn Quake 1; Quake 2 never made it to Saturn. PSX Quake 2 was done by Hammerhead.

Ah yes sorry - you are right, mixing up the port devs heh...

Mining Colony, There is no spider mastermind. instead there are nightmare mancubus guarding the red keycard

On 4/26/2020 at 6:21 PM, Erick194 said:

A data of high interest, the Archvile only consumes (262.3Kb) of RAM

Is there any way to optimize that futher? Using 5 rotations instead of 8? Sacrificing a bit of the animation? It might be useful for maps that have plenty of enemies.