Jump to content
COMBATSIM Forum

3dfx EF2000 part deux


Recommended Posts

For reasons, I'm going to waste some time looking at 3dfx again to see if we can do anything at all for EF2000.


To start, we need to get the 3dfx SDK contemporary with that version EF2000, ie about 1997.

So, I'm using the second one down from here (CD-ROM : 3dfx Software Developer's Kit V1.0):
https://3dfxarchive.com/reference.htm

 

The intention is to use DOS as much as possible, but maybe ancient Windows may come in handy so I've extracted the SDK to 'drive_c' of the host PC's .wine folder as I'm using Linux (Fedora 32) for this.

The SDK comes with some test programs, but to get the DOS versions working we're going to need Dosbox.
Unfortunately, vanilla Dosbox 0.74-3 doesn't support PCI bus and Voodoo emulation, so the plan is to use the Linux version of the fork Dosbox-x from here:
https://dosbox-x.com/
Things are never smooth with Open Source though, so had to go back a few versions to 0.82.1 before I could get the Linux source to build.

 

Anyway working now, and we can run the first test program which just produces a blue screen.
I had to copy the DOS driver glide2x.ovl to the same folder as the exe.

sdk3dfx1.gif.0d419747a29746ff746c733ff39d5f21.gif

Oh, the memories. It just misses the click when going between the 2D and 3D cards.

 

The next task will be to try and build the examples from source...

Link to post
Share on other sites

After setting up the Watcom environment, we can try to build 'test00.c'.

Almost surprisingly, it compiles without any warnings, but there are linker errors aplenty.

 

So, reducing the program to one function call, the linker complains it can't find _grGlideInit.

Looking at the lib file in a hex editor, we see it labelled all in capital letters.

Selection_002.png.d3aa64cebe5193feebb94feafd7e66ed.png

If I manually edit it from GRGLIDEINIT to grGlideInit, I get a different linker  error. I thought DOS was fairly case insensitive but maybe the underlying Linux system is having an effect.

With this SDK, it doesn't look like we can build our own libs, so we may be in trouble.

 

In the installation doc, it says this:

"NOTE: Glide 2.1.1 (or lower) applications are statically linked with Glide and do not provide support for hardware other than Voodoo Graphics."

 

This SDK is for version 2.3 but EF2000 uses version 2.1. I've always wondered why EF2000 used static linking for 3dfx. Now I know. :)

 

Next step will be to try the earlier 2.1.1 SDK which is the first download in the first link of this thread.

 

 

Link to post
Share on other sites

Works perfectly with the 2.1.1 SDK. All the examples I've tried build without the slightest complaint from the Compiler or Linker.

Don't think I've ever experienced that before. :)

 

Running the exe's results in more sluggish performance though compared to the dynamically linked ones from the v2.3 SDK.

This was the case for the pre-built binaries as well.

 

I thought it was maybe something to do with Dosbox-X, but I installed the EF2000 Reloaded version of Dosbox with Wine and see the same thing.

 

Anyway, we'll worry about that later.

 

Link to post
Share on other sites
5 hours ago, mikew said:

After setting up the Watcom environment, we can try to build 'test00.c'.

Almost surprisingly, it compiles without any warnings, but there are linker errors aplenty.

 

 

 

You certainly are in an enterprising mood  and being met with some success.  Noname1668.txt had me wondering how the Watcom environment would be set up.

 

 

CONFIG=WIN
TMP=C:\TEMP
TEMP=C:\TEMP
PROMPT=$p$g
winbootdir=C:\WINDOWS
COMSPEC=c:\4dos\4dos.com
CMDLINE=b GBVTYPES.TXT
BPATH=c:\apps\brief\macros
BHELP=c:\apps\brief\help
BFILE=c:\apps\brief\state.rst
BFLAGS=-i120kll250M70z -mSJP -mrestore -Dega
TMPDIR=C:\TEMP
INCLUDE=C:\WATCOM\H;C:\WATCOM\H\NT
WATCOM=C:\WATCOM
QUICK_FLAG=1
CVSROOT=n:/projects.rep
LOGNAME=Stephen
CFLAGS=/d2 /fhq
LFLAGS=debug all
LONGNAMES=n
LFN=n
EDITOR=c:\apps\brief\b.exe
EDPATH=C:\WATCOM\EDDAT
windir=C:\WINDOWS
BLASTER=A220 I5 D0 H5 P300 T6 E620
TZ=GMT0
USER=STEPHEN
PMR=\\SERVER\SYS\PEGASUS
PML=\\SERVER\SYS\PEGASUS
NB=\\SERVER\SYS\PUBLIC\NB
WINPMAIL=1
MV=SERVER/SYS:
PATH=c:\watcom\binw;C:\FIREFOX\WINWS\FFMAIL;C:\BC5\BIN;C:\NEWTOOLS;C:\WINDOWS;C:\WINDOWS\COMMAND;C:\DOS;C:\APPS\BRIEF;C:\BATCH;C:\UTILS\MASM;C:\WATCOM\BINNT;C:\WATCOM;Z:.;Y:.;X:\PUBLIC;V:\RCS5;W:\TOOLS

 

Link to post
Share on other sites

I was wondering if anyone dared comment on my deranged 3dfx blog. 'Enterprising' isn't really how I'd describe it. :D

 

That's a nice list of Stephen's environment variables.

His Watcom 'includes' don't seem to contain any third party stuff though.

 

I never knew there was an editor called 'Brief' but it's still available.

http://www.briefeditor.com/index.htm

While I should use something like that for the retro vibe, I think I'll stick to VS Code for the modern 'niceness'.

 

Most of the Watcom stuff is similar to mine though. Here's the batch file I run when Dosbox starts up:

@echo off
echo Open Watcom Build Environment
SET PATH=C:\WATCOM\BINW;%PATH%
SET LIB=C:\3dfxv211\dos\lib\watreg;c:\WATCOM\lib386\dos;%LIB%
SET INCLUDE=C:\3dfxv211\dos\include;C:\DXSDK\INCLUDE;C:\WATCOM\H;C:\WATCOM\H\NT;%INCLUDE%
SET WATCOM=C:\WATCOM
SET EDPATH=C:\WATCOM\EDDAT
SET WIPFC=C:\WATCOM\WIPFC

Not yet sure what those last two lines are for. :)

Link to post
Share on other sites
On 9/19/2020 at 10:26 PM, Krycztij said:

Amazing 👍

Hardly, but it's great to experience medieval times where the world ended at 640kB. :)

 

I've managed to build the debug version of the latest Dosbox-X (0.83.5) now. It's really easy if you read the instructions.

 

I then repeated the process on Win10. The only problem is that the 3dfx and Watcom self extractors are 16bit, so needed to be extracted elsewhere and copied across.

Here, building Dosbox-X is just a case of pressing 'Build' in VS2019. The resulting exe is a bit temperamental though.

 

The reason I'm using Dosbox-X instead of Vanilla Dosbox is that it already has the 3dfx Voodoo patch included and also can be built using SDL2.

Unfortunately, Voodoo and SDL2 can't work together which is incredibly disappointing :(  and probably the first thing to tackle.

Luckily, I just need to follow the instructions here: https://wiki.libsdl.org/MigrationGuide

...and all will be well.

 

 

Link to post
Share on other sites

No, the Voodoo handling parts are written around SDL1 where setting up the OpenGL 'display surface' is a completely different procedure to SDL2.

It doesn't seem that anybody has deemed it important enough to implement the necessary changes.

 

There is no real need either, as SDL1 is perfectly good enough to reproduce a DOS game, but I'd like the flexibility to set up a second window for debugging etc.

Link to post
Share on other sites

I think M1TP2 is a Win95 game that uses Direct3D or Glide. In that case, the DXWND and nGlide wrappers are useful.

The 3dfx version of EF2000 has Glide statically linked (or built-in) to the game exe, so you have to intercept the raw Voodoo API calls at the hardware level.

We already have this working with 'EF2000 Reloaded', but I'd like to see if improvements can be made.

 

It's not that easy though. I'm having trouble just working out which files I need to hack. :)

Link to post
Share on other sites

Frustration...

Since SDL2 can handle multiple windows across multiple monitors, I thought it would be good to try a standalone SDL2 tutorial to get up to speed.

The one I chose used Cmake, but as it was a couple of years old, it didn't work straight away and couldn't find SDL.h.

This is a standard Linux setup, so it's going to be in 'usr/include' or 'usr/local/include' but it won't look there unless I add another component to Cmake.

 

Got it working in the end, and at least it adds the right switches for the complier and linker. Something I'd probably never get right unless I spent a lot of time I don't have learning it. Why is nothing easy with building C++ projects? :(

 

The actual C++ code is quite easy and I managed to get the 3dfx emulation working with SDL2 by changing:

#if defined(C_SDL2)
    E_Exit("SDL2 3Dfx OpenGL emulation not implemented yet");

to

#if defined(C_SDL2)
//    E_Exit("SDL2 3Dfx OpenGL emulation not implemented yet");

 

Now it nearly works, and here's 'test25', the most complicated example...but the triangle should have red, green and blue vertices rather than just red.

Hopefully, that will be trivial...

db_gif.thumb.gif.954f9df90e17671342312e105e7e7416.gif

 

Link to post
Share on other sites
59 minutes ago, mikew said:

Why is nothing easy with building C++ projects? :(

It is clear that Visual C++ project files are a dead end for inter-platform development, so I had a look at alternatives.

 

Make is out because it doesn’t reliably support spaces in filenames. (There are workarounds, but these are incompatible e.g. for GNU make vs. nmake.)

 

Ninja looked promising, but it doesn’t support Unicode on Windows. There is a ticket on that where the maintainers show very questionable attitude towards the topic; so much it just makes me cringe.

 

Cmake would be one of the next options, but I hate its complexity. (I hate this with make as well, but at least make is pre-installed everywhere, while Cmake needs to be configured.) Plus … your latest experience.

 

2020 and no platform-independent way to compile C++ files with spaces or non-ASCII characters in their names. I can’t believe it.

 

(I gave up on the topic and wrote a 20-line batch script for compiling my stuff with Clang. Yay.)

Link to post
Share on other sites

Thanks! Maybe I'll give PCem a go next time I try to get Mig Alley working. I had a quick look at their source and they've implemented the 3dfx part in Assembler. That's pretty hardcore. :)

 

Luckily, I've grown up never putting spaces in my file names and 7-bit ASCII,  that doesn't bother me but since I'm usually dealing with other people's projects, I guess I just have to put up with the build system they've used.

I should invest some time in learning to do it properly, but it'll never happen...

 

I really need to sort that triangle out in that last picture because I'm having coloured polygon problems with EF2000 as well.

Strange, as the only difference between SDL2 and SDL1 is the surface that OpenGL writes to. The OpenGL stuff shouldn't change...but it seems it does.

The textures look OK at least.

ef2a.gif.c0832aaa7507d8b4193da5683f1efd8e.gif

 

 

Link to post
Share on other sites
  • 4 weeks later...

Very interesting work Mike. I think Dosbox-x's implementation of Glide is buggy and this is not the fault of EF2K, right?

 

How were you able to get it working so well for Reloaded?

 

Also, I wonder if it would ever be possible to modify the model size for some sort of "smart scaling" like the Dos version does. The models for ground units are impossible to see, and I'm assuming it cannot be changed without changing the source code :(

Link to post
Share on other sites

I haven't had time to look into it yet, but the problem is somewhere in the Dosbox-X code for SDL2.

Reloaded uses the original Dosbox SDL1 code with the 3dfx patch, and I didn't do so much except add some vertex scaling.

 

It's maybe not impossible to add 'smart scaling'. I 'just' need to identify the polygons associated with a ground vehicle as they come down the 3dfx pipeline, and modify them. Probably won't be my first priority, but this is the sort of thing that SDL2 would be useful for, as multiple windows can be used.

 

Link to post
Share on other sites
6 hours ago, mikew said:

I haven't had time to look into it yet, but the problem is somewhere in the Dosbox-X code for SDL2.

Reloaded uses the original Dosbox SDL1 code with the 3dfx patch, and I didn't do so much except add some vertex scaling.

 

It's maybe not impossible to add 'smart scaling'. I 'just' need to identify the polygons associated with a ground vehicle as they come down the 3dfx pipeline, and modify them. Probably won't be my first priority, but this is the sort of thing that SDL2 would be useful for, as multiple windows can be used.

 

Wow, that would be quite the undertaking. I know that TAW suffers from the same issue with ground vehicles but has some sort of smart scaling for air at least (to me it feels that way). I wanna also see if it is possible to make EF2K compatible with VR using direct3d or something, but not sure if the 3dfx supports depth. I mean it once was compatible with the VR headset of the 90s...

Link to post
Share on other sites

Both ground and air mobile units can probably be identified by the palette colours used, so it's theoretically possible they could handled separately. There is another problem though in that distant objects jump around on screen probably due to rounding errors when converting the object's position in 3D space to screen coordinates. This is OK on a native 640x400 monitor of the day, but not so good when the vertex positions are scaled up to modern resolutions and screen sizes.

 

VR is something else I'd like to do. While EF2000 did support the VFX1 headset and we use the tracking part to use TrackIR in EF2000 Reloaded. The game didn't use stereoscopic vision though, so it would have been like have a flat monitor on your head.

Now, there is depth information with 3dfx and it should be theoretically possible to do something similar to what Nvidia did with 3DVision and somehow feed that to the VR goggles.

 

It's much easier to think about this than actually do it. :)

Link to post
Share on other sites
  • 2 weeks later...

A bit of a gap due to work, but with Dosbox-X rev 0.83.6 the coloured polygon problem mentioned above is now fixed...even without me asking them. :woohoo:

So might try to look at non-stereoscopic VR first. I have the OpenVR demo working so just need to write the SDL output buffer to a texture and feed it to OpenVR in some way.

How hard can that that be? :)

Link to post
Share on other sites
On 11/5/2020 at 9:21 PM, mikew said:

How hard can that that be? :)

Probably too hard for me. :(

 

The only VR headset I have is the original Vive, and the only PC I have with a GPU capable of driving it runs Windows 10.

For Dosbox, we don't particularly want to be stuck with a particular headset or OS, so I've been looking at 'OpenHMD'.

It sort of works in that the gyro information from the headset seems to be read OK, but I've yet to be able to turn on the Vive's display.

 

This may have something to do with SteamVR that is already on the PC though. It's deeply embedded and difficult to circumvent.

So, I need another PC untainted by Steam...or a cheaper hobby. :)

 

Link to post
Share on other sites
  • 4 weeks later...

I hadn't realised how fragmented the VR scene is. With the Vive you're basically stuck with SteamVR on Windows unless 'extended mode' can be enabled so it's treated like another monitor. I don't think you can install SteamVR without Steam though.
On Linux, Monado can be used instead of SteamVR and that looks like it basically reverse engineers what SteamVR does in an incomplete way for the Vive. 3DOF headset tracking seems to work, so that's probably enough for EF2000. Also on Linux, an alternative could be to use 'Extended Mode' and OpenHMD for EF2000. This would be something similar to what Dosculus did with the Rift DK1.

So, with some effort, I might be able to get something working with VR in Dosbox on my PC, but even if I could get the basic mechanics to work, I doubt the refresh rate would be fast enough to be usable.

Link to post
Share on other sites
  • 4 weeks later...
On 12/1/2020 at 4:37 PM, mikew said:

I hadn't realised how fragmented the VR scene is. With the Vive you're basically stuck with SteamVR on Windows unless 'extended mode' can be enabled so it's treated like another monitor. I don't think you can install SteamVR without Steam though.
On Linux, Monado can be used instead of SteamVR and that looks like it basically reverse engineers what SteamVR does in an incomplete way for the Vive. 3DOF headset tracking seems to work, so that's probably enough for EF2000. Also on Linux, an alternative could be to use 'Extended Mode' and OpenHMD for EF2000. This would be something similar to what Dosculus did with the Rift DK1.

So, with some effort, I might be able to get something working with VR in Dosbox on my PC, but even if I could get the basic mechanics to work, I doubt the refresh rate would be fast enough to be usable.

Amazing thoughts MikeW! I think SteamVR / openVR will be the way to go here. All VR headsets support SteamVR now, and it has a lot of support in general. I would go with that.

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...