Also for those interested:
P2 400mhz, 1GB SDRAM, 3dfx Voodoo 5 5500 AGP @ 1280x1024x75hz
demo1: 50.8fps
Also I just tested your x86 version and there was no change in framerates.
Also to compile the voodoo 3 build just use H4=1 when you run make. I found out though, you can use the voodoo 5 build and it works just the same.
Did you try to compile with USE_X86=1. When i try to, once it gets to the asm files the %include "file.inc" stuff always fails.
That's great! It would have been difficult to adapt the h3 code! That's a time savings on building binaries and less things to track, for sure.
Also, that's interesting the x86 has no significant difference. Just as well because the C path compiles so cleanly.
I noted your examination of the video modes and code in fxapi.c. I vaguely recall that the video modes had updates (from the changelog), but that is perfect if it plugs in easily to your resolution settings.
wrote:Did you try to compile with USE_X86=1. When i try to, once it gets to the asm files the %include "file.inc" stuff always fails.
I showed the exact same error and bypassed by copying the headers files from /src to /glide3x which is more topmost.
I found out to fix the include crud you have to change the path to h5\glide3\src\ for the include
i.e. %include "h5\glide3\src\fxgasm.h"
😀
Edit: I'll check back some time later, but this is all very promising.
I wonder if your USE_X86=1 compiled properly or if you sent me the wrong file because previously, when I compiled it normally withotu x86 I got the same filesizes you sent me. But with USE_X86=1 I got a slightly larger file size now. Will test as soon as its done compiling
Yeah, it's definitely different because now I get some link errors with q2dos about vprtisetup_call being definied multiple times in xdraw3_ref.o then again in gxdraw.o
It's possible -- I must have been testing and updated the directory with the non-x86 compile. Sorry about that. Perhaps it will make a difference after all (the x86 path)!
I tried to turn on the path but sometimes it didn't work correctly. I sent the mesa makefiles for that reason, because it was troublesome to set x86 properly. However, if there are build errors then it must be true that I was building non-x86 in spite of the makefile settings. I'm glad that you are able to make short order of these issues.
I should say that all my tests were on the sst1 branch.
Okay. I think I figured out a solution for that.
Wonderful! I'll be back some time later, just to recharge. But thank you for solving these issues. It would be nice to have optimal builds (I tried my best at the sst1).
I figured it out, there was a slight 2 fps difference in timedemo, but it had rendering errors. This was with USE_MMX=1
Okay USE_X86=1 has no rendering errors, but its only like 0.5 difference, hah. I'd probably rather just use the C code because I know it's less likely to have hidden issues.
I think the compiler settings were for Pentium, too. It also sounds like the C code is doing very well by itself, perhaps they needed Abrash otherwise. 😀
Honestly, it's about the same speed as in Windows. Though, I haven't benchmarked in Win98 yet.
I'm more interested in knowing that I can play it on a p1 200mmx with a voodoo 2 at about 30-40 frames at 640x480 which is very nice.
(yeah right now, I got 3 computers going on hitting a KVM switchbox to see it all, hah)
Well, at least it's meeting those expected frame rates. There is some code that is in the (later?) mesa versions, perhaps by "Amigamerlin". He claimed some speedup in the drivers, but that may be too adventuresome to port back, and I would think the advantage is small in most cases.
The P1/V2 benchmark is very interesting. That sounds like a fairly common setup for that era. But the KVM setup grants you alot of power to test across the other eras easily!
