Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Cire

How can I convert the PSX Doom demo to PC readable format?

Recommended Posts

I want to convert the PSX Doom demo to a format that PC editing and source ports can read. SLADE can open PSXDOOM.WAD but can't seem to read the files inside and can't open MAP33.WAD.

Share this post


Link to post

The map format is not entirely compatible. A big difference (the largest) is in how vertices are written.

There is an Experimental Feature For Power Users Only, however. Usual disclaimers in full force. Select the vertex lump of your PSX map. Open the console. Type the vertexpsx command in the text entry box at the bottom of the console window.

The vertices have been converted into the Doom format, and you can now open the map. Note that some stuff will still be fucked up because there are other differences (notably to support colored lighting), but at least the geometry will look mostly correct.

Share this post


Link to post

Are you talking about doing this in SLADE? Problem is I can't even open MAP33.WAD because SLADE says archive is invalid and/or corrupt.
EDIT: Nevermind, it works with latest SVN release.

Share this post


Link to post

Just tried it myself and the sector heights are amazingly broken. The light levels are literally off the scale too in some cases; 16137!!

Still, I suppose it's quite a nice feature to have in a way , and inevitably this will likely end up as grounds for yet another 'downgrade' project at some point. PSX Doom for Vanilla Doom/Doom II?

Share this post


Link to post
BaronOfStuff said:

Just tried it myself and the sector heights are amazingly broken. The light levels are literally off the scale too in some cases; 16137!!

Yep. The sector information is written differently too; but at least the map preview is okay (since it only use vertices and linedefs) and you can open the map in the editor without crashing.

In the hypothetical future, there might be native support for the PSX map format, or a built-in converter, using UDMF with a PSX namespace for edition. I'm not sure which approach would be the best. The former seems more intuitive, but the latter would need a lot less boilerplate code.

Share this post


Link to post

The OP was about the demos, not the maps: those are practically black boxes in an unknown format, with unknown data structures, data endianness etc. and only by the dumbest of luck they might be in any way similar to the PC's format and usable as-is.

As for opening the PSX (or other console WADs) on the PC: there are TONS of potential problems.

First and foremost, the WAD format used in consoles is slightly different than that on the PC because of different data endianness: all those consoles were BIG ENDIAN vs LITTLE ENDIAN on the original PC Doom, and the data structures used in memory and ON-DISK were altered to aid faster loading, rather than maintain PC compatibility.

The result? Not even the number of entries in a WAD file will be read correctly. Also, the lump index table in WADs is different: the index struct has been extended to indicate the use of compression/encryption on SOME lumps, compressed/uncompressed size (of course, they are ALSO Big Endian) and almost certainly even the values inside map lumps (vertexes etc.) have been converted to big endian, so you need an editor designed to handle those. Otherwise, while opening them, you will see "far off" numbers (or even negative values).

Share this post


Link to post
Maes said:

First and foremost, the WAD format used in consoles is slightly different than that on the PC because of different data endianness: all those consoles were BIG ENDIAN vs LITTLE ENDIAN on the original PC Doom, and the data structures used in memory and ON-DISK were altered to aid faster loading, rather than maintain PC compatibility.

The result? Not even the number of entries in a WAD file will be read correctly. Also, the lump index table in WADs is different: the index struct has been extended to indicate the use of compression/encryption on SOME lumps, compressed/uncompressed size (of course, they are ALSO Big Endian) and almost certainly even the values inside map lumps (vertexes etc.) have been converted to big endian, so you need an editor designed to handle those. Otherwise, while opening them, you will see "far off" numbers (or even negative values).


This kind of things isn't a problem for SLADE 3. It opens WADs in big-endian and little-endian flavors correctly, and it also expand those compressed lumps correctly.

Now the PSX used little-endian formats anyway. The issue with the PSX VERTEXES lumps? They're written in fixed point. Since it's 16.16 LE, the first two bytes are generally 00 and can be ignored. That console command I talked about earlier? That's what it does. Chop the selected lump in half, taking the latter half of every bucket of four bytes. Interestingly enough, the Sega 32X port of Doom used fixed point VERTEXES too, but this time in 16.16 BE; so there's also a vertex32x command that only keeps the first two bytes of every vertex coordinates, and shuffle them around.

One other thing about the PSX and 32X vertices: the extra precision isn't just for the sake of changing stuff around. There are maps with a few vertices that use them. (They might just be those added by the nodebuilder, though, since I don't think DoomEd or whatever editor the Williams/Midway guys used allowed fractional positioning.)

There's a few other undocumented console commands for L33t Power Userz who want to toy with console WADs: lightspsxtopalette will convert the selected LIGHTS lump into a palette, so you can see what are the colors used for the 256 colored lights; palconvpsx will convert the PSX palette into the format used by PC Doom and assorted editing utilities; palconv64 will do the same for Doom 64 palettes. (Which you generally will not need to do because it's better to use the IWAD generated by Kaiser's wadgen anyway, in which the palettes will be in a sane format to begin with.) The common point to all these commands is that using them on random files that aren't what they should be used on will fuck the data up without giving anything useful in return. So use at your own risk and stuff.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×