Doom Classic Code Review 2 : The gift and the curse

Good readin'. :)

BTW, slightly off-topic, but... iPhone Doom is... huge.
77MB download from the App store.

That's what happens when you take a 12Mb WAD and replace the music the MP3s

Excellent technical read.

Excellent - a joy to read...

Awesome... cheers

Not quite informative as the first article IMO. From the information in it, you got a good grasp of how DOOM's renderer worked from top to bottom. This one kinda skimps on the overall architecture and only talks about a few things that are specific to the modifications needed to render on iPhone, and not addressing much about the OpenGL engine overall. For example you'd get the impression from the article that each wall can only generate one polygon, and that's not true, since there are upper and lower textures to account for as well ;)

	// JDC: E3M8 has a map error that has a couple lines that should
	// be part of sector 1 instead orphaned off in sector 2.  I could
	// let the non-closed sector carving routine handle this, but it
	// would result in some pixel cracks.  Instead, I merge the lines
	// to where they should have been.
	// This is probably not the right solution, because there are
	// probably a bunch of other cases in the >100 Id maps.

	extern int gameepisode, gamemap;

	if ( gameepisode == 3 && gamemap == 8 ) 
	{

		void IR_MergeSectors( int fromSector, int intoSector );
		IR_MergeSectors( 2, 1 );

	}

This should be very scary for anyone thinking about using PWADs on their iDoom...

(By the way, how do various ports handle issues like these?)

Gez said:

(By the way, how do various ports handle issues like these?)

They don't. PrBoom is the only port using the GLU tesselator. With GL nodes this becomes a non-issue because despite the map error the nodes are usable without rendering glitches.

There's indeed more mapping errors in Doom. E1M3, for example also contains an unclosed sector that might cause problems.

Regarding PWAD compatibility this hack clearly is not a bright idea - but it's somewhat fitting to add yet another dirty hack to the already long list of dirty hacks in Doom's official history.

Could have taken a leaf from ZDoom and used the level's MD5 sum to identify it as needing the hack.

Or, given that they're Id Software and distributing the IWAD, they could have fixed the map bug with an editor... I wonder if it even occurred to them that they could.

Gez said:
Or, given that they're Id Software and distributing the IWAD, they could have fixed the map bug with an editor... I wonder if it even occurred to them that they could.

That would make people not using the new or patched IWAD have problems. After all, their priority was getting the game itself to run fine, and PWADs, which are unsupported, are well below that priority.

Due to Carmack's generosity, anyone with enough talent can provide a general fix from the source if they really want to see PWADs running on the iPhone without issue. Practically all add-on work for the DOOM games has been done by the community independently, short of id disclosing some helpful information.

myk said:

That would make people not using the new or patched IWAD have problems. After all, their priority was getting the game itself to run fine, and PWADs, which are unsupported, are well below that priority.

Due to Carmack's generosity, anyone with enough talent can provide a general fix from the source if they really want to see PWADs running on the iPhone without issue. Practically all add-on work for the DOOM games has been done by the community independently, short of id disclosing some helpful information.

But thanks to iPhone's TiVoization, distributing such a modified version is relatively useless. Code signed for development testing purposes only won't execute on the commercial units, AFAIK.