Sign in to follow this  
Followers 0

GAMEINFO support

A recent addition to ZDoom was the GAMEINFO lump. It's pretty simple but very efficient, and I think Eternity could benefit from it.

The principle is simple: the files loaded as parameters are briefly scanned to see if they have such a lump. If one is found, then the engine reads inside it which IWAD is needed and whether other files should be loaded as well.

Why is it something that would be practical for Eternity as well? Like ZDoom, Eternity supports more IWADs than a strictly Doom port. Accidentally loading a Heretic mod in Doom dumb. (Okay, I know Heretic support is not finished yet anyway, but it will be.) That's for the IWAD key. The LOAD key would actually be even more useful for EE than for ZDoom, because with ZDoom you can just bundle all needed WADs in a zip file and load that. With Eternity you have to specify each required file independently since they can't be bundled in such a way. Take for example this which uses two or three texture packs, or Ogro Power Facility which uses one.

Share this post


Link to post

This sounds like the purpose of GFS files. See GFS_REF.HTML, it's even documented. I don't know if they can be turned into lumps, or declare the main WAD, for now, because I haven't used them.

Share this post


Link to post

I don't understand how ZDoom can determine the proper GAMEINFO lump to parse before W_InitMultipleFiles, and Eternity *must* determine the current gamemode long before it gets that far. So as of right now, I don't believe this is technologically possible. It's certainly not a bad idea, and it is indeed somewhat similar to GFS. I just don't know how it will fit into EE at the present time.

Share this post


Link to post
printz said:

See GFS_REF.HTML

And where is that?

http://www.doomworld.com/eternity/gfs_ref.html => Error 404: This file just ain't here!

Quasar said:

I don't understand how ZDoom can determine the proper GAMEINFO lump to parse before W_InitMultipleFiles


Apparently, it just looks for the presence of that lump in each file indicated by the parameter, in sequence starting from the last. In doing so, this doesn't seem more complicated, technologically speaking, than scanning through the list of known IWAD names to look for the presence of specific lumps. As soon as one is found, the search is stopped.

	// scan the list of WADs backwards to find the last one that contains a GAMEINFO lump

Share this post


Link to post

Download the source code of Sekhmet from this forum. The documentation is still that one, not updated for Phoenix even.

Share this post


Link to post
printz said:

Download the source code of Sekhmet from this forum. The documentation is still that one, not updated for Phoenix even.


Thanks. That does sound indeed like it has a lot in common, with one notable difference: GAMEINFO is embedded in the wad, while GFS are external files.

Because of this, GFS are to be made by the user, while GAMEINFO lumps can be placed in by the modder.

Share this post


Link to post

By the way, GFS files and Console Commands will be good candidates for linking from Wiki's front page, once their articles are created.

Share this post


Link to post

I admit my knowledge of GFS is pretty limited, but I'm pretty sure that it's possible for a modder to include a GFS file along with their project, which can be loaded into Eternity for the same basic result of loading a GAMEINFO-using wad in ZDoom.

So, while they can be made by an end-user, I'm fairly certain that it's also possible for a modder to include one directly with their project, to be loaded/double-clicked/drag-n-dropped/whatever onto EE.

Share this post


Link to post
Quasar said:

I don't understand how ZDoom can determine the proper GAMEINFO lump to parse before W_InitMultipleFiles, and Eternity *must* determine the current gamemode long before it gets that far. So as of right now, I don't believe this is technologically possible. It's certainly not a bad idea, and it is indeed somewhat similar to GFS. I just don't know how it will fit into EE at the present time.



That's why I did a complete restructuring of the resource loading code.
It now separates the file objects from the WAD manager object and it's capable of opening single files outside of the main WAD manager and closing them again. This is also used to open the IWADs to check their contents.

This scenario wouldn't have been possible with 'classic' WAD loading code at all. ZDoom was no different in this respect before this change.

Share this post


Link to post
printz said:

By the way, GFS files and Console Commands will be good candidates for linking from Wiki's front page, once their articles are created.

The console command doc is significantly out of date, by the way. Commands have changed, commands have been deleted, and tons of new variables and commands exist. So that doc as it exists currently is more or less useless.

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  
Followers 0