That was my quote....and I could never get the result I wanted from daum's settings in EF2000.
All I'm doing is applying a scaling factor as the triangles are being sent to opengl. The scaling factor is the wanted window resolution divided by the 640 x 400 dimensions of EF2000....which is the only game I'm interested in.

Here's a link to an XP friendly binary, together with voodoo_emu.cpp and voodoo_opengl.cpp (and also sdl_main.cpp which shows how crudely I'm working out the scale factor). I've put a //mikew comment after every line that I've altered.
http://rapidshare.com/files/3312974923/voodoo_ef.zip

That's an ingenious idea! Thank you for posting your source code, too. Have you also tried the glScalef function to scale the image?

This is an especially powerful technique to scale because the 3dfx code is also used in dosbox 95/d3d games, and these games would benefit from the offloading of CPU operations to the GPU and from the excellent quality of the scaler. Also, the DOS glide games, if the image above is any guide, will scale much better than with default dosbox.

Attached is bored's 3dfx scaler patch for EF2000 (and adaptable to all 3dfx powered games in dosbox). It is applicable to DOSBox-0.74/SVN + Voodoo1 patches.

Attached are a modified version of Bored's 3dfx scaling patch and corresponding test builds of DOSBox 0.74/SVN+3dfx scaling patch. Included with the test builds are SDL.dll, SDL_net.dll and dosbox.conf; there are no other files which these builds depend upon. Also, the following dosbox.conf settings should not be changed: fullscreen, fullresolution, windowresolution, output, aspect, scaler, and voodoo; the remaining settings may be changed. The two test builds consist of one which scales 2x in 3dfx mode while the other scales to 3x. Therefore, if your 3dfx DOS game runs at 640x480, then the 2x scaler will scale the game to 1280x960; the 3x scaler to 1920x1440. If your monitor has a native resolution of 1280x1024, then you can run the 2x scaler but not the 3x scaler because it will expand beyond the boundaries of your screen.

Modifications to Bored's patch include: centering the window instead of anchoring at the screen corner, reverted code to integer scaling instead of fractional scaling, removed automatic detection of resolution in sdl_main, a couple of edits to code, and removed lines which did not impact function. This version should run all 3dfx DOS games. This patch was only tested against EF2000, so once other 3dfx titles are tested, then a fractional scaler could be reintroduced into the code.

EF2000 fully works with Bored's patch, however, there is a graphical anomaly which does not affect gameplay. When zooming in to the instrument displays, then the surrounding background has an overlapping texture which is a mirror of the instruments. I know the source of this issue, it is the glVertex2f function which handles the 2d HUD display. When all is scaled but this HUD display, then the anomaly disappears; even the smallest degree of scaling causes this anomaly. I was unable to fix this issue at the level of the opengl function. Also, the fullscreen function will not preserve the aspect ratio of a game. This issue may also be caused by expanding the 2d HUD display. However, the quality and speed of the scaling is very high. As Bored indicated, this 3dfx-based scaling is without loss of quality in contrast to conventional scaling techniques based upon pixel placement.

moved to the patches forum

Attached is version #2 test build of DOSBox+3dfx_Scaler along with an updated patch. This update includes fractional scaling of the 3dfx window and an option for fullscreen rendering; also, the included dosbox.conf file has 2 additional options and a new value for output mode. The output should be set to 3dfx (output=3dfx); then the 3dfxheight and 3dfxwidth settings and values will be active. The values are in percent, so setting both these to 100 will result in no scaling; setting both to 200 will double the window size. These values correspond to exact %scaling when rendering to a window.

However, in fullscreen mode the correspondence is not exact; setting both 3dfxwidth and 3dfxheight to 160 will result in a near fullscreen image, even though the values instead must be 200 for full stretch in window rendering (at least for a 1280x1024 monitor). The user should experiment with lower values of scaling to find a decent fullscreen fit of the image where running fullscreen=true.

I haven't looked at the code in detail, but why aren't width and height connected to the window/fullresolution options?

Hi! I agree. :-) I implemented this way mainly for testing; also since I haven't found a better way to determine the game's screen resolution and communicating a ratio of that resolution and the user's screen dimensions to the 3dfx emulation code. In addition, the fullscreen dimensions do not correspond properly to the scaling factor - just another hurdle. With the way implemented above, it gives the user the ability to adjust for all these separate issues with the hope they can test other 3dfx games (I only tried EF2000).

Another benefit of Bored's scaling method is that it corrects for the ATI opengl bug (font issues) I encountered in EF2000/3dfx.

Edit: Confirmed that this scaler works for 3dfx titles in both DOS and Windows95. Unreal Tournament has faster framerates using this scaler as opposed to other configurations; used screen resolution of 512x384 and scaling factor of 200%. There appears to be no performance penalty for increasing this scaling factor. However, Direct3d titles are not compatible with this current scaling method.

I tested both of these on Whiplash 3dfx. No problems-- in fact, I'm now disposing of some dedicated hardware for playing this game. Thanks a bunch.

Oh, does Dosbox fail to record opengl output? I couldn't make any recordings, but that's just a minor annoyance.

I'm glad it worked for you and in another 3dfx title. Kekko's V1 code (with credit to gulikoza) sends video directly to the GPU (by OpenGL instructions), so capturing video could be done by the "Fraps" software which works at the video driver level. In addition, ClipX will capture images where "Print Screen" does not.

To what source are the patches in this thread applied against? I've been looking for a recent patch to apply to the SVN for voodoo emulation. I hit this thread, 3dfx voodoo chip emulation which is locked. I get "No input file specified." when I try to download the patch at the beginning of that thread.

I've not been able to find a recent patch that adds voodoo capability.

As an aside, my aim is to recompile the binaries offered so that they work on older hardware-- they work great on my core2 systems, but crash immediately on an athlon-xp system I want to run on.

Your web link is to the Vogons thread which contains the patch: view page 4 (and later) of that thread. The issue on the athlon-xp system may be related to the video card. Unfortunately, I would be unable to determine the cause of the compiling problem as this part of the forum is for developing and testing patches. You may contact Ykhwong, the author of the Daum build, if you would like the patch included in a multi-platform build. I fully support his DOSBox build, especially for use of the most recent patches. I removed the above test builds as the patch has been evaluated by others.

[quote="truth5678"]The issue on the athlon-xp system may be related to the video card.[/quote]

I tracked down the crashing to sdl.dll. Probably one of the ones I was working with had optimizations for core2 or something. Swapping it out for the one in the release 0.74 solved the crashing.

[quote]I fully support his DOSBox build, especially for use of the most recent patches. I removed the above test builds as the patch has been evaluated by others.[/quote]

I actually had the best results with your two test builds-- I was unable to get the 20130725 (the latest I could find) build to work at all with voodoo support. The dos window just goes blank. Redirecting output to a file, it ends with: Query hardware failed. So the software (whip3dfx) was unable to detect the voodoo hardware. I tried everything I could think of to configure that build to possibly allow detection to no avail. I ended up using a much older build where detection worked, but for which the emulation clearly had bugs. In addition, the 20130725 package crashed on the athlon-xp. It's not clear if it was the executable or one of the dlls. But in that package there is no sdl.dll dependency, so swapping it out was not possible.

[quote]Unfortunately, I would be unable to determine the cause of the compiling problem as this part of the forum is for developing and testing patches.[/quote]

Yeah, sorry to try to get other support here-- I understand the desire to keep the forums easy to search.

Attached is a compilation of SDL.dll files, compiled by different compilers (mingw vs VS) and by different methods. They include SSE2 and non-SSE versions, and SDL 1.2.15 versus 1.2hg versions. The 1.2hg versions are developmental and the code includes updates as recent as a few days ago. They all should include the OpenGL-HQ patch.

Ideally, we can document the issue with the Daum build so Ykhwong can examine it. One possible solution is to compile an alternate win32 Daum build with SDL as a dynamically linked library. I believe you now have working binaries for all your systems. If you have further issues, please post abundant details and tests so it can be easily resolved.