I was able to convince the AI to use SMP alongside with Windows 9x by hammering my head hundreds of times against the security wall. But now it's done. We have up to 3 worker cores under Windows 98 SE, started by the GLSMP.VXD driver. The driver is loaded by the glide2x.dll, so there is no need to install anything (it just has to be next to the glide2x.dll). Be aware that the workers run in the game's own memory, so a pointer mess in the game could result in a crash of the game. Also write combing is working. I get 35 fps in the Half-Life mwd5 timedemo without any visual enhancements on my i7 4770T. Unfortunately it crashes from time to time, but I'm not sure yet what the reason is.

It seems to have a very difficult time on my AMD E1 based anacronistic laptop. Granted, that only has one other core, but it crashes quite hard.

It has successfully started twice for me, creates a bunch of .bin files in the game folder, then fails to proceed. (Trying to run Redguard 3dFX.)

It looks like redguard SHOULD be able to work with it, eventually though. (It DOES start the .OVL)

Wainting for the Rendition Verite version so we can play unaccelerated accelerated Quake in DOS. 😏

Hehe a bit more effort and it will turn Win9x to SMP OS like NT 😀
OK, I understand it's not so easy but the VXD for SMP could be made as some specific win9x extension that also other projects could use it and it could safely handle if there will run more apps requesting SMP to not crash..

wierd_w wrote on 2026-10-18, 20:03:

It seems to have a very difficult time on my AMD E1 based anacronistic laptop. Granted, that only has one other core, but it crashes quite hard.

It has successfully started twice for me, creates a bunch of .bin files in the game folder, then fails to proceed. (Trying to run Redguard 3dFX.)

It looks like redguard SHOULD be able to work with it, eventually though. (It DOES start the .OVL)

Unless I am mistaken, the AMD E1 APUs are not that much faster per core, in terms of IPC, from a Pentium 3. If you can it to run, I am really curious about the performance it will achieve.

ElTentakel wrote on 2026-10-18, 19:08:

I was able to convince the AI to use SMP alongside with Windows 9x by hammering my head hundreds of times against the security wall. But now it's done. We have up to 3 worker cores under Windows 98 SE, started by the GLSMP.VXD driver. The driver is loaded by the glide2x.dll, so there is no need to install anything (it just has to be next to the glide2x.dll). Be aware that the workers run in the game's own memory, so a pointer mess in the game could result in a crash of the game. Also write combing is working. I get 35 fps in the Half-Life mwd5 timedemo without any visual enhancements on my i7 4770T. Unfortunately it crashes from time to time, but I'm not sure yet what the reason is.

That is pretty impressive speed! I will have to try out myself.

ElTentakel wrote on 2026-10-18, 19:08:

I was able to convince the AI to use SMP alongside with Windows 9x by hammering my head hundreds of times against the security wall. But now it's done. We have up to 3 worker cores under Windows 98 SE, started by the GLSMP.VXD driver. The driver is loaded by the glide2x.dll, so there is no need to install anything (it just has to be next to the glide2x.dll). Be aware that the workers run in the game's own memory, so a pointer mess in the game could result in a crash of the game. Also write combing is working. I get 35 fps in the Half-Life mwd5 timedemo without any visual enhancements on my i7 4770T. Unfortunately it crashes from time to time, but I'm not sure yet what the reason is.

Couldn't you reserve some PCI memory with the bios/os?
Ie you pretend to be a plug-and-play device and ask to reserve what are we talking here... <32mb? in the PCI space ?
Actually... I may have another, simpler way.
Block the memory from 9x
Re: want to use pc-133 cas2 512mb sdram with bad memory addresses under win9x

RayeR wrote on 2026-10-18, 23:03:

Hehe a bit more effort and it will turn Win9x to SMP OS like NT 😀
OK, I understand it's not so easy but the VXD for SMP could be made as some specific win9x extension that also other projects could use it and it could safely handle if there will run more apps requesting SMP to not crash..

Yes, I think so. But only in very specific workloads, since the synchronisation is very expensive for now. But I can think of an HD HEVC/Blu-ray video player or other things that only need a synchronisation every 20–40 ms.

Maybe I should create a library first and test it extensively before continuing work on the compatibility of this project.

darry wrote on 2026-10-18, 23:06:

wierd_w wrote on 2026-10-18, 20:03:

It seems to have a very difficult time on my AMD E1 based anacronistic laptop. Granted, that only has one other core, but it crashes quite hard.

It has successfully started twice for me, creates a bunch of .bin files in the game folder, then fails to proceed. (Trying to run Redguard 3dFX.)

It looks like redguard SHOULD be able to work with it, eventually though. (It DOES start the .OVL)

Unless I am mistaken, the AMD E1 APUs are not that much faster per core, in terms of IPC, from a Pentium 3. If you can it to run, I am really curious about the performance it will achieve.

I have an AM1 board and a T56 board here. Maybe I can reproduce it. But these are not my target plattforms, since they are very limited regarding performance.

myne wrote on 2026-10-19, 00:42:

Couldn't you reserve some PCI memory with the bios/os? Ie you pretend to be a plug-and-play device and ask to reserve what are w […]
Show full quote

ElTentakel wrote on 2026-10-18, 19:08:

I was able to convince the AI to use SMP alongside with Windows 9x by hammering my head hundreds of times against the security wall. But now it's done. We have up to 3 worker cores under Windows 98 SE, started by the GLSMP.VXD driver. The driver is loaded by the glide2x.dll, so there is no need to install anything (it just has to be next to the glide2x.dll). Be aware that the workers run in the game's own memory, so a pointer mess in the game could result in a crash of the game. Also write combing is working. I get 35 fps in the Half-Life mwd5 timedemo without any visual enhancements on my i7 4770T. Unfortunately it crashes from time to time, but I'm not sure yet what the reason is.

Couldn't you reserve some PCI memory with the bios/os?
Ie you pretend to be a plug-and-play device and ask to reserve what are we talking here... <32mb? in the PCI space ?
Actually... I may have another, simpler way.
Block the memory from 9x
Re: want to use pc-133 cas2 512mb sdram with bad memory addresses under win9x

I think I tried that (if I understand your attempt correctly), but it failed on the worker side. I'll try to recover the log of the session.

The solution for now was to allocate memory in the game and lock the pages. That works very well, but it has some implications when the memory management of a game is bad, since every illegal memory access in the worker will crash the worker core.

How about the second option?
You tell 9x it's unusable via reg key?

myne wrote on 2026-10-19, 05:39:

How about the second option?
You tell 9x it's unusable via reg key?

No, my statement only refers to the PCI memory. I need to think about the other option first. As I mentioned, I have to recover the session of the AI agent to find out why it failed, but it turned out that the memory on the worker cores was not identical to that on the DOS/Windows core. But maybe it’s worthwhile to revisit it, since there were many cache and TLB issues that I had to fix for the ingame memory allocation method.

Yeah fair enough.

In a nutshell, ram can go bad. So I looked for a way to block bad ranges in 9x. Linux and Windows have mechanisms to block bad ranges. Memtest86 can spit out a badram list.

You could use this mechanism (reg key) to tell 9x that a 16-32mb chunk is "reserved"(bad) ,and then your workers can do what they want with it.

My assumption is that himem reads it from registry quite early in the boot process. That may or may not complicate things.

The disadvantage would be that it is not a plugin solution, which is my goal for Glidulator. But if it is more stable or useful for others, I could add it as an additional path later. I will put the test on my todo.

I tried the new version "0.9.2" on Windows 98, using "GLSMP.VxD" + "GLIDE2X.DLL" as an external library for DOSBOX-X, and it actually works in Multi Thread. Without any issues or glitches.

I also tested the same "PYL Demo" in the "BURNMEM + HIMEM + EMM386" configuration, together with HDPMI32I, since without it, GLIDULATOR still crashes in MS‑DOS mode when running this game, upon loading a save or the first level. The "CPUID Limit" is also enabled in the BIOS (disabled in parentheses). Results:

before launching Windows:

- 1 Core - HT = 1/1 Cores 14.7 FPS (1/1 14.7)
- 1 Core + HT = 1/2 Cores 14.7 FPS (1/1 14.7)
- 2 Core - HT = 1/2 Cores 14.7 FPS (1/2 15.1)
- 2 Core + HT = 4/4 Cores 29.6 FPS (1/2 14.7)
- 3 Core - HT = 3/3 Cores 29.5 FPS (3/3 30.3)
- 3 Core + HT = 5/6 Cores 30.3 FPS (3/3 29.5)
- 4 Core - HT = 4/4 Cores 45.3 FPS (4/4 45.2)
- 4 Core + HT = 5/8 Cores 29.9 FPS (4/4 45.3)

in Windows:

- only Single Thread (15.2 FPS);

after exiting Windows:

- without HDPMI32I and EMM386, Multi Thread works, but the game crashes when loading a level;
- works fine in both cases when combined with "HDPMI32I", but only in Single Thread mode (14.7 FPS).

Thank you for the screenshots and for adding a more visual indication of the flows. By the way, the statistics are not included in the screenshots, and it would be useful to have a switch "GLIDULATOR_SCREENSHOT=2" (Displaying statistics in screenshots). There is no explicit display of the current operating mode in a single letter - (R)ing0, (P)aging, (F)lat, (G)lsmp, or (O)ff.

It would also be good to add support for "GLSMP.VxD" at the same time in "GLIDE2X.OVL" for DOS games that work well on Windows. This feature would be very useful.

ElTentakel wrote on 2026-10-12, 04:31:

Thanks for pointing that out. […]
Show full quote

leileilol wrote on 2026-10-12, 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.

I see you did not credit the ones whose work this project is based on in the readme of the github release. I'm not strictly against using AI, but I think you should credit the people/projects in your release's readme as well, not just the first post of this thread. And the credits to those hardworking people should be at the top/forefront rather than as a footnote at the bottom.

I think it's basic courtesy (though I appreciate you at least credited them in this thread's first post).

And on a different note, great work on this project so far

I tried new version and i seems running on 4 cores of my Sandy under win98 just fine. Dos version runs too, as expected on 1 core...

I was randomly looking at the code, and with my limited understanding it looks like there's some optimisations to be found.

This, at face value looks like an important function probably called a lot.
If it's not a hot path used thousands of times a second, it doesn't matter.
If it IS, then it looks like it should be broken into different functions and the correct one selected during init.

As an example, imagine I ask you to cut 5000 pieces of wood and you're an idiot that can only follow a flow chart.
Every time you are given a piece of wood, your first question is
"what is this?"
"Should I use scissors, a saw or a knife?"
Only after a bunch of decisions for EACH piece, do you start cutting.

IF this is a hot path, that's wildly inefficient.
You make the decisions first. Set up a cutting saw function, and just dump wood into the "in box".

Again, I could be very wrong. This could be the "upfront" decision tree and the actual drawing function is elsewhere, but it DOES SAY "Apply fog" which is what makes me think it is the thing that adds fog.

If I were to optimise it, I'd split it into "apply_no_fog", "apply_fixed_fog", "Apply_multi_fog" or something like that and then just set the correct one as your current "cutting saw" station and blindly feed it data.

Reusing code is often very useful. But there's a time and a place to get fancy with one flexible multitool, and a time to build 10 custom single purpose factories.

https://github.com/ElTentakel/Glidulator/blob … voodoo_render.h

1#define APPLY_FOG(src_r, src_g, src_b, z, ia, w)  \
2    do {                           \
3        if (params->fogMode & FOG_CONSTANT) {     \
4            src_r += params->fogColor.r;          \
5            src_g += params->fogColor.g;          \
6            src_b += params->fogColor.b;          \
7        } else {                   \
8            int fog_r, fog_g, fog_b, fog_a = 0;   \
9            int fog_idx;           \
10                                   \
11            if (!(params->fogMode & FOG_ADD)) {   \
12                fog_r = params->fogColor.r;       \
13                fog_g = params->fogColor.g;       \
14                fog_b = params->fogColor.b;       \
15            } else                 \
16                fog_r = fog_g = fog_b = 0;        \
17                                   \
18            if (!(params->fogMode & FOG_MULT)) {  \
19                fog_r -= src_r;    \
20                fog_g -= src_g;    \
21                fog_b -= src_b;    \
22            }                      \
23                                   \
24            switch (params->fogMode & (FOG_Z | FOG_ALPHA)) {     \
25                case 0:            \
26                    fog_idx = (w_depth >> 10) & 0x3f;            \
27                                   \
28                    fog_a = params->fogTable[fog_idx].fog;       \
29                    fog_a += (params->fogTable[fog_idx].dfog * ((w_depth >> 2) & 0xff)) >> 10; \
30                    break;         \
31                case FOG_Z:        \
32                    fog_a = (z >> 20) & 0xff;     \
33                    break;         \
34                case FOG_ALPHA:    \
35                    fog_a = CLAMP(ia >> 12);      \
36                    break;         \
37                case FOG_W:        \
38                    fog_a = CLAMP((w >> 32) & 0xff);             \
39                    break;         \
40            }                      \
41            fog_a++;               \
42                                   \
43            fog_r = (fog_r * fog_a) >> 8;         \
44            fog_g = (fog_g * fog_a) >> 8;         \
45            fog_b = (fog_b * fog_a) >> 8;         \
46                                   \
47            if (params->fogMode & FOG_MULT) {     \
48                src_r = fog_r;     \
49                src_g = fog_g;     \
50                src_b = fog_b;     \
51            } else {               \
52                src_r += fog_r;    \
53                src_g += fog_g;    \
54                src_b += fog_b;    \
55            }                      \
56        }                          \
57                                   \
58        src_r = CLAMP(src_r);      \
59        src_g = CLAMP(src_g);      \
60        src_b = CLAMP(src_b);      \

61    } while (0)