32-Bit Map Format Proposal

[Quasar]

No offense meant whatsoever but your solution sounds far too tailored to a specific source port to be adoptable by any others without importing tons of code (redundant code in some cases) from the Doomsday source.

[DaniJ]

At this point it is not tailored to Doomsday at all since (currently) the games nor engine have made ANY changes to the map format (or how it is handled) above the original DOOM and HEXEN source releases.

All it does is read data from a stream (byte array loaded using the traditional WAD lump code) and put the results into the internal data structs. The code is also completely self-contained in a seperate subsystem (other than parsing the format definitions which is handled by the DED reader but then all ports have their own text definition parsers). The reason it has become quite robust is due to the requirements placed on it by Doomsday's engine+game.dll architecture (which can be easily stripped out for other ports).

It should be quite portable with minimal effort. All that would need to be done is updating the hooks (returning ptrs and a data type constant to portX's internal struct members based on the value of a property constant). It is based on the original solution posted here...

I get where you're coming from though. I've just taken it further to a point where everything is handled at runtime out of necessity due to Doomsday's architecture. It's probable that other ports don't need this level of dynamic so its up to them what they choose to do.

From my POV it doesn't really matter if other ports opt to use my code. What matters is that the same functionality can be added to any port as its not too different from the existing functionality present in all source ports.

The only thing we need to agree on are names/value constants for properties (but even those could be determined at runtime if we can't agree ;))

[sirjuddington]

Graf Zahl said:

No. Before I can do anything I need an editor source I can work with. That's why I am waiting until SlayeR has converted SLADE to wxWidgets.

Why do you need an editor source to continue with the spec? I'd be happy to send you what I've done of it so far. It's actually pretty close to being done.

[Graf Zahl]

The spec itself isn't the problem. I have a good idea what to do and how to do it. But I need something with which I can test the whole thing and an editor is much better suited for that than the engine itself. After all, without the ability to create levels using the new features it's all rather useless, isn't it?

But if you are almost done I think it's better to finish it first. I won't be able to work on anything Doom related in the next 2 or 3 weeks anyway.

[DaniJ]

After all, without the ability to create levels using the new features it's all rather useless, isn't it?

Thats where there is a huge difference between our reasons for attempting this in the first place.

In Doomsday I'm doing this so that:

• Structs are no longer used to provide byte offsets into the lumps (so making packed structs a requirement (which might not be guaranteed on all target platforms))
  
• Map loading is handled independantly of what games' format the data is in, without knowing the format at compile time (within the engine). This immediately makes extendability of paramount importance.
  
• Map data objects can be hidden from the games completely inside the engine and are accessed via the DMU (map update API).
  
• Games no longer need to be concerned with reading map data, it is a job for the engine anyway.
  

These reasons alone make this work extremely worthwhile and necessary for extending further the game<>engine independance.

[Jon]

Graf Zahl said:

No. Before I can do anything I need an editor source I can work with.

WadC is open source...

[Quasar]

Fascinating idea to use WadC, but it's definitely not the editor of choice for most people. The fact it already uses a textual input language to create a map would make it EXTREMELY easy to add native support for ExtraData -- BUT, this is the problem to begin with: editors that do not support a textual interface have much more difficulty, because they base their user input on controls that are hard-coded to the known fields that are available. It takes quite a bit more programming (a good deal of it API-related) to make them support it.