On Week 46

skyjake

skyjake:

Last week I took a look at the items in the multiplayer debugging backlog and did some reordering. I intend to continue the work by focusing on weapon behavior and psprites -- things that are front and center in the gameplay experience.

I had to revert back to 32-bit builds for my daily development, as SDL_net does not have a 64-bit binary available on the Mac and attempts to build one myself have not borne fruit.

Other things on my to-do list are some enhancements to the autobuilder system so that we can get the installation packages distributed via SourceForge download servers and integrate the build information at some level to the wiki.

danij:

It is was recently brought to our attention that Doomsday lacked the ability to disable antialiasing. I rectified the situation by implementing a -noaa command line argument in the master branch, which presently disables the full scene antialiasing used on the Windows platform (now available in build #325). At some point I'll expand upon this by adding an in-game control to the control panel.

As outlined in my previous update my plan was to address the problems with our support for DOOM's method of dynamically constructing texture/flat animations.

To this end there have been several significant changes in branch ringzero+master. The largest of which being the deferral of game initialization until after startup resources for the game have been loaded. Consequently texture animation sequences are read during game pre-init. These animations are then later used to autogenerate Group definitions (in the process fixing bug #2480718). These changes also mean that it should now be possible to fix the "flashing bloodfall" issue seen in Plutonia2.

The Textures collection was enhanced with support for resolving texture URNs (of the form urn:<namespace>:<uniqueid>) via the same mechanisms used with URIs. Each unique texture is associated with a URN, determined by namespace specific logic. For example, the TEXTURES namespace allocates URNs using the texture's logical index from the start of the corresponding lump. It is these unique texture URNs that are now used to implement DOOM's dynamic texture/flat animation building logic.

Further to the work on the animation construction, I spent some time cleaning up our public API facilities for working with textures. I also removed the last remnants of patchinfo_t for caching metadata about Patch graphics on game side.

The Fonts collection was enhanced with the same interface features as present in the Textures collection (in the process addressing the outstanding issues with the management of logical Fonts). There however remains an issue in the font renderer with the management of font display lists after an engine/texture reset.

The plan for the coming week is to refactor the mechanisms which derive the GL texture unit state from Materials, addressing the last big performance bottleneck in this subsystem.

All in all it was rather a productive week. Lets hope this becomes a trend

gary

I just installed this new build not knowing that I could download a new build each week without having to wait for the next major release and without having to register for the feed or anything else. Is it me or is the lighting more realistic and the performance is better with dynamic lights in this build as opposed to 6.9? It does load faster too. However, I do notice that an animated texture is having the same problems as the bloodfalls texture. I have no idea what the texture is supposed to be though, but I'm on map 27: Red Hot in Plutonia 2. But the performance and improved detail just awe inspired me. I don't think it is my imagination that the lighting, glows, and performance is better. I like this. Very good work.

Also, all I did when installing was download the exe file build and install it into the already existing Doomsday folder without removing anything first. Is that the correct way to install it? In the past, I felt that I had to delete the folder and all, but that takes time. I can also tell that it updated some of the files under Doomsday by looking at the date next to the files. I am assuming that I installed it correctly and it automatically overwrited just the core files. This is good since it means I never have to delete anything or cut out the custom folders and put them back in after making a new Doomsday folder or have to risk losing a saved game or resetting the Doomsday options.

DaniJ

You shouldn't need to place user data into the Doomsday install folder. Doing so you will run into the kind of issues you mentioned. What have you got in there and why?

In short, no, you didn't install it correctly. At present the Doomsday for Windows installer does not automatically handle an "upgrade" scenario. The correct way to upgrade is to uninstall first and then install the new version.

We have plans to address the situation with upgrading Windows installs in a future release.

gary

You asked what I have in there and why...

I copied the high res textures and put them into a folder structure under jdoom (currently making the folder structure match the way it appears in the texture rar container) so that if a high res texture is conflicting and overwriting a Plutonia 2 custom texture, I can remove it in the folder. That way I can use high res textures for almost everything else and at the same time have the Plutonia 2 textures appear. I'm not going to play the entire wad using all low res textures so I came up with a way around that.

I also made a model pack by combining the jdrp+ fixes pack which has better assets with the tea monster caco and pinky models. That way I can use the superior assets of that updated package and at the same time replace the caco and pinky within that package with the superior Tea Monster versions.

I also have some sky background ded's in my addons folder so I can select them from the launcher, giving me more options of what I want to use. I could simply rename a sky into skybox2, for example, then paste it into the skybox folder that corresponds to whatever Doom I'm playing, then select the ded file from the addons menu and it will use that sky instead of the sky I don't want to use.

It would be easier to somehow take screenshots of my folders and post them, but I don't think the forum has that ability.

One reason I didn't reinstall is because I'm afraid of losing my saved game data. I'm all the way on map 28 now. So if the bloodfalls problem is fixed, I guess I need to uninstall and reinstall for that to take effect. Maybe I can find and copy the saved data. I will have to look for it and cut out the file.... My guess is it is under the profiles folder. So I just copy that or will uninstalling leave that intact and no need to copy the data?

DaniJ

You don't need to work within Doomsday's install folder to accomplish the above. Doomsday has various command line options which allow you to install your data in another location and then map it into Doomsday's virtual file system at run time.

For example, the textures could be mapped using the -texdir argument (e.g., -texdir c:\doomstuff\textures).

Your save games are safe during an uninstall. Try it; make a copy of them (just to be safe), uninstall Doomsday, now install the new version. Look in your saved game directory and you should see your saves are still there.

As for the bloodfalls issue, I was actually talking about the ringzero+master branch in my update and not the master branch. The automated builds are generated from the master branch. You won't see those fixes until the ringzero+master branch is merged with the master.

gary

Maybe that is what the Doomsday Frontend folder is for. To use that for what you are suggesting. I'm trying to understand this concept but it sounds like a backup and being able to undo changes if something goes wrong in the main Doomsday folder. But no matter what, I would think that it would load files from the main Doomsday folder. I don't see what creating another folder would do and why map it since it all depends on what happens in the main Doomsday folder.

Mapping indicates that they are linked and one affects the other. I know about mapping keys to my gamepad controller, but not mapping folders of the concept. Even when I took a computer class long ago mentioning something about mapping files, I couldn't understand the concept. Sounds more difficult to use a non - GUI method. I took a DOS class a while back too.

So is this some form of backup? It seems that no matter what, things within the Doomsday folder will need to be changed for the game to be changed in anyway. Also, if I just use command lines and not open the folder to see what has changed and what I accomplished in a GUI way, then it is not as easy to know if I did it correctly. Plus memorizing all the commands, understanding their value and what they do, and finding the list itself, which I assume is in some document file stored in Doomsday.

DaniJ

The benefit behind mapping resources into Doomsday's virtual file system is that those resources can exist entirely independently from Doomsday. If you want to upgrade Doomsday you can do, without worrying about what happens during an uninstall or whether your user data is safe (it is only "at risk" because you placed it within Doomsday's install directory). It is much the same as telling Doomsday the path to your IWAD(s).

You can find a mostly complete listing of Doomsday's command line options at the wiki.

I agree with your point about the command line being trickier to use than a GUI (in this case I assume you mean Explorer, on Windows). Once Snowberry has been phased out and Doomsday itself can be used for addon management - we'll look at implementing a GUI mechanism to assist in creating these mappings.