ZDoom

Wow, this look awsome
Great job randy.

Hexen, map36 - enjoy new polyobjects.

Spoiler:

---

hehe, just joking, this is small penalty for all possible things now.

Hm, ok, seems that a compatibility option is needed after all...

Heh, that wasn't exactly the most well-thought-out poly use, there. Leave it to Raven to use one of their own diabolical constructs incorrectly.

It didn't actually dawn on me until my most recent playthrough that the only reason it looked as if the blocks were rotating without bleeding is that the upper and lower textures hid the error.

Should be better now. I added a compatibility option to force all segs into the center subsector and Hexen's MAP36 as well as Deathkings's MAP47 have this enabled.

This is also accessible through MAPINFO by specifying compat_polyobj in the map definition.

New poly code = awesome. There's a few places in Sonic that looked a bit awkward before (esp. the map 19 gauntlet), but are spot on now. Good thing there's a compatflag too, as I have some of those Hexen-map-36-style poly puzzles in Serpent.

randy wrote:One example that immediately came to mind is a room with details with Death Star garbage disposal-like crushing walls.

I tried to do something similar in Sonic, but the most I could get was 3 damage per hit...any chance of making them deal more damage on hit?

The Ultimate DooMer wrote: I thought polyobjects could only consist of 1-sided linedefs.

Nope, 2-sided lines all with Polyobj_ExplicitLine (order 1) and forming a self-referencing sector will work just fine

(if you want to use them as doors etc. put the door special on the lines that the poly appears on top of in-game)

The Ultimate DooMer wrote:2-sided lines all with Polyobj_ExplicitLine (order 1) and forming a self-referencing sector will work just fine

I think Polyobj_StartLIne should work fine now, too. (No guarantees, though.)

Didn't SonicDoom require that special zdoom 2.0.94f?

Coming to this a bit late because I was away when it was released so thank you to Randy and all others involved for this release.

Hirogen2 wrote:Didn't SonicDoom require that special zdoom 2.0.94f?

No. It just didn't work with the official release at the time. It required some fixes that were only in 2.0.95 and on.

It was ok with newer versions eventually, not sure when (except 2.3.x cos of those dehsupp errors that stopped the deh from loading) but soon it'll require 2.5.0 for the new poly code.

Are you going to re-release Super Sonic Doom?

In a GZDoom compatible version? The skybox windows are an utter nightmare with the hardware renderer and the only way to make this WAD work at decent performances is to disable skybox processing.

SSD runs like a nightmare and I don't think it's just my hardware. Particularly the volcano zones, and many of the later maps slow to an unplayable crawl. I was at Doom Star Act 2 when the fan room trap brought GZDoom down to a steady 1 FPS and kept it there.

There's a few problems in this WAD that make it slow:

- the biggest ones are the skybox windows
- the second biggest problem is that the crossbeam walkways contain an extremely high amount of linedefs. This is particularly harmful to performance in the engine core in the first Doom Star map. I got a decent speed up there by joining any linedefs forming a straight line.

I never had problem with the fan room though.
As for the volcano, I hate these maps with such a passion that I modified the MAPINFO to skip them. I never played them in GZDoom.