LV
2
- Joined
- Mar 5, 2026
- Messages
- 38
- Reaction score
- 52
- Points
- 38
Source Tales of Pirate 2026 x64 DX9 by alexxst.st
- Thread starter alexxst
- Start date
LV
2
- Joined
- Mar 5, 2026
- Messages
- 38
- Reaction score
- 52
- 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
LV
0
- Joined
- May 28, 2026
- Messages
- 14
- Reaction score
- 2
- Points
- 8
- Location
- Above and Below
- Website
- chaospirates.com
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
- 38
- Reaction score
- 52
- 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.
LV
0
- Joined
- May 28, 2026
- Messages
- 14
- Reaction score
- 2
- Points
- 8
- Location
- Above and Below
- Website
- chaospirates.com
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.
LV
0
- Joined
- May 28, 2026
- Messages
- 14
- Reaction score
- 2
- Points
- 8
- Location
- Above and Below
- Website
- chaospirates.com
Wanted to share some progress and, more usefully, document the specific traps, since anyone porting this engine to x64 is going to hit the exact same ones.
Short version: I have a native x64 build of the client (Game64.exe) that's playable end to end against the unmodified 32-bit servers. Login, character select, world load, rendering, combat all work. No server changes required.
Why it can talk to 32-bit servers unchanged: Windows x64 is LLP64, so int and long stay 32-bit and only pointers grow to 8 bytes. The packets serialize field by field and carry no raw pointers, so the wire format is identical between the 32-bit and 64-bit builds. That's the key realization that lets you do an x64 client without touching the server at all.
Approach: every x64 change is wrapped in #ifdef _WIN64, the 32-bit build stays byte-identical, and the x64 output is isolated to its own folder. I deliberately did not refactor anything while porting. The goal was "get to playable x64 with zero regression to the shipping client," and keeping the two builds surgically separated is what made that achievable.
The mechanical stuff (expected): inline x86 asm rewritten as portable C (MSVC x64 forbids __asm), ODBC indicator vars to SQLLEN/SQLULEN, SetWindowLongPtr/INT_PTR for the window and dialog procs, and sourcing x64 builds of every third-party dep (DX9 libs, LuaJIT, SDL2 in place of SDL 1.2.7, discord-rpc, CryptoPP with asm disabled).
The part actually worth documenting, because LLP64 means only pointer-bearing serialized structs break:
1. lwTexInfo::data is a void*. It's a 4-byte slot in the on-disk model file but 8 bytes in the x64 struct, so a raw fread of the record over-reads and desyncs all the material/texture data, then crashes during resource load. It is the only directly-fread pointer-bearing struct in the whole model/mesh/material/bone/anim path, so the fix is narrow: read each record through a 32-bit on-disk mirror struct and leave the rest untouched.
2. Table .bin: CRawDataInfo:
Data is also a void*, which breaks the encrypted record stride on x64. I read these through a mirror with the on-disk stride derived from the record count rather than sizeof, because tail-padding on x64 makes a sizeof-based guess wrong for any table whose derived fields aren't an 8-byte multiple (that one cost me a crash before I figured it out).
3. Biggest landmine, flagging this one loudly: if your x64 build ever calls the "make bin" path, it rewrites the shared .bin files (StringSet.bin in my case) in 64-bit record layout. Your 32-bit client then reads that as garbage and crashes on load. If you run both builds against shared data, guard every bin-write path with #ifndef _WIN64 or you'll corrupt your working 32-bit client from the x64 one and spend a while wondering why.
Still open: the bad-model handler is currently a try/catch net rather than a real fix, deeper in-game testing, and then the server x64 phase, which will hit the same pointer-in-serialized-struct issues for the server-side data structs.
None of this is a replacement for the proper modernization work happening on the engine, it's the conservative "keep 32-bit intact, get x64 running alongside it" route. Happy to compare notes with anyone going down the same path, the serialization gotchas above are engine-wide and not specific to my fork.
Short version: I have a native x64 build of the client (Game64.exe) that's playable end to end against the unmodified 32-bit servers. Login, character select, world load, rendering, combat all work. No server changes required.
Why it can talk to 32-bit servers unchanged: Windows x64 is LLP64, so int and long stay 32-bit and only pointers grow to 8 bytes. The packets serialize field by field and carry no raw pointers, so the wire format is identical between the 32-bit and 64-bit builds. That's the key realization that lets you do an x64 client without touching the server at all.
Approach: every x64 change is wrapped in #ifdef _WIN64, the 32-bit build stays byte-identical, and the x64 output is isolated to its own folder. I deliberately did not refactor anything while porting. The goal was "get to playable x64 with zero regression to the shipping client," and keeping the two builds surgically separated is what made that achievable.
The mechanical stuff (expected): inline x86 asm rewritten as portable C (MSVC x64 forbids __asm), ODBC indicator vars to SQLLEN/SQLULEN, SetWindowLongPtr/INT_PTR for the window and dialog procs, and sourcing x64 builds of every third-party dep (DX9 libs, LuaJIT, SDL2 in place of SDL 1.2.7, discord-rpc, CryptoPP with asm disabled).
The part actually worth documenting, because LLP64 means only pointer-bearing serialized structs break:
1. lwTexInfo::data is a void*. It's a 4-byte slot in the on-disk model file but 8 bytes in the x64 struct, so a raw fread of the record over-reads and desyncs all the material/texture data, then crashes during resource load. It is the only directly-fread pointer-bearing struct in the whole model/mesh/material/bone/anim path, so the fix is narrow: read each record through a 32-bit on-disk mirror struct and leave the rest untouched.
2. Table .bin: CRawDataInfo:
Data is also a void*, which breaks the encrypted record stride on x64. I read these through a mirror with the on-disk stride derived from the record count rather than sizeof, because tail-padding on x64 makes a sizeof-based guess wrong for any table whose derived fields aren't an 8-byte multiple (that one cost me a crash before I figured it out).3. Biggest landmine, flagging this one loudly: if your x64 build ever calls the "make bin" path, it rewrites the shared .bin files (StringSet.bin in my case) in 64-bit record layout. Your 32-bit client then reads that as garbage and crashes on load. If you run both builds against shared data, guard every bin-write path with #ifndef _WIN64 or you'll corrupt your working 32-bit client from the x64 one and spend a while wondering why.
Still open: the bad-model handler is currently a try/catch net rather than a real fix, deeper in-game testing, and then the server x64 phase, which will hit the same pointer-in-serialized-struct issues for the server-side data structs.
None of this is a replacement for the proper modernization work happening on the engine, it's the conservative "keep 32-bit intact, get x64 running alongside it" route. Happy to compare notes with anyone going down the same path, the serialization gotchas above are engine-wide and not specific to my fork.
LV
0
- Joined
- May 28, 2026
- Messages
- 14
- Reaction score
- 2
- Points
- 8
- Location
- Above and Below
- Website
- chaospirates.com
x64 client update: freeze gone, scenery rendering, optimized
Follow-up to my earlier post about the native x64 client. Made serious progress over the last day, and as before the useful part is the specific traps, since they're engine-wide and not specific to my fork.
Where it's at now: smooth, optimized, buildings and decorations render, character-select to world is instant. User-confirmed in-world with no lag. Still client-only, the 32-bit servers are untouched and stay the backend (the x64 client is wire-compatible because Windows x64 is LLP64, so nothing forces the server to follow).
Three things got it there:
1. The whole x64 tree was building unoptimized. None of the vcxproj files had an <Optimization> setting, so every Release|x64 binary, including the MindPower3D engine, was compiling at /Od, roughly 5-20x slower than the /O2 32-bit build. That was the slow boot, slow teleports, and input lag. Setting MaxSpeed across all units fixed the general sluggishness. Worth checking if you've branched the tree for x64, it's easy to miss because the 32-bit configs have it and the new x64 ones silently don't.
2. A 30-40 second freeze at character select, traced to a phantom 51 GB allocation. 156 of ~519 scene meshes use the legacy v0/v1 mesh format. On x64 the header read was coming back with vertex_num == 0xFFFFFFFF, so the loader tried to allocate ~51 GB, failed after ~265 ms, times 156 = the freeze, and the renderer choking on the broken models every frame was the in-game movement lag. Note this was NOT compute-bound, so the optimization fix above did nothing for it, they were two separate problems.
3. Root cause of both the freeze and the missing buildings: another un-mirrored void* in a serialized struct. This is the recurring x64 demon for this engine and the main thing I'd warn anyone about. The legacy material struct lwTexInfo_0001 (MTLTEX_VERSION0001) has a void* data member. On x64 that's 8 bytes versus a 4-byte slot on disk, so a raw fread over-reads, the file position desyncs, and then the following mesh header reads garbage, which is where the bogus vertex count came from. My original fix had mirrored the newer lwTexInfo but missed this older versioned one. Added a second 32-bit on-disk mirror for it and the legacy props load correctly.
The lesson, which I'll repeat because it cost me time twice: the pointer-in-serialized-struct problem is not one bug you fix once, it recurs per format version. You have to sweep every directly-fread struct across every version of every format for pointer members. I also left a sanity-guard on the mesh counts as defense-in-depth, so the next un-mirrored pointer struct (if there is one) fails safe by skipping the model instead of hanging on a giant allocation.
Still open, tracked as visual polish: a few UI items (label positioning, a text-color issue, a display dialog missing options) and combat skill FX. Some of those I suspect are one or two more of the same pointer-mirror sweeps rather than real UI bugs.
Happy to compare notes with anyone porting this engine to x64. The serialization gotchas above will hit any fork, since they're in the shared MindPower3D loaders.
Follow-up to my earlier post about the native x64 client. Made serious progress over the last day, and as before the useful part is the specific traps, since they're engine-wide and not specific to my fork.
Where it's at now: smooth, optimized, buildings and decorations render, character-select to world is instant. User-confirmed in-world with no lag. Still client-only, the 32-bit servers are untouched and stay the backend (the x64 client is wire-compatible because Windows x64 is LLP64, so nothing forces the server to follow).
Three things got it there:
1. The whole x64 tree was building unoptimized. None of the vcxproj files had an <Optimization> setting, so every Release|x64 binary, including the MindPower3D engine, was compiling at /Od, roughly 5-20x slower than the /O2 32-bit build. That was the slow boot, slow teleports, and input lag. Setting MaxSpeed across all units fixed the general sluggishness. Worth checking if you've branched the tree for x64, it's easy to miss because the 32-bit configs have it and the new x64 ones silently don't.
2. A 30-40 second freeze at character select, traced to a phantom 51 GB allocation. 156 of ~519 scene meshes use the legacy v0/v1 mesh format. On x64 the header read was coming back with vertex_num == 0xFFFFFFFF, so the loader tried to allocate ~51 GB, failed after ~265 ms, times 156 = the freeze, and the renderer choking on the broken models every frame was the in-game movement lag. Note this was NOT compute-bound, so the optimization fix above did nothing for it, they were two separate problems.
3. Root cause of both the freeze and the missing buildings: another un-mirrored void* in a serialized struct. This is the recurring x64 demon for this engine and the main thing I'd warn anyone about. The legacy material struct lwTexInfo_0001 (MTLTEX_VERSION0001) has a void* data member. On x64 that's 8 bytes versus a 4-byte slot on disk, so a raw fread over-reads, the file position desyncs, and then the following mesh header reads garbage, which is where the bogus vertex count came from. My original fix had mirrored the newer lwTexInfo but missed this older versioned one. Added a second 32-bit on-disk mirror for it and the legacy props load correctly.
The lesson, which I'll repeat because it cost me time twice: the pointer-in-serialized-struct problem is not one bug you fix once, it recurs per format version. You have to sweep every directly-fread struct across every version of every format for pointer members. I also left a sanity-guard on the mesh counts as defense-in-depth, so the next un-mirrored pointer struct (if there is one) fails safe by skipping the model instead of hanging on a giant allocation.
Still open, tracked as visual polish: a few UI items (label positioning, a text-color issue, a display dialog missing options) and combat skill FX. Some of those I suspect are one or two more of the same pointer-mirror sweeps rather than real UI bugs.
Happy to compare notes with anyone porting this engine to x64. The serialization gotchas above will hit any fork, since they're in the shared MindPower3D loaders.
LV
0
- Joined
- May 28, 2026
- Messages
- 14
- Reaction score
- 2
- Points
- 8
- Location
- Above and Below
- Website
- chaospirates.com
Just went through this today, idk if you figured it out yet but here's the solution I found.
The missing and transparent buildings, fences, and stairs are something we just ran into and fixed on our side. Good news is it's an x64 asset-loader bug, not a rendering one, so it's completely independent of your DX11 work and the same fix applies.
Root cause: the legacy material struct lwTexInfo_0001 (MTLTEX_VERSION0001) has a void* data member. On x64 that member is 8 bytes, but it's only a 4-byte slot in the on-disk model file. So a raw fread of the texture-info array over-reads, the file position desyncs, and the next mesh header then reads garbage. The tell is vertex_num coming back as 0xFFFFFFFF. From there the model either gets discarded entirely (missing) or renders with broken material data (transparent), which lines up exactly with what you're seeing.
The part that makes this one sneaky: most x64 ports already mirror the newer lwTexInfo, but this older versioned struct is easy to miss, and lwTexInfo_0000 is pointer-free so it loads fine. That mix makes it look like only "some" objects are broken when really it's everything using that one legacy material version.
Fix: read each VERSION0001 record through a 32-bit on-disk mirror struct (a DWORD data slot, no 8-byte alignment) instead of the raw array fread. It's all in lwExpObj.cpp. After that the legacy scene props load correctly and the buildings, fences, and stairs come back.
General tip for x64 on this engine, since it cost us time twice: the pointer-in-serialized-struct problem recurs per format version. You have to mirror every directly-fread struct that has a pointer member, across every version, not just the newest one. It's also worth adding a sanity guard on the mesh counts (reject 0xFFFFFFFF or absurd values) so the next un-mirrored struct fails safe by skipping the model instead of attempting a multi-GB allocation, which in our case showed up as a 30+ second freeze at character select before we tracked it down.
LV
0
- Joined
- May 28, 2026
- Messages
- 14
- Reaction score
- 2
- Points
- 8
- Location
- Above and Below
- Website
- chaospirates.com
LV
2
- Joined
- Mar 5, 2026
- Messages
- 38
- Reaction score
- 52
- Points
- 38
LV
0
- Joined
- May 28, 2026
- Messages
- 14
- Reaction score
- 2
- Points
- 8
- Location
- Above and Below
- Website
- chaospirates.com
I think I'll not share how to fix this one see who the real ones are to figure out where to change this one hahaha, gj Montana pwning nabs
LV
4
funny fact we shared what been leaked so the discord id not mine either but i pushed it as empty in other github but its simple to change so things is good to go 
![[TwT]~Darkness](/data/avatars/m/0/213.jpg?1774049328){kind=avatar}
LV
0
- Joined
- Mar 11, 2026
- Messages
- 34
- Reaction score
- 10
- Points
- 28
Hola!
Listen, maybe u can explain what happends with my broken hands?
cuz im trying to rendered gate\acc\group cuz in folder only game cfg files.
and?
and i have million problem.
SDK connot be readed. sdk not dound. im downloaded 8\10 version during to list inside github. and? nothing !
how to fix this shit ? maybe someone knows?
maybe need to update full c++ with full staff 50+ GB? or what....
or i can using acc\group\gate from the mhontana main project? just copy past?
LV
2
- Joined
- Mar 5, 2026
- Messages
- 38
- Reaction score
- 52
- Points
- 38
1. You can't use the original mhontana files because the game now uses a different protocol, msgpack. The network part has been heavily refactored and tested.
2. You need to install .NET support in the studio, as indicated in the solution explorer.
LV
0
- Joined
- Mar 11, 2026
- Messages
- 34
- Reaction score
- 10
- Points
- 28
The thing is, I updated Visual Studio 4GB, then updated it again with the missing components. Then I installed additional SDK versions separately. Now I'm updating C++ again. I hope it works.
Thanks a lot)
LV
0
- Joined
- May 28, 2026
- Messages
- 14
- Reaction score
- 2
- Points
- 8
- Location
- Above and Below
- Website
- chaospirates.com
