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
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.
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).
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.
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.
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?
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.
> I'm sure you mean well but as someone who has considered posting on who wants to be hired in the past.
Ever since I posted once 6+ months ago, I've been getting random emails from people who found my "posting" on a bunch of different listing websites. I feel bad for them, some of them are even tailoring the resume. The position is no longer available..
Hi, I'm the author - no it's not an analysis of the Lost City codebase (though I am a contributor to LC).
Most of the knowledge came from my refactor of the #317 RS2 client (https://github.com/Jameskmonger/317refactor) though I looked at some other decompiled versions while writing this blog post.
Apparently you only want wayland based DEs and considered the argument to be over for everyone.
How wrong were you. Lot's of people don't want to use wayland until it reaches a certain feature-complete maturity. I for instance have again put it off for another year and won't consider running a wayland only DE at all for the forseable future since it breaks too many things for no good reason and I need to be able to switch back to X11 if needed. I use my pc for for work, not just as a troubleshooting toy.
Taking the topic into account of people moving from old school Windows 7 to this Windows-like distro, these people will probably be more pleased by X11 (hassle free screen sharing, global shortcuts) vs the wayland "in theory it is great and modern but in practice there still are way too many incomplete and missing pieces" situation.
Wayland is stable. What it's not is stagnant, like X11, which lacks fractional/mixed-DPI scaling, per-window HDR/color management, explicit GPU synchronization, and a security model ready for the modern challenges of the mid 90s.
It's also technically cross-platform, as evidenced by FreeBSD's support for Wayland compositors. But it's not its goal either, the goal is an excellent Linux desktop, not something that serves the 17 people in the world that routinely run the same exact desktop config on Linux and non-Linux PCs.
X11 used to crash all the time, especially after an update, back when it was being vibrantly developed. It's been a lot more stable since it got abandoned. I've not had a crash in 13 years.
Matter of fact, the vast majority has moved on to Wayland years ago, both KDE and Gnome have reported their usage stats and neither sees a point in keeping X11 afloat. I too have been using Wayland (KDE) for years, it addressed some decades-long struggles around multi monitor and DPI layouts. I use input methods for CJK that work better and more consistently than before. As far as I'm concerned, this ship has sailed, for the better.
Wayland is annoying out of touch crap that works well enough for some people to think it's good. Enjoy your Wayland. Surely all the people who aren't you must just be stupid.
based on every country that didn't adopt capitalism until recently, absolutely not. there are very few non-capitalist countries as all of them either failed or changed their economies.
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
reply