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

[intacowetrust]

On 4/26/2020 at 7:59 AM, Dark Pulse said:

Basically, any map with Pain Elementals, if you give them enough time, will eventually crash the game due to how many Lost Souls get spawned. I'm not sure if PS1 Doom has a limit just like PC Doom does - I'd hope so. If not, then maybe Erick needs to add one to the re-engineered project.

 

Just on this, @Erick194 asked me to confirm some strange code for Pain Elementals in the PSX version and I was reminded of this comment. Basically what I found was that the PSX code was trying to limit the number of Lost Souls but unfortunately the logic was broken and it ended up not enforcing that limit at all. The engine can spawn as many lost souls as it wants until it crashes...

 

Long story short, it looks like some changes made for the Jag version were incompatible with the Pain Elemental code taken from Doom 2 on PC and caused the Lost Soul limit check to silently fail. For those who are interested, I've added more on this in the comments for 'A_PainShootSkull' in PsyDoom:

https://github.com/BodbDearg/PsyDoom/blob/c3dd02df16d30d5102d8fb56f5cec6c92db8b937/game/Doom/Game/p_enemy.cpp#L970

 

For PsyDoom I'm going to leave this bug alone, as fixing it might result in some demo de-sync and vanilla incompatible behavior. Eventually I will not be so constrained by memory, so it's not really a problem... Up to @Erick194 however whether he wants to fix the bug for this project; if it's a crashing problem on some maps then maybe losing a small bit of demo compatibility it is worth the end result?

[Gez]

As a compromise, maybe fixing the bug but increasing the limit would work? Say like 60 or 80 lost souls max maybe. Depends on memory constraints and how many extra lost souls can the average level support before running out of memory and crashing. It should leave most demos just fine.

 

Alternatively, replace it with a memory check, and don't spawn lost souls if there's less than X free memory left. Exact value needs some padding to account for stuff like rockets and fireballs being spawned without any check.

[Redneckerz]

On 5/18/2020 at 8:25 PM, riderr3 said:

 

I assume that people again confuse GEC GZDoom source port with this topic. And port it still has not been renamed from Master Edition to DZDoom as previously planned.

Worse, that's supposed to be called DZDoom.

 

AFAIK i discern these, and they may overlap:

• DZDoom (GEC GZDoom)
• PSXDoomRE (Reverse engineered PSXDoom, and not to be confused with PsyDoom)
• GEC Master Edition PSX Edition

I really really would like to see some clarity on this. The DZDoom term is going on for a while but it was only going to be officially called on the next release.

 

Secondly, a clarified list of what each of these does and features. I think when its clear what each project's goals are, confusion will subside.

[Erick194]

Excellent @intacowetrust, so it also happens in greatest hits, thanks for checking it, I noticed that error thanks to the Icon Of Sin as it has a similar logic to find the spawnspots before launching the spawning cube. I had to change from thinkercap to mobjhead, similar to find the keys and in the A_BossDeath function, for it to work, I think Final Doom fixes it (I'm not entirely sure) but I think it can be corrected as @Gez says, since in Actually the original demos of PsxDoom do not have Pains Elementals, and if new ones are created, the error will be corrected.

You are also right about the encoding and decoding of passwords, you can still use 2 flags to extend the map limit to 255.

[Dark Pulse]

10 hours ago, intacowetrust said:

Just on this, @Erick194 asked me to confirm some strange code for Pain Elementals in the PSX version and I was reminded of this comment. Basically what I found was that the PSX code was trying to limit the number of Lost Souls but unfortunately the logic was broken and it ended up not enforcing that limit at all. The engine can spawn as many lost souls as it wants until it crashes...

 

Long story short, it looks like some changes made for the Jag version were incompatible with the Pain Elemental code taken from Doom 2 on PC and caused the Lost Soul limit check to silently fail. For those who are interested, I've added more on this in the comments for 'A_PainShootSkull' in PsyDoom:

https://github.com/BodbDearg/PsyDoom/blob/c3dd02df16d30d5102d8fb56f5cec6c92db8b937/game/Doom/Game/p_enemy.cpp#L970

 

For PsyDoom I'm going to leave this bug alone, as fixing it might result in some demo de-sync and vanilla incompatible behavior. Eventually I will not be so constrained by memory, so it's not really a problem... Up to @Erick194 however whether he wants to fix the bug for this project; if it's a crashing problem on some maps then maybe losing a small bit of demo compatibility it is worth the end result?

Demos will need to be re-recorded for the project anyway since the Master Edition won't have any of the original levels of PSX Doom/Final Doom, so I see no reason not to implement the change.

 

It'd only be a theoretical showstopper for if there was a combined project that would "slot in" the Master Edition levels while keeping the original levels as well (I think someone was working on that), and even then it'd only really matter if any of the old demos had lost souls in them - or more accurately, if they passed the overload check that'd be (re-)introduced.

 

Both of which I doubt is the case. I'm sure you/Erick could check for that though. Erick just said here...

3 hours ago, Erick194 said:

Actually the original demos of PsxDoom do not have Pains Elementals, and if new ones are created, the error will be corrected.

...that it's not a problem for PSX Doom since none of them have them, so it's just down to if Final Doom has them or not. If not, then we've got carte blanche to just apply the fix wholesale - we'd need new demos recorded for the new maps anyway, and none of the old demos would have inconsistency to worry about.

 

7 hours ago, Redneckerz said:

Worse, that's supposed to be called DZDoom.

 

AFAIK i discern these, and they may overlap:

• DZDoom (GEC GZDoom)
• PSXDoomRE (Reverse engineered PSXDoom, and not to be confused with PsyDoom)
• GEC Master Edition PSX Edition

I really really would like to see some clarity on this. The DZDoom term is going on for a while but it was only going to be officially called on the next release.

 

Secondly, a clarified list of what each of these does and features. I think when its clear what each project's goals are, confusion will subside.

• DZDoom/GEC GZDoom is basically a port of Doom 64 and PSX Doom to (currently) an older version of the GZDoom Engine (though Erick has said he will put it to a newer version at some point in the future). It's intended to run on PCs, but basically it's a modified version of the ports to run the games without necessarily being 1:1 reverse-engineered examples of the code. It's not trying to mimic how the original engines do stuff, but rather to simulate the result - changes needed for proper functionality are (of course) applied, but it's still fundamentally a modded-up fork of GZDoom, made specifically to run these games closely to the original versions.
• PSXDoomRE is a reverse-engineered version of PSX Doom. In other words, the assembly has been reversed back to C, and with the right compilers, you can compile a new PSX EXE to burn to a disc and play it on an actual Playstation. Since you've got source code, you could also fork it, mod the game, and compile it to run on the Playstation. The game and provided code is intended to be run on Playstation only; there is no PC version - that's basically the niche filled by PsyDoom/StationDoom, to be a PC-native PSX version (to the point it's still emulating Playstation hardware to some degree) along the lines of Phoenix Doom being a PC-native version of 3DO Doom (also made by @intacowetrust), or Calico being a PC-native version of Jaguar Doom.
• GEC Master Edition is the project that's hacking PSX Doom/Final Doom to remove the original maps, and provide conversions of the removed maps (as well as maps done after the game's release that were considered official or semi-official, such as NRFTL or SIGIL), done by about a dozen mappers in the community - think of it as PSX TC: The Lost Levels, but done on the actual PlayStation game, and thus 100% compliant with limits of the PSX Engine (well, Erick might be improving a few things now that it's reversed...), unlike The Lost Levels (which got close but obviously had more flexibility for a number of technical reasons - more RAM, etc.) The project will ONLY have these missing levels - a combination of the original levels plus these restored levels is technically out of the scope of the project. It is intended to be run on a PlayStation, but of course, a reasonably-accurate PS1 emulator (like BeetlePSX in RetroArch) will run it just fine as well. Possibly as PsyDoom progresses, the levels will run on it too (unless it sticks to a vanilla-compatible code and Erick mods up the Master Edition code to the point it's no longer compatible).

Edited May 20, 2020 by Dark Pulse

[Redneckerz]

1 hour ago, Dark Pulse said:

• DZDoom/GEC GZDoom is basically a port of Doom 64 and PSX Doom to (currently) an older version of the GZDoom Engine (though Erick has said he will put it to a newer version at some point in the future). It's intended to run on PCs, but basically it's a modified version of the ports to run the games without necessarily being 1:1 reverse-engineered examples of the code. It's not trying to mimic how the original engines do stuff, but rather to simulate the result - changes needed for proper functionality are (of course) applied, but it's still fundamentally a modded-up fork of GZDoom, made specifically to run these games closely to the original versions.
• PSXDoomRE is a reverse-engineered version of PSX Doom. In other words, the assembly has been reversed back to C, and with the right compilers, you can compile a new PSX EXE to burn to a disc and play it on an actual Playstation. Since you've got source code, you could also fork it, mod the game, and compile it to run on the Playstation. The game and provided code is intended to be run on Playstation only; there is no PC version - that's basically the niche filled by PsyDoom/StationDoom, to be a PC-native PSX version (to the point it's still emulating Playstation hardware to some degree) along the lines of Phoenix Doom being a PC-native version of 3DO Doom (also made by @intacowetrust), or Calico being a PC-native version of Jaguar Doom.
• GEC Master Edition is the project that's hacking PSX Doom/Final Doom to remove the original maps, and provide conversions of the removed maps (as well as maps done after the game's release that were considered official or semi-official, such as NRFTL or SIGIL), done by about a dozen mappers in the community - think of it as PSX TC: The Lost Levels, but done on the actual PlayStation game, and thus 100% compliant with limits of the PSX Engine (well, Erick might be improving a few things now that it's reversed...), unlike The Lost Levels (which got close but obviously had more flexibility for a number of technical reasons - more RAM, etc.) The project will ONLY have these missing levels - a combination of the original levels plus these restored levels is technically out of the scope of the project. It is intended to be run on a PlayStation, but of course, a reasonably-accurate PS1 emulator (like BeetlePSX in RetroArch) will run it just fine as well. Possibly as PsyDoom progresses, the levels will run on it too (unless it sticks to a vanilla-compatible code and Erick mods up the Master Edition code to the point it's no longer compatible).

... See how confusing that is? ;)

[Dark Pulse]

1 minute ago, Redneckerz said:

... See how confusing that is? ;)

I do, which is why I strongly was against them naming GEC GZDoom Master Edition how they did. It seems they agreed, but only after the fact - something they'll only act on with a new release, which'll come eventually.

 

PSXDoomRE, on the other hand, should be no confusion whatsoever. It's a reverse engineering effort - the other two aren't. :P

[RonLivingston]

 

 

Sorry for the late posting, The PSX Ironclad has the Williams entertainment telepad

 

 

[intacowetrust]

On 5/20/2020 at 6:55 AM, Erick194 said:

Excellent @intacowetrust, so it also happens in greatest hits, thanks for checking it, I noticed that error thanks to the Icon Of Sin as it has a similar logic to find the spawnspots before launching the spawning cube. I had to change from thinkercap to mobjhead, similar to find the keys and in the A_BossDeath function, for it to work

 

You're welcome @Erick194! Yeah that makes total sense, some of the original PC logic would definitely be broken with the changes made in JagDoom to thinkers...

 

On 5/20/2020 at 6:55 AM, Erick194 said:

I think Final Doom fixes it (I'm not entirely sure)

 

Good to know - I'll keep an eye out for that. It's on my TODO list to check out Final Doom eventually and compare differences, so that support can be officially added to PsyDoom. If I find anything interesting I'll be sure to let you know :)

 

On 5/20/2020 at 6:55 AM, Erick194 said:

original demos of PsxDoom do not have Pains Elementals, and if new ones are created, the error will be corrected.

 

 

On 5/20/2020 at 10:34 AM, Dark Pulse said:

It'd only be a theoretical showstopper for if there was a combined project that would "slot in" the Master Edition levels while keeping the original levels as well (I think someone was working on that), and even then it'd only really matter if any of the old demos had lost souls in them - or more accurately, if they passed the overload check that'd be (re-)introduced.

 

 

Yeah maybe my reservations against fixing on the basis of 'demo compatibility' and precise vanilla behavior are a bit academic. I need to investigate whether my own automated playthrough of the game would break if I added the limit in also - it's possible. I suppose one compromise here might be to make the behavior configurable, so that users who want vanilla behavior can get it. Perhaps a similar approach could be used to work in a fix for Lost Souls spawning outside the map also - that bug is annoying but at least 1 of my demos has it during the playthrough, so if I fix then I get a de-sync :)

 

On 5/20/2020 at 10:34 AM, Dark Pulse said:

Possibly as PsyDoom progresses, the levels will run on it too (unless it sticks to a vanilla-compatible code and Erick mods up the Master Edition code to the point it's no longer compatible)

 

It's definitely on my list of goals to support playing the Master Edition, along with Final Doom. A stretch goal might also be to support the awful 'PSX Doom Forever' mod/ripoff - depending on whether it is just an asset swap or not... I can already play some of the original PSX Doom format maps from the Master Edition however using the simple modding system added so far.

 

[Erick194]

Of agreement @intacowetrust, I will soon be with Final Doom, since I feel that there is little to verify the differences of the (1.0 and Greatest Hits) of PsxDoom, I hope to find new updates in Final Doom, in addition to Final Doom incorporates a new flag for the linedefs that cuts the wall at the height of the texture and positions it at the limit of the floor cannot be moved with the yoffset as Doom Pc, in addition the Master Edition will have changes to have support for GameInfo, Clusters and MapInfo per map, in order to store the names of the maps, put where it starts the secret levels for the warpmap, amount of division per episode and its name among other things, this in GameInfo, for MapInfo there will be the possibility to choose which music, reverb, cluster id (if necessary), among other things such as flags, this in order to be modifiable and users have no problem making internal modifications. All this I will also help to include it for PsyDoom.

[Dark Pulse]

2 hours ago, Erick194 said:

Of agreement @intacowetrust, I will soon be with Final Doom, since I feel that there is little to verify the differences of the (1.0 and Greatest Hits) of PsxDoom, I hope to find new updates in Final Doom, in addition to Final Doom incorporates a new flag for the linedefs that cuts the wall at the height of the texture and positions it at the limit of the floor cannot be moved with the yoffset as Doom Pc, in addition the Master Edition will have changes to have support for GameInfo, Clusters and MapInfo per map, in order to store the names of the maps, put where it starts the secret levels for the warpmap, amount of division per episode and its name among other things, this in GameInfo, for MapInfo there will be the possibility to choose which music, reverb, cluster id (if necessary), among other things such as flags, this in order to be modifiable and users have no problem making internal modifications. All this I will also help to include it for PsyDoom.

This is all for PSX Doom? So then basically it's a form of preprocessor where we make a script like this and feed it to the converter (along with the level WADs) and it does all that work for us, right?

 

Because otherwise this sounds like it'd be something for DZDoom, and I'm not sure how this would work on PSX.

[Erick194]

41 minutes ago, Dark Pulse said:

This is all for PSX Doom? So then basically it's a form of preprocessor where we make a script like this and feed it to the converter (along with the level WADs) and it does all that work for us, right?

 

Because otherwise this sounds like it'd be something for DZDoom, and I'm not sure how this would work on PSX.

 

It will be for PsxDoom, No DZDoom, this data will be written in text format and will become processed structures, so that the exe does not have to suffer reading texts, let's say as a map structure (SIDEFS, SECTORS, LEAFS, ETC ...) , although the ENDOFWAD lump I will use it as MAPINFO not to create a new entry (Possibly).

 

The GAMEINFO and the Clusters "CLUST001 (002, etc ..)" will be in the PSXDOOM.WAD

[Dark Pulse]

8 minutes ago, Erick194 said:

 

It will be for PsxDoom, No DZDoom, this data will be written in text format and will become processed structures, so that the exe does not have to suffer reading texts, let's say as a map structure (SIDEFS, SECTORS, LEAFS, ETC ...) , although the ENDOFWAD lump I will use it as MAPINFO not to create a new entry (Possibly).

 

The GAMEINFO and the Clusters "CLUST001 (002, etc ..)" will be in the PSXDOOM.WAD

Okay, so then that's a heck of a rewrite of what the PSX EXE can do then. Will definitely make it a lot easier to mod than hex editing though :)

[Erick194]

Another advantage that I recently implemented is the increase of the maximum LeafEdgeClip from 21 to 128, an example is the Last Call map, in the room where the Cyberdemon is blocked and immediately generates some of these errors (FrontZClip: Point Overflow, LeftEdgeClip: Point Overflow , RightEdgeClip: Point Overflow), with 128, the room does not overflow in the least (works correctly), the consumption of the maximum leafs increase is 4Kb in the internal memory of the exe and not using the Scratchpad memory

[Dark Pulse]

Just now, Erick194 said:

Another advantage that I recently implemented is the increase of the maximum LeafEdgeClip from 21 to 128, an example is the Last Call map, in the room where the Cyberdemon is blocked and immediately generates some of these errors (FrontZClip: Point Overflow, LeftEdgeClip: Point Overflow , RightEdgeClip: Point Overflow), with 128, the room does not overflow in the least (works correctly), the consumption of the maximum leafs increase is 4Kb in the internal memory of the exe and not using the Scratchpad memory

Good! That's the one issue that really can give us some fits.

 

Have you figured out if an updated GZDoom Builder would be able to detect if geometry is too complex and would overflow?

[Erick194]

1 minute ago, Dark Pulse said:

Have you figured out if an updated GZDoom Builder would be able to detect if geometry is too complex and would overflow?

No, that is processed in real time in the console, it takes the angle and the view of the player for the overflow to happen, I don't think it is possible to do something that GZDoom Builder detects.

[Dark Pulse]

Well, a higher limit will still make that less likely, at least.

 

@intacowetrust, any ideas on how that could be made to happen maybe? After all, it's a fatal error.

 

Possibly make it non-fatal if it can't be figured out? If it's just something like, say, segs, maybe rendering could get skipped.

[Erick194]

@intacowetrust Indeed, Final Doom corrects the error, in addition to changing the maximum of Lost Souls from 20 to 16.

 

[Erick194]

 

/*
==============
=
= A_PainShootSkull
=
==============
*/
//inline
void A_PainShootSkull(mobj_t *actor, angle_t angle)//L800186D0()
{
	fixed_t	x;
	fixed_t	y;
	fixed_t	z;

	mobj_t*	newmobj;
	angle_t	an;
	int		prestep;
	int		count;

	mobj_t	*mo;

	// count total number of skull currently on the level
	count = 0;

	for (mo=mobjhead.next ; mo != &mobjhead ; mo=mo->next)
	{
		if ((mo->type == MT_SKULL))
        {
            // if there are allready 16 skulls on the level,
            // don't spit another one
            count++;
            if (count > 16)
                return;
        }
	}

	// okay, there's playe for another one
	an = angle >> ANGLETOFINESHIFT;

	prestep = mobjinfo[MT_SKULL].radius + (4 * FRACUNIT) + actor->info->radius;

	x = actor->x + FixedMul(prestep, finecosine[an]);
	y = actor->y + FixedMul(prestep, finesine[an]);
	z = actor->z + 8 * FRACUNIT;

	newmobj = P_SpawnMobj(x, y, z, MT_SKULL);

	// Check for movements.
	if (!P_TryMove(newmobj, newmobj->x, newmobj->y))
	{
		// kill it immediately
		P_DamageMobj(newmobj, actor, actor, 10000);
		return;
	}

	newmobj->target = actor->target;
	A_SkullAttack(newmobj);
}

 

[intacowetrust]

11 minutes ago, Erick194 said:

@intacowetrust Indeed, Final Doom corrects the error, in addition to changing the maximum of Lost Souls from 20 to 16.

 

 

Nice find! That's good to know... Well in that case I might just go ahead and do compatibility with the Final Doom behavior and add a TODO maybe to make the behavior toggle-able for purists. 

 

10 hours ago, Erick194 said:

Of agreement @intacowetrust, I will soon be with Final Doom, since I feel that there is little to verify the differences of the (1.0 and Greatest Hits) of PsxDoom, I hope to find new updates in Final Doom, in addition to Final Doom incorporates a new flag for the linedefs that cuts the wall at the height of the texture and positions it at the limit of the floor cannot be moved with the yoffset as Doom Pc, in addition the Master Edition will have changes to have support for GameInfo, Clusters and MapInfo per map, in order to store the names of the maps, put where it starts the secret levels for the warpmap, amount of division per episode and its name among other things, this in GameInfo, for MapInfo there will be the possibility to choose which music, reverb, cluster id (if necessary), among other things such as flags, this in order to be modifiable and users have no problem making internal modifications. All this I will also help to include it for PsyDoom.

 

That all sounds really neat - such features will make the game much more mod friendly. Looking forward to adding those to PsyDoom too :)

 

6 hours ago, Erick194 said:

6 hours ago, Dark Pulse said:

Have you figured out if an updated GZDoom Builder would be able to detect if geometry is too complex and would overflow?

No, that is processed in real time in the console, it takes the angle and the view of the player for the overflow to happen, I don't think it is possible to do something that GZDoom Builder detects.

 

Actually this should be possible to verify at map build time, once all the map nodes and leafs have been generated. A 'leaf' (the source of the clipping overflows) in PSX Doom is basically just the same as a subsector in regular Doom, except that it has all of the edges fully defined rather than some edges being 'implicit' and defined via the structure of the BSP tree.

 

A subsector in Doom is always a convex polygon and one of the properties of a convex polygon is that when it is clipped against an infinite line, then the product is another convex polygon with at most 1 additional edge. Because clipping of the leaf occurs against 3 infinite lines/planes (front, left and right) then at most 3 additional edges could be created. Therefore if you know that your leaf contains say 20 edges at build time then it might possibly exceed the runtime limit of 21, since up to 23 edges could be required in some cases. You could totally do build time checks based on this information - just warn/error if the edge count is > 18.

 

Now it's possible that mathematical imprecision might under extremely rare circumstances cause this convex polygon invariant to be violated and polygon clipping to produce more than 3 extra edges, but that should be exceptionally rare. If you wanted to be safe you could add allowance for 6 additional edges at runtime due to clipping - that should be more than enough for any possible situation.

 

I think with @Erick194's raised limit to 128 though, it should be pretty hard to exceed the edge limit unless the map geometry is very highly tessellated, like with very detailed curved walls or something. You'd probably be wanting to avoid that kind of stuff anyway on PSX due to the performance implications :)

 

7 hours ago, Erick194 said:

the consumption of the maximum leafs increase is 4Kb in the internal memory of the exe and not using the Scratchpad memory

 

@Erick194 Just out of curiosity, does not using the scratchpad for leaf clipping have any noticeable impact on performance on the real hardware? Did you notice any change in FPS after making that change? I'm curious how much the scratchpad helped, if at all...

 

6 hours ago, Dark Pulse said:

Well, a higher limit will still make that less likely, at least.

 

@intacowetrust, any ideas on how that could be made to happen maybe? After all, it's a fatal error.

 

Possibly make it non-fatal if it can't be figured out? If it's just something like, say, segs, maybe rendering could get skipped.

 

As @Erick194 mentioned it's kind of hard to determine. A lot of it is view dependent, and depends on where you are looking, how close you are to subsector (which you can't visualize directly of course) and how the map was built and split up for the BSP tree etc.

 

I did a little experiment however to see if I could recover from the error and what that would look like. Basically I made the code just stop emitting subsector edges if too many were generated during clipping rather than giving up and killing the game completely. I reduced the limit down to '8' just to make it trigger the problem on regular maps. It kinda looked like what I thought it would, some holes and missing geometry and some skewed geometry in some cases. A visual glitch to be sure but probably much preferable to a hard crash? Here's examples:

 

 

[Dark Pulse]

1 hour ago, Erick194 said:

@intacowetrust Indeed, Final Doom corrects the error, in addition to changing the maximum of Lost Souls from 20 to 16.

 

Well shit. And here I put what... 40 Lost Souls in Bloodsea Keep on Ultra-Violence, or something like that? :P

 

Kind of had to though with how limited I was in memory on that map, plus PSX Lost Souls having less HP than PC Lost Souls... I wanted to make the difficulty as close as I could to the PC version in terms of monster HP strength as possible (IIRC in the end I got it to within 10 HP).

 

19 minutes ago, intacowetrust said:

Actually this should be possible to verify at map build time, once all the map nodes and leafs have been generated. A 'leaf' (the source of the clipping overflows) in PSX Doom is basically just the same as a subsector in regular Doom, except that it has all of the edges fully defined rather than some edges being 'implicit' and defined via the structure of the BSP tree.

 

A subsector in Doom is always a convex polygon and one of the properties of a convex polygon is that when it is clipped against an infinite line, then the product is another convex polygon with at most 1 additional edge. Because clipping of the leaf occurs against 3 infinite lines/planes (front, left and right) then at most 3 additional edges could be created. Therefore if you know that your leaf contains say 20 edges at build time then it might possibly exceed the runtime limit of 21, since up to 23 edges could be required in some cases. You could totally do build time checks based on this information - just warn/error if the edge count is > 18.

 

Now it's possible that mathematical imprecision might under extremely rare circumstances cause this convex polygon invariant to be violated and polygon clipping to produce more than 3 extra edges, but that should be exceptionally rare. If you wanted to be safe you could add allowance for 6 additional edges at runtime due to clipping - that should be more than enough for any possible situation.

 

I think with @Erick194's raised limit to 128 though, it should be pretty hard to exceed the edge limit unless the map geometry is very highly tessellated, like with very detailed curved walls or something. You'd probably be wanting to avoid that kind of stuff anyway on PSX due to the performance implications :)

This sounds promising. Basically if there's a way it could be detected, that means it could be factored for.

 

That said, that's also a fair point - unless one goes insane with geometry, no way should 128 be hit though. I mean, I know that I needed to do that for Evilution's MAP05 (the little vertical buttresses were a small complex shape and that bombed it), but I remember in the part just past those (the elevated walkway) I could consistently get an Edgeclip overflow when I looked in a certain direction when I backed into the corner of the "L," but only when I merged some sectors to get rid of redundancy. Obviously since that happened I kept the sectors unmerged and now it won't happen in the current GEC build, but it always irked me.

 

19 minutes ago, intacowetrust said:

I did a little experiment however to see if I could recover from the error and what that would look like. Basically I made the code just stop emitting subsector edges if too many were generated during clipping rather than giving up and killing the game completely. I reduced the limit down to '8' just to make it trigger the problem on regular maps. It kinda looked like what I thought it would, some holes and missing geometry and some skewed geometry in some cases. A visual glitch to be sure but probably much preferable to a hard crash? Here's examples:

 

I do think that could be preferable. It might be better if we could have it somehow flash or stick out better a la TNTHOM, but that's probably not possible since it's just rendering the void and skybox.

 

That said, we also have to balance this against that a fatal error is impossible to miss - whereas something that's really small and miniscule might be missed by even the best of eyes.

 

That said, again, this is probably something mostly mooted by the raised edge limit. If the original was 20 before it exploded, a limit of 128 is 6x as much. We'd have to almost try, at that point, to overflow it.

 

But it still might not be a bad option to let it just do a quick render bug, since presumably when you move and reduce the number of edges in view, the rendering fixes itself, right?

[Erick194]

27 minutes ago, intacowetrust said:

Just out of curiosity, does not using the scratchpad for leaf clipping have any noticeable impact on performance on the real hardware? Did you notice any change in FPS after making that change? I'm curious how much the scratchpad helped, if at all...

 

Good point, I will have to do a CD burn to verify it in the real hardware, but I did tests in the XEBRA emulator and I do not see differences in the game execution, it lies with a 40-56 fps (normal). I read that the scratchpad is considered Fast Memory, but in the end it is an internal memory space and the MIPS process will not modify its speed to access that data space.

 

Taken from: http://problemkaputt.de/psx-spx.htm

Data Cache aka Scratchpad
The MIPS CPU usually have a Data Cache, but, in the PSX, Sony has misused it as "Scratchpad", that is, the "Data Cache" is mapped to a fixed memory location at 1F800000h..1F8003FFh (ie. it's used as Fast RAM, rather than as cache).
There <might> be a way to disable that behaviour (via Port FFFE0130h or so), but, the Kernel is accessing I/O ports via KUSEG, so activating Data Cache would cause the Kernel to access cached I/O ports.
Not tested yet, but most probably the Scratchpad can be used only for Data (ie. NOT for program Code?).

Although I may be wrong.

[RonLivingston]

I forgot about these other 2 ambient soundtracks, Steadfast extermination and hopeless despair are not in final doom

[Impboy4]

1 hour ago, RonLivingston said:

I forgot about these other 2 ambient soundtracks, Steadfast extermination and hopeless despair are not in final doom

Technically they are there in Final Doom if you ripped out the samples and sequences, but I think Williams/Midway forgot to place them in the game's code so they ended up with repeats of Tendrils of Hate and Breath of Corruption.

[Hydra Spectre]

I hope that both DualShock and mouse support get added to a future version of Master Edition.

P.S: I would also be really happy with PS3 PKG versions.

Edited June 23, 2020 by Hydra Spectre

[riderr3]

1 hour ago, Hydra Spectre said:

I hope that both DualShock and mouse support get added to a future version of Master Edition.

 

If you mean Dualshock with its support for analog sticks and smooth walking/aiming. It will be convenient and quite fit into the control scheme, as if the game came out later when this gamepad was available.

 

But it will be more difficult to apply functions that were not originally supported initially - even if the code is decrypted. Perhaps backport it from Quake 2 which have DualShock support? And maybe even vibration feedback? For example, the fact that some options were backported from PSX Hexen, as shown earlier.

 

If the possibilities increase the comfort and perform cosmetic functions, while not violating the physics and gameplay, this only benefits. (maybe except re-added monsters from PC version)

Edited June 23, 2020 by riderr3

[Hydra Spectre]

AFAIK mouse support was in the PS1 version of Final Doom.

[Dark Pulse]

1 hour ago, Hydra Spectre said:

AFAIK mouse support was in the PS1 version of Final Doom.

Mouse is probably fairly simple to add. Dualshock would be way harder.

[Hydra Spectre]

And can you please have a PS3 PKG option to make it easier for people with PS3s with HAN or CFW?

I really want to try this out and future versions on my PS3.

[Dark Pulse]

2 hours ago, Hydra Spectre said:

And can you please have a PS3 PKG option to make it easier for people with PS3s with HAN or CFW?

I really want to try this out and future versions on my PS3.

We don't produce those directly, but I'm sure someone out there can easily do so (someone already did that for PSP/Vita/PSTV).

 

Theoretically shouldn't be hard for anyone to package up with the appropriate tools, though.