the difference between the existing WAV recording mode and multitrack
recording is that all mixer channels are recorded separately to their
own audio track in an AVI. Hopefully, you can use the AVI to then do
your own downmix in your video editing software of choice.
After the release of SDL 1.2.13, a commit for their bug# 611 was applied to enhance ioquake3 mouse input in Windows, particularly to enable dinput in an opengl application and for reliability of mouse input under the windib driver. For example (from their commit): "Googling for this indicates that often this is known to result in "spurious" and/or "missing" mouse movement events...". It also added a dependency on dinput7.
The attached patch reverts the above commit and it applies to a recent version of SDL 1.2hg (tested in mingw32 and Vista). This restores the mouse input latency to that of SDL 1.2.13 and fixes specific mouse cursor stuttering issues (limited testing of windib and directx under output=surface and =opengl in games such as SC2000, FS 5.1, and UT99/3dfx). It also fixes other minor mouse issues, such as the major loss of mouse movement events while the 3dfx emulation is active in the opengl or software rasterizer path. The previous workarounds
retrace even if not blanking. some DOS demos program custom VGA modes
(incorrectly) that end up putting vertical retrace during active
display.
"Monolith" demo custom mode (320x590) works again.
bit 0 of 3DAh = 1 means horizontal OR vertical blanking
bit 3 of 3DAh = 1 means vertical retrace
the mistaken code set both bits during vertical blanking, not vertical
retrace, which caused hpel and page flipping/flicker issues with DOS
games and demos.
[http://www.osdever.net/FreeVGA/vga/extreg.htm#3xAR]
register and page register when carrying out 16-bit DMA? this change
updates the code to allow either one method that allows 128KB boundaries
for 16-bit DMA (which DOSBox has already been doing anyway) and the
other method that limits 16-bit DMA to 64KB boundaries but preserves all
bits of the page register (which is said to be the way PCI-based
motherboard do it). You can choose which one from dosbox.conf now, or
let DOSBox-X decide based on your hardware configuration (which is
currently based on whether or not the VM has PCI emulation enabled).
See #231 : for vga emulation, expect both bits set during vertical blank/retrace. Improves mouse responsiveness in FS 5.1 and, by a previous report, in non-flight screens of Wing Commander.
This change is specific to the Voodoo software rasterizer and effectively disables its mipmapping; however, the opengl path is unaffected. Where mipmapping is active, then textures are compressed to low resolution at a near distance whereas this should occur farther away. For GLQuake, the gl_nearest and gl_linear modes are available. UT does not offer the mipmap option in its preferences for glide mode, but this commit will workaround the above texture issue.
No reference to the contents of SDL_thread.h in sdl_mapper.cpp, so removed the relevant line. Verified also in a win32 build with this change - the compiler and linker reported no error.
hardware. Apparently bits 3 and 7 must be set to enable memory access,
else register 0x83 just returns chip ID. bits 4-6 don't matter in that
case. bits 0-2 enable index reset and autoincrement as noted.
0x83 appears to be uninitialized at power-on. what I thought were
signficant contents were really just bytes of RAM that are mostly 0xFF
but contain randomly flipped bits based on whatever the RAM cells
happened to latch onto when the card first powered up.
actually mean. Apparently modes 0xF8-0xFF are some kind of memory access
mode, and bit 2 resets the memory index == 0, bit 1 says to increment
memory address on write, bit 0 says to increment memory address on read.
this also emulates useless ASP modes 0xFD-0xFF as well.
register 0x83 is some sort of access port to what appears to be 2KB of
RAM on the chip (it's readable/writeable). When you set mode == 0xFA,
you enable writing to the RAM with increment. When you set mode == 0xF9,
you enable reading from the RAM with increment. Creative's DIAGNOSE.EXE
utility appears not to care so much whether the byte sequence is
0x00,0xFF,0x00,0xFF so much as it cares whether or not it can read the
bytes, invert them, write them back, then read back and invert the bytes
again. For reference, a dump of the 2KB RAM block from the chip is
provided in the source code as the initial contents. The dump is from a
Sound Blaster 16 non-PnP card with DSP version 4.4 and ASP chip version
ID 0x10. Creative's DIAGNOSE.EXE utility is happy with the emulation so
far, since it gets all the way to asking for the chip version ID.
I can only assume this 2KB block of RAM is somehow key to communicating
with the chip and the microcode you upload to the chip when you want
hardware accelerated decompression (to run CSP images).
what is returned to the game or OS differs by whether or not there is an
ASP chip. Cards that lack the ASP always return 0xFF no matter whether
you ask version, register contents, etc. If DOSBox/DOSBox-X does not
emulate the ASP anyway, why give the driver the impression that there
is one? Why not act like a typical SB16 that doesn't have one? But if
you want the old behavior back, you can set "enable asp=true" in the
[sblaster] section of your dosbox.conf
command 0x40 (set time constant) and command 0x41/0x42 (set sample rate)
when handling SB/SBpro style playback commands (DSP command 0x14).
Bugfix for unofficial Silpheed Sound Blaster drivers. These drivers use
SB16 sample rate commands if DSP version 4.xx is detected, but will also
use DSP 1.x/2.x commands to play audio.
indicating it's presence. Also fixup autodetect to use pkg-config to find it (because CentOS 7 sticks FFMPEG
headers under /usr/include/ffmpeg for some reason).
extended load/store and 64-bit integer load/store will use it to
preserve the contents correctly instead of downgrading FPU precision to
"double" type. This hack makes it possible for DOS games/demos using the
"fast Pentium memcpy trick" to copy data correctly. "Toontown" demo now
renders to screen correctly without vertical lines.