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

[Tristan]

Also bear in mind revenants weren't a blanket replacement for arch-viles - the very first one (in O of Destruction) was replaced by an arachnotron.

[Kloki38]

I would like to reserve these maps :

 

TNT :

 

Level 8: Metal
Level 19: Shipping/Respawning

 

Plutonia:

 

Level 8: Realm

[marver0PS]

What does enconding do?

[CoTeCiO]

7 minutes ago, marver0PS said:

What does enconding do?

It compresses WAD files. WAD files in PSX Doom are compressed, but GZDoom Builder doesn't like compressed files, so, to manipulate them and then reinsert them in the CD image, you need to decompress them and then compress your modified file. For the time being it isn't of much use for this project as decompressed files work perfectly fine, but I guess it will be very useful when doing the final build.

[marver0PS]

Making some progress on E4M6, the main "pool" area still lags a lot.

 

 

[mrthejoshmon]

I have a quick question, I'd love to help with this (it's a dream come true) but I need to know if the provided files and executables are Windows XP compatible, I'm running on ancient obsolete hardware here so I might not be able to help if these are not XP compatible.

[Erick194]

 

 

I suppose the programs are compatible, but I do not know if the gzdoom builder is compatible. Try downloading and trying them.

[Dragonsbrethren]

Caged is nearly done, outside of some texture rendering oddities that I need to work out. Interestingly, I feel like a lot of the changes I made for the Lost Levels weren't actually needed--I probably could've kept the sector heights the same as the PC version of the map, but I really liked how that conversion turned out, so I applied most of its changes anyway. The sight blocking walls keep the framerate much more stable than the direct PC conversion and make the level a little more fair with a gamepad...it's still tough as nails on UV, though. Losing the Revenants and Mancubi is hardly a big deal.

 

 

One new change, however, has been shifting the northern section of the map with the yellow door west 112 map units. Unlike the new wall in Well of Souls, this wasn't strictly necessary, but it's a little change that significantly improves the framerate when returning to the start area.

Edited June 22, 2018 by Dragonsbrethren

[riderr3]

On 6/21/2018 at 6:39 PM, Gerardo194 said:

Edit: @riderr3 the "cache miss error on lump 703" error is happening because a sprite hasn't been inserted at all. Leave it like that, my brother will fix it later when gets home. 

In my case it's happened just because I compress wad BEFORE makeimg (it even not needed to be compressed). Now map playable and maxable, I've added colorings for sectors. Also I need to reduce some steps to get more stable framerate at the courtyard.

Some other opinions:
-important quirk of PSX DOOM engine is possibility of activating actions if the action line too near, as example on TNT:MAP10 now I can lower red bars from the other side or just open hell knight closet through the outdoor wall! So all who converting maps should bear in mind that they need to check situations like this and make changes to map.
-negative texture offsets leading to stretching/reversing textures.
-"Reverb off" sector flag should be applied to outdoor areas (according to original PSX maps).
-in original PSX maps there is "line block projectile" flag used on some glass windows, but not many of them.
-in MAPSPR01.IMG there is a limit, the output should be about no more than 730kb, otherwise ZMALLOC error will happen. You probably need to sacrifice some sprites to make space for this or that thing. Anyway, it would be convenient to see used sprites and free space in VRAM Viewer.
-monsters on plutonia maps can be slightly nerfed, according on PSX controls and speeds.

About monster usage. Now I understand why mancubus is rare kind in PSX DOOM. Because his sprite is big and used many space in VRAM, along with spiderdemon. So if you use fatso on your map, get ready to sacrifice two another monster types. Baron is also high consumption, especially when you can use hell knight even in Ultimate Doom maps. I've used nightmare HK in my case.

@Erick194 I found crash in map editor, when map have no sky, GZDB crashes.
The DoomED thing 50 (hanger) have chain hook sprite.
Also I hope there are more automated tools will available to build image without many hassle (batch files, e.t.c.)
 

Edited June 22, 2018 by riderr3

[Dragonsbrethren]

Adding onto @riderr3's list:

 

• Doors require negative texture offsets to avoid scaling
• Midtextures will tile vertically in sectors taller than 128 units. I still haven't determined how Ballistyx avoided this issue; the only way I've been able to work around it is to lower the sector's ceiling.
• Sprites get clipped by the PSX renderer's equivalent of visplanes, areas where sector properties change. It's impossible to avoid this for all things, but static ones like item pickups can be moved to minimize it in most locations. (I don't think visplanes are the right equivalent here, it might be the leafs structure? Regardless, there is consistent clipping that can be avoided by moving things.)
• Lowered sky sectors will render higher sectors behind them, sometimes even if those sectors aren't directly connected.

 

Speaking of tiling midtextures and lowered skies, dropping the sky height on both sides of this gate is how I worked around the vertical tiling on Caged.

Edited June 22, 2018 by Dragonsbrethren

[marver0PS]

43 minutes ago, Dragonsbrethren said:

Adding onto @riderr3's list:

 

• Doors require negative texture offsets to avoid scaling
• Midtextures will tile in sectors taller than 128 units. I still haven't determined how Ballistyx avoided this issue; the only way I've been able to work around it is to lower the sector's ceiling.
• Sprites get clipped by the PSX renderer's equivalent of visplanes, areas where sector properties change. It's impossible to avoid this for all things, but static ones like item pickups can be moved to minimize it in most locations.

Also midtextures that are only applied to one side and then set to render will glitch.

 

Like this screenshot of E4M6's Plasma gun secret:

 

 

 

Edited June 22, 2018 by marver0PS

[riderr3]

47 minutes ago, Dragonsbrethren said:

Midtextures will tile vertically in sectors taller than 128 units. I still haven't determined how Ballistyx avoided this issue; the only way I've been able to work around it is to lower the sector's ceiling.

There are "Render Mid-Texture" line flag can be toggled. Maybe it should do it? If not, what it is actually do. I've used glass window midtexture without that flag.

Edited June 22, 2018 by riderr3

[Danfun64]

I'm curious if it will be possible to hack the Icon of Sin back in, with all its behaviors. *shrugs*

[Dragonsbrethren]

The render midtexture flag does exactly what it says: Without it, midtextures won't be rendered at all.

[DynamiteKaitorn]

Is there a limitation on how may different textures (both in terms of flats AND walls separately) I need to keep an eye on? (like only 10 flats or 12 wall tex, etc...)

[Dragonsbrethren]

Yes. You're limited to a max of 16 flats. For wall textures, it depends on the width of the textures you're using. Go to Mode -> Vram Viewer Mode in GZDoom Builder and make sure no textures are going into the green highlighted area.

[DynamiteKaitorn]

Now sure how the viewer works. Doe it update as I use ePSXe or is it just a handy guide whislt mapping?

 

EDIT: First attempt at converting the map boi! :o

[Dragonsbrethren]

Just while mapping. PSX Doom caches all of its textures, what you see in the VRAM viewer is what will be loaded at all times. Only sprites are loaded into VRAM dynamically.

[CoTeCiO]

8 minutes ago, DynamiteKaitorn said:

Is there a limitation on how may different textures (both in terms of flats AND walls separately) I need to keep an eye on? (like only 10 flats or 12 wall tex, etc...)

Apart from what @Dragonsbrethren said, keep in mind that the VRAM viewer considers the second frame of only one of the switches you got on your map (or something like that), so if your map got two switch textures, you will see it using three slots when in reality it uses four, so keep that in mind. Animated textures don't seem to use multiple slots, but the animation will freeze if you are over the limit with the textures.

 

I've also noticed that in rare ocassions, the VRAM viewer doesn't update when you remove a texture from your map (as, replacing all instances of that texture for another) and keep appearing even when it's no longer there. If that happens, close the map and open it again.

[Dragonsbrethren]

The VRAM viewer has always properly shown both frames of an animated switch for me:

 

[CoTeCiO]

3 minutes ago, Dragonsbrethren said:

The VRAM viewer has always properly shown both frames of an animated switch for me

Yeah, it works fine for one, but if you add another switch, it tends to just show the "off" frame of the switch and ignore the "on" one, so you get one complete switch with both frames, and another with just one, but the game actually load both switch textures with both frames, and thus you get corrupted textures even when the VRAM viewer shows everything is ok.

 

For example, the following map would not load the door texture, even when it looks fine here.

[Dragonsbrethren]

Looking at Well of Souls, you're correct, the second frame of SW1SKUL2 isn't showing. I don't think I ever checked the viewer after I added that switch, I just knew I needed to free up two textures for it.

[marver0PS]

I keep getting "P loadblocks: data failure" while trying load (Final Doom). Does anybody know what this error is?

[RichardDS90]

Might be a long shot, but some of the map changes that happen on this project also be reflected onto the original PSX Lost Levels mod?

[Erick194]

3 hours ago, marver0PS said:

I keep getting "P loadblocks: data failure" while trying load (Final Doom). Does anybody know what this error is?

 

@marver0PS Remember to copy the PSXDOOM.WAD from PSX Final Doom, in the MEKEIMG folder. When creating maps for PSX Final Doom.

 

9 hours ago, riderr3 said:

@Erick194 I found crash in map editor, when map have no sky, GZDB crashes.
The DoomED thing 50 (hanger) have chain hook sprite.
Also I hope there are more automated tools will available to build image without many hassle (batch files, e.t.c.)

4 hours ago, CoTeCiO said:

Yeah, it works fine for one, but if you add another switch, it tends to just show the "off" frame of the switch and ignore the "on" one, so you get one complete switch with both frames, and another with just one, but the game actually load both switch textures with both frames, and thus you get corrupted textures even when the VRAM viewer shows everything is ok.

 

For example, the following map would not load the door texture, even when it looks fine here.



I will correct the errors of Gzdoom Builder, I will update it when I have it ready.

Edited June 22, 2018 by Erick194

[Dragonsbrethren]

5 hours ago, Salahmander2 said:

Might be a long shot, but some of the map changes that happen on this project also be reflected onto the original PSX Lost Levels mod?

I’d like to see that. Lost Levels was always intended to be an authentic project. I feel like the final call is out of my hands, though, I was too busy to properly manage the project so it was no more mine than anyone else who contributed.

[CoTeCiO]

Guys, I just discovered something when hacking maps to a stock PSX Doom (that means, no PSXDOOM.EXE hacking).

 

If you replace a map for another that has different textures than the original, it won't run on the console even when it does on an emulator, it will freeze on the Loading screen (just like some of you saw when trying your own maps). You can try that by editing MAP01 and changing one texture for another and trying to run it. Probably it will run fine in ePSXe, but it will fail to run on the console and probably other emulators. That means for this project to finally work on a real hardware, the texture cache must be taken into consideration, a dummy file is not enough. Apart from that, maps take quite a lot longer to load when they use textures outside the cache.

 

That might mean that the real problem with running maps made for this hacked version on the console and some emulators are not the sprites, the maps, the modified EXE or the generated disc image, but the missing texture cache. I'll try to find a way to test this further.

 

Do anybody knows what emulator is the most accurate one? I need something like the Chocolate Doom or the bsnes for the PSX.

[Dragonsbrethren]

I believe Mednafen/Beetle holds that title now. It used to be the horribly (or brilliantly?) named pSX Emulator.

[CoTeCiO]

I GOT IT! I finally got it!! I found out why maps don't work in the console/Xebra/Beetle and got it fixed!

 

I decompressed the stock MAP01 and recompressed it and that's what it took for the game to lock at the loading screen. So I started looking for differences in the original MAP01 and the recompressed one and I noticed one difference right away. In the original, the BLOCKMAP lump is 6802 bytes and in the recompressed one is 10 bytes. The information from the 10 bytes version is nowhere to be found in the 6 KB one, but none of the custom maps I did have this truncated BLOCKMAP, and yet still they don't load, so I guess that's kind of a bug from the encoder? I don't know, but that was not the problem.

 

Upon checking both files side by side on a hex editor I noticed one difference apart from the BLOCKMAP thing. Some lumps in the original had extra bytes around that the recompressed one didn't and that reminded me of something @Kaiser noticed:

 

Quote

The IWAD has no major change, except all the lump positions/offsets are always in multiples of 4. This is the same for all console ports.

 

In other words, the beginning of the data of every lump must be on an address that is a multiple of 4. I painstakingly edited a PC-ported Hangar map I did in a hex editor and calculated that every address was a multiple of 4 in the index and then added the necessary bytes in the data for everything to fit and lo and behold, it worked!!

 

This is very important for the project and I'd like to ask @Erick194 to work on making the encoder do this address padding thing. It's the only thing keeping this from working on the real hardware. Unfortunately, no WAD editor consider this, at least that I know of, so GZDoom Builder also break the maps, and I don't know if it's possible to add such a thing to the software (I checked, and uncompressed maps also work when padded).

 

Oh, by the way, all the stuff I said before about the texture cache... Forget about that, it's all debunked now. The game actually load the textures from the main IWAD if not present in the cache on the console as well. But I want to say that I got a Z_MALLOC crash when trying to enter the fourth custom map when playing on ePSXe, all of them using textures outside the cache and loading correctly on their own by either password or warp cheat, so considering implementing the texture cache for MAKEIMG would be a wise idea nonetheless.

 

So, it's 6:07 AM here and I'm finally gonna get some sleep. This problem kept me awake all night! Talk to you all tomorrow!

 

Here's a picture of my ported E1M1 (note the blue floor instead of brown) running on the console! Excuse the cable mess, but you gotta love that little old-school CRT!

[Gerardo194]

@CoTeCiO that's great but we have already run edited maps on the real hardware, e.g. New Hangar map that was shown in a recent video.