In this Discussion

Lifting the New Files Ban

<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.)

Comments

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.

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.

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.

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).

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.

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.