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

[Job]

Awesome work, everyone, keep it up! It's times like this that I'm really proud of our community. :) 

[DynamiteKaitorn]

Thanks. It's not easy converting.

[Job]

I can only imagine. It must be extremely challenging to try something even the original developers walked away from. There's a lot of limits and constraints to work with. 

[DynamiteKaitorn]

I just wanna ask guys, what's the height limit for a PSX map? (As in what's the actaul height limit before the game just dies and what is a recommended max height so that texture stretching doesn't start to glitch out)

[Dragonsbrethren]

Textures will only tile one time vertically (256 height), any taller and they stretch. This can be worked around with extra sectors, conceivably you could do 768 tall, although I haven’t tried using midtextures. It’s certainly easiest to not go above 256 unless absolutely needed.

 

To offset wall textures vertically, positive values must be used for lower/mid textures, and negative values for upper. Don’t set both upper and lower unpegged on the same line. Lifts have additional stretching issues on the 1 sided lines bordering the moving sector.

Edited June 30, 2018 by Dragonsbrethren

[Dragonsbrethren]

Oh, one more thing about using border/dummy sectors: two sided lines in the console Dooms have less precise collision detection. Running along one of these walls will “feel” wrong. Sometimes feel matters, especially if it’s an area where you want smooth movement, for example an encounter where you have to do a lot of dodging.

[Gerardo194]

6 hours ago, Job said:

Awesome work, everyone, keep it up! It's times like this that I'm really proud of our community. :) 

Thank you very much @Job I'm very glad seeing people helping to make this project a dream come true; thank you guys. I'm also gonna start converting maps with my brothers and testing the sent maps we have. I've seen great results so far. 

GEC has more surprises coming soon.

 

[Dark Pulse]

Question for @Erick194, what's the difference between Sector Types 4 and 16? Both say "Damage -10 or 20% health."

 

If this is based on the original engine's numbers (which it seems to be, up to 17 - then it gets custom ones), 4 should also mention the light blink.

 

Anyway, progress is going nicely in Dis (which I began doing to take a break off Open Season), but unfortunately there's a bit of typical PS1 "garbage" on the main floor of the arena due to texture warping and breaking. Not sure if I can do much about that short of shrinking the arena, and that's a little hard to do with the Spider Mastermind.

 

I'm working on solutions, though.

[DynamiteKaitorn]

I mostly asked because I MIGHT give chasm a try. [Map 24 of DooM 2] (no guarantees yet, Just wanna do some testing before I leap into it)

[DynamiteKaitorn]

Interesting fact:

It is possible to load a PSX DooM map with all 255/256 sector colours loaded at the same time.

 

Also: Count me in for Map24! Chasm I will take! :D

[DynamiteKaitorn]

So err.. here's my update for Chasm so far:

Looking good so far! And no crashes with this insane size! (Even AFTER I shrunk it down a little)

 

However... the map isn't perfect:

 Not fully sure what is going on with this linedef error.

 

Also a funny glitch I found. I'm not sure I can ever fix it due to bad coding but you know how in DooM/DooM 2 you can re-use ANYTHING that is SR-based? well...

I managed to get this floor to raise so high that it started to glitch out.

After raising it some more (took a good 5-10 minutes just to get this far). I noticed barely any slowdown and no crash so far.

 

 

I then decided to save-state with ePSXe. All well and good. Then I continued playing, saved on a different state, died, loaded that state and CRASH. So what's the lesson here? Don't play with glitches.

[riderr3]

Well, I have many interesting errors and glitches in Manor and Habitat, but I've managed to eliminate all of them.


Some walls begin to disappear dynamically(!) if you stand at certain points. Fixed by removing the window inside the library, and this is the only one removed window in the map. Loose-based Lost Levels TC have many windows removed as example.


Don't try to put COMPTALL on upper texture.


This can happened if the sky ceiling is lower than some nearby sectors. (reminds me of MAP12 glitch on Doom Legacy)

Habitat at the first run exits with error "P LoadLeafs: leaf/subsector inconsistancy" because of empty leafs lump, rebuilding nodes is helped. I lowered the number of linedefs/sectors much, but only the optional ones were affected. As the chaingunner is removed, a chaingun was added in several places.

Also @Erick194 I've searched an automated way to convert pc texture/flat names to their PSX derivatives (and vice versa), like ASHWALL2>ROCK14  (tired of UNKNOWN textures which needs to be replaced manually). It seems to be possible with text/hex replacers in binary files, without changing file size. I've tried REPL.BAT but I can only replace only one value. Maybe this will be an idea for someone who can find the way how to do it. Anyway, a variety of textures will later need to be reduced manually for VRAM.

P.S.

5 hours ago, DynamiteKaitorn said:

Looking good so far! And no crashes with this insane size! (Even AFTER I shrunk it down a little)

 

 

Also a funny glitch I found. I'm not sure I can ever fix it due to bad coding but you know how in DooM/DooM 2 you can re-use ANYTHING that is SR-based? well...

 

I hope there are not much slowdowns at this place. That is important on that ledges.

And also WR raise platforms have unpredictable behavior if the action used multiple times.

 

Edited July 7, 2018 by riderr3

[Dexiaz]

1 hour ago, riderr3 said:

Some walls begin to disappear dynamically(!) if you stand at certain points. Fixed by removing the window inside the library, and this is the only one removed window in the map. Loose-based Lost Levels TC have many windows removed as example.

 

So, your version is not based on mine?

Edited July 7, 2018 by DeXiaZ

[Dragonsbrethren]

I had what I can only describe as a Ghost Lost Soul today, although it's not exactly equivalent to the ghost monster bugs on PC: A Pain Elemental spawned a Soul at me. I think what happened was it clipped through a thin wall (16-32 units) into the next room. I've seen Lost Souls get stuck behind 1s linedefs plenty of times in this engine, but never the result of one making it through two lines: It was still solid, could still attack me, but could not be hit by hitscans/projectiles.

[riderr3]

45 minutes ago, DeXiaZ said:

 

So, your version is not based on my?

In fact, yes, my version is closer to the original (except lowered sky ceiling and some minor changes in blue key room). Also not sure why LL version have redesigned barn (wall removed). My screenshots above quite old though.

Edited July 7, 2018 by riderr3

[CoTeCiO]

3 hours ago, riderr3 said:

I've searched an automated way to convert pc texture/flat names to their PSX derivatives (and vice versa), like ASHWALL2>ROCK14  (tired of UNKNOWN textures which needs to be replaced manually). It seems to be possible with text/hex replacers in binary files, without changing the size. I've tried REPL.BAT but I can only replace only one value. Maybe this will be an idea for someone who can find the way how to do it. Anyway, a variety of textures will later need to be reduced manually for VRAM.

I've been using dm2conv for that. I use it to replace textures and a couple specials and items, you can define the name of the texture you want to replace with anything, the same with specials and objects, it's quite versatile. Then I use find and replace to look for similar textures (select the option to show used textures on top, it's a huge time saver) and reduce the texture usage.

 

Unfortunately, that program runs in DOS, so you need DOSBox to use it in any 64-bits system and I don't think it would work with UDMF maps. Hexen format, maybe? Haven't tried.

 

It'sthe closest I could find to "prepare" a map to be inserted into PSX Doom. Hopefully someone else knows about a more modern alternative.

[Dragonsbrethren]

I've just been using the find and replace mode in GZDoom Builder. I prefer it to a blanket find and replace since it shows where the texture/flat is used.

[Dark Pulse]

Nice to see updates after a week of silence!

 

I've gotten my third map (TNT's MAP05: Hanger) into the engine, though honestly it took quite a bit of work. This is definitely a map that disproved my older post on the limit for MAPSPR01.IMG; even at the "safe" limit of ~800KB it just wasn't allocating due to the complex map, resulting in me chopping a few (little-used) monster types to get it down to 676KB, but now it runs, and aside from one or two rooms, performance is actually really good throughout. Progress was also made slower by that after working on one version of it for awhile, I eventually ran into some serious texturing problems with the outer courtyard (they were getting horrendously stretched), so I restarted from scratch, then had to go through a whole bunch of texture alignment fun due to the new texture scheme and the fact that the original's alignment wasn't particularly great in a lot of places, anyway.

 

Don't really have anything to show, though, since while I've gotten it up and running, I haven't gotten to coloring the sectors yet. (Almost ready to start that though, I'm just trying to get those last few textures aligned and triple-checking to make sure I haven't goofed - it's a lot easier to spot mistakes with normal Doom lighting than colored sectors.)

 

The two main areas that have framerate problems are the room where you get the blue key (though it's not too bad, it's noticeably slower), and the room where you have the room that rolls down the walls to expose you to the outer courtyard. Framerate is clunky there when looking out towards the courtyard, and ESPECIALLY gets slow when that wall opens up and you look out towards that direction. I'm kind of at a loss as to how to simplify this (my original pre-do over version of the map couldn't really improve this either and I tried some fairly radical geometry improvements there), so I figured I'll ask a few of you guys for your thoughts (since I'm not allowed to show video to demonstrate how it runs). The choices are:

1. Just leave it as-is, since while it's definitely slow and clunky and maybe 10 FPS, the official maps do have maps with similar framerate problems in spots, and you're only in here a relatively small chunk of the time - most of the map is actually quite nicely performant.
2. Prevent the wall from opening to the courtyard, this does improve FPS to maybe 15-20 or so but it removes some of the "gotcha" factor and lets the player fundamentally control their courtyard exposure, unlike before. Generally makes the slowness more tolerable, but it's not entirely gone (and may never be). That said, I could possibly get it performing better if I make them one-sided linedefs as opposed to my earlier idea of just disabling the trigger (which kept the linedefs as two-sided - it just never opened).
3. Radically redesign the room until it somehow does a decent framerate (but it will always be slower as this is one of the bigger areas of the map).
4. Some combination of 2 & 3.

There is the possibility that letting your emulator overclock the virtual CPU may do some benefit, but obviously I'm assuming a normal speed one so as to simulate how it'd be on an actual Playstation.

 

The courtyard area actually runs surprisingly well, although I did have to simplify it slightly, otherwise it'd bomb out from point overflows. It runs far faster than the room that connects to it, which is kind of surprising since it's much bigger, and actually generally has more complex geometry.

 

Hopefully I'll have some screenshots in the next few days.

[DynamiteKaitorn]

@Dark Pulse I vote 1!

[Dragonsbrethren]

I'd go with 2. The unaltered PC maps already exist, so I'd rather see a more playable framerate on the PlayStation. This is the choice I made in Caged and Power Control--the levels were certainly playable with the original geometry, but I opted to add walls/remove windiows and slightly rearrange a few sections to increase the framerate anyway.

[Erick194]

Hello folks, it's good to see your progress, we almost have Ultimate Doom done, here's a pic of a possible menu for the final game.

 

 

Besides, here are screenies of the map Fear:

 

 

 

[riderr3]

8 hours ago, CoTeCiO said:

I've been using dm2conv for that. I use it to replace textures and a couple specials and items, you can define the name of the texture you want to replace with anything, the same with specials and objects, it's quite versatile. Then I use find and replace to look for similar textures (select the option to show used textures on top, it's a huge time saver) and reduce the texture usage.

 

Unfortunately, that program runs in DOS, so you need DOSBox to use it in any 64-bits system and I don't think it would work with UDMF maps. Hexen format, maybe? Haven't tried.

Thanks, I'll try. Dosbox does not frighten me, since it's one of the most used applications I have.

 

6 hours ago, Dark Pulse said:

 

1. Just leave it as-is, since while it's definitely slow and clunky and maybe 10 FPS, the official maps do have maps with similar framerate problems in spots, and you're only in here a relatively small chunk of the time - most of the map is actually quite nicely performant.
2. Prevent the wall from opening to the courtyard, this does improve FPS to maybe 15-20 or so but it removes some of the "gotcha" factor and lets the player fundamentally control their courtyard exposure, unlike before. Generally makes the slowness more tolerable, but it's not entirely gone (and may never be). That said, I could possibly get it performing better if I make them one-sided linedefs as opposed to my earlier idea of just disabling the trigger (which kept the linedefs as two-sided - it just never opened).
3. Radically redesign the room until it somehow does a decent framerate (but it will always be slower as this is one of the bigger areas of the map).
4. Some combination of 2 & 3.

 

I vote for 2. Especially I never liked that window which suddenly opens when I have already closed it. Player is anyway need to fight with monsters on the other side.

 

1 hour ago, Erick194 said:

Hello folks, it's good to see your progress, we almost have Ultimate Doom done, here's a pic of a possible menu for the final game.

 

 

 

This sub-menu intrigued me.
Also background color looks suitable.

 

[Gez]

17 hours ago, riderr3 said:

Also @Erick194 I've searched an automated way to convert pc texture/flat names to their PSX derivatives (and vice versa), like ASHWALL2>ROCK14  (tired of UNKNOWN textures which needs to be replaced manually). It seems to be possible with text/hex replacers in binary files, without changing file size. I've tried REPL.BAT but I can only replace only one value. Maybe this will be an idea for someone who can find the way how to do it. Anyway, a variety of textures will later need to be reduced manually for VRAM.

SLADE 3's "replace in maps" feature can do this. (Archive->Maintenance->Replace in maps)

[Danfun64]

Am I the only one that thinks that the only psx emulators that should be allowed for this project are XEBRA and Mednafen/Beetle (Not HW)? I'm reminded of the Super Mario 64 scene, where most rom hacks can't run even with relatively accurate emulation like the Angrylion video plugin, let alone real hardware. As for why I'm excluding epsxe from being considered acceptable... http://emulation.gametechwiki.com/index.php/PS1_Tests

 

Quote

This is a small collection of tests looking at very specific areas of the PlayStation's hardware. It was originally useful to see what emulators had happened to accurately implement for these specific edge cases. However, these tests have also been a target for many developers to build their reputation. The ePSXe project, a closed-source emulator, deliberately targeted these tests for 2.0.0 and, at the time of release, a developer edited this page in their favor. This demonstrates that they intend to dodge accuracy rather than ensure it, as the specific plugins and settings used to get the following results would actually cause more bugs in commercial games. This is another reason why it is not recommended.

 

[riderr3]

What about the official built-in emulator PS1 on PSP? PSP's MIPS R4000-based CPU is running most of the PS1's R3000 code natively. I did a few tests and sometimes it it even runs little more faster than ePSXe.

Anyway, GEC knows more than we can guess.

[CoTeCiO]

2 hours ago, Danfun64 said:

Am I the only one that thinks that the only psx emulators that should be allowed for this project are XEBRA and Mednafen/Beetle (Not HW)? I'm reminded of the Super Mario 64 scene, where most rom hacks can't run even with relatively accurate emulation like the Angrylion video plugin, let alone real hardware. As for why I'm excluding epsxe from being considered acceptable... http://emulation.gametechwiki.com/index.php/PS1_Tests

Well, I used ePSXe to test my maps. It's less resource intensive, I'm more accustomed to the interface, and it's easier to load a game.

 

Mednafen uses a command line, really?! I have to mount the image with Daemon for XEBRA to work and I still don't get the Retroarch's interface, I've quitted the freaking thing a million times by pressing Esc trying to go back and I never got Beetle to load the image and no, I'm not up to look up for tutorials to use a damn emulator, they should be intuitive already these days. I expect to load the image and get something else rather than "can't load content" or whatever.

 

Not all of us got gaming-grade (or even decent) computers to run accurate emulators, you know... My PC crawls with Bizhawk running SMW, so I can't even think on using an accurate PSX emulator. I'm in the middle of doing repairs in my house, I can't afford a new computer. That should kick me out of the project?

 

So far in my tests I've noticed no difference in the limits, if it crashes on the real thing, it crashes in ePSXe, and viceversa. And if there's a speed difference, it's unnoticeable for me. It might be faster, but not enough to make a drastic difference that might actually make a map unplayable on the console while it runs smoothly on ePSXe.

 

There was only one thing that kept the maps working on the console that I myself exposed, a small structural difference in map WAD files, which was already fixed. I've been testing some of my maps builds on the console itself (far better than the emulators, anyway) and ePSXe is accurate enough for this. The maps we're working in are pretty much guaranteed to work on the real thing and run as good or bad as they run on ePSXe.

 

That's not saying ePSXe is the best emulator for this, some guys are already using XEBRA and Beetle, but ePSXe is good enough.

 

As for the final build, I'll be the first one to grab it, CD-R in hand, and test in the console and report anything that doesn't work, as I've been doing during the whole project, but the whole coding thing is the work of the GEC guys, so it's up to them to work with any compatibility issues in the end, we're just making the maps and that part is already covered.

[Danfun64]

3 hours ago, riderr3 said:

What about the official built-in emulator PS1 on PSP? PSP's MIPS R4000-based CPU is running most of the PS1's R3000 code natively. I did a few tests and sometimes it it even runs little more faster than ePSXe.

3

Another page on the Emulation Gametech wiki suggests that Mednafen/Beetle and Xebra has surpassed even the PSP PSX emulator in accuracy, but I have no real source to confirm or deny that. It might (keyword being might) be a better choice than epsxe though. 🤷‍♂️

[Dragonsbrethren]

My levels run fine in Xebra with the exception of Downtown, which I knew was pushing limits. I just have to load the binary file instead of the cue sheet in that emulator. It's slow to load them compared to the stock maps, though, which is really annoying. I'm not sure what Mednafen/Beetle's issue is, I get a warning about slow disk access.

Edited July 9, 2018 by Dragonsbrethren

[Dark Pulse]

11 hours ago, CoTeCiO said:

Mednafen uses a command line, really?! I have to mount the image with Daemon for XEBRA to work and I still don't get the Retroarch's interface, I've quitted the freaking thing a million times by pressing Esc trying to go back and I never got Beetle to load the image and no, I'm not up to look up for tutorials to use a damn emulator, they should be intuitive already these days. I expect to load the image and get something else rather than "can't load content" or whatever.

Mednafen is probably easier to run via RetroArch, which has Mednafen as one of the PS1 "cores", under the guise of Beetle PSX. (There's also a hardware renderer based version, Beetle PSX HW, that's OpenGL-accelerated, but apparently it's still considered an alpha.) What's probably throwing you off is that it will be expecting a BIOS - both EPSXE and Xebra can now run without the BIOS, but the compatability and accuracy might be lower.

 

That said, Xebra is probably the most accurate of the lot. EPSXE is fine for quick testing, but if we're going to do torture-level testing and to make it as hack-free as possible, Xebra would be the emulator to test against since it's based on reverse-engineering of the PS1 hardware, assuming we don't have access to actual PS1s (since hard or soft-modding those is relatively easy) and people who are willing to test all the maps on actual hardware (which would be no small feat, since there's a lot of maps and a lot of work involved - especially if it's an edge case that's tricky to trigger). A PS2 in PS1 mode may or may not do the trick - it's got all the hardware, but getting it to read a burned disc would be trickier unless it's a flip-top model PS2, or you use those good ol' disc tray tools.

 

The only other alternative around this would be if they basically did what Quasar did with Calico - backport the PS1 engine into its own "source port" that runs on PC, with an aim of 1:1 accuracy. The PS1 port was based on the Jaguar port, after all, and the codebase for that is public, so combined with reverse-engineering, that may be possible to do - albeit, it would probably be quite a bit of work. The upside of that though would be that it'd allow for this creation process to be much easier, as we'll have guts-level access and could then add in all sorts of debug stuff.

 

EDIT: Kaiser and Quasar apparently discussed that at one point, not much seems to have come of it though, but AFAIK they're both busy with commercial projects too.

Edited July 9, 2018 by Dark Pulse

[Lollie]

21 hours ago, CoTeCiO said:

Mednafen uses a command line, really?! I have to mount the image with Daemon for XEBRA to work

I emulate PlayStation a ton, so I'm quickly chiming in here with a couple tips:

 

Mednafen supports loading games via drag-and-drop. Simply drag your .cue file onto Mednafen.exe, and it should automatically load the image with the correct emulation core. Quick and easy.

 

XEBRA shouldn't require images to be mounted. File > Open > "CD-ROM image". You may need to select the .bin file - like Dragonsbrethren said, XEBRA is extremely slow at loading .cue files.

 

Mednafen is pretty damn accurate these days, and great on performance. I used to love XEBRA myself, and there's no doubting its accuracy, but in my experience performance tends to be a bit sluggish - I'd argue only using XEBRA to double-check compatibility.

Edited July 9, 2018 by Lollie