lands of lore 2 is a 3dfx dos game if you want test.

nglide and dgvoodoo 2 have some problems with this game and glide emulation.

Is it possible to use it with dosbox staging or dosbox-x ?

If you can add high resolution rendering support like dgvoodoo 2 and nglide, it would be amazing. i don't know if it is possible.

willow wrote on 2026-10-11, 21:03:

Is it possible to use it with dosbox staging or dosbox-x ?

If you can add high resolution rendering support like dgvoodoo 2 and nglide, it would be amazing. i don't know if it is possible.

Yep, it runs in DOSBox, but you can’t use the multicore feature there. I haven’t tried running it as a wrapper around DOSBox yet, but I can’t think of a reason it wouldn’t work. Maybe I should add a multithreaded version for NT based systems. But then you might want to use a Glide Wrapper anyway.

more discrediting sarah's emulation code from PCem via slop

i'm tired boss

leileilol wrote on Yesterday, 01:50:

more discrediting sarah's emulation code from PCem via slop

i'm tired boss

Thanks for pointing that out.

That has nothing to do with AI slop. In forked projects, it's often hard to tell where a contribution actually comes from. I've fixed it in the post and will fix it in the source as well. I don't mind if this software ends up in three different forks whose maintainers don't even know me. But this project is very important to me. I've dreamed of it since 2009, and without the help of these tools, it wouldn't exist.

At the same time, it didn't build itself. Over the past few weeks, I've spent many hours on it alongside everything else in my life, and the AI tools alone wouldn't have known what the solution should look like. That's also why I understand how important proper credit is: every day, thousands of developers contribute to open source without their names ever being noticed.

In fact, that's exactly why I referenced existing projects: I didn't want the work of their developers to disappear behind generic AI-generated code. This work deserves to be visible, and I'll make sure it is.

ElTentakel wrote on Yesterday, 04:31:

In fact, that's exactly why I referenced existing projects: I didn't want the work of their developers to disappear behind generic AI-generated code. This work deserves to be visible, and I'll make sure it is.

AI is the future, even if you agree or disagree with how it works or who owns it etc. It is going to open up so many cool tools (like yours) for the retro community. So I say great work!

It's really funny, I've been working on some glide stuff as well, but for running on real hardware (works well).

Anyway nice project, I will check it out!

This is mine: https://github.com/michaeldale/velocity9x

Fun fact: your project, together with other contributions to DOS drivers, was what finally got me to start the whole thing. AI now finally has the knowledge to help adapt Linux driver work to DOS, which opens up a huge field of opportunities.

The hard part will be making the projects compatible with each other, especially when multiple cores are involved. For example, I detect CSMWrap, since it occupies a core of its own. However, that detection doesn't work very well yet.

This is one very, very good use of AI coding. To help the retro community help with hitherto impossible or very difficult projects. In general, I don't support AI slop either, but in specific instances it can help and fills a need admirably. 99% of what AI and LLMs are being used for now is totally a "first world" and "pure capitalism" problem (eg, a "created" way to launder money and wean the public on stuff they don't need).

Thanks for releasing this project. I look forward to following its progression and trying it out.

What I understand is that your project will run the DOS 3dfx version of, for example, Tomb Raider, on a "modern" system without a 3dfx card. Other DOS games like Screamer 2 and Carmageddon may run their 3dfx DOS versions on bare metal (no DOSBOX, nothing loaded except bare DOS and the game's 3dfx .exe)?

I didn't RTFM and now know why both Tomb Raider and Carmageddon won't work.

However, I did get Screamer 2 and Screamer Rally 3dfx versions working in bare metal DOS. This on a laptop with no 3dfx card present of course. The system was an i5-3427 running at 2.9 mhz in DOS, with MTRRLFBE enabled and LFB writecombining working.

The .cfg has robust options, including the ability to use my laptop's native 1366x768 resolution, and therefore display the rendered 640x480 frames in the proper aspect ratio. (not stretched to 16:9). However Falcosoft's utility does this natively now for all 4:3 dos content. But this .cfg option will work on intel core systems where Falcosoft's utility will not (Skylake and above).

The framerate is between 10 and 15 fps in pure DOS. There are only 2 cores on this system. I'll try another laptop (i5-8250) soon, which has 4 cores and will hopefully run @ approx. 30 fps.

Great work!

It looks amazing! Thank you. I checked in a hurry (So far only on Windows 98) and it really works there.

Can you add redirection to OpenGL \ DirectX 7-9c as an additional option, so that you can use real hardware and enable AA\AF x16?

EDIT: I deleted the previously added screenshots because, due to “nolfb.com” in the game’s BAT file — which I forgot to remove — the quality of those images didn’t match reality. I haven’t found a way to take new screenshots yet (for some reason, PrintScreen doesn’t work with the shell without “nolfb.com”).

zyzzle wrote on Yesterday, 10:48:

I didn't RTFM and now know why both Tomb Raider and Carmageddon won't work. […]
Show full quote

I didn't RTFM and now know why both Tomb Raider and Carmageddon won't work.

However, I did get Screamer 2 and Screamer Rally 3dfx versions working in bare metal DOS. This on a laptop with no 3dfx card present of course. The system was an i5-3427 running at 2.9 mhz in DOS, with MTRRLFBE enabled and LFB writecombining working.

The .cfg has robust options, including the ability to use my laptop's native 1366x768 resolution, and therefore display the rendered 640x480 frames in the proper aspect ratio. (not stretched to 16:9). However Falcosoft's utility does this natively now for all 4:3 dos content. But this .cfg option will work on intel core systems where Falcosoft's utility will not (Skylake and above).

The framerate is between 10 and 15 fps in pure DOS. There are only 2 cores on this system. I'll try another laptop (i5-8250) soon, which has 4 cores and will hopefully run @ approx. 30 fps.

Great work!

Thank you very much for the kind words! Yes, there are ways to get games working where the Glide library is statically linked. But my first goal is to get Glide2 running well and fast under DOS. I also have some other features in mind, like accelerated output under Windows 98 SE, SMP (which might not even be possible on 9x), Glide3x support, and maybe even support for early DirectX games. So please be patient, or contribute if you can’t wait 😁. The idea isn’t to build something that just somehow works, it should be genuinely useful for the people who use it.

Just a side note: in theory, this should also work on NT-based operating systems as a host-side Glide wrapper for a 32-bit DOSBox-X. Back in the day, I used the same approach to hook up my Voodoo2 as a renderer for DOSBox. But I haven’t actually tested this yet and it’s not the goal of this project either 😁

/edit: I think I misunderstood willow. I’ve also added a 64-bit build version to the to-do list, in case that’s useful.

DoZator wrote on Yesterday, 13:31:

It looks amazing! Thank you. I checked in a hurry (So far only on Windows 98) and it really works there:

...

Can you add redirection to OpenGL \ DirectX 7-9c as an additional option, so that you can use real hardware and enable AA\AF x16?

Thank you very much for testing! I tried to keep the render paths modular, so it might be possible. The main limitations are time and tokens. But to be honest, it’s not my top priority right now.

ElTentakel wrote on Yesterday, 14:43:

/edit: I think I misunderstood willow. I’ve also added a 64-bit build version to the to-do list, in case that’s useful.

I suspect SSE/AVX would add a lot of performance. Is that what you mean?
Since the "workers" are running basically as a microcontroller, you should be pretty free as far as that side of the architecture goes.

You're right, the extra CPU cores are basically like dumb microcontrollers. But not all features are easily accessible under DOS, since some hardware and firmware protection mechanisms get in the way.

I meant that with 64-build a bit differently. In theory, there are two ways to use this library: inside DOSBox and outside of it. Inside DOSBox, performance is very poor, because you lose all the advantages: no SMP, slow CPU emulation, and at best MMX.

Outside, DOSBox-X simply passes the Glide API calls through to an external Glide DLL on the host. That's where you can either use an original 3dfx Glide DLL to render on a real Voodoo (32-bit OS only, depends on the driver), or use a library as a host-side wrapper with multithreading and modern CPU features.

A 64-bit build of DOSBox-X would need a 64-bit build of the library, since a 64-bit process can't load 32-bit DLLs. It's on my to-do list, but only as a low priority. The main goal of this project isn't DOSBox, but supporting the native platforms

So sse/avx requires more access?
You can't just drop in the assembly instructions to chomp on the data in memory?

(I'm talking bare metal or at least a proper hypervisor with more cores assigned)

myne wrote on Today, 05:45:

So sse/avx requires more access?
You can't just drop in the assembly instructions to chomp on the data in memory?

(I'm talking bare metal or at least a proper hypervisor with more cores assigned)

Maybe "access" is the wrong term. The following is about DOS only, Win9x is a much more difficult beast. There are two things to consider: the main core (the one DOS and the game run on) and the worker cores.

The main core has to live with whatever environment the system gives it. Boot plain DOS without a memory manager and you are in ring 0. Want SBEMU? Then you need HDPMI32i or VDPMI, and the game runs in ring 3, because SBEMU traps the Sound Blaster ports through the I/O permission bitmap, which only works above IOPL. The DOS box of Windows is ring 3 as well. The workers are a different story. DOS has no scheduler, so the OVL starts the other cores itself (INIT/SIPI to a small trampoline). They don't belong to the DPMI host, so they can run in ring 0 even when the game is in ring 3. The big challenge was to give them the same address space as the game: under HDPMI32i they load the host's page tables, under VDPMI memory is mapped 1:1 and they run without paging.

Because the workers bypass the host's protection, they follow very tight rules: no port I/O, no MSR writes, no BIOS or DPMI calls, interrupts off. Before a worker touches any memory outside its trampoline, it checks a few bytes of heap and code against the main core's view and halts on a mismatch, so a wrong address space means "single core", never stray writes. If a worker crashes or hangs for 2 s, the main core redraws its lines and carries on alone.

SSE (the JIT renderer) needs CR4.OSFXSR, otherwise the first SSE instruction raises #UD. In ring 0 the OVL sets the bit itself. In ring 3 it depends on the host: HDPMI32i sets it, VDPMI does not (C renderer there, same picture). AVX would need CR4.OSXSAVE and XSETBV, but neither DOS nor Win9x saves the upper YMM halves, so it is never used. Getting this right took a lot of crash screens. That's what the debug build is for: its own exception handler in ring 0 that tells you which exception hit where.

The nice part: the main core can run in ring 0 or ring 3 without you noticing. The OVL detects the environment and picks the matching path (GLIDULATOR_SMP=auto, or force ring0/paging/flat/off). The one thing that gives you a single core is a memory manager with paging but no DPMI host, e.g. plain EMM386.

1    Environment               Main core       Workers                   SSE/JIT
2    ------------------------  --------------  ------------------------  -------
3    Plain DOS / HIMEM only    ring 0          ring 0, no paging         yes
4    EMM386 (VCPI, no DPMI)    ring 0, paging  none (single core)        yes
5    HDPMI32i + SBEMU          ring 3          ring 0, host's page dir   yes
6    VDPMI + SBEMU             ring 3          ring 0, no paging (1:1)   no (C)
7    Windows DOS box           ring 3          none (Windows owns APIC)  98SE: yes

leileilol wrote on Yesterday, 01:50:

more discrediting sarah's emulation code from PCem via slop

i'm tired boss

It's one thing to stand on belief, another to be incorrigible. I am NO fan of AI, do not use it, and draw the line at the point it starts replacing people, but I am still open-minded at how it can save A LOT of effort while delivering faster results for everyman projects like this, book proofreading for budding authors, etc. As retrocomputing enthusiasts we of all people should be cognizant of the critical balance between keeping our essential humanity and the use of available tools to accomplish more.

A sweeping dismissal of AI like this might as well be a sweeping dismissal of modern technology altogether...and if that is the direction you want to go, the Amish are an example of how to make a good life out of it.

Could someone do a proof of concept YouTube video for this plz