ggorts_ wrote:

There was just one type of error among many lines in the glide3x source code. I tried to typecast the pointer as intended, but attached is a patch for verification.

That patch is wrong. The intention of the original code is to do pointer math as if the pointer is of the casted type. You want something like this:

1-        (float *)pointers += 3; 
2+        pointers = (float *)pointers + 3;

I think I require nasm.exe. No warnings about it, but I don't see it in my path.

Ok, I'll try your corrected version for the pointer math.

szo wrote:

That patch is wrong. The intention of the original code is to do pointer math as if the pointer is of the casted type. You want […]
Show full quote

ggorts_ wrote:

There was just one type of error among many lines in the glide3x source code. I tried to typecast the pointer as intended, but attached is a patch for verification.

That patch is wrong. The intention of the original code is to do pointer math as if the pointer is of the casted type. You want something like this:

Copy code to clipboard

1-        (float *)pointers += 3; 
2+        pointers = (float *)pointers + 3;

Your solution did not fix the problem. There is still the linker error. Thanks for trying to help.

ggorts_ wrote:

Here is a hint on the fenceVar once the warnings were enabled in gcc: […]
Show full quote

Here is a hint on the fenceVar once the warnings were enabled in gcc:

Copy code to clipboard

1h5/minihwc/minihwc.c:994:14: warning: 'fenceVar' defined but not used [-Wunused-variable]
2 static FxU32 fenceVar;

Edit: I'll try to define this outside the condition block (specific to djgpp):
#define P6FENCE __asm __volatile ("xchg %%eax, fenceVar":::"%eax")

For a project like this you should certainly be compiling with -Wall and capturing the output. It may produce a lot of a junk. Sometimes you get lucky and it's only like 10 or 20 small warnings, but one of those warnings could be quite serious.

Also if fenceVar is defined as static is it called in any other file? If it's static it's obviously only local to that specific file (or even function if it's inside one).

I should have built it with the recommended gcc/djgpp version, at least to verify a good build. But this is the only issue. It's only called in minihwc.c, at least I think so. It's referenced in the code block for P6FENCE(). My guess is that the code block isn't read by the compiler or something similar. That would cause the warning, too....

I don't have the proper build environment... yet. So I can't really comment on how the code works.

It probably just requires a single line change, but it may be related to the inline assembly format between the older and newer gcc.

Edit:
this is the line that's probably causing the issue in minihwc-
#define P6FENCE __asm__ __volatile__ ("xchg %%eax, fenceVar":::"%eax")

I've tried to rewrite the line like this:

1#define P6FENCE asm("xchg %%eax,%0"
2 		    : /* no outputs */
3 		    : "m" (fenceVar)
4 		    : "eax"
5 		    );

That worked!!

You produced a test app?

also i'm not sure if such a thing needs to be declared volatile still as it was previously. Or if just fenceVar should be static volatile? Szo would have a more definitive answer on that.

Yes, I'll attach the patch now and then a minute or two attach binaries for h5 (voodoo4/5?). This issue was the assembly inline which was likely older gcc. Please verify patch (includes szo pointer fixes).

I'll post glide3x and tests shortly....

I'll declare it volatile, you are right, I missed that....

These glide3x libraries should work (attached).

There are 49 tests to make, but please try test00 (also just attached).
It seems to work as it produces input and output about have no device.

Edit: attached are 49 of the 50 tests (sorting out an error in one of the test's source files).

It works, with it's classic ugly bilinear text filtering and all.

Has to be run in actual DOS. It hard crashed in Windows 98 as soon as it rendered the screen.

At least we have a result! 😀 It must have been the pmode dos session in 98?

SDK Test #26, attached patch to build Test26 along with a binary. It requires verification.

Well that or clashing with 3dfx drivers actually being loaded in win32 as well. I assumed such an exotic feature as this will be a true DOS only thing if it worked at all...

I'm actually in the middle of reading a book right now, but I intend to test all of this more thoroughly later on.

You should be able to run the tests yourself in pcem (or maybe even newer dosbox?). I don't know, but I assumed the glide3x.dxe is required in the same directory as that's where I put it just in case.

That's true. It may also be a gateway to compatibility with other cards.