TheEqualizer

The performance difference is definitely not "minimal". When I said "compile in 64 bit" I meant after properly porting the client code (which, as I said, is not hard but time consuming). If you did not see any meaningful perf difference than that is your experience with it, which is OK, since each port is different we cannot make direct comparisons. The advantages of 64 bit also go beyond performance.

64 bit offers many advantages, performance being the most important. In my experience, just porting to 64 bit can get you a 10-15% perf boost. Some hardware vendors are dropping support for 32 bit systems, so 64 bit offers better compatibility with modern devices. In my opinion every, a client should support both 32 and 64 bit builds. Doing this is not even complicated, the hard part is usually obtaining 64 bit libs. If you have the libs, the rest is simple (although a bit time consuming).

It is not clear to me what the problem is. Is the problem exporting the normal map to the gr2 file or reading the exported normal map at run time? If it's the former, then the limitation is likely the exporter you are using not exporting the normal map related data. If it's the latter, then you may need to figure out how to properly read the normal map at runtime. Note: This is just my opinion, I am no expert in normal mapping, and haven't used normal mapping with models. I don't see anything that suggests the gr2 file format cannot/does not support normal maps.

Right now, I am working on stability and fixing some efficiency issues. After that I have some features planned. Regarding lights, is there a reason you can't simply add more lights to your scene? If you use the fixed function pipeline, the maximum number of lights available is driver dependent (but you can expect at least 8 to be available). If you use the programmable pipeline (shaders), then the number of lights you can have is pretty much unlimited. In my renderer I limited the maximum number of lights to 24 due to performance concerns (mostly for entry level/low end hardware. Decent hardware can handle much more than that).

I am still developing it. There will be updates in the future. I haven't had the time to work on it lately, but I will update it as soon as my schedule frees up.

You haven't stated what your problem is. The error you are getting is because your code is trying to dereference a pointer to an incomplete type. To fix this you have to provide the definition of the type (by, for example, including the header where the type is defined) before you can dereference it. Here's an example that causes the error you got: #include <iostream> struct foo; //forward declare type 'foo' void PrintFoo(foo* f) { std::cout << f->bar; //Error: dereferencing an incomplete type } struct foo { int bar{0}; }; void PrintFoo2(foo* f) { std::cout << foo->bar; //OK: compiler has seen the definition of 'foo' }

@Muffins character literals are value types, so it can't be assigned to a pointer variable. Just think a little bit, this is basic C++.

The error you are getting is self-explanatory. String literals are constant, and you are trying to assign a pointer to a string literal to a pointer to non const which is not valid (because this would allow you to violate the const attribute of the string literal).

Metin stones and effects I have been hearing about the performance impact of metin stones and effects since I entered the scene. But are metin stones really as heavy as many say they are? Metin stones don't appear to be complex objects but looks can be deceiving, so I decided to investigate what impact these stones (and effects) have on performance. These are the testing conditions: Resolution: 1920 x 1080; Map: Map A1; Field of View: 45 degrees (vertical); Metin stone count: 750 (arranged in a 25x30 grid, the stones are interleaved, so that they don't arrive at the renderer in an optimal order); Clients: TMP4 (Reference); Old version of my D3D11 Renderer and the new optimized version. Builds: All clients use Distribute. OK with that out of the way let's start testing. TMP4 (reference): Metin stones only: 23 ms (~43 FPS); Metin stones and effects: 73 ms (~14 FPS); Yeah, performance is pretty bad. Let's see how the old version of the renderer fares: Metin stones only: 12 ms (~ 83 FPS), 37 ms (~27 FPS. Shadows, AO and DoF set to max quality); Metin stones and effects: 40 ms (~25 FPS), 65 ms(~15 FPS. Shadows, AO and DoF set to max quality); While the renderer beats reference, as soon as graphical features are activated or there are a lot of effects, the performance becomes unacceptable. This hardware, while not high end by modern standards should be able to breeze through this test scene. So, it's time to optimize. After working on this for weeks, these are the results: Metin stones only: ~6 ms (~ 166 FPS, 32-bit exe); ~4 ms (~250 FPS, 64-bit exe); Metin stones and effects: 7 ms (~142 FPS, 32-bit exe); 5 ms (~200 FPS, 64-bit exe); This is a much, much better result. The overhead from effects became negligible, and we are able to render with graphics features set to max quality without worrying about performance. OK this is great so what are the disadvantages? When many effects are close together like this, some flickering can be observed. This can probably be mitigated by sorting the effects in a way that produces more consistent output (by distance perhaps?). 64-bit brings around 30% performance improvement, so in my opinion, it's worth it. So that's it, the fearsome metin stones and their effects have been conquered. This should be good enough for most scenes while leaving enough performance headroom for other things.

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.

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).

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

What hardware was used for these tests?

That is a problem with the geometry. MSAA can make seams visible if the geometry is not modelled correctly, although your case seem to be really an extreme example of it. A solution is to use a post processing AA technique (FXAA, SMAA, CMAA, etc) or supersampling (render at a higher resolution and then downsample to backbuffer resolution). In D3D11 you can resolve the MSAA samples yourself, so it may be possible to mitigate this (or fix it entirely)

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)