Issues when compiling 3dfx wrappers via Apple Silicon

[wolfpax]

A user with Apple M1 here. I am willing to donate to this project because I see the potential of the project as “Software Preservation” (not only games) for Apple Silicon-based devices, especially if/when Intel is slowly becoming a thing of the past. 3D acceleration features can help those required to use legacy graphical-intensive projects (e.g. Mathematical/3D modelling, forecasting, C4D, etc.) without the need/hassle of legacy hardware. There are plenty of those, especially in academia.

However, there is no evidence that the above use case can currently be realized. Thus, I investigated the possibility of this use case myself. I have managed to compile Gendef (from this) and get other dependencies (make, mingw64, etc.) with their latest variants (at the time of posting) via Homebrew. However, I got these errors when compiling a 3dfx wrapper:

pciNoop.c:3:1: error: expected identifier or '(' before '-' token
    3 | -n void PT_CALL pciClose(
      | ^
pciNoop.c:6:1: error: expected identifier or '(' before '-' token
    6 | -n void PT_CALL pciDeviceExists(
      | ^
pciNoop.c:11:1: error: expected identifier or '(' before '-' token
   11 | -n void PT_CALL pciFindCard(
      | ^
…
pciNoop.c:76:1: error: expected identifier or '(' before '-' token
   76 | -n void PT_CALL pciUnmapPhysical(
      | ^

As it is related to “echo -n” (since the old/default bash version is used when executing “make” via macOS), I replaced them “printf” in “makefile.in” (line numbers 104 to 108), but different errors ensue:

pciNoop.c:4:69: error: redefinition of parameter 'arg0'
    4 | void PT_CALL pciDeviceExists(uint32_t arg0, uint32_t arg1, uint32_t arg0) { }
      |                                                            ~~~~~~~~~^~~~
pciNoop.c:4:39: note: previous definition of 'arg0' with type 'uint32_t' {aka 'unsigned int'}
    4 | void PT_CALL pciDeviceExists(uint32_t arg0, uint32_t arg1, uint32_t arg0) { }
      |                              ~~~~~~~~~^~~~
pciNoop.c:7:69: error: redefinition of parameter 'arg0'
    7 | void PT_CALL pciFindFreeMTRR(uint32_t arg0, uint32_t arg1, uint32_t arg0) { }
      |                                                            ~~~~~~~~~^~~~
pciNoop.c:7:39: note: previous definition of 'arg0' with type 'uint32_t' {aka 'unsigned int'}
    7 | void PT_CALL pciFindFreeMTRR(uint32_t arg0, uint32_t arg1, uint32_t arg0) { }
      |                              ~~~~~~~~~^~~~
gmake: *** [Makefile:100: pciNoop.o] Error 1
...

Another issue with a shell command? Any explanation for this? Am I chasing up the wrong tree here? Any pointer would be highly appreciated.

To the project’s author: I am fully aware the above use case (and me, to the extent) is not your target audience. Hence, no evidence/YouTube video for the above use case, and no “Software Election”, only games. What you have been through in that website and its moderators (I refuse to mention/give them a credit here) is simply unjust. Regardless of the response, you have my support. Keep up the good work. May us be in a more constructive/better/friendlier community than what you unfortunately experienced.

[kjliew]

I have fixed the shell scripts issues for Apple macOS.

You're right about the scope of this project. It's all about the Games!

I see the potential of the project as “Software Preservation” (not only games) for Apple Silicon-based devices, especially if/when Intel is slowly becoming a thing of the past. 3D acceleration features can help those required to use legacy graphical-intensive projects (e.g. Mathematical/3D modelling, forecasting, C4D, etc.) without the need/hassle of legacy hardware. There are plenty of those, especially in academia.

For macOS Intel x64 productivity software, Apple already offered the solutions through Rosetta 2. It is a stellar achievement by Apple Software engineering. You really don't need anything else. And many of those software will eventually have native ports for Apple Silicon. There is literally no value in keeping the old versions for Intel compatibility.

Frankly, the 3D pass-through acceleration is missing support of windowed 3D rendering on purpose for the sakes of simplicity and the focus on Games. This isn't going to do well for many graphical productivity software that you mentioned. You should explore the professional solutions from VMware and Parallel Desktop.

[wolfpax]

Thank you for your prompt response and sincerity. I have managed to complie the said wrapper with the new commit.

The issue is now solved.

Perhaps I will see you again when I want to show my children off of my childhood video games with the likes of Premier Manager 96, Monster Truck Madness 2, etc.