Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Sign in to follow this  
wesleyjohnson

FreeDoom recognition characteristics

Recommended Posts

I am working on Legacy 144 code in the area of recognizing special wads.
There has been some interest in engines recognizing FreeDoom.

Right now FreeDoom is recognized as DoomII, and as it is a drop-in replacement for DoomII, is there anything different that would be done.
The only thing I have considered right now is to change the title line from DoomII to FreeDoom and drop some of the warning messages.

What would be different between DoomII and FreeDoom ???

What does FreeDoom offer as recognition characteristics ???
- name of doom3.wad ??
- some special lump name in the wad ??
- some text string appearing somewhere ??
- the easy test is for size, but I do not know the size of the
DoomII versions (don't have a copy)

This would have to be maintained in every release of FreeDoom.

Share this post


Link to post

I have exploded the wad and cannot find a lump with the FreeDoom name.
I have seen the string in the wad through, which is why I asked this question.

Where is this FreeDoom lump in the Deutex directory structure.

Unfortunately, this test needs to be done before the wad is loaded.

Also, the clash is with Doom2, as it shares the same name doom2.wad.
Ultimate doom is distinguished by using the name doomu.wad or doom.wad, and having a certain size. Size can be checked quickly before loading the wad.

Share this post


Link to post

Question: Does Freedoom intend to have a MAP32 with the special test conditions that doom2 used.
I have noted two flags being set in the code upon doom2 recognition. I am not entirely sure what they do, but the notation indicates something to do with MAP32.

Would FreeDoom want those flags the same as Doom2, or clear them ??
This was probably something in MAP32 that got triggered when the key monsters died.

This decision could really be a problem, because any other port that does not have a FreeDoom fix would not have any difference between doom2 and FreeDoom.

Share this post


Link to post
wesleyjohnson said:

Where is this FreeDoom lump in the Deutex directory structure.

Nowhere. It looks like DeuTex only extracts lump types it can identify and this one-byte lump isn't one of them.

OTOH - if I add some text (like "Ultimate FreeDoom 0.6.4", which is what I was experimenting with) it's extracted to the \lumps directory as raw data.

Share this post


Link to post
GreyGhost said:

Nowhere. It looks like DeuTex only extracts lump types it can identify and this one-byte lump isn't one of them.

OTOH - if I add some text (like "Ultimate FreeDoom 0.6.4", which is what I was experimenting with) it's extracted to the \lumps directory as raw data.


Yeah, since the lump is empty by default deutex won't bother creating an empty file to represent it.

Share this post


Link to post

EE looks for the FreeDoom lump, and additionally, if the IWAD is determined to be of commercial variety, the gamemission is readjusted to be doom2 rather than pack_tnt or pack_plut. This is necessary because of the presence of the CAV* and MC* lumps which are the only reliable way to tell DOOM II and Final Doom apart normally.

Share this post


Link to post

ReMooD maps freedoom.wad to Doom II and ultfdoom.wad to Doom. But the IWADs are named after normal wads, so it's treated as such.

EDIT

Share this post


Link to post

ZDoom looks for the FREEDOOM lump as well, and determines whether it's Freedoom, Ultimate Freedoom or the Freedoom "demo" based on available map lumps. In addition, it makes the difference between Freedoom and FreeDM based on file name, since there are no other ways of telling whether it's the Freedoom IWAD or the FreeDM one.

ZDoom also recognizes Blasphemer from the presence of a BLASPHEM lump.

Freedoom and FreeDM uses Doom2 mapinfo (MAP01 is Entryway, etc.).

Share this post


Link to post
Gez said:

ZDoom looks for the FREEDOOM lump as well, and determines whether it's Freedoom, Ultimate Freedoom or the Freedoom "demo" based on available map lumps. In addition, it makes the difference between Freedoom and FreeDM based on file name, since there are no other ways of telling whether it's the Freedoom IWAD or the FreeDM one.

ZDoom also recognizes Blasphemer from the presence of a BLASPHEM lump.

Freedoom and FreeDM uses Doom2 mapinfo (MAP01 is Entryway, etc.).

Thanks, some of this info is useful to me :>

Share this post


Link to post

If FreeDoom is a drop-in replacement for DoomII, then should Freedoom detection modify the engine in any way different than doom2 does, other than change the title name and not display those Id modified game warnings ??
It is already detected as a DoomII iwad, based on the filename doom2.wad.

If that FREEDOOM lump contained something then people could use deutex to explode and re-build it (such as testing a new lump or building a version with the levels from the daily build).
I would suggest something useful, like the title.
FREEDOOM
ULTIMATE FREEDOOM

Share this post


Link to post
wesleyjohnson said:

If FreeDoom is a drop-in replacement for DoomII, then should Freedoom detection modify the engine in any way different than doom2 does, other than change the title name and not display those Id modified game warnings ??
It is already detected as a DoomII iwad, based on the filename doom2.wad.

If that FREEDOOM lump contained something then people could use deutex to explode and re-build it (such as testing a new lump or building a version with the levels from the daily build).
I would suggest something useful, like the title.
FREEDOOM
ULTIMATE FREEDOOM

It's a good idea to have something in there just so the process of rebuilding is possible, but keep in mind any info in there won't be used by most ports so it doesn't matter very much (IMO) what it says.

EE just changes the version name of the IWAD that is reported at startup, to properly reflect what you're playing. I don't see how that's really incorrect or a problem :) I also adjust the gamemission for DOOM II because FreeDoom is meant to replace DOOM II and not Final Doom, and otherwise my BOOM-based IWAD detection code misidentifies it :)

Share this post


Link to post

Well, I am changing the Legacy wad recognition over to a table based
characteristics (code is written but not yet committed to svn) and am including FreeDoom and Blasphemer.
I am considering a FreeHeretic and FreeHexen entries too, although there are not projects of that name, to catch such compatible iwads that are not id (and not Blasphemer).

Still am groping with the lump name recognition thing. Cannot find any useful strings in Ultimate doom, etc., so it becomes a matter of not being recognized as anything else. Too bad they could not of put their name or a title string in there somewhere. This means that I will have to check for FreeDoom before other doom's, and other free wads after checking for the id dooms, and do not know a good test for that.

Thank you for the information.

Share this post


Link to post

I am curious as to the original use of Boom features.
Was it TNT and Plutonia, or some later wad ??

(I committed Legacy code that now recognizes FreeDoom and Blasphemer.
Blasphemer is so incomplete that I thought the engine was broken.
It is just that the "dead" sprites just stand there and are exactly the same as the live ones. )

Share this post


Link to post
wesleyjohnson said:

I am curious as to the original use of Boom features.
Was it TNT and Plutonia, or some later wad ??

(I committed Legacy code that now recognizes FreeDoom and Blasphemer.
Blasphemer is so incomplete that I thought the engine was broken.
It is just that the "dead" sprites just stand there and are exactly the same as the live ones. )

BOOM features originated with the source port BOOM, by Team TNT. All of the original games used the "vanilla" DOOM engine for DOS.

The reason that Freedoom is detected as TNT gamemission on BOOM-based source ports isn't because it contains BOOM features, but rather because it contains certain CAV* and/or MC* texture patches which are meant to provide compatibility with Final DOOM PWADs.

These lumps are the only easy-to-detect internal difference in the IWAD directory between commercial DOOM II and the Final DOOM IWADs. Without those, you'd either need to do some more complex verification of internal data, which is more difficult, or you'd need to go on the filename alone, which is less reliable if people are trying to be overly clever.

Share this post


Link to post

ZDoom's IWAD recognition is not based on Boom if I'm not mistaken, and it looks for different lump names: a lump named REDTNT2 means that it's TNT, a lump named CAM01 means that it's Plutonia.

Share this post


Link to post

I wanted to know more so that if Boom gets turned off for some reason, I do not disable it for the wrong wads.
I made a lump based, and file name based, recognition for Legacy.
I used some of the ZDoom technique information about checking for REDTNT2, and CAM01, (my own code though).
Thanks to the ZDoom team for this information, and I included a little credit in that code segment.

This does mean that FreeDoom, using Boom features, is not wholly playable on old Id engines, and old Id games do not need Boom enabled on any modern Boom supporting ports. Of course, the operating systems that these old Id engines ran on are disappearing and that is much less of a problem,
(unless you want to argue about Vanilla Doom (not here please!!)).

In Legacy, currently, the Boom support is always enabled except when it actually conflicts with something specific to another game type. It is possible, sometime in the future, that FreeDoom support and Id game support may differ because of Boom.

Share this post


Link to post
Quasar said:

These lumps are the only easy-to-detect internal difference in the IWAD directory between commercial DOOM II and the Final DOOM IWADs.


Which is why I think it's a bad idea to have the final doom texture names in the freedoom doom2 IWAD. That and file size bloat. (I would have preferred a separate final doom freedoom iwad)</rant>

Share this post


Link to post

Concerning mixing Final-FreeDoom and FreeDoom elements in the wad.

In terms of engine recognition:
Final Doom and DoomII run on the same engine internals. Only some title lines are changed.
In Legacy (now) both are irrelevant if the FREEDOOM lump is found.

In terms of bloat:
Less bloat. Keep only the stuff in the wad to play the designated levels.

In terms of confusion:
Yes, less confusion, do not put too many things together if they confuse the engine. I do not need more confusion. You may succeed in breaking the engine.

In terms of ease of use:
To play Final-Doom pwads, using FreeDoom IWAD ??
It is probably easier than a separate Final-FreeDoom add-on PWAD.

We probably could live with a separate add-on PWAD for Final-Doom stuff. It would at least be easier to keep track of what stuff is
included for Final-Doom.

Share this post


Link to post

I found a difference between Doom wads and Freedoom that is causing problems.

The coronas that are added for light sources depend upon the location of the flame or light on the sprite.

FreeDoom has moved the flame locations on the sprites so the coronas do not appear on the flames.
The most notable are the candle and the tall torches.

Does any other engine have problems with such differences between
FreeDoom and the original wads ????

If we made special corona location info for FreeDoom, is there any reason to believe that it would not change the next time someone wanted to replace a sprite with their latest creation.

I am thinking that there could be an additional lump to describe flame location, size, color, intensity, and such. This would support coronas and other special effects. The lump would be optional in IWADS, and if missing the engine could supply its own copy or turn the features off.
Such an idea would be best supported if the major engines agreed on
the format, fields, and meanings.
I could easily make a support file only for legacy, but it would be hard to get IWAD creators like FreeDoom to include one in their released lumps if it was Legacy only.

Would FreeDoom maintainers be willing to add such a lump to their IWAD to support corona and other lighting effects ????

This is a long term idea at the moment, as we won't be taking on such a large thing this close to release.

Share this post


Link to post
wesleyjohnson said:

I found a difference between Doom wads and Freedoom that is causing problems.

The coronas that are added for light sources depend upon the location of the flame or light on the sprite.

FreeDoom has moved the flame locations on the sprites so the coronas do not appear on the flames.
The most notable are the candle and the tall torches.


Ah, that age-old problem. I remember it with mods and Legacy in 1999!

wesleyjohnson said:

I am thinking that there could be an additional lump to describe flame location, size, color, intensity, and such. This would support coronas and other special effects.
...
Would FreeDoom maintainers be willing to add such a lump to their IWAD to support corona and other lighting effects ????


I'm sure they would. I don't think it would be a big deal for freedoom to include a legacy-specific lump, especially one which would be so small, so long as it did not interfere with other ports (was properly ignored). Obviously a cross-port lump would be ideal if possible. Perhaps leading by example is not such a bad thing though.

Share this post


Link to post

I think before adding some port specific definition lump, first there should be a common format for simple light definitions that is easily usable by all ports that have dynamic lights.

And for that, I'm sorry to say, Legacy is the worst thing that could be used as a guideline. I haven't even figured out yet, how the size and offset values are being used in it. They are not proper map units, that's for sure!

Share this post


Link to post

A standard format for dynamic lights?

1. Identifying the object. If only things like torches are concerned, it would be possible to go with their editor number. If you also want fireballs and the likes, though, the only impartial standard would be their index (aka dehacked number). This prevents said format from being usable for new content, but that's not a problem as far as Freedoom is concerned.

2. Light offset. Relative to the sprite, or to the world? It changes the interpretation of the Y and Z values.

3. Light color. RGB triplet is probably the simplest.

4. Light intensity.

5. Light effects (such as flickering, pulsing, etc.).

Share this post


Link to post

I don't care how. But I find it rather useless to cater to the least popular hardware rendering port - just because its (long gone) developers were stupid enough to hard code this stuff into the executable.

As Jon said, it has been a problem for more than 10 years now.


Anyway, how far should such things go? Now that Legacy's developer asks for special treatment we might as well ask for GZDoom light definitions (or Risen3D if it needs them to work as intended, or ZDoom MAPINFO, or some stuff that might be useful to Eternity, or who knows what.)

Share this post


Link to post

It's not hardcoded in Legacy. Only which items that got the coronas. The rest is scriptable in FS. Not the best way I am sure. But at least it isn't hardcoded.

Share this post


Link to post
kristus said:

It's not hardcoded in Legacy. Only which items that got the coronas. The rest is scriptable in FS. Not the best way I am sure. But at least it isn't hardcoded.



Hardcoded doesn't mean you can't change parts of it. It means that it's stored in a place where it can't be removed and that you can't freely edit it. And the fact that you can't change the items is hardcoded enough for me anyway.

The FS option is just a (very) crappy hack to change the hardcoded stuff.

Share this post


Link to post

Legacy is being updated. I personally have made a large number of fixes. I really do not need all the "I hate Legacy" posts. Such posts would only be useful if they actually included what bug they encountered that bothered them so much, so I could fix that. General "I hate it" messages are a useless waste of this forum.

I have not asked for, nor would seriously consider, a "Legacy only" lump being included in FreeDoom. It would never be maintained by any of the FreeDoom team, especially the Legacy haters. A lump supported by Legacy, ZDoom, and Eternity, etc.., would be interesting to consider.

I was asking this forum if they were aware of the differences, and was there an established action, or lack of action, on this issue.
I was asking if the ZDoom and Eternity developers who have to deal with FreeDoom differences have something to say.

It might be that no other engine has tried to do coronas and so it is a problem local to Legacy.

A new hardware renderer was written for Legacy 2.0, but it does not have coronas yet.
I have fixed a couple of problems in the Legacy144 hardware renderer but it is still not finished, and is unlikely to be much better in the upcoming release, and it is likely to be replaced by the new hardware renderer.
Any more beyond these statements, I do not see as being subject matter for this forum, or this question that I have asked.

Legacy144 already has the ability to load a support file for an identified IWAD. It is much easier for me to make another support file local to Legacy, if I could trust that the sprites would not change, which I would never believe. I cannot trust that unless the FreeDoom team has some established position on preventing such changes.

I am already looking at moving whatever IWAD dependent information that I can, into separate user editable support files. It depends on how much code it takes to support such a thing and is it worth it.
There is only FreeDoom and Blasphemer that I know of that are volatile enough to make serious use of such an ability.

A local support file in Legacy could not cope with two versions of FreeDoom with different sprites, such as the release version and a daily build. That is why it is worth considering a support lump in the FreeDoom IWAD itself.

Share this post


Link to post

Eternity doesn't have any current plans for a GL renderer so we really cannot weigh in on this issue. If it ever comes around to adding one, we'll just play catch-up to the standards that exist at that time.

However, I don't really see any particular reason that something like this cannot be implemented in a cross-port manner that any code could deal with. Just be smart about it :)

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
Sign in to follow this  
×