Alternatively tested with the internal opl midi emulation, but that runs slow and doesn't prevent the issue. The earlier instability in an emulator was likely from inability of the Win95 audio buffer to keep pace with both the midi and sound playback. If testing in an emulator, set display option "rendering interpolation" to off. Testing in modern Windows and an emulator running Windows 95 OSR2 (with riched20.dll). The libsndfile distribution has instructions for including flac, ogg, and vorbis (configure without largefile support). The libsndfile v1.0.25 and and mpg123 v1.19 binaries were built from unmodified source code. User accepts sole responsibility for use of these unsupported binaries. Changes were made to adapt software to Win95. Included patches to compile zdoom and openal by mingw32/gcc46/nasm208/dx8. If testing in an emulator, set display option "rendering interpolation" to off.Īttached archive of binaries built from maintenance branch of zdoom (4/18/16). Removed the dependencies on ie4 and active desktop. The libsndfile distribution has instructions for including flac, ogg, and vorbis configure without largefile support where available.Ĭurrently testing in modern Windows and in an emulator running Windows 95 OSR2 (with riched20.dll). Verify that "sound backend" is openal and that a valid "playback device" is selected under "openal options". On starting zdoom: under sound options, change "midi device" by pressing right arrow until finding a working device such as: Creative Music Synth. A third patch is for openal-soft v112 and win95 compatiblity. Included two patches, one to compile source code by mingw32/gcc46/nasm208/dx8 and the other with updates to the openal code in zdoom (mainly from more recent commits to the openal branch). Reply 22 of 94, by leileilolĪttached archive of binaries built from openal branch of zdoom (2-2-15). This will greatly reduce any chance of preserving those mods on a software renderer. The issue into the future is that mod authors will develop solely on the gl renderer, such as in gzdoom. Using multithreading is not ideal for a Win95 target platform. I don't think the vanilla win32 Quake engines (1/2/3) are highly dependent on this kind of component (I recall that there is an additional thread to handle the Q2 console in Windows, but I'd have to verify). And if it is possible to restore some or all of the assembly path without breaking the more recent zdoom features (much like an addition of colored lighting to Quake 1).Īlso, it would be informative to test a zdoom client without multithreading components, particularly for Windows 9x. Also, I couldn't find which zdoom version corresponded to each mod version.Īnother major issue is the difference in performance between zdoom 2.2.0 and 2.7.1 and whether it is mainly attributable to the removal of an assembly path. If one of the goals is historical preservation of the best zdoom mods, then it may help to archive the different versions of each mod.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |