Indeed. The name Voodoo is a trademark, as far as I can see, at least it has been. I guess our working title SDL_3dfx needs some adjustment as well. I don't know what laws apply to a company name that has ceased to exist/to be used 6 years ago.
Hi, I tried OpenGlide patches on Linux x86_64. Tomb Raider 1 running under DOSBox works very well. (Of cause with correct tomb.exe + glide2x.ovl + dosbox glide patch) Thanks, great work!
Anyway, I have few questions. I applied patches against latest OpenGlide CVS from sourceforge. It was not quite smooth. I had to apply some rejected changes by hand, but fortunately at the end everything works ok 😀. Is there any more appropriate version of OpenGlide that could be used as base for the patches?
I noticed at the beginning of this thread something about further development of OpenGlide, particularly gulikoza mentioned some personal CVS. Is there any possibility to access/try those sources?
Is there any possibility to play the game in scaled window? Well, I noticed somewhere negative answer, but things sometimes changes. I applied little hack to window creation/glViewport in my build to be able to play the game in 1280x960 window, but it could be good to know if (possibly new) API of OpenGlide have support for that.
I think the patches applied cleanly to cvs when I released them. Yes, that was some time ago, I didn't review them since. Moe has done a tremendous job merging OpenGlide and MACGlide (yes, including window scaling) and even improving it a bit further. I, on the other hand, haven't done much 😀. I promised to take a look at broken LFB support, but haven't got the time... 😢
Great to see the patches in cvs 😉
There's another issue remaining which I haven't mentioned: sdk2_3dfx.h.
The problem is, that the header defines Fx*32 as long. Long is 64-bit on x86_64 linux, so this breaks anything that expects Fx*32 to be 32-bit. At the moment, my configure patch will recreate this header in config.h with the detected sizes. This is fine for openglide, but unfortunately any applications that include openglide headers will not compile with the correct data types. I don't know what is the best way to solve this. Recreating the sdk2_3dfx.h at compile time means the headers will not be portable across machines. Or maybe stdint.h can be used, but I don't know if it's available on all platforms.
Assuming that long = 32 bits is (IMO) dangerous. If some C-type needs to map to some hardware registers, it should be made clear in the code, using some type-definition that says int32, uint32, reg32 or something.
Sometimes old code needs to break before it can be fixed...
Firstly, let me just say that this is fantastic work from everyone responsible! Tomb Raider 1 runs really well on my Linux system using Dosbox and these patches.
I'm having a problem compiling some of the inline assembly inside the Convert565to8888 function (Line 486 of openglide-mmx.diff). In particular, I'm running out of registers of class 'GENERAL_REGS' using gcc 4.2.3 compiling for 32bit architecture:
1can't find a register in class 'GENERAL_REGS' while reloading 'asm'
My assembly is really rusty, but are there enough registers available on 32bit CPUs to satisfy those constraints?:
Are there 8 general purpose registers and the mmx registers are considered an additional 8? How many are available when using -fomit-frame-pointer with gcc on 32bit CPUs? If I use 1 less register, then it compiles. Can someone more knowledgeable let me know if that makes sense?
This sounds familiar. I think I got the same error. But IIRC I've changed the Mask565* parameters to be memory operands ("m") not "r", so gcc shouldn't be loading them in registers. The rest is the same as unpatched code.
Well, actually those 3 should be in registers. My point was that this function uses 3 registers just like all the other Convert* functions so I don't know why gcc is failing to assemble it... 😀
However, that function isn't actually using 3 registers. It's using 7. Those masks (with the m class) still use a register each, because their address is placed into esi, ecx, edx and eax, and then they're referenced from these registers.
Because the ebp and edi registers are also being used for the Src and Dst arguments, that's a total of 6 registers. The original patch tries to put (FxU)NumberOfPixels) into a register as well, which is a total of 7.
Here is the assembly generated by gcc (from FormatConversion.s):
As you can see from the first 4 operations, the 4 masks are copied from the locations pointed to by esi, ecx, edx and eax into the mmx registers, so those 4 general purpose registers are still being tied up with these masks.
The strange thing is that my change (using the 'm' class for (FxU)NumberOfPixels) doesn't use a register, it just passes it on the stack (as you can see from the subl $4, 28(%esp); above). So, I guess that a variable already on the stack with a 'm' class constraint stays on the stack. The masks are on the heap, and they do tie up a register when using the 'm' class. Sure enough, if I copy the 4 mask definitions (Mask565A/R/G/B) to inside the Convert565to8888 function - just above the inline assembly- they use the stack instead:
Is this the best solution? Just declaring the masks on the stack before passing them into the inline assembly?
As a side note, I really need a 64bit box. I am getting a serious case of register envy here. All of you x86_64 users have so many registers, you don't know what to do with them. 😀
hmm...what happens if you add const to mask initializations? Masks are only used in each function only once, so I guess they could be defined inside the function anyway...