Concerning Vanilla Compatibility of Freedm.wad

A few days ago I've got the rather exotic port 'ps2doom' (http://psx-scene.com/forums/f19/ps2doom-v1-0-5-0-released-last-week-64013/) running on a Playstation 2.

It runs the genuine DOOM IWADs well and although it is obviously not able to fetch command line options I could also quickly get some Vanilla PWADs running (h2h-xmas, Eternal, ...) by using 'deusf -merge', :-).

However, the port does *not* run using the FreeDM IWAD but crashes on startup.

I'm not sure whether this port is BOOM compatible or not, but I think FreeDM claims to be 100% Vanilla, doesn't it?

While this may be due to the strange port, another issue is not:

When I merge and run eternall.wad from Eternal Doom to the IWAD (see above) this works fine for the genuine DOOM2 IWAD but not for FREEDM.WAD (different or no error messages like 'W_GEtNumForName: ...' on different ports/platforms).

At least, the last issue could be considered to a bug in FreeDM, couldn't it?

FreeDM was tested on the official 1.9 binary(needs to be renamed to DOOM2.WAD). So it is technically vanilla compatible. Maybe ps2doom is more picky than the vanilla binary?

Do you have error logs or any more information? Does it crash at titlescreen? Start of map? or start of demo?

Did you run it in singleplayer? Did you consider that FreeDM contains no monsters?

FreeDM is a fast-paced competitive deathmatch game, part of the Freedoom project. Rather than the usual single-player focused levels, these contain no monsters and are intended for deathmatch only.

EDIT: My bad, sorry, the monster sprites are apparently there.

Catoptromancy said:

FreeDM was tested on the official 1.9 binary(needs to be renamed to DOOM2.WAD). So it is technically vanilla compatible. Maybe ps2doom is more picky than the vanilla binary?

I'm aware of FreeDM runs fine using the vanilla engine. Otherwise I wouldn't have asked at all.

But there are obviously some more technical deviations between genuine doom2.wad and freedm.wad than replaced resources.
This seems to affect merging somehow. As far as I remember I am not the first one to have noticed this.
But I can't give you more details here anymore as I am not a WAD guru, :-).

However, everyone is, at least partly, able to reproduce my problem by doing the following:

1) Get chocolate-doom (just tried V2.1.0 for this test myself)
2) Get Vanilla compatible final release of Eternal Doom (http://www.doomworld.com/idgames/index.php?file=themes/TeamTNT/eternal/eternal.zip)
3) Get deusf V3.4 *and* V4.4
(I use V3.4 from h2h-xmas, http://www.doomworld.com/idgames/index.php?file=themes/xmas/h2h-xmas.zip , and V4.4 from http://www.doomworld.com/idgames/index.php?search=1&field=filename&word=deutex&sort=time&order=asc&page=1).
I haven't tested other deusf versions for this issue yet.

Merging both main PWADs (h2h-xmas.wad, eternall.wad) using 'deusf -merge xyz.wad' to the genuine doom2.wad will result in perfectly playable merged IWADs no matter what PWAD or deusf version you use.
All these IWADs (including the unmerged genuine doom2.wad) are also playable on ps2doom.

In the case of freedm.wad (renamed to doom2.wad of course) things change if you use the older deusf version for merging (see above).
Then, merging eternall.wad to *this* IWAD will result in a corrupted IWAD. Try it yourself in chocolate-doom.
The IWAD (size: 44.801.132 Bytes) will crash chocolate-doom at
'R_Init: Init DOOM refresh daemon - .................' (from stdout.txt),
reporting 'W_GetNumForName: F_END not found!' (from stderr.txt).

However, this does *not* happen using deusf V4.4.
The resulting IWAD will be slightly bigger then (size: 44.804.396 Bytes) and runs perfectly on chocolate-doom, vanilla doom and ps2doom!

So you may blame deusf for this. But nevertheless, obviously the IWADs (genuine doom2 and freedm) are somehow different as all deusf versions works perfectly together with the genuine doom2.wad.

Catoptromancy said:

Do you have error logs or any more information? Does it crash at titlescreen? Start of map? or start of demo?

Unfortunately, I'm not only new to ps2doom but also to the Playstation 2 itself. And the the doom port is far from having been completed.
I'll try and look if I get some more information but it seems to crash at about the same point in the doom init process
(still in textual boot screen, similar to genuine doom boot up, nothing visible or audible from the game started yet).
If I'll ever get more information I'll tell you.
However, the unmerged (renamed) freedm.wad crashes while the 'deusf V4.4 to eternall.wad merged' IWAD does *not*.

This might be a hint that something is somehow irregular in freedm.wad that does not even effect vanilla doom and get smoothed by deusf latest version ...

Finally: If this is bug in freedm.wad, deusf, ps2doom or even vanilla - or not a bug at all - is another question then.

Why use deusf when Chocolate Doom itself supports a -merge parameter that does the same thing? Maybe I'm misunderstanding you.

Quasar said:

Why use deusf when Chocolate Doom itself supports a -merge parameter that does the same thing? Maybe I'm misunderstanding you.

Oh, I'm *not* questioning about running PWADs in chocolate doom.
I am pretty familiar to old ports and tools (more than to newer ones).

My thread is about - maybe unwanted - differences between freedm.wad and genuine doom2.wad I noticed when I merged the IWADs with PWADs manually.

I did this because I *have to* merge the PWADs into the IWAD if I want to play custom WADs on a somewhat exotic DOOM port to Playstation2 (see above).
It does *not* support command line options at all due to technical reasons of the Playstation2 (try to start *any* self-made program on a PS2 if you don't know what I mean, :-) ).

I think "vanilla" compatibility is very interesting for old and exotic (but sometimes great) ports.
And I know FreeDM *is* vanilla compatible.

However, if I create deusf merged IWADs on base of freedm.wad I get sometimes corrupted merged WADs.
This can also be tested on chocolate doom.
And this won't happen if I use the genuine doom2.wad.
Maybe this also happens if I use the -merge option, maybe not.
I haven't tested it yet.
But this is not the point, is it? I expected it to work (or not) any way I go, no matter what IWAD I use. They claim to be compatible.


So this might be also of interest for the community.
And this is one of the reasons why I started this thread here.

That's all ... :-).

Maybe deusf manually messes with texture1/pnames lmps in a hardcoded style. So when it is given FreeDM and it jumbles the lmps.

I do not think anyone has tested any of Freedoom's wads using dos iwad merging tools. Can you upload a copy of the merged FreeDM along with the script/command line used to make it?

Catoptromancy said:

Maybe deusf manually messes with texture1/pnames lmps in a hardcoded style. So when it is given FreeDM and it jumbles the lmps.

Indeed, it seems to be a deusf bug of its older version(s).
I merged and tested some more PWAD to freedoom1/freedoom2/freedm merged scenarios using deusf V4.4 and they seem to work well.

Catoptromancy said:
I do not think anyone has tested any of Freedoom's wads using dos iwad merging tools.

I'd prefer some other quick'n'dirty ways either.
Is there any other, more up to date, command line driven small and free tool to do this job fast?

Catoptromancy said:
Can you upload a copy of the merged FreeDM along with the script/command line used to make it?

Not before the next days.
But as described above, it's easy to create this WAD yourself if you are able to run a 16-bit DOS console application ...

btw: Sorry for this silly question: How/Where should I upload it?

You can try to use updated version of deutex/deusf:
http://code.google.com/p/xwadtools/

It'll be faster than running it in dosbox anyway (not emulated, not bound to slow FAT32...)

That copy of deutex/deusf hasn't been altered at all. The one recommended for Freedoom is at https://github.com/chungy/deutex (shameless plug ...). It's not really maintained either, but it has several patches related to IWAD paths and compiling it on modern systems (especially Mac OS X and Windows).

chungy said:

The one [of deutex/deusf] recommended for Freedoom is at https://github.com/chungy/deutex

Thanks!
According to the changelist, there could be really some more bugs fixed.
However, as there already precompiled binaries of V4.4.0 available and this version runs (still) fine for me, I will not go a compile them myself for my little needs ...

I mean updated in the sense that new xwadtools builds/runs on 64-bit systems and native filesystem, so it'll be faster than running it in dosbox. I do stuff all the time in dosbox and it's slow... even with very high cycles.

Then again, I wonder why the xwadtools maintainer didn't copy the Freedoom deutex patches. Maybe he doesn't know about them...

It fails with "W_GetNumForName: F_END not found!".

Alright, the next Crispy Doom release will get a "-mergeout" parameter which acts as a simple deusf replacement. The IWAD and the PWADs get merged "internally" anyway, but there was no means yet to write that merged data back to disk.

Edit: In Crispy Doom 2.3 the parameter is called "-mergedump".