Almost got it, perhaps the sse will work instead.

Edit: that's convenient on the gamex86! There is a boxonplaneside or something issue (included in that diff file), but perhaps that issue was fixed.

Edit2: just saw your latest msg - cvg should be interesting!

Voodoo 2 works also

If you can compile the voodoo 3 /h3 path then they all should be OK.

Oh, great! That should cover a lot of potential users. (V2)

I think the C path is ok for V5, at least this older version, but the assembly paths are not yet compatible. Perhaps a different gcc version or it can be fiddled with. I also wondered if these glide versions are interchangeable by changing the string, like ppl have done with dos 3dfx games. But I would guess it wouldn't work.

Ok, trying h3 path....

It's a long ways away, but we know this stuff works so eventually a decent clean up can begin and maybe one day make some sort of detection routine to different paths, but the glide3 codebase is quite large it might be more trouble than it's worth for such things.

That's an interesting idea. I agree that there will be a lot of offshoots from the glide, including your quake1 port. 😀 The glimp_* is fairly similar the last time I looked.

It's quite incredible that the code even works at all, and works properly. This would have been amazing in 1999.

I know. It's amazing that it was neglected. Almost like just a couple of developers worked on it for everyone else. The work seems quite extensive and may be robust due to the win32/linux paths. The 502 seems best, also got a mesa6 to compile but the demos are kind of broken in the ver6 case. The work is out of sync between mesa versions and dos port, too.

I fixed the BOX_ON_PLANE_SIDE error. It's because you setup USE_ASM=1 but forgot the math files. The r_* and d_* are obviously not needed though.

Also afaik v5.02 as the last real maintained build that the djgpp guy was working on.

It may take some work for the h3 path. It may require a makefile, but I'll verify.

That's good to know that 502 is working well for a reason! So that saves time to search too much further in later versions.

Thanks for fixing the boxonplaneside issue. I used the C path originally, but the upload I tried to add some asm (which now I realize is mainly for software renderer), although I thought the audio asm code may help.

We can leave h3 for another time? I wouldn't want to put something together that is broken at best. I think it requires asm editing or testing with gcc versions (although a simple fix may still turn up).

Yeah, that's fine. I'm going to try and clean up the vid_dos.c back to the original and possibly just make a separate vid_3dfx_dos.c for opengl menus to make it easier to maintain.

I noticed you added _stklen in sys_dos.c what was the purpose of this?

Page faults due to lots of static array use, at least that's my assumption of cause. But it is required in my environment. It saves from using stubedit q2.exe minstack=1K. (I think 1K?)

By the way, thanks again for the recent, excellent work on the enhanced software renderer and all the interface work. It's a lot time and effort.

Edit: I'll check the thread again in a while.

If you get on IRC or somewhere we can talk more if you'd like.

Thanks on the software renderer. I really like being able to use r_coloredlights 2 to be able to use ASM at the expense of white lights cast on models instead of the coloured lights. I posted a message to the guys over at the NASM forums hoping they can help me tie up the loose ends in the enhanced software renderer.

Also vsync can be disabled with set FX_GLIDE_SWAPINTERVAL=0

That's all very good news. I also noted that you fixed the refresh rate already! I'll monitor the thread at least, and I'll try to help where I can. I hope the nasm forum is helpful, otherwise perhaps we could take a look.

I remember that there was some sort of override values but they werent working and i had to check out the fxapi.c code to see why and I didn't know there was two separate functions for setting up modes.

Hoping in a couple of days I can clean it up a bit more to have a list of video modes. setting gl_mode -1 and using r_customwidth and r_customheight work properly. And the best part is the Voodoo 5 is scaleable so I can get the same frame rate even in 1024x768!