[DEV] Priston Tale rewriting the client engine from scratch (C++17 / DX11)

[lkzera]

Hey,

Been working on this quietly for some time and decided to finally make a thread about it.

The idea is pretty straightforward: rewrite the old PT client engine (smLib3d) from scratch using modern C++ and DirectX 11, while keeping full compatibility with the original assets .smd, .smb, .inx, textures, animations, stages, all of it. I’m not trying to make a “PT 2.0” or reinvent the game. The whole point is to keep the original behavior while replacing the old codebase with something cleaner and easier to maintain/debug.

One thing I learned early is that PT has a lot of weird internal behavior that only makes sense once you look at the original source. So before changing or recreating anything, I usually cross-check the old clients (PTClassic / EU-main / ex-machina) and replicate the original logic as closely as possible. Things like the Y/Z axis handling, bone anti-rotation, animation blocks, material blend flags, etc. are very easy to break if you try to “improve” them blindly.

Current progress so far:

- Core math library finished (Vec / Mat4 / Quat)
- DX11 renderer working
- SMD / SMB / INX loaders reading original binaries correctly
- Characters, monsters and items rendering with skeletal animation
- Stage system loading/rendering
- Collision grid + raycast working
- Click-to-move implemented
- Day/night cycle
- Per-map sky, fog and lighting
- Wind animation on foliage
- Water rendering + underwater transition effect on characters
- Maps 0~44 loading correctly (Ricarten, Navisko, Pilai, fore-1, de-1, etc.)
- Ground item drops + pickup
- First audio system pass
- Minimap + player arrow
- Inventory UI
- In-game console
- Classic camera modes
- Basic camera transitions/clamping
- LOD system running

Still a lot left to do obviously, but the project is finally at a point where it feels stable enough to start sharing progress publicly.

I’ll post updates whenever I have something interesting to show.

 

[habboplayer]

unity? or just native c++??

 

[lkzera]

unity? or just native c++??

I'm using only C++, in the same way the original source was built. However, since I'm coding from scratch, I took the opportunity to separate the code well and not have the server and client all together.

 

[lkzera]

Quick thread about the Priston Tale remake progress and an important technical decision I made recently.

When I started the project, I rewrote the entire renderer in DX11/HLSL because it was the more modern and flexible stack. On paper, it sounded like the ideal path.

The problem is that classic PT was authored 100% around the DX8/DX9 fixed-function pipeline.

A lot of the game depends on very specific fixed-function quirks:

• RGB(0,0,0) color keying on BMPs
• AlphaTestDepth=60
• TextureStageStates(MAP_OPACITY MAP_SELFILLUM>)
• custom blend modes (SMMAT_BLEND_LAMP SHADOW ADDCOLOR INVSHADOW)
• vertex lighting driven by material RGBA + global ambient
• shadow projection through texture matrices
• etc

In the original client, all of this lives inside SetRenderState andSetTextureStageState calls in smRend3d.cpp

What I underestimated is that porting this to HLSL is NOT simply “writing modern shaders”.

Every visual detail in PT depends on implicit fixed-function behavior. So in DX11 I had to manually translate every single quirk.

And every visual bug I encountered so far came from exactly that:

• lee_07 rendering white
• broken Ricarten alpha
• sky luminance leaking into alpha
• shadow flickering
• incorrect glow halos

Every single time, it was some FF pipeline behavior that the shader still wasn’t replicating 1:1.

During this process, while investigating texture issues that “looked slightly off”, I started comparing with other PT sources that were also migrated to DX10/DX11.

And that’s when I noticed something interesting:
they all showed the exact same visual deviations.

Nothing dramatically broken.
Most people probably wouldn’t even notice.

But for people who played PT for years and know every map visually from memory… you instantly feel that “something is different”.

Lighting reacts differently.
Some textures look more washed out.
Certain materials lose depth.
Some blends become too aggressive.
The overall atmosphere changes slightly.

And that happens because the game’s original assets were authored expecting the behavior of the old fixed-function pipeline.

The cost becomes cumulative:
every new map exposes another historical renderer quirk.

So I decided to migrate the main renderer back to DX9 fixed-function.

Because in PT’s case:
the original material flags map almost 1:1 to SetRenderState.

The result:

• MUCH less complexity
• far higher visual compatibility
• less time hunting graphical edge cases
• behavior identical to the original game

And honestly:
there’s absolutely no visual quality loss.
The assets were built specifically for this pipeline.

In practice, using DX11 was actually moving me further away from the original game’s visual fidelity not closer to it.

The plan now is:

• use DX9 fixed-function as the main renderer
• stabilize visual compatibility first
• then add modern improvements incrementally and carefully

Sometimes “more modern” does not mean “more correct” when preserving a legacy game.

 

[lkzera]

Following up on my last post about the DX9 fixed-function decision the renderer migration is finally finished.

DX9 fixed-function migration complete​

The main renderer is now fully back on the DX9 fixed-function pipeline, and the results were worth the effort.

• The original material flags map almost directly to SetRenderState and SetTextureStageState
• Historical quirks such as RGB(0,0,0) color keying, AlphaTestDepth=60, custom blend modes (LAMP, SHADOW, ADDCOLOR, INVSHADOW), texture matrix shadow projection, and vertex lighting based on material RGBA + ambient now behave the same way they did in the original client
• The visual issues that showed up in most DX10/DX11 ports washed-out textures, incorrect lighting, and overly aggressive blending are gone

Maps now look the way I remember them. Instead of chasing rendering edge cases one map at a time, I can finally focus on gameplay systems again.

​

Server​

This was the biggest milestone over the last few months.
The client is no longer the source of truth. All gameplay state now lives on the server:

• Position, HP/MP, combat, and spawns are handled server-side
• The networking layer is fully asynchronous, so network operations never block rendering
• The server loads the actual stage geometry and performs collision checks using the original CheckNextMove logic, so both players and monsters follow the real map data rather than approximations
• Testing with multiple concurrent players has been stable so far

​

Monsters & Spawns​

• Data-driven spawn system with per-field JSON definitions, including ambient spawns
• Server-side spawn manager responsible for the entire monster lifecycle
• Monster definitions migrated from the original .inf files into a cleaner structure covering stats, drops, and related data

Skills & Combat​

• Skills are now processed server-side
• Combat formulas have been ported from PT-Classic, including derived stats, attack rating, class and weapon scaling, defense, absorb, block, and hit calculations
• Visual skill effects, trails, particles, and cast lighting are running on the rebuilt DX9 renderer while preserving the original blend behavior

GM / Admin Tools​

• Added GM and Admin access levels
• Server-side command channel with all permission checks enforced by the server

What's next​

With the renderer and server foundations in place, the focus now shifts back to gameplay systems and content.
The goal remains the same: preserve the original experience while modernizing carefully where it makes sense

 

[polancecky]

Wow this is awesome. Im not a coder like you but I just followed a video from youtube and build my own server through a VPS and local machine just 5days ago. I'm looking to something I can learn to maybe develop it further. Seeing this thread makes me a happy. It just shows there are still peiple out there whos still working on this game. Hope you can help sometime if I have some questions. Thanks!

 

[lkzera]

Wow this is awesome. Im not a coder like you but I just followed a video from youtube and build my own server through a VPS and local machine just 5days ago. I'm looking to something I can learn to maybe develop it further. Seeing this thread makes me a happy. It just shows there are still peiple out there whos still working on this game. Hope you can help sometime if I have some questions. Thanks!

Thanks for the message, I really appreciate the support!

It's always nice to see people still interested in Priston and trying to learn more about it. Building your own server after just a few days is already a pretty good start.

I've been putting a lot of time into this project over the last few weeks, mainly focused on making it more usable and getting things into a better state before sharing more. There are still plenty of things to work on, but I'll be posting more updates here soon.

And sure, feel free to ask if you have any questions. I'll help whenever I can.

 

[polancecky]

Thanks for the message, I really appreciate the support!

It's always nice to see people still interested in Priston and trying to learn more about it. Building your own server after just a few days is already a pretty good start.

I've been putting a lot of time into this project over the last few weeks, mainly focused on making it more usable and getting things into a better state before sharing more. There are still plenty of things to work on, but I'll be posting more updates here soon.

And sure, feel free to ask if you have any questions. I'll help whenever I can.

I will support you all the way man. Will definitely keep an eye on this thread. Thanks for the hardwork!

 

[NeoZexika]

Totally and utterly pointless. Unless you plan on navigating DWORD hell and porting the source files over to x64 architecture, there is nowhere near enough benefit to do projects like this.