rdragon1

The way i have done it is that the editor uses the engine directly. So the level loading function all comes straigh from the engine. That way when i have a standalone executable that i release i can reuse the exact same loading function. Everything the editor does it uses the engine. That way you get what is WYSIWYG (What you see is what you get) type of editor. I have attached an screenshot of my 3d editor which i am currently working on just to give you an idea.

Looks like someone likes Unity

No, vertices can be shared between adjacent triangles, as long as all attributes match (position, normal, uv, whatever). For example, vertices along a 'hard edge' (not shared normals) are not shared between adjacent triangles. At maximum, numVertices = numTriangles*3, but there is as much sharing as possible.

I don't know how fast it is, but I'm sure it wasn't designed with speed in mind. It's more the kind of thing you want to run once over your shader to get the information you need, then store that in your own data for use at runtime as necessary. I wouldn't use it in your render loop, it's more of a tooling library for inspecting the shader code.

The lesson for me was: Yes, C++ is faster when you know how

 

This is a very important point. Many game engine developers have the "know how", but the problem you run into with managed environments is that even if you know how, you simply don't have low level enough access to implement the optimizations, so you're stuck. That's a deal breaker for a major engine to adopting a language.

What version of Visual Studio? It's called Win32 in VS, not x86, in the configuration manager.

GC is another topic that always pops up in these kind of discussions... IMO is pure non-sense. GC won't trigger if you don't "new" stuff, and will be VERY fast if you don't have objects with medium life expectancy.. it's just a matter to take some time to understand how the system works and how you can make it work for you... it's much easier to learn to deal with .NET's GC than learning proper memory management in C++, simple or through the 6-7 "smart" pointers available.
Just as you try to avoid new and delete in your game loop in C++, avoid newing class objects in C# and GC won't cause any troubles.

 

But really what you're suggesting here is that to "solve" the problem of the GC needing to halt all threads and needing an unknown amount of time to complete, that you do "manual memory management" and try to avoid invoking the GC, which also means designing around ctors/dtors and doing init/cleanup of your objects yourself so you can reuse instances. IMO that's a lot easier to do when there is no GC to worry about, and you reintroduce the problems GC was meant to solve (ie dangling pointers).

Global variables can be fine, and it certainly helps when debugging to just be able to type gResourceMgr into a Watch window and get at the resource lists.

 

I think the resource loader is fine to be global - it's the sort of thing you would only want one of in a process. Every engine I've ever worked with has had the resource loader be global. I certainly wouldn't want to pass a pointer to it through every function that could possibly call a function that might call a function that needs to get a resource.

Performance on modern hardware is less about optimizing instructions and more about memory access patterns and data layout. C++ lets you exactly control how your data is laid out in memory, so you can more explicitly control your memory behavior. C# tries to abstract this sort of thing away to favor programmer productivity at the cost of some performance.

 

I think most game engines being written in C++ is simply because C and C++ are extremely portable languages. If there were another language that was equally as portable you might see more engines written in that. It doesn't hurt that one of C++'s goals is also to be performance king.

In your fragment shader, the input.pos (surface position) that you're using is in projection space. However your light position is in world space. So when you compute the 'surface to light' vector (tmp_light - tmp_pos), you're doing it with coordinates in different spaces, and certainly not getting the world space direction you're looking for. Send the world position into your fragment shader and use that instead.

It doesn't cost money, nor is art required to prototype gameplay. Just start coding.

To write scalable parallel code, the answer isn't to take serial code and replace the data structures with 'thread-safe' versions that do the same operations. If you're resorting to using locks, then you're already down the wrong path. The right path is to create algorithms that don't need read+write access to shared data, or to constrain those stages of your algorithm to as small a piece as possible, but still extract parallelism where you can. The data transform you're performing dictates the data structures and algorithms, and a std::vector with locks in every member function is likely a terrible structure.

Everyone's pace is different, just keep going.

You're missing that you're calling normalize() on these encoded [0-1] vectors, and that's not doing what you want.

Keep everything in its natural [-1,1] form until just before you write it to the render target, then deencode it on the other end when you read it from the texture

For debugging, a much smaller test case would be preferred. Can you export a single 4-sided poly, and does your code correctly read it in and turn it into triangles? If not, start there. In that case it's easy enough to understand what the results should be by hand, so stepping through your algorithm in a debugger should be much easier.

I just ran the program in the debugger and switched to the disassembly window.

For your other question, the destructor will be called whenever the object goes out of scope, so the compiler will add another call to the destructor just before that other return.