On Week 37
skyjake:
This time I was focusing pretty much exclusively on the qmake switchover. As the changes have a significant impact on our automatic building and distribution packaging system, there was plenty of work to do. Currently the work is nearing completion, with some final details still missing that need to be updated in the build system so that the automation will work correctly. I can already build fully functional distribution packages on Windows and Ubuntu.
One bigger change in the Windows build was that UNICODE will be enabled by default. This does not have any effect on the internal workings of the engine as such, but it will cause Doomsday to use the Unicode wchar versions of Win32 API calls. In the future, use of Unicode will be extended mostly thanks to Qt -- I doubt there is much to be gained by converting Doomsday's existing string/text handling routines to Unicode.
One cool thing with the Debian/Ubuntu build is that the build system will now create the .deb package on its own. For example, the .deb changelog will be automatically generated based on the git commits. Previously deb packaging was handled by CMake (CPack) and there were some annoying limitations...
I hope to finish the qmake switchover this week. The only problem remaining is that I need to add SDL_net back to the build before I'll merge the branch back to the master. I removed it earlier because it was incompatible with the Snow Leopard 64-bit build. After all this is done, the unstable releases will start using the qmake builds and I can start a new work branch for getting rid of SDL_net for good.
danij:
Work on the file system in ringzero continued this week. Various refactorings were implemented to simplify and clean up the object interface hierarchy. All in all there isn't a great deal to say about that however there are a couple of new noteworthy features; a) AbstractFile specializations such as WadFile can now be opened on any file from a non-zero base offset, facilitating the direct loading of files embedded within in larger containers, b) all lumps throughout the virtual file system are now marked with a hierarchical chain of containing-object pointers.
Other than the file system refactorings I also fixed a couple of bugs in the texture manager and font renderer subsystems, however it has been a pretty lite week from me progress wise.
Over the coming week I intend to complete the current bout of file system refactorings and then move on to addressing the remaining resource management regressions in branch ringzero.
This time I was focusing pretty much exclusively on the qmake switchover. As the changes have a significant impact on our automatic building and distribution packaging system, there was plenty of work to do. Currently the work is nearing completion, with some final details still missing that need to be updated in the build system so that the automation will work correctly. I can already build fully functional distribution packages on Windows and Ubuntu.
One bigger change in the Windows build was that UNICODE will be enabled by default. This does not have any effect on the internal workings of the engine as such, but it will cause Doomsday to use the Unicode wchar versions of Win32 API calls. In the future, use of Unicode will be extended mostly thanks to Qt -- I doubt there is much to be gained by converting Doomsday's existing string/text handling routines to Unicode.
One cool thing with the Debian/Ubuntu build is that the build system will now create the .deb package on its own. For example, the .deb changelog will be automatically generated based on the git commits. Previously deb packaging was handled by CMake (CPack) and there were some annoying limitations...
I hope to finish the qmake switchover this week. The only problem remaining is that I need to add SDL_net back to the build before I'll merge the branch back to the master. I removed it earlier because it was incompatible with the Snow Leopard 64-bit build. After all this is done, the unstable releases will start using the qmake builds and I can start a new work branch for getting rid of SDL_net for good.
danij:
Work on the file system in ringzero continued this week. Various refactorings were implemented to simplify and clean up the object interface hierarchy. All in all there isn't a great deal to say about that however there are a couple of new noteworthy features; a) AbstractFile specializations such as WadFile can now be opened on any file from a non-zero base offset, facilitating the direct loading of files embedded within in larger containers, b) all lumps throughout the virtual file system are now marked with a hierarchical chain of containing-object pointers.
Other than the file system refactorings I also fixed a couple of bugs in the texture manager and font renderer subsystems, however it has been a pretty lite week from me progress wise.
Over the coming week I intend to complete the current bout of file system refactorings and then move on to addressing the remaining resource management regressions in branch ringzero.
Comments
We need support for positional audio, MIDI music playback and OGG and MP3 music playback, ideally in a framework that supports all our platforms.
SDL_mixer is presently the default, lowest-common-denominator of the available sound drivers and support is built in to the engine itself. As I'm sure pretty much everyone knows by now, SDL_mixer is seriously broken and the output is not even all that good quality wise either.
FMOD EX is about the best option, both quality and functionality wise, however it is license encumbered and many distros and/or users object to its use in an open source project like ours. The current plan is to implement FMOD EX support using a plugin so that it can be optionally installed.
OpenAL has since gone proprietary while the open source OpenAL Soft (which as the name suggests) is implemented mostly in software.
Honestly, the situation is pretty grim on the audio front for any application with our requirements. We can solve the problem on each platform individually, using a combination of various platform specific APIs but that results in considerable duplication and it all has to be maintained.
PrBoom+ has some new music code that I heard works, is cross-platform, supports MP3, Ogg Vorbis and whatnot.
I expect the audio situation will move up our priority list once multiplayer is in a better state and the ringzero branch has been merged with the master.
As for the random pitch shifting of sounds, that is intentional to add a bit of variation. It can however be disabled with the -norndpitch command line option.
I just tried switching the option ingame and I get no ingame sounds (Only menu sound) unless I go back and turn off the 3D sounds. Then I get sound back.......
I tried it again, this time I had 3D sounds on before starting the map, and I hear sounds fine, but no matter how far away I get from the awakened monsters, they sound just as loud as if I was right next to them. I turned off 3D sounds ingame and they get quieter as I move farther away, like they are supposed too.
My motherboard is a gigabyte motherboard from 2009 with AM3. I doubt something that modern would be the culprit. So the culprit would have to be Doomsday, since it is far less modern than my hardware. In your case, I don't know if your problem is caused by your sound card. I used to have your same issue when I had the previous motherboard, but now I just have a different issue if I use 3D sounds. It also makes the sound lower quality.
I don't even know what 3D sound is supposed to do to make it any better. Give it surround sound? Sounds fine without it, and these days you don't need 4 speakers to have surround sound quality. I often get the sense that I can hear monster sounds coming from a specific direction (tell where they are coming from much of the time) with 3D sounds disabled and I have 2 small Logitech USB speakers. These are what my speakers look like: http://www.tigerdirect.com/applications ... No=3584262
3D sound in Dday adds a reverb effect to a sound, based off the texture and flat (1.8.6 only uses the textures; the 1.9 betas also use the flats) composition of the area it occurs in.
In a ded, one defines each texture or flat in the game as one of four hardcoded "environment types" (though 1.8.6 at least, also tries to call a fifth non-existing one). Obviously this doesn't work so well, when a wad includes custom textures/flat that replace the originals; i.e some wad may replace a metal texture with a custom wood one and the enviroment def attached to the texture, obviously wouldn't change). It's something that can't really be dealt with though.
The closest comparison is ZDoom's much newer REVERB Mobjs; these give an area a preset reverb out of loads of options (i.e. many many times more than four with some customization options to make your own variant). But the REVERB mobjs have to be placed in a map manually (Dday's 3D sound will work with any map without having to modify it) and aren't dynamic like Dday's 3D sound (in Dday, if a flat changes in game play, the 3D sound from the area changes).
However, it seems Dday's 3D sound doesn't work well with all sound cards.
Secondly, there was a bug in the management of the 3d sound state which has only just been fixed in recent automated builds. You can still change the 3d sound state but you would have to close and restart Doomsday for it to work correctly.
The 3d audio environment classes attributed to materials could do with a few enhancements, as you noted Vermil. The main one being that if a texture is replaced in a PWAD then the environment class should be changed to a neutral config by default.
In all there isn't a great deal wrong with the audio. In fact, using the DirectSound plugin with 3d sound and upsampling enabled; things sound considerably better than the default config (except obviously there is no music). It just seems to be a combination of non-intuitive options in the control panel (when using SDL_mixer), an interface bug which requires a restart and all the known issues with SDL_mixer itself.