64-Bit Build

[TheEqualizer 117]

Last month I decided to take on the challenge of porting TMP4 source to 64-bit, just to see how far I could go. This week I finally got it to compile and run in 64-bit. In the screenshots below, you can see that the 64-bit version has more graphics memory available than the 32-bit version. 64-bit also brings a decent performance uplift (4 - 5 ms against 6 - 7 ms, in the test scene).

The most difficult part was the sound system, it took a long time to get it to work, and even now two problems remain:

• MP3 files don't work in 64-bit because I don't have a compatible 64-bit mp3 decoder. As a workaround, I converted the mp3 files to bink audio, and it works; And
• There is a bit of latency when starting a sound/stream. I will investigate this when I have the time.

For extra challenge, I chose to have everything (except system libraries of course) linked statically. And here, python gave me a bit of trouble to compile in 64-bit.

It's very likely that my changes introduced some bugs, but at this time I can't fully test the code (especially the gameplay parts), so I will leave further testing for later. I don't need 64-bit right now, I mostly wanted to see if it was possible.

If you have acceptable performance already, or you don't intend to modernize, or you are not ready for the challenge then it's best not to poke the bear and stay in 32-bit.

[Khabib Nurmagomedov 388]

Hello, that looks amazing and great.

Regarding your mp3 files issue on 64bit, you can have a look at my post: 

MSS32 is the part of the client that causes you that certain issue, make good use of the lib, compile it in 64bit and it should be fixed(it needs some adaption though, keep that in mind as its not ready to use for metin2 straight out of the box).

[TheEqualizer 117]

44 minutes ago, FrenchForeignLegion said:

Hello, that looks amazing and great.

Regarding your mp3 files issue on 64bit, you can have a look at my post: 

MSS32 is the part of the client that causes you that certain issue, make good use of the lib, compile it in 64bit and it should be fixed(it needs some adaption though, keep that in mind as its not ready to use for metin2 straight out of the box).

Version 6.5 is not compatible with 64-bit. I tried it, made several changes to it to get it to compile to 64-bit, but the code wouldn't compile. I realized I was wasting time, so I checked the changelog online and found that version 7 introduced native 64-bit support, so all I needed was a more recent version of the library.

And even with a more recent version, it took some effort to get the code to compile.

I have a compatible 32-bit mp3 decoder, but not the 64-bit version. 64-bit code cannot load the 32-bit decoder, that is why I converted the mp3 files to bink audio, and I believe that format is actually the best for MSS (it didn't exist when this game was released)

[m2Ciaran 1100]

2 hours ago, TheEqualizer said:

Version 6.5 is not compatible with 64-bit. I tried it, made several changes to it to get it to compile to 64-bit, but the code wouldn't compile. I realized I was wasting time, so I checked the changelog online and found that version 7 introduced native 64-bit support, so all I needed was a more recent version of the library.

And even with a more recent version, it took some effort to get the code to compile.

I have a compatible 32-bit mp3 decoder, but not the 64-bit version. 64-bit code cannot load the 32-bit decoder, that is why I converted the mp3 files to bink audio, and I believe that format is actually the best for MSS (it didn't exist when this game was released)

Hello.

Mile ver 9.3b is compatible as I'm actually using it and does not require that much amount of work

Good job!

[PeaceMaker 143]

On 9/13/2024 at 10:10 PM, TheEqualizer said:

Last month I decided to take on the challenge of porting TMP4 source to 64-bit, just to see how far I could go. This week I finally got it to compile and run in 64-bit. In the screenshots below, you can see that the 64-bit version has more graphics memory available than the 32-bit version. 64-bit also brings a decent performance uplift (4 - 5 ms against 6 - 7 ms, in the test scene).

The most difficult part was the sound system, it took a long time to get it to work, and even now two problems remain:

• MP3 files don't work in 64-bit because I don't have a compatible 64-bit mp3 decoder. As a workaround, I converted the mp3 files to bink audio, and it works; And
• There is a bit of latency when starting a sound/stream. I will investigate this when I have the time.

For extra challenge, I chose to have everything (except system libraries of course) linked statically. And here, python gave me a bit of trouble to compile in 64-bit.

It's very likely that my changes introduced some bugs, but at this time I can't fully test the code (especially the gameplay parts), so I will leave further testing for later. I don't need 64-bit right now, I mostly wanted to see if it was possible.

If you have acceptable performance already, or you don't intend to modernize, or you are not ready for the challenge then it's best not to poke the bear and stay in 32-bit.

Did you by any chance experience any issues with "PCBlocker"? It's basically when your camera view hit an object and it's rendered with a lower opacity

Edited October 22, 2024 by PeaceMaker

[TheEqualizer 117]

1 hour ago, PeaceMaker said:

Did you by any chance experience any issues with "PCBlocker"? It's basically when your camera view hit an object and it's rendered with a lower opacity

No, no problems as far as I know. What kind of problem are you talking about?

[PeaceMaker 143]

8 hours ago, TheEqualizer said:

No, no problems as far as I know. What kind of problem are you talking about?

32bit 

https://metin2.download/picture/hZOS2wy5aAYa6K6cLskhY19w2C17h34X/.png

64bit

https://metin2.download/picture/qA9rFZe8NfZVT7Iw2h5zQW14RC93jhRy/.png

I haven't really touched that part of the code so I'm a bit surprised why it would stop working.

Edited October 23, 2024 by Metin2 Dev International
Core X - External 2 Internal

[TheEqualizer 117]

I don't have that problem. I use my own renderer (which was developed with 64bit in mind), so I don't know how 64 bit affects the client's old render code.

What I think is happening there is that for some reason, that tree is not flagged as a pcblocker so it renders normally or it could be that in your 64bit code path alpha blending is not enabled (so the tree is rendered opaque).

These are just guesses, since I don't know how you are dealing with pcblockers.

 

EDIT: To test if the tree is properly flagged as a PCBlocker, comment the PCBlocker render code, if the tree (or any object) gets flagged as PCBlocker it will disappear (since the render code was commented), and if that happens, the problem may be that you are not blending pcblockers properly).

Edited October 23, 2024 by TheEqualizer

[PeaceMaker 143]

13 hours ago, TheEqualizer said:

I don't have that problem. I use my own renderer (which was developed with 64bit in mind), so I don't know how 64 bit affects the client's old render code.

What I think is happening there is that for some reason, that tree is not flagged as a pcblocker so it renders normally or it could be that in your 64bit code path alpha blending is not enabled (so the tree is rendered opaque).

These are just guesses, since I don't know how you are dealing with pcblockers.

 

EDIT: To test if the tree is properly flagged as a PCBlocker, comment the PCBlocker render code, if the tree (or any object) gets flagged as PCBlocker it will disappear (since the render code was commented), and if that happens, the problem may be that you are not blending pcblockers properly).

Thanks for your reply.

I've only showed the tree but this is also happening for normal objects... I just had the time to look at it again and added a bit more trace and I couldn't find anywhere that CMapOutdoor::RenderPCBlocker() was called from ... then I also looked at the code prior to 64bit upgrade and guess what  it's also not called anywhere. 

Calling CPythonBackground::RenderPCBlocker() from CPythonApplication::RenderGame() makes buildings work again but not trees... So it could be possible that trees are indeed not flagged as PCBlockers as they don't get hidden either.

So I cannot really explain how the hell that worked before, maybe you have some clues?

Edit: I also checked that "RenderPCBlocker" is not called from the python module "background"

Edited October 23, 2024 by PeaceMaker

[TheEqualizer 117]

You need to determine what the problem is (if it's a flag problem or a blending problem). A flag problem can be solved by checking the functions that flag objects as PCBlockers (could be inside CArea). A blending problem will likely only require checking your render states.

This doesn't appear to be a problem related to 64bit, it seems you messed up something while converting to 64bit.

[PeaceMaker 143]

9 hours ago, TheEqualizer said:

This doesn't appear to be a problem related to 64bit, it seems you messed up something while converting to 64bit.

You are absolutely right, it isn't related to 64bit but seems more like a side effect after porting to 64bit ...  I'm pretty sure I haven't touched that part of the code and gitlense can vouch for me  

I guess you never had these issues as you had modified the original rendering code prior to porting.

Anw, you were right, instances with type TREE_OBJECT were never appended to PCBlocker list so still a mystery how this stuff worked before.

 

Thanks for your input again