LV
2
- Joined
- Mar 5, 2026
- Messages
- 35
- Reaction score
- 50
- Points
- 38
Source Tales of Pirate 2026 x64 DX9 by alexxst.st
- Thread starter alexxst
- Start date
LV
2
- Joined
- Mar 5, 2026
- Messages
- 35
- Reaction score
- 50
- Points
- 38
Hahaha, "without years of previous knowledge" is a big statement for the history of agent development, which only started to do something worthwhile in 2025.
P.S. @Fade, you can try claude code (better than codex) for development. Some small features can be added on any source. Features that require global refactoring and architectural changes can be sent to me. I will definitely get to them.
Actually any type of auto patcher since there is no guide for that
Thank you for your attention
Alex I was taking to a friend they said this might be completely rewriteable in rust. Haven't actually given it any thought but wanted to see what you thought.
I'm going to investigate I'll post my findings.
edit:
Following up on my offer to dig into the Rust angle — I went deep on it (scoped the actual LOC across engine/client/server, the DX8/9 surface, the CaLua coupling, the IOCP/MSSQL server stack) and honestly, alexxst, you're right about the core problem. You can't translate this codebase as-is. The coupling is exactly what you said — global state, deep pointer graphs, the architectural layers all bleeding into each other — and that's the textbook worst case for Rust's ownership model. Anyone who thinks you autocxx your way through a mixed-up engine like this is going to have a bad time. So to be clear, I'm not proposing a line-by-line port of the current tree, and the work you're already doing — C++23, decoupling the layers, bgfx for rendering, RmUI for scripting — is exactly the refactoring that would make any future port tractable in the first place. The cleaner the boundaries get, the more a rewrite stops being insane.
Where I'd push back gently is on the framing of "translate." The interesting path isn't translation, it's rewrite-against-an-oracle — and that sidesteps the coupling entirely, because you're matching observable behavior, not porting internal structure. The old client and server still run, so you capture real traffic, replay it against both, and diff. Every discrepancy is observable and fixable, which means correctness becomes convergent rather than a gamble — you grind diffs to green instead of hoping you reproduced 20 years of edge cases. With that harness, server-first (Linux-native, no Windows/IOCP lock-in, memory-safe packet handling, kills the 32-bit dependency hell), I'd put a faithful result genuinely high. None of this is an argument to drop what you're doing — your modernization is the prerequisite. It's more "once the layers are actually separated, the Rust question stops being theoretical." Happy to share the full scoping numbers if anyone wants them.
I'm going to investigate I'll post my findings.
edit:
Following up on my offer to dig into the Rust angle — I went deep on it (scoped the actual LOC across engine/client/server, the DX8/9 surface, the CaLua coupling, the IOCP/MSSQL server stack) and honestly, alexxst, you're right about the core problem. You can't translate this codebase as-is. The coupling is exactly what you said — global state, deep pointer graphs, the architectural layers all bleeding into each other — and that's the textbook worst case for Rust's ownership model. Anyone who thinks you autocxx your way through a mixed-up engine like this is going to have a bad time. So to be clear, I'm not proposing a line-by-line port of the current tree, and the work you're already doing — C++23, decoupling the layers, bgfx for rendering, RmUI for scripting — is exactly the refactoring that would make any future port tractable in the first place. The cleaner the boundaries get, the more a rewrite stops being insane.
Where I'd push back gently is on the framing of "translate." The interesting path isn't translation, it's rewrite-against-an-oracle — and that sidesteps the coupling entirely, because you're matching observable behavior, not porting internal structure. The old client and server still run, so you capture real traffic, replay it against both, and diff. Every discrepancy is observable and fixable, which means correctness becomes convergent rather than a gamble — you grind diffs to green instead of hoping you reproduced 20 years of edge cases. With that harness, server-first (Linux-native, no Windows/IOCP lock-in, memory-safe packet handling, kills the 32-bit dependency hell), I'd put a faithful result genuinely high. None of this is an argument to drop what you're doing — your modernization is the prerequisite. It's more "once the layers are actually separated, the Rust question stops being theoretical." Happy to share the full scoping numbers if anyone wants them.
Last edited:
LV
2
- Joined
- Mar 5, 2026
- Messages
- 35
- Reaction score
- 50
- Points
- 38
I don't know.
In my opinion, the client-server architecture is a piсe of shit right now, and all the architectural layers are mixed up, and as a 20-year-experienced system architect, I'm crying bloody tears.
I'm not even trying to make any features right now, because they'll inevitably blow up in other places and cause unexpected issues.
I'm doing my best to improve the architecture.
Raise the language level to C++23.
Throw out the bad modules and add the already written, well-established third-party libraries (fontstash font rendering, RmUI, throw out the DirectX renderer and rewrite it with bgfx. Implement LuaBridge and eradicate the obscene language in lua scripts.
Using C++ and AI, I can replace the voluminous code of the server and client in parts, monitoring the negative trends in time. I've already had multiple rollbacks because something in the client just fell off completely due to forgotten edits or strange variables.
I believe that due to the excessive coupling, it won't be possible to simply rewrite this game into any other language other than the original one. However, after refactoring, it might be possible because the code's coupling will decrease significantly, allowing the AI to track everything correctly.
Following up on the Rust idea I floated earlier, since I said I'd investigate and report back. After digging into it properly, I've landed somewhere different from where I started, and I think it's worth sharing because the conclusion surprised me.
Short version: I don't think a full Rust rewrite is the move, and finishing the C++23 x64 path is. Not because Rust is bad, but because the question kind of dissolved once I looked closely. 64-bit is already a solved problem on this engine (there are native 64-bit builds running out there, mAPKO being the obvious one), so Rust was never actually needed to get there. The client side doesn't need Rust either, especially with milten21's Unity port building first-class importers for the proprietary formats. So the only place a rewrite ever made real sense was the server, which is also the one part Rust is genuinely good at. "Rewrite everything in Rust" quietly turned into "maybe rewrite just the server, eventually."
And here's the part that settled it for me. The only safe way to rewrite the server is to verify it against the existing C++ server, capture real traffic, replay it, and diff the output until it matches. That means you need a finished, working C++ server to check against. So finishing the C++ x64 work isn't a competitor to a rewrite, it's a prerequisite for one. Even if the server in Rust were the end goal, you'd still finish the C++ version first to have a reference to verify against. That flips the whole thing: C++ first, regardless of what you do later.
Short version: I don't think a full Rust rewrite is the move, and finishing the C++23 x64 path is. Not because Rust is bad, but because the question kind of dissolved once I looked closely. 64-bit is already a solved problem on this engine (there are native 64-bit builds running out there, mAPKO being the obvious one), so Rust was never actually needed to get there. The client side doesn't need Rust either, especially with milten21's Unity port building first-class importers for the proprietary formats. So the only place a rewrite ever made real sense was the server, which is also the one part Rust is genuinely good at. "Rewrite everything in Rust" quietly turned into "maybe rewrite just the server, eventually."
And here's the part that settled it for me. The only safe way to rewrite the server is to verify it against the existing C++ server, capture real traffic, replay it, and diff the output until it matches. That means you need a finished, working C++ server to check against. So finishing the C++ x64 work isn't a competitor to a rewrite, it's a prerequisite for one. Even if the server in Rust were the end goal, you'd still finish the C++ version first to have a reference to verify against. That flips the whole thing: C++ first, regardless of what you do later.