Lifting the New Files Ban

skyjake

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

Now that the plans for 1.9 have changed quite a bit, I think we should lift the ban on creating new source and header files. If we are holding out on creating new files until 1.9.0, we will be seeing some extra-long files very soon. <tt>p_data.c</tt> is already suffering from this.

These are the new rules:
<ul>
<li>Create a new source & header file for code that clearly forms a new subsystem, e.g., the DMU functions.</li>
<li>Source files shouldn't be over 2000 lines long in any case. If it is possible to logically split a file this long, it should be done.</li>
<li>Existing file naming conventions should be followed.</li>
</ul>
However, in order to make it easier to keep all the build scripts and project files of all platforms up to date, we should maintain a list of new, renamed, or removed source and header files in this post. That way it's easier to do the update even a bit later.

I will be keeping the Mac project files up to date since I'm developing on a Mac nowadays. Danij, you can probably maintain the Windows <tt>vcbuild.bat</tt> script?

When it comes time to merge all the 1.9 stuff back to the trunk in the CVS, we must be careful that all the created/changed files get included.
<h3>List of Changed Files</h3>
(Keep these roughly alphabetical.)

<strong>New files:</strong>
<tt>Data/Doomsday.pk3</tt>
<tt>Defs/jDoom/PlutMaps.ded</tt>
<tt>Defs/jDoom/TNTMaps.ded</tt>
<tt>Include/p_arch.h</tt> (header for core DAM; map loading/init stuff)
<tt>Include/p_dmu.h</tt> (internal core DMU header)
<tt>Include/Common/dmu_lib.h </tt>(declarations for above)
<tt>Include/jHeretic/h_event.h</tt>
<tt>Include/jHeretic/h_items.h</tt>
<tt>Include/jHeretic/h_player.h</tt>
<tt>Include/jHeretic/h_stat.h</tt>
<tt>Include/jHeretic/h_type.h</tt>
<tt>Include/jHeretic/m_cheat.h</tt>
<tt>Include/jHeretic/m_menu.h</tt>
<tt>Include/jHeretic/p_mobj.h</tt>
<tt>Include/jHeretic/p_pspr.h</tt>
<tt>Include/jHeretic/p_setup.h</tt>
<tt>Include/jHeretic/r_data.h</tt>
<tt>Include/jHeretic/r_defs.h</tt>
<tt>Include/jHeretic/tables.h</tt>
<tt>Include/jHexen/p_setup.h</tt>
<tt>Src/p_arch.c</tt> (core DAM; map loading/init stuff)
<tt>Src/p_dmu.c</tt> (core DMU)
<tt>Src/Common/dmu_lib.c</tt> (helper functions for accessing DMU)
<tt>Src/Common/g_controls.c</tt> (moved all game-control & ticcmd building here)
<tt>Src/Common/p_setup.c</tt> (common code for loading a map)
<tt>Src/jDoom/d_api.c</tt> (Doomsday API setup/initialization moved here)
<tt>Src/jHeretic/h_api.c</tt>
<tt>Src/jHeretic/m_random.c</tt>
<tt>Src/dpMapLoad/glBSP/analyze.c</tt> (added during glBSP 2.20 update)
<tt>Src/dpMapLoad/glBSP/analyze.h</tt> (added during glBSP 2.20 update)

<strong>Obsolete files:</strong> (to be removed)
<tt>Data/Doomsday.wad</tt>
<tt>Include/jDoom/r_sky.h</tt> (now unused)
<tt>Include/jDoom/d_french.h</tt> (old unused french language support)
<tt>Include/jDoom/d_main.h</tt> (old unused file)
<tt>Include/jDoom/d_netJD.h</tt> (old unused file)
<tt>Include/jDoom/d_ticcmd.h</tt> (old unused file)
<tt>Include/jDoom/x_hair.h</tt> (old unused file)
<tt>Include/jHeretic/S_sound.h</tt> (now unused)
<tt>Src/jDoom/p_setup.c</tt> (old game specifc map loading code)
<tt>Src/jDoom/r_sky.c</tt> (old unused file)
<tt>Src/jDoom/doomdef.c</tt> (old unused file)
<tt>Src/jDoom/doomstat.c</tt> (old unused file)
<tt>Src/jDoom/dstrings.c</tt> (old unused file)
<tt>Src/jDoom/m_swap.c</tt> (unused. we have common endianes stuff now)
<tt>Src/jHeretic/M_misc.c</tt> (now unused)
<tt>Src/jHeretic/P_sight.c</tt> (now unused)
<tt>Src/jHexen/P_sight.c</tt> (now unused)

<strong>Unneeded files:</strong> (added in 1.9.0 branch but can be removed)
<tt>Data/Graphics/BigFlare.png</tt>
<tt>Data/Graphics/BRFlare.png</tt>
<tt>Data/Graphics/DLight.png</tt>
<tt>Data/Graphics/Flare.png</tt>
<tt>Data/Graphics/Zeroth.png</tt>

DaniJ

This is good news. Not just for the engine-side code. As the games now use a lot more common code I was planning on a bit of reorganising in Common/ at some point (the game headers could do with it too). They'd also benefit from sharing a common layout. The jHexen headers in particular seem very unorganised.
<blockquote>Danij, you can probably maintain the Windows vcbuild.bat script?</blockquote>
Yeah thats no problem.

skyjake

One more note about the merge that has to done some time in the future. Due to shortcomings of CVS, we should avoid renaming files in the 1.9 branch. Any changes in the trunk will be in the originally named file, not the one with the new name. We risk losing some of the changes, which requires manual merging.

DaniJ

Understood.

DaniJ

Any files due for removal after the head merge I'll empty and mark with:
<strong>#ifdef TODO_SRC_CLEANUP
</strong>#warning "Obsolete file, to be removed"<strong>
#endif</strong>

skyjake

Yes, that's good.

I updated the list of files and revised the formatting a bit. Note that new files should be all in lower case. I added the <tt>p_dmu.c</tt> and <tt>p_arch.c</tt>.

DaniJ

What would be a good file name to put the various new game-specific handlers (eg P_HandleMapDataProperty())?

Some of them will be generic and should go into d_api and others are map data specifc.

skyjake

How about <tt>p_setup.c</tt>? Each game already has one of those, which is good. We could add a <tt>Src/Common/p_setup.c</tt> as well.

DaniJ

I thought that myself but after creating <tt>Common/p_setup.c</tt> I got the following:

<strong>warning LNK4042: object specified more than once; extras ignored</strong>

It appears the linker in msvc toolkit doesn't like the idea of two objects with the same name.

I'm not sure if modifying <tt>vcbuild.bat</tt> so that objects are put in seperate folders before linking (atm they are all moved to <tt>Obj/Release/jDoom</tt> even those in Common) can/will help.

DaniJ

Before I start the clean up on jHeretic:

Do you have a banner I can apply to Raven licensed src files?

If not I'll make one by extracting stuff from <tt>Ravenlic.txt</tt>

skyjake

<blockquote>warning LNK4042: object specified more than once; extras ignore</blockquote> Ah yes, that might be an issue. Just name the common one <tt>Common/Src/p_mapsetup.c</tt>?

<blockquote>Do you have a banner I can apply to Raven licensed src files?</blockquote> No. <tt>Ravenlic.txt</tt> sounds like a good starting point, though.

DaniJ

Added <tt>Include/jHexen/p_setup.h</tt>

DaniJ

Began cleaning up <tt>Src/Common/g_game.c</tt>
Moved all game control & ticcmd stuff to (new) <tt>Src/Common/g_controls.c</tt>

Removed obsolete <tt>Src/jHeretic/P_sight.c</tt>

DaniJ

Added <tt>Defs/jDoom/PlutMaps.ded</tt> & <tt>Defs/jDoom/TNTMaps.ded</tt>

DaniJ

Made flare, dynamic light and particle zeroth graphic resources external files in <tt>Data/Graphics</tt>

Removed obsolete <tt>Doomsday.wad</tt>

TODO: If necessary put all the <tt>Data/Graphics</tt> into eg Doomsday.PK3 and load that automatically.

skyjake

Yes, having a Doomsday.pk3 with most of the engine's Data/* files would make things a bit cleaner.

I guess the practical benefit of having a Doomsday.pk3 is that we could create alternate pk3s for customizing things like the Control Panel UI theme. This means the pk3 should contain .cfg files for setting the default colors and things like that in addition to the graphics, help text, keymaps, and other data.

DaniJ

Sounds good to me.

While we are on the subject of cleaning up the install directory - will the jDoom.EXE etc forwarding apps be removed from the 1.9.0 distro? If not they need to be fixed as on my system at least they don't seem to work correctly anymore (I don't recall when exactly since I've always used Snowberry/KickStart).

skyjake

We should get rid of those "quick launch" exes. They can be replaced with .BAT files.

Further note about Doomsday.pk3: When we have a standard Doomsday.pk3, it is easy to replace specific files in it using another pk3 that contains only those files. This means a "theme" pk3 would not need to include all the data files, just the ones that are different than in the default package.

DaniJ

How about the Doomsday DED's (<tt>Doomsday.ded, Flags.ded and XG.ded</tt>) should these go into Doomsday.pk3 also?

Is there any reason you know off as to why Doomsday can't find <tt>CPHelp.txt</tt> when I put it in <tt>Doomsday.pk3 Data/</tt> and the <tt>dir</tt> ccmd lists it with the correct virtual path?
Also I think a shortcut to Snowberry (named Doomsday) should be added to the Doomsday base folder.

NOTE TO SELF: When creating the quick launch .BAT files remember to update <tt>Example.BAT</tt> in <tt>Docs/</tt> also.

DaniJ

<tt>Src/jHexen/P_sight</tt> Obsolete (to be removed)

Added <tt>Data/Doomsday.PK3</tt>

The new files recently added in the 1.9.0 branch to <tt>Data/Graphics</tt> (eg Zeroth.png) have now been included in the new <tt>Data/Doomsday.PK3</tt>