| ▲ | OsrsNeedsf2P 7 hours ago | ||||||||||||||||
I'm currently in the middle of porting a game from 2004 to run on MacOS via wine. On a 5000$ Macbook Pro, I'm getting about 4 FPS. This has multiple causes, including the game being single threaded and running through Rosetta, but damn is it hard to get good single core performance out of Macbooks. Out of curiosity, I also ported the game to arm Linux with fex + upstreamed the wine patches in about a third the time and there's no FPS issues | |||||||||||||||||
| ▲ | aenis 5 hours ago | parent | next [-] | ||||||||||||||||
Did you forget to tell Claude to make it run fast? (I am not joking. I did a port of an old utility, Dos Navigator, and I gave Claude+Codex a set of KPIs: cold start under 100ms, 30MB RAW image preview under 50ms, and a few others. I went to bed, and I woke up to a file manager written in Swift that is a joy to use, its so fast, esp. when previewing images. If I haven't requested it, it would likely be way slower). | |||||||||||||||||
| |||||||||||||||||
| ▲ | mirsadm 7 hours ago | parent | prev | next [-] | ||||||||||||||||
If anything it's the exact opposite. They're ridiculously powerful with more memory bandwidth than pretty much any equivalent PC. It is easy to make sloppy software because you can get away with so much. | |||||||||||||||||
| ▲ | galad87 6 hours ago | parent | prev | next [-] | ||||||||||||||||
Running something with "Wine" doesn't usually mean "porting", "porting" means making a native binary that doesn't run through an emulation layer. Anyway, probably you are trying to run a 32-bit executable with Rosetta, that won't be fast, because Rosetta was never meant to run 32-bit things and has got a lot of pitfalls. | |||||||||||||||||
| ▲ | SXX 7 hours ago | parent | prev | next [-] | ||||||||||||||||
What porting you talking about exactly? Packaging existing binaries? Compiling source code making it more compatible with Wine? In my experience as game developer and porting C++ code tells such difference usually mean there are something really wrong with syncronization primitives. So 99.99% of the time code does nothing just waiting for something to unlock. | |||||||||||||||||
| |||||||||||||||||
| ▲ | CJefferson 6 hours ago | parent | prev | next [-] | ||||||||||||||||
Something is going horribly wrong. I don't know what it is (without your code I don't know), have you profiled where it's going wrong? There's no way a game for 2004 would be that slow. If you want help, I've done some similar work, you could pop it up on a github repo or something. What is the game? | |||||||||||||||||
| ▲ | bel8 5 hours ago | parent | prev | next [-] | ||||||||||||||||
OS/Software is why I don't like macs. For me it's like they built a Ferrari with 4 thin bicycle tires. What a waste. | |||||||||||||||||
| ▲ | logicallee 6 hours ago | parent | prev [-] | ||||||||||||||||
Thanks for sharing your experience. I recommend you try giving your AI an open ended task like, "it's at 4 fps even though it's a 22 year old game and the raw hardware performance is many orders of magnitude higher. Maybe due to running under Wine and Rosetta. Please figure out the simplest way you can unlock usable performance (30-60 FPS) short of decompiling, reverse engineering, and reimplementing the full game yourself natively. Maybe there is something else you can figure out for the performance unlock. The hardware is definitely there, so there has to be a way. The game is running so make sure you don't break it. Keep the same game behavior." Regardless of which AI you're using, it will be able to figure something out in a few hours. 2004 pc's were 500-800 mhz, 128 MB RAM, and if they had a GPU at all it was 16-32 MB, 0.2-1 GLOP. Your AI should be able to figure out a way to get it running in realtime. | |||||||||||||||||