This thread is about *development* aspects of kekko's nice work, not an attempt
to collect as many people as possible with "it's so slow" experience or compiling problems.

kekko wrote:

I never had any of the troubles described; anyway, here's the ovl I use, I hope it works for you too 😀

@kekko: Thanks for the ovl, kekko. Nice work. I will try to see if there is something that I can help for optimization.

For someone who is willing to try with the latest SVN, I posted a patch here. It is the almost the same as Kekko's one.

It would be really cool, I was thinking, if that when this Voodoo emulation is completed (or stable, at least) you incorporated it into your build with a selection between the software Glide wrapper passthrough to the host as we have now, or the full emulation. This way you could achieve the compatibility of both (the current one works great with most titles now, and is likely to always be faster than full emulation, but some titles may need full emulation) without having to have multiple copies of DOSBox installed.

@Yushatak: Providing both the full emulation and wrapper inside DOSBox? Disabling PCI and full emulation to turn off glide emulation might be possible to use glide wrapper. There should be an option to select one of the emulations as you said. I did not try it yet, so I am not sure if it would be really working. I prefer to only implement kekko's emulation if it becomes faster, because it does not require any external library and it is simple.

Well the thing about the wrappers is that you can support Voodoo 2 games, if I'm not mistaken, under 95. Granted at the moment this isn't an appealing prospect, but in another few years DOSBox might be more evolved and computers will be more powerful. Otherwise I'm all for replacing it entirely with the full emulation if it gets that fast as you said.

ykhwong wrote:

I did not try it yet, so I am not sure if it would be really working. I prefer to only implement kekko's emulation if it becomes faster, because it does not require any external library and it is simple.

It's not simple, it's complicated, and it's gonna become even more if opengl/threading/whatever is used to speed it up 😁. But it is simpler in the respect that at the moment it uses dosbox rendering so all the usual options + fullscreen switching work fine.
As of running both emulations at the same time - it shouldn't be a problem. It's just the matter of using the right ovl file. If you'd want a config setting, the ovl would probably need to get loaded on the Z: drive so that you don't have to switch it inside game directories... (except for the games that do not use ovl file in which case only the chip emulation can work)

From a user's point of view it would certainly be nice to have both features, and being able to choose which type of emulation to use. This could also be useful for debugging/identifying problematic games, as there'd be some "common ground" with which to test games with (like "game a works with the wrapper, but not with the full emulation" and such).

it's very simple... you have to download sdl sources, compile and install them (into msys environment), then you can compile dosbox (there is a file, something like SDL.h in the include directory of dosbox sources that you will have to remove, otherwise the make process will not end succesfully); to compile sdl:
./configure
make
make install
to compile dosbox:
./autogen.sh
./configure
make install
you will find the bin file of dosbox in /local/bin if I remeber 😀
the whole process into msys is not much different from the process into bash and gcc

gulikoza wrote:

As of running both emulations at the same time - it shouldn't be a problem. It's just the matter of using the right ovl file. If you'd want a config setting, the ovl would probably need to get loaded on the Z: drive so that you don't have to switch it inside game directories... (except for the games that do not use ovl file in which case only the chip emulation can work)

Yes, you're right. I've done some modifications to it, and it was successful to switch ovl files. Tested with GTA1. 😀

Hello I just compile dosbox with Microsoft Visual C 2010 Express through this tutorial Building DOSBox with Visual C 2008 Express, but after installing the 1st part of Windows 95 C OSR 2.5 on the drive C and restart to continue installation boot -l c did not start. How to install and run correctly with 3dfx Voodoo hardware, not software!
even after several minutes nothing happens!

this is not the thread to ask how to compile Dosbox nor how to install Windows 9x in Dosbox. Please keep the thread clean...

This new patch adds compile-time precomputed scanline renderer technique, as available on mame.
The new "voodoo_raster.h" file contains few precomputed rasterizers from some of the games I tested.
If you want some speed boost for your game, you have to manually add the missing rasterizer and rebuild sources; the rasterizer entries which dosbox does not find in the voodoo_raster list, are sent to console while the game is running.
It boosts speed in a range from nothing up to nicely fast, depending on game.
I had this code on my hdd from few weeks, I just decided to make a patch out of it and make it available.

EF2000 with 3dfx acceleration, running under dosbox.

sweet. 😁

Can these be computed on the fly as some sort of cache?

gulikoza wrote:

Can these be computed on the fly as some sort of cache?

that would require a sort of dynamic recompiler.
at this moment it just builds a group of functions where few parameters are compile-time constants instead of run-time variables, so the compiler optimizes out some of the IFs.
That's not much straightforward to move to run-time, not until you implement a dynamic recompliler that assembles (and caches) a scanline rasterizer on the fly.
That would in theory make it gain even more speed, but I'm not sure it worths the effort required.
Imho opengl seem the way to go, but I'm not much into it and have little time to spend with it. I would gladly accept help on this, especially how to properly and politely setup the opengl framework in dosbox. I may figure out how to render triangles by myself...maybe 😜

These lists, they aren't dependent for the key on a signature (for instance md5 or something) that changes if the exe is edited are they?

first experiments with opengl.
it just draws wireframes tris, and the scene is upside down, but it works.
here's the patch (to apply after main patch)
software rasterizer should still work byjust putting v->ogl to false.
awaiting comments and suggestions 😀

Might be enough to swap bottom and top in glOrtho.

3dfx chip can draw in either direction (grSstOrigin() call in glide). The origin needs to be checked and proper matrix set as wd suggests.

According to glide sources, origin is stored in the FBZMODE register. So this register should be checked for correct orientation and the matrix should also be changed when the register is changed 😀