Kaiser

This is a guide on how to remove the devil library used in Metin2 and process guild icons with stb_image. After this process, devil.lib will no longer be used and will not be an extra load. Firstly, download the stb_image.h file. Download [Hidden Content]

Although I don't dedicate much time to map work, the heightmap feature will be very useful. Thank you.

for now final:

I'm sorry I forgot. Thank you. Also, this line; std::stable_sort(m_PatchDrawStructVector.begin(), m_PatchDrawStructVector.end(), FSortPatchDrawStructWithTerrainNum()); is inside the void CMapOutdoor::SetPatchDrawVector() function. You can delete that function COMPLETELY. It's not used at all. I had already deleted it, so I even forgot about the existence of the line you mentioned

While cleaning up the project, I sometimes come across and remove unused/dead code. This is one of them. All of the following code is useless and can be deleted because it was added during area drawing for development/debugging purposes but was abandoned after the final stages. Please proceed carefully. [Hidden Content]

Hi, I've been working on Metin2 graphics and DirectX as a hobby for a long time. My priority has never been visual spectacle; my only goal has been to improve the infrastructure beyond DirectX 8/9, and after all the effort and work, I have finally fully upgraded to DirectX 11. I would like to point out that no APIs or wrappers are used. There is no actively used DX9 code in the project. Of course, from this point on I will focus on the visual aspect and see what can be done with DirectX 11. If there are no issues, the detailed changelog is here. I am open to ideas and criticism.

Download While revising the old code in the project, I noticed the DXTCImage.cpp file and the .DDS files loaded within it. Upon examining where this file was used, I found it was only used in the GrpImageTexture.cpp file. Instead of using the outdated and complex DXTCImage structure, which is used exclusively by this file, I found it more appropriate to use the DirectXTex library. DirectXTex is a library designed for DX11/DX12 and is capable of doing many times more than the DXTCImage file. It does not have direct support for DirectX8/9, so we will use a small converter in the code. I've included many formats that can be used in Metin2 in this converter; if you get a syserr error, it means you need to update this code. Please follow the steps below carefully. In case of any problems, revert the changes or use the #ifdef statement. Following this update, the DXTCImage.cpp and DXTCImage.h files will no longer be used. [Hidden Content]

Download Hello, yesterday while testing in debug mode, I accidentally noticed something. In the upper right corner, the ATM value was stuck at -1. When I asked a friend who uses a 12GB GPU, he said he was seeing nonsensical values like -51 and -63. Looking at the code again, I saw that it was due to the 32-bit limit. My GPU is 16GB, but the information displayed on the debug screen was being calculated based on 32-bit (Max. 4GB), causing it to crash and become corrupted. The GetAvailableTextureMemory function used in Python and C++ is dependent on DirectX, and unfortunately, DirectX 8 and DirectX 9 are very old and return a maximum of 4 billion values (UINT, 4GB). This means that graphics cards with more than 4GB cannot be correctly included in this calculation. The purpose here is not to show the total capacity of the available GPU on the debug screen, but to show the remaining usable space within the application. As for the solution; to fix this situation as best as possible, we will use the DXGI library. DXGI is a bit more modern than normal DX libraries and allows us to see the most accurate information under current conditions.First, if you get an unresolved external symbol error during compilation, add the .lib file I provided to your project. [Hidden Content]

Hi, due to some "dead" code related to fog, client crashes and other issues occasionally occur, and various fixes are being produced accordingly. The most critical factor here is that the fog.tga file read by the client is a useless texture file of about 4x2 size. However, after a small cleanup operation, the crashes related to fog should end. The main issue: fog.tga file. Many people think this file somehow works in relation to fog, but it's not used and just sits there. The client copies this incompatible and corrupted tga file into RAM every time it starts, but never uses it. I think the developers intended to create the fog structure through a texture, and then, realizing that DirectX already does this automatically, they left these codes as they are. In short; the fog in Metin2 is drawn and executed by DirectX, and these leftover codes continue to cause headaches from time to time. For those interested: THIS PROCESS WILL NOT DAMAGE/AFFECT THE EXISTING FOG IN THE GAME [Hidden Content]

In rare cases, a crash may or may not occur when the application is closed. This is a memory issue. To completely eliminate the possibility of such risks, it would be prudent to destroy post-processing along with all other systems within Destroy. Add a void Destroy() function as "public" to the .h and .cpp file and: CPostProcessManager::~CPostProcessManager() { Destroy(); // Add -- This is all that will happen here. // Move all of the following code into the newly created Destroy(); /* safe_release(m_ScreenQuad); ReleaseTextures(); for (const auto& elem : m_ShaderMap) { IShader* shader = elem.second; delete shader; } /* } And: void CPythonApplication::Destroy() { [...] m_PostProcessManager.Destroy(); // Must be before m_grpDevice.Destroy()! [...] m_grpDevice.Destroy(); // !! [...] [...] }

Try: void CPostProcessManager::ReleaseTextures() { [...] // add for (const auto& elem : m_ShaderMap) { if (elem.second) elem.second->OnLostDevice(); } } bool CPostProcessManager::CreateTextures() { [...] [...] [...] // Add for (const auto& elem : m_ShaderMap) { if (elem.second) elem.second->OnResetDevice(); } return true; }

I experienced this problem in my own project a long time ago. I don't remember the exact solution, but it was likely due to a missing backup in post-process rendering. In particular, before calling SetFVF and SetStreamSource, these two states must be backed up and the backup must be reloaded after rendering. Otherwise, these two are very likely to create conflicts with other Render functions in the project and are dangerous. Since everyone's project may have different layouts, doing this backup and restore process within Render will ensure consistent operation across all other projects. What I said above also includes Transform backups.

I was browsing through the code during my graphics work, looking for anything that could be considered "junk," when I came across the 16-bit color controls.The 16-bit era was more or less completely lost to history around Windows 7, and no monitor is physically limited to 16-bit these days. The worst monitors are currently 24-bit, which indirectly supports 32-bit color.Therefore, I decided to purge the source code of any code that provided extra controls for this, or that was useless even though it existed. If you are not using a monitor like this, you can easily do this cleaning process: So let's get started, but let me state it again; read the explanation carefully and follow the steps carefully. [Hidden Content] That's all there is to it; those who wish can make these edits using macros. Any conflicts with external edits you make to your project are your responsibility.

First of all, thank you for sharing this. Additionally, it would be really great if you could add an installation guide or video for those unfamiliar with it. I've never used cmake before, so I'm unfamiliar with this type of setup. Thanks again.

Hi, I'm migrating Metin2 completely to shader, and inevitably, a lot of files/code are wasted in the process, and I end up removing them all. Yesterday, while migrating the contents of GrpScreen.cpp to shader, I noticed the ScreenFilter.cpp file. It's a tiny, unused file that was sitting there, but disabled. I looked into it a bit and discovered that it filters the screen by coloring it. Of course, it doesn't work in its current state, and ymir disables it by setting it to FALSE. I tried enabling it by setting it to TRUE, but it didn't work because the render function is broken. They also used incorrect values in the pack. In short, after some effort, I finally got it working. Since these codes were of no use to me, and since I was already doing this with shaders, I wanted to fix them and share them with anyone who wants to use them instead of deleting the file directly. The steps are short and simple. However, be careful. You can use it for any purpose you want. It's up to your imagination. I hope it works on DirectX 8 too but I'm not sure. Tested on DirectX 9 and no issues were found. "I apologize for my bad English." [Hidden Content] Final(Map C1): Original and Filtering