Commonized Map Setup

skyjake

<i>This post was originally made by <b>skyjake</b> on the dengDevs blog. It was posted under the categories: Engine, Games.</i>

I was wondering what is the current status of the map setup code? I now have jHexen starting up nicely, but map loading fails. Looking at the code, it doesn't seem completely functional at least in jHexen's case.

If I remember things correctly, the code in <tt>p_arch.c</tt> will be handling the map setup on engine-side. How does this work in Hexen's case, with its own map data formats and extra lumps?

Danij, if you haven't been looking at jHexen's map setup, please do so in addition to the jDoom and jHeretic map setup.

DaniJ

The map setup code is functional but not all the struct formats are implemented yet (for now disable GL Nodes via bsp-build 0). Plus I've not updated jHexen's property forwarding, handler functions so it will bomb (probably when reading sectors?). This is what I had planned to work on today but I have been busy with other things up to now.

There is still some work to do (ie reading sides+lines needs to use the new P_ReadBinaryMapData).

There is the issue of poly object setup which we need to decide how it will be handled before the common map setup code can be finalized (the required calls to R_SetupLevel arn't being made (they will happen in the engine now) but until we decide how poly object init will happen I've left them in the game).

The common code works for all the games including jHexen (it was completely functional before I moved it into the engine) but due to the above - none of them will load successfully at present. I have taken jHexen into consideration when designing the common map setup code and it will work for all the games.

MAPINFO and BEHAVIOR is still handled by jHexen but if BEHAVIOR is found the map setup code will assume the map is in Hexen format.

RE:
<blockquote>#warning "Should P_UpdateMobjFlags be defined somewhere?"</blockquote>
I removed it as it wasn't serving any purpose in any of the games.

DaniJ

I've now updated jHexen to use the new custom property handlers (in CVS).

I can now compile and run jHexen.

After map loading is complete Doomsday currently exits with:
<tt>P_Callbackp: Type (invalid) unknown.</tt>

Have fun

skyjake

I'll get on it.

Currently there is a function called <tt>G_ResetMousePos</tt> missing. Has it been committed to the repository?

skyjake

Ah, spotted it. Apparently you added in g_controls.c?

DaniJ

Yes. I've made some new file additions recently, see the "Lifting the New Files Ban" thread (I've been leaving comments and updating the main list after each change).

DaniJ

Update:
I've just commited some fixes to the common map loading to CVS that address the problems with loading GL Nodes.

It should now be possible to load GL Node data once again (bsp-build 1).

DaniJ

Have you had chance to think about poly objects with regard to map setup?

I'd like to try and get the common map setup code finalized this weekend.

skyjake

Unfortunately I haven't had time to think about the polyobjs. What needs to happen in practice is that at least some of the polyobj init code currently run by jHexen is moved to the engine, or at least commonised. I'll see if I can look at this during the weekend.

DaniJ

I'm currently working on the map setup code again, revising the implementation so that it will intergrate with the DMU subsystem.
EG:
It should be possible to read a value from an archived map using the same functions for accessing DMU ie
<pre>P_GetIntp(sector, DAM_LIGHT_LEVEL);</pre>
<pre>---</pre>
I noticed your response to the propertyTypes array in <tt>p_data.c</tt> While I'm fixing that I wondered if I should create a new type (dmupropertyinfo_t) that would hold both the value for the property type constant and the "nice name" used for debug messages in <tt>p_dmu.c</tt>-DMU_Str() ?