Doomsday and ZIPs

[sirjuddington]

Note from Randy: This topic was split from the xWAD topic.

It will load any GTK supported PNGs from within TX_START and TX_END, true-colour or not.

TX_ namespace only? How about regular patches and textures?

Shouldnt be hard to add, but why? Does anyone actually use patches/TEXTUREx for new textures any more (when they have the TX_ option anyway)?

Grubber: That would be preferable yes, but pointless if everyone only uses the tabbed layout anyway. I'll have to see how much work it is to support both.

[Graf Zahl]

It will load any GTK supported PNGs from within TX_START and TX_END, true-colour or not.

TX_ namespace only? How about regular patches and textures?

Shouldnt be hard to add, but why? Does anyone actually use patches/TEXTUREx for new textures any more (when they have the TX_ option anyway)?

Of course people do. For scaled textures it is a requirement to do it this way.

[Kristus]

Not to mention, that there might be other people than Zdoom/GZdoom users who want to use it?

[sirjuddington]

Not to mention, that there might be other people than Zdoom/GZdoom users who want to use it?

Thats why I said '(when they have the TX_ option anyway)' AFAIK the only ports that support PNG patches also support TX_.

But Graf has a point, I'll add support for it when I can.

[Graf Zahl]

Another potential use would be to combine patches with a sum of >256 colors.

[DaniJ]

AFAIK the only ports that support PNG patches also support TX_.

Well Doomsday doesn't support TX_ (it doesn't support any of the newer WAD namespaces) but yet it was the first port to support PNG patches by using real files (in a folder or in PK3).

I'm still pondering the whole TEXTUREx/TX_/HIRESTEX issue as the new namespaces don't really benefit Doomsday mods from what I can see.

All our users need is to be able to add new textures without replacing an existing one.

[Graf Zahl]

All nice and well. But the problem with that is not on the engine side, the problem is that this is so different from everything else that editor support for it is bad to non-existent. That's probably the biggest advantage of TX_ so far. All the current editors support it.

[DaniJ]

But the problem with that is not on the engine side, the problem is that this is so different from everything else that editor support for it is bad to non-existent.

I think you've missed the point(?) there doesn't need to be any editor support (everyone has WinZip + Notepad (or similar)) when you're using "real" files.

Hang on, I've just realised what you meant...

I can't see how adding support for real files in a folder is difficult for editors. They are easy to read and easy to manipulate with no weird rules like in WAD. If you've written any kind of modern GUI app then you know how to do this stuff already. No excuses.

RANT: It's about time we had an editor with native PK3 (and lump assembly) support!

In this modern DOOM community there should be no need for editors to constantly read/write into WAD. Modern editors should write to (lmp) files in a folder (one folder per project with subfolders per level). Use cfg files to configure stuff like lump order (if required) saved to the "project" folder and editable via an interface in the app. Then in the app itself you have the options to Package as WAD and Package as PK3. Simple.

[Graf Zahl]

RANT: It's about time we had an editor with native PK3 (and lump assembly) support!

In this modern DOOM community there should be no need for editors to constantly read/write into WAD. Modern editors should write to (lmp) files in a folder (one folder per project with subfolders per level). Use cfg files to configure stuff like lump order (if required) saved to the "project" folder and editable via an interface in the app. Then in the app itself you have the options to Package as WAD and Package as PK3. Simple.

That is so true. It is annoying as hell that everything has to be packaged in a WAD for editing. In a perfect scenario the WAD/PK3 should only be the final output for distribution. But somehow I don't see this changing. Most mappers are so used to this that they wouldn't change their behavior.

[DaniJ]

Most mappers are so used to this that they wouldn't change their behavior.

True but at least Doomsday mappers are starting to. They can see how much easier it is working with real files and PK3s when it comes to models so thats why Skyjake implmented all this stuff in the first place.

For example in Doomsday you can run it with -vdmap C:/myawesomepwad }Data/jDoom/Auto and Doomsday will treat the folder C:/myawesomepwad as if it was the /Auto folder. So if you put a lump assembly inside that folder you've got a folder on your HD that Doomsday treats like a PWAD.

It annoys me that we've done all this work (including an overhaul of the virtual filesystem) but the editors are still stuck using the same old designs as the editors of late 90's.

[Nash]

As I have suggested on the GZDoom forum, I prefer working with real files directly, rather than the import/export nature of pwads. It's so 1993, it's old and inefficient.

Workflow would be soooooooooooo much faster if I can work directly with all the files in the folder. Especially when it comes to models...

[MartinHowe]

It annoys me that we've done all this work (including an overhaul of the virtual filesystem) but the editors are still stuck using the same old designs as the editors of late 90's.

While on the subject, the doomsday engine page, doomsdayhq.com, hasn't been updated in over a year and "skyjake" is still listed as the developer.

Where exactly is the "official" web site for the Doomsday Engine these days?

[DaniJ]

While on the subject, the doomsday engine page, doomsdayhq.com, hasn't been updated in over a year

It is pretty much dead yeah. It is too much of a pain to update since skyjake doesn't have access to a Windows machine (I think its updated from a local db or something (Access?))

"skyjake" is still listed as the developer.

Indeed he his. Also about 10 months ago I joined the project as a developer so now there is a "development team".

Where exactly is the "official" web site for the Doomsday Engine these days?

Currently there isn't an up to date, offical homepage. We'll get that sorted out once we're closer to putting the lid on the 1.9.0 release (we expect to have a somewhat extended beta period first due to the amount of new code). For now anyone wanting the latest on development would best to keep an eye on the forums and dengDevs.

dengDevs is home to our public developer blogs:
http://deng.sourceforge.net/blog/

Also, I'm busy finishing off the design of the new DEW (Doomsday Engine Wiki). Theres not much content yet (I still need to import the existing content from the old (Twiki) DEW:
http://dew.dengine.net

[DaniJ]

The only annoyance I could see with using folders instead of WADs is needing a seperate folder for each map.

Thats why in the new map loading code I've removed the lump name/order restrictions for map data loaded from real files

The idea is that you can prefix each lump for a given map with the name of the map eg:
E1M1_THINGS.lmp
E1M1_VERTEXES.lmp
etc

However IMO, seperate sub folders for each map (the name of the subfolder then becomes the identifier) is easier to manage.

[Graf Zahl]

The only annoyance I could see with using folders instead of WADs is needing a seperate folder for each map.

Thats why in the new map loading code I've removed the lump name/order restrictions for map data loaded from real files

The idea is that you can prefix each lump for a given map with the name of the map eg:
E1M1_THINGS.lmp
E1M1_VERTEXES.lmp
etc

However IMO, seperate sub folders for each map (the name of the subfolder then becomes the identifier) is easier to manage.

Do you really think it's a good idea to physically split the map into lumps?

IMO even when working with directories or Zips the maps should still be kept together. Unlike other data there's nothing to be gained here.
Dealing with split map data was something I deliberately avoided when adding Zip support to GZDoom.