compiling some legacy code math library
I'm trying to compile a 3d library from an old game engine programming book I found on the internet, I have succeeded to build all the engine components but I get an error message trying to compile the math library I figured out that the error is coming from this:
the error messages I'm getting are the following:
I am using visual c++ 6.0 with service pack 4.0 and processor pack installed as recommended by the book, I feel like one step away from running and testing the sample game.
|
|
the error messages I'm getting are the following:
|
|
I am using visual c++ 6.0 with service pack 4.0 and processor pack installed as recommended by the book, I feel like one step away from running and testing the sample game.
Last edited on
If your CPU has both SSE2 and MMX (which is all but the most ancient at this point), I'd suggest you remove or comment out the entire code posted here, and merely set the two entries in the info structure (bSSE and bMMX) to 1, then return it.
Doing that you will not need the "try" or the catch (__except), just return as the function is declared (return info) after setting those members.
This test is an old way of checking for MMX and SSE2 support. Anything this side of a Pentium 4 (including the Pentium 4) will have it.
Now, why anyone would want to use a game engine of that age, requiring Visual C++ 6.0 I simply can't fathom, but there's another story I'm sure.
Doing that you will not need the "try" or the catch (__except), just return as the function is declared (return info) after setting those members.
This test is an old way of checking for MMX and SSE2 support. Anything this side of a Pentium 4 (including the Pentium 4) will have it.
Now, why anyone would want to use a game engine of that age, requiring Visual C++ 6.0 I simply can't fathom, but there's another story I'm sure.
Last edited on
thank you for your fast answer, I got the game running now :) it's not as bad as I thought
the only part of the engine that I think is old and deprecated is the math library's code because it uses some creepy assembly for fast 3d calculations and for the SIMD optimizations. vs 6.0 is a recommendation, not a requirement, I use it because the engine project in the books CD was written using vs 6.0 so that was I can just double click and build.
the engine uses directx 9 witch many great today's games are still using or supporting at least, for the network interface it uses winsock 2.0, I'm sure that there are many better ways to implement networking for games but I just love low-level programming, after I finish reading the book, I'll replace the direct3d 9 code with direct3d 11 code so yeah, I have a modern game engine :)
just out of curiosity I want to know why this code is not working
error:
I tried with goto LABEL; and it worked but why the assembly version is not working
|
|
the only part of the engine that I think is old and deprecated is the math library's code because it uses some creepy assembly for fast 3d calculations and for the SIMD optimizations. vs 6.0 is a recommendation, not a requirement, I use it because the engine project in the books CD was written using vs 6.0 so that was I can just double click and build.
the engine uses directx 9 witch many great today's games are still using or supporting at least, for the network interface it uses winsock 2.0, I'm sure that there are many better ways to implement networking for games but I just love low-level programming, after I finish reading the book, I'll replace the direct3d 9 code with direct3d 11 code so yeah, I have a modern game engine :)
just out of curiosity I want to know why this code is not working
|
|
error:
|
|
I tried with goto LABEL; and it worked but why the assembly version is not working
Last edited on
I have no answer about the jump to "label".
I did want to point out, though, that "modern", with respect to 3D API, has one particular significant point - the model of the GPU.
From the first OpenGL to the Directx 11, the GPU is treated as a server. Everything the GPU will act upon is sent to it as if it were a remote computer (and in the very early OpenGL model, it was a separate computer).
Directx 12 shares a significant change with Vulkan and Metal API's. They no longer treat the GPU as a remote computer or server. The memory model is more unified. It is no longer required that everything the GPU acts upon is shipped to the GPU for work.
There can be significant performance benefits, sometimes orders of magnitude, but it requires a considerably different programming model and mindset. So far as I can tell most engines are just now getting tuned to actually take advantage of it, even as they claimed to use it for a while now.
I point this out because it is the first really significant modernization of the API's after programmable shaders. The shader languages and featuress have been incrementally improved over the various versions, with increased processing power and options, and no less with Directx 12 and related API's.
So, my point is that while Directx 11 will offer shader improvements, there is not such a major jump toward modernization.
The real power of any engine comes from the shader features. Modern engines use PBR, or physically based rendering techniques, usually with reflections accounted on everything. This gives recent games their particular look, and makes certain materials seem real.
Metals, water, glass, wetness - these are part of modern engines that might not be available to you unless you make these shader features yourself.
If your purpose is study, that's not an issue. If your purpose involves having a game engine for building games, I have to wonder why you rejected the major game engines.
I don't quite follow why an engine, in this epoch, would do well to limit the targets to one platform. Most modern engines support targets from Windows to consoles, to MAC to mobile, though mobile support differs widely among the big names. One in particular only really supports very high end mobile targets, while another covers the entire range much better.
The next real issue is physics. What physics is offered in the engine you're using? Physics has a huge number of "gotchas", as I've encountered, and lately I've come to rely on an open source (recently released as such) engine with features I needed but could not reliably use elsewhere.
Another issue is workflow. Most game development ends up waiting on artwork, and the connectivity between various modeling tools and the engine is key to productivity.
Even as a learning exercise, I have to wonder how valuable it might be to learn from an older engine, and to what end. One direction, the one you're on, aims toward the creation of engines. The other is toward working games. If you're really focused on the latter, I'd seriously suggest you change directions for a modern engine. It is an entirely different experience.
I did want to point out, though, that "modern", with respect to 3D API, has one particular significant point - the model of the GPU.
From the first OpenGL to the Directx 11, the GPU is treated as a server. Everything the GPU will act upon is sent to it as if it were a remote computer (and in the very early OpenGL model, it was a separate computer).
Directx 12 shares a significant change with Vulkan and Metal API's. They no longer treat the GPU as a remote computer or server. The memory model is more unified. It is no longer required that everything the GPU acts upon is shipped to the GPU for work.
There can be significant performance benefits, sometimes orders of magnitude, but it requires a considerably different programming model and mindset. So far as I can tell most engines are just now getting tuned to actually take advantage of it, even as they claimed to use it for a while now.
I point this out because it is the first really significant modernization of the API's after programmable shaders. The shader languages and featuress have been incrementally improved over the various versions, with increased processing power and options, and no less with Directx 12 and related API's.
So, my point is that while Directx 11 will offer shader improvements, there is not such a major jump toward modernization.
The real power of any engine comes from the shader features. Modern engines use PBR, or physically based rendering techniques, usually with reflections accounted on everything. This gives recent games their particular look, and makes certain materials seem real.
Metals, water, glass, wetness - these are part of modern engines that might not be available to you unless you make these shader features yourself.
If your purpose is study, that's not an issue. If your purpose involves having a game engine for building games, I have to wonder why you rejected the major game engines.
I don't quite follow why an engine, in this epoch, would do well to limit the targets to one platform. Most modern engines support targets from Windows to consoles, to MAC to mobile, though mobile support differs widely among the big names. One in particular only really supports very high end mobile targets, while another covers the entire range much better.
The next real issue is physics. What physics is offered in the engine you're using? Physics has a huge number of "gotchas", as I've encountered, and lately I've come to rely on an open source (recently released as such) engine with features I needed but could not reliably use elsewhere.
Another issue is workflow. Most game development ends up waiting on artwork, and the connectivity between various modeling tools and the engine is key to productivity.
Even as a learning exercise, I have to wonder how valuable it might be to learn from an older engine, and to what end. One direction, the one you're on, aims toward the creation of engines. The other is toward working games. If you're really focused on the latter, I'd seriously suggest you change directions for a modern engine. It is an entirely different experience.
Well you should probably take smaller bites before spending 4 years making your dream engine (knowing that everyone that tries without prioritizing making a game fails, and it is a flex of skill but you have to remember those graveyard videos on youtube tho...).
I think you will find using something like unreal engine way more worth it the second you start thinking of 3D models, networking (UE rep graphs are nice), physics, a map editor, and a community to help you if you have problems. Personally I think anything is possible in unreal engine, if I wanted to render a doom style gun on the screen, I could, or even make the engine not have that hyper realistic lighting system.
The one good reason for looking at engine books are the aspects that are beyond low level API code, like how AI, Game Rules, Managers, inputs, events fit in. But most importantly organization and "game feel" (IE: art+sound+design). I recommend taking the high level organization that you have found from the book you read, and scrap all the internals of the rendering, sound, networking, and windowing stuff with super basic SDL2 code and just learn how to make an 2D game (directX + win32 api can work too) and work on that for a month and polish everything other than the engine.
I don't recommend using vulkan or Directx12 or metal because they only add bloat, the more lines of code for equal functionality the less modern your code is (in my opinion). There aren't any notable features added other than performance, and my rule of thumb is that if you are too lazy to do laborious benchmarking to see that you are actually saving or loosing performance through your changes, all your effort for getting performance is worthless, and you might be adding bloat to a section of your code only to make it run 0.0000001 milliseconds faster for more lines of code. So just treat it as an upgrade when you need it (which you will never reach because you don't want to spend years studying on how to render a triangle the most efficient way possible, you want to make games!).
But for the __try thing, using goto is bad anyways, everything with a goto can be replaced either with normal flow logic or just create a bool to make it work.
I think you will find using something like unreal engine way more worth it the second you start thinking of 3D models, networking (UE rep graphs are nice), physics, a map editor, and a community to help you if you have problems. Personally I think anything is possible in unreal engine, if I wanted to render a doom style gun on the screen, I could, or even make the engine not have that hyper realistic lighting system.
The one good reason for looking at engine books are the aspects that are beyond low level API code, like how AI, Game Rules, Managers, inputs, events fit in. But most importantly organization and "game feel" (IE: art+sound+design). I recommend taking the high level organization that you have found from the book you read, and scrap all the internals of the rendering, sound, networking, and windowing stuff with super basic SDL2 code and just learn how to make an 2D game (directX + win32 api can work too) and work on that for a month and polish everything other than the engine.
I don't recommend using vulkan or Directx12 or metal because they only add bloat, the more lines of code for equal functionality the less modern your code is (in my opinion). There aren't any notable features added other than performance, and my rule of thumb is that if you are too lazy to do laborious benchmarking to see that you are actually saving or loosing performance through your changes, all your effort for getting performance is worthless, and you might be adding bloat to a section of your code only to make it run 0.0000001 milliseconds faster for more lines of code. So just treat it as an upgrade when you need it (which you will never reach because you don't want to spend years studying on how to render a triangle the most efficient way possible, you want to make games!).
But for the __try thing, using goto is bad anyways, everything with a goto can be replaced either with normal flow logic or just create a bool to make it work.
@Niccolo
great reply.
but I think you misunderstood me, I have chosen the book "game engine programming" not for the purpose of creating games, but to learn the architectue of game engines. I don't really care about the advanced rendering techniques, my goal is to create a basic but fully functionning game engine that I can use later to build a simple 3d game. All i need is a renderer that draws shaded triangles to tbe screen,
a strong networking system to process client server messages, a simple audio and input systems witch I have found in that book. About the physics engine, the book offers AABB and OBB collision detection, a gravity system and few more things witch suits my needs (yey).
I like the design and structure of the engine studied throught this book, for example how it cranks up the d3d functions, networking functions etc, and how it is seperated into 4 parts (renderer, network, audio, input) each interface is implemented in a dll file and then the application using the engine would load these dll files (not necesserally all of them) witch I think is a great design idea because it is based on encapsulation ( correct me if I'm wrong ).
Now once I build the engine offered by the book and understand every single line of code of it, I'll be ready to update the rendering and physics system, maybe the audio and input too and dive deeper into the new rendering technologies as you have mentioned.
About the error thing I found out that the author used visual studio .NET 2002 to build the math library witch seems to ignore the illegal jump error, and vs 6.0 to build the rest of the engine.
great reply.
but I think you misunderstood me, I have chosen the book "game engine programming" not for the purpose of creating games, but to learn the architectue of game engines. I don't really care about the advanced rendering techniques, my goal is to create a basic but fully functionning game engine that I can use later to build a simple 3d game. All i need is a renderer that draws shaded triangles to tbe screen,
a strong networking system to process client server messages, a simple audio and input systems witch I have found in that book. About the physics engine, the book offers AABB and OBB collision detection, a gravity system and few more things witch suits my needs (yey).
I like the design and structure of the engine studied throught this book, for example how it cranks up the d3d functions, networking functions etc, and how it is seperated into 4 parts (renderer, network, audio, input) each interface is implemented in a dll file and then the application using the engine would load these dll files (not necesserally all of them) witch I think is a great design idea because it is based on encapsulation ( correct me if I'm wrong ).
Now once I build the engine offered by the book and understand every single line of code of it, I'll be ready to update the rendering and physics system, maybe the audio and input too and dive deeper into the new rendering technologies as you have mentioned.
About the error thing I found out that the author used visual studio .NET 2002 to build the math library witch seems to ignore the illegal jump error, and vs 6.0 to build the rest of the engine.
Last edited on
Ok, so you're on the first path.
I'd suggest you consider looking at some of David Eberly's books on the subject.
They are almost exclusively from the mathmatical viewpoint on how rendering is performed, and plenty on physics. His "Wild Magic" engine is also on the 'net.
Eberly was actually a major contributor, a few years back, to some of the fundamental advancements in such graphics engine design.
There's a book by Ian Millington on the subject of physics engine design. You get just about the entire course material on the subject as a specialty. It is a discussion on the full physics pipeline as it was understood at the time of the writing. To go beyond that one must become familiar with the various discussion boards on the subject (like this, but for physics engine design).
What would you say is your math background? Trig, linear algebra, quaternion algebra, the calculus?
Of course, in engines these are handled through the math libraries, but one must understand the pieces to use them.
I'd suggest you consider looking at some of David Eberly's books on the subject.
They are almost exclusively from the mathmatical viewpoint on how rendering is performed, and plenty on physics. His "Wild Magic" engine is also on the 'net.
Eberly was actually a major contributor, a few years back, to some of the fundamental advancements in such graphics engine design.
There's a book by Ian Millington on the subject of physics engine design. You get just about the entire course material on the subject as a specialty. It is a discussion on the full physics pipeline as it was understood at the time of the writing. To go beyond that one must become familiar with the various discussion boards on the subject (like this, but for physics engine design).
What would you say is your math background? Trig, linear algebra, quaternion algebra, the calculus?
Of course, in engines these are handled through the math libraries, but one must understand the pieces to use them.
I would say that I feel comfortable coding 3d stuff, I have a deep understanding of 3d coordinate systems and vectors/matrix operations for 3d transformations and a lot more things. I required that knowledge while learning directx 11 through the book "Introduction to 3D game programming with DirectX 11" by Frank D Luna witch dedicated a full chapter to vector and matrix algebra and basically all the math stuff required for a 3D scene.
I will check the resources you have mentioned, thank you.
I will send you the sample game of the book I'm reading in private, and please tell me if it's worth is or not :)
I will check the resources you have mentioned, thank you.
I will send you the sample game of the book I'm reading in private, and please tell me if it's worth is or not :)
Topic archived. No new replies allowed.