C++, Graphics, Programming, Review, Vulkan

Review: Vulkan Graphics API: in 20 Minutes by Kenwright

Vulkan Graphics API: in 20 Minutes is short, no-nonsense, introduction to the Vulkan graphics API. Though the title of the book says “20 minutes,” I believe I spent somewhere between 1 and 2 hours to finish it (though I admittedly read pretty slow). This is the type of book I wish there were more of: something short and sweet as a brief  intro to get your feet wet. I feel many programming books can be daunting at 600+ pages, so it’s nice to find something you can complete in one or two sittings.

So what is actually covered in this little book? Basically it shows the basics of how to initialize the Vulkan renderer and draw a triangle on the screen. The author does not use any additional libraries, so it’s only showing the Vulkan API itself and some boilerplate Win32 code for opening a window. Though I had already been reading about Vulkan previously, and didn’t find any new material here, I could see this as a decent first step in learning the API.

To be honest,  Kenwright does not really provide any deep explanation of the concepts presented. It’s basically just showing some of the common function calls and the structure to set things up. You could easily find similar code online (at various sources) for displaying a triangle in Vulkan.  Even so, I still think the text holds value and may be more accessible than some of the larger (and more costly) Vulkan books that do provide more detail. This is sort of something that would be useful if you’ve really never worked with the API before and just want to see how the code looks and if it’s something you’re interested in prior to researching further.

All in all, I can’t really fault  Vulkan Graphics API: in 20 Minutes too much. While there were a couple typos and odd use of the English language, overall the book was concise and coherent. It provided a cursory look at a new, exciting, graphics API and it did with with a meager time and money investment on behalf of the reader. While you can find basically the same material online for free, I still personally enjoy learning from books and think the format may click for some people better. It only really scratches the surface, but as a short “first intro” book it’s not bad.

C++, Graphics, Math, Physics, Programming, Review

Review: Essential Mathematics for Games and Interactive Applications by James M. Van Verth and Lars M. Bishop

Essential Mathematics for Games and Interactive Applications by James M. Van Verth and Lars M. Bishop is a quality math book if I ever saw one.  Strangely, the first edition came out in 2004 but the book was kind of off my radar until recently.  This third edition was published in 2015 and seems very current. The authors here do a great job of explaining the material properly. I felt like they created a great foundation for learning these complex ideas and I appreciated the  quality and readability of the code  samples.

The book starts with an overview of computer number representations, and goes into detail with the IEEE 754 floating-point standard. At first I assumed this was unnecessary detail, but actually it’s pretty useful to understand and a good base to build on. They continue with vectors and points, linear transformations and matrices, affine transformations,  orientation (including matrices, Euler angles, axis-angle, and quaternions),  and interpolation (linear and curved). In the next section they transition to more graphic oriented topics such as: viewing and projection, geometry and programmable shading, lighting, rasterization, then a random chapter on… random numbers, and finish off with intersection testing  and rigid-body dynamics.

Just looking at the table of contents is sometimes not enough to get a feel for the quality of the text, so I will reveal  more. The beginning parts are really exactly what you’d expect for a game math book. The basics of vectors, matrices, quaternions, etc. are the bread and butter for a 3D programmer. The coverage here is solid and great for a beginner. Advanced readers  may not find any surprises, but it’s still a good refresher.  The interpolation chapter I found interesting, especially the detail into different types of curves and splines .  This could be immediately useful for coding  a skinned character or animating a camera in a game.  Viewing and projection were given adequate coverage and are essential to anyone wishing to code a graphics engine themselves.  The next chapter was particularly long and explained the programmable shader pipeline to great effect.  The authors explained everything from color representation, vertex attributes, drawing geometry, fixed-function versus programmable, vertex and fragment shaders (aka pixel shaders), and texture mapping. Really a great introduction for anyone wanting to learn to code shaders themselves.  Then they  move onto lighting and go into the basic types (point, spot, directional, and ambient), surface materials, per-vertex and per-fragment lighting, combining with textures, and a few small sections of more advanced topics like normal mapping, physically based lighting, HDR, and deferred shading.

Next up is rasterization, which was an awesome chapter that explained (in epic detail) how rasterizers work which I feel does help when you know what’s going on behind the scenes. I don’t know of many other books that explain this part of the pipeline so well, so this was much appreciated. The random number chapter was also quite informative. It’s easy to just call a function that spits out a number and not actually understand what’s happening.  I found this  portion of the book to be a nice surprise. Intersection testing was covered near the end, and  it was one of the longer chapters. Almost anything you could think of was here: finding distances from lines and points, sphere/ray/plane intersections, axis-aligned bounding boxes (AABBs), swept spheres, object-oriented boxes, triangle intersection, and a simple collision system. Finally the book closes with a chapter on rigid-body dynamics. I actually purchased my copy mostly for the rigid-body material and I felt I learned a few useful things. Of course, it was only one chapter but some of the explanation was better than whole books I’ve read on physics. Certainly it gave me a few things to research further, and I appreciate that.

Overall I would say that  Essential Mathematics for Games and Interactive Applications is an almost flawless textbook. I may be a great place to start for a beginner, and even intermediate to advanced readers may learn a thing or two. Some of the other game math books I recommend I read so long ago it’s hard to make a direct comparison. But this title is certainly up there with the best. I would wholeheartedly recommend.

C++, Math, Physics, Programming, Review

Review: Beginning Math and Physics for Game Programmers by Wendy Stahler

beginning_math_and_physics

Beginning Math and Physics for Game Programmers by Wendy Stahler is the kind of book I like. The title is straight-forward, and the content actually delivers what it claims. I’ve read a number of game development math books but I find that many of them expect a college level mathematics background, or at least some intermediate knowledge already. Not here. This is a book that is accessible to stark beginners, and I’d even recommend it to high school students.

Stahler’s text covers all the basics for both 3D math and physics. Topics include: points and lines, geometry, trigonometry, vector and matrix math, transformations, unit conversions, motion, Newton’s laws, energy and momentum, collisions, and, finally, rotational motion. Clocking in at around 500 pages, there is enough space to delve into each area with adequate coverage. I found the explanations to be very clear and geared to novices.  The author uses lines like: “The fancy name for moving objects in these directions is translation.” While advanced readers may feel somewhat patronized by the language, I actually think this is a great approach for beginners. 3D programming is not easy, but sometimes the arcane conventions used in more advanced books can be off-putting to people just getting started.

One thing I should note, I don’t typically test code samples or verify the accuracy of formulas while I’m progressing through the text. What I expect from the book is to gain a high-level conceptual understanding of the material in order to better grasp the subject matter. When it comes to the actual programming implementation, I will just use the book as a reference but usually find the formula online on Wikipedia or similar sites. I realize some people expect every code sample to work, but I’m not one of those people. It’s the concepts themselves that are important to learn and once you understand you should be able to know what to search for or even implement the code yourself.

One aspect I appreciated was that most of the concepts started with an explanation first in one dimension, then two, then three.  This was especially helpful as it’s conceptually simple to understand something like motion in only 1 dimension and it gradually builds upon that. Some other books jump straight into higher dimensions right off the bat, and that may be difficult to some without prior knowledge. The author also provides ample diagrams, graphs, charts and sample code. She also makes effort to show unit conversions when needed, and emphasizes differences between easily confused units.

Wendy Stahler’s book is, however, somewhat dated being originally published in 2004. While the core material is still relevant, and hasn’t really changed much in those years, some of the samples are written for antique computer systems. For example, for one demo included on the CD-ROM she recommends that the “minimum system requirements for the program are a 700MHz processor, a graphics card with 8MB of memory, and 64MB of RAM.” Those specs would have been laughable even in 2004, when the book originally came out. However, it is humbling to consider my smart-watch has specs that would put the machine those demos were build for to shame.

Overall I enjoyed the book, even with the caveat the nearly all the material was a refresher for me. If you are already a professional game developer, then there probably won’t be much to learn here. I’ve been kind of on a binge of game math and physics books, so I figured I’d give this a shot. I also like to have material to recommend to people new to game development and I find it interesting to read books of different levels to get a broader perspective. If you are just starting out, this may be a nice resource to get your feet wet before graduating to the more complex, but much better math books out there.

C++, Gaming, Review

Review: Programming Game AI By Example by Mat Buckland

ProgrammingAI

Programming Game AI By Example by Mat Buckland is one of those books that comes highly recommended and was one I had been meaning to read for a long time. In fact, I originally purchased the paperback in 2006 and never got around to reading it. The interesting part is that the book is still very much relevant today and is not dated in the least. Well now maybe some of the engines and middleware have this stuff built in, but the fundamentals I think I still important to understand.

The book starts with a quick primer on math and physics. The basics are explained, like Cartesian coordinates, trigonometry, vectors, coordinate spaces, and some physics. Like most people reading a book of this level, the beginning was a light refresher. However, I’m a big stickler for reading books from cover to cover with no skipping around, so I did not mind a short recap. Next Buckland gets into state-driven design and demonstrates a simple command-line app using the concepts. I found this approach successful, and it was able to show the concepts without complex 2D or 3D math getting in the way.

He followed up with autonomous moving agents, mostly based on steering behaviors. I was already somewhat familiar with steering behaviors, but I found the author’s description and code to be clear and concise and explained the concept better than I’ve seen before. He then applies the previous topics to a simple soccer game. This was a great next step, and really compiled the knowledge being taught into something concrete. In the next chapter, the author went into graphs; what they are, how to use them, and some popular algorithms link Dijkstra and A*. I always wanted to know what A* was, and this book explains it fairly well.

Buckland then devotes a section to cover scripting languages and why they are useful. In this case, he chose Lua (not a bad choice) and explains some basics about the language, how to interface it with C++, and creates a simple finite state machine. This chapter is helpful even if you’re not coding AI and just need a scripting language for your game or engine (provided you like Lua). In fact, a lot of the concepts in this book are generic enough that they can be applied to multiple fields of interest for game developers.

Next, the author creates a simple overhead game framework used in the subsequent examples. Using this framework he then shows practical path planning, goal driven agent behavior, and finishes up with fuzzy logic. Fuzzy logic is another one of those buzzwords that always intrigued me but I never really understood. Buckland concludes with a quite excellent explanation of the concept.

Overall I found this book to be stellar on all accounts. I feel that any game developer could gain insight from this text, even if they aren’t primarily working with AI programming. The scripting coverage could be used in many games, and the algorithms covered are generic enough to apply to different disciplines. While this is the first book I’ve read on AI, I really can’t imagine a better introduction. Highly recommended.

C++, Game Engine, Graphics, Review, Unreal

Review: Learning C++ by Creating Games with UE4 by William Sherif

LearningUnreal

Right here is a book with a clearly defined goal and an excellent execution. Learning C++ by Creating Games with UE4 by William Sherif takes you on a journey from being a total blank in C++ to coding some basic features of a 3D game. Even though I have been coding in C++ for years, I still enjoy reading novice level texts as sometimes they can teach you a new way of thinking about familiar problems. For me, it’s also important to have good book recommendations (especially for people starting out), and I actually discovered this book from a member of the Unreal Engine community looking for a review. So here it is.

William Sherif starts the book proper, with how to setup a project using either Visual Studio or XCode. This is actually a great design, and it’s thoughtful to include both operating systems (Linux is not officially supported by Epic yet, so I can’t knock the author on that one). When first starting with C++ programming, probably the hardest thing is not the syntax but understanding how to configure the project and settings in the IDE, so I like that this was covered first. Next Sherif moves onto the basics of programming: variables and memory (numbers and pointers), control flow (if, else, equality and comparison), looping (while and for loops), functions and macros, variable scoping, objects and classes, inheritance, and finishing up with dynamic memory allocation and arrays. Really quite a good foundation for learning C++. I found the explanation to be clear and concise, and the author did a good job of easing the reader into the information. C++ is a huge topic to cover, and there are volumes of text many times this size going deeper into the intricacies of the language. I wouldn’t actually fault the book for this, I think it’s a strength. Some novices may be overwhelmed by C++ if they start with something like Stroustrup’s 1,300 page tome. So I would say this is a great introduction to the language, and a great refresher if you’re coming back after a while.

The second half of the book is focused on Unreal development in particular. The author opens by discussing templates and containers in UE4, including some basic ones like TArray, TSet, TMap and then discussing the STL versions of these and how they differ in Unreal. He follows up with the first real example in the engine: an inventory system (with a UI) and the ability to pickup items in the world. I like this approach as it’s a real tangible task that many games would include. The author then shows how to code NPCs that are able to display a text message to the player. Next, Sherif talks about how to create monsters – basically enemy characters that can chase and attack the player. He closes with adding spell casting (including the code and setup of the particle system).

So this is not a book that will show you “How to Make a Complete AAA Game in 24 Hours” but I don’t think that was the intention. What the author does is introduce C++ at the right pace, and also show how to get started with applying that knowledge to developing games in Unreal 4. In some ways, it almost feels like two separate books: one on basic C++ programming, and another on coding in C++ for Unreal Engine 4. This is not necessarily a bad thing, and I think both parts are worthwhile. Really, this book would be most valuable to someone that has little experience with C++ and is also new to using C++ in UE4. If you are already a C++ pro, the first half of the book may seem too basic. However, I think the Unreal coverage can be useful to developers of varying skill levels.

Overall I enjoyed Learning C++ by Creating Games with UE4 and would entirely recommend it to anyone interested in gaining knowledge in C++ for Unreal. To be honest, this is one of the only books out there on the topic right now, so it sort of stands alone. I believe it’s taken me a little over a week to read the 342 page text. Certainly, it doesn’t cover everything you need to know (not even close) but it’s a great place to start. I’d also add that I read the book on the Kindle Fire HDX, and the formatting looked pretty good. The price on the e-book was also much more affordable, so now may be a good chance to upgrade if you’ve still been reading on ink and paper.

3D Engine, C++, DirectX, Game Engine, Graphics

Creating a 3D Game Engine (Part 25)

So it comes with great reluctance but I think I will have to suspend development on my 3D game engine, at least for the near future. Surely this will be a disappointment to anyone following the progress and I did not make the decision lightly. After spending some time thinking about it, I think it’s the right move. It’s just really hard to justify the amount of time and effort put into this when there are much better solutions available off-the-shelf.

In the little less than 2 years I’ve worked on this project, I think I have made decent strides. Honestly, I was not working on it full-time. Just on weekends mostly or maybe here and there when I had time after work. My initial goal was to have something functional in about 6 months to a year. It took a little longer, but I guess eventually I did have the basic features of an engine somewhat working. I will list what was implemented below, but it was enough to load in some textured models and fly a camera around. Not ground-breaking work by any means, but I built nearly everything myself so I was happy about that. There was just an enormous amount of work remaining to get to a state where a game could be produced. Finally, it was too much.

So before I give my personal advice, I’ll break down how I got to this point. First, let’s look at all the books I read as research for this project:

Game Engine Architecture – Jason Gregory
Game Coding Complete, Fourth Edition – Mike McShaffry
Real-Time Rendering, Third Edition – Tomas Akenine-Moller
Game Engine Design And Implementation – Alan Thorn
3D Game Engine Programming – Stefan Zerbst
Game Engine Gems, Volume One – Eric Lengyel
3D Game Engine Architecture – David H. Eberly
3D Game Engine Design –  David H. Eberly
3D Math Primer for Graphics and Game Development – Fletcher Dunn
Mathematics for 3D Game Programming and Computer Graphics, Third Edition – Eric Lengyel
Introduction to 3D Game Programming with DirectX 11 – Frank Luna
Practical Rendering and Computation with Direct3D 11 – Jason Zink
Beginning DirectX 11 Game Programming – Allen Sherrod
Game Programming Patterns – Robert Nystrom
Game Physics Engine Development – Ian Millington
Physics for Game Developers – David M Bourg
Physics for Game Programmers – Grant Palmer
Game Physics Pearls – Gino van den Bergen
Shadow Algorithms Data Miner – Andrew Woo
The C++ Programming Language, 4th Edition – Bjarne Stroustrup
C++ Primer (5th Edition) –  Stanley B. Lippman
C++ Primer Plus (6th Edition) – Stephen Prata
More Effective C++ – Scott Meyers

If you are considering engine development, please read on, but I believe all the above books are valuable to look at. I’ve also read a variety of sources online, from tutorials to official documentation and more. Looking at that list it seems huge, but I am an avid reader and have read and listened to a number of non-technical books in that time-span as well.

Next, let’s look at what features were actually implemented and working (or mostly working):

  • Win32 app template (message pump)
  • DirectX 11 based rendering engine
  • DirectInput mouse and keyboard controls
  • Custom math library (Vector, Point, Matrix, view/projection)
  • Node-based hierarchical scene graph
  • Frustum culling (sphere and point tests, minimal bounding sphere)
  • Generic XML parser (from scratch, kind of hacky and slow)
  • COLLADA importer (only basic vertex and UVs)
  • Custom binary 3D model format (for speed)
  • Camera object (spectator mode)
  • Texture mapping and Skybox (cube mapping)
  • Directional, ambient, and specular lighting
  • Normal and shadow mapping shaders
  • Command-line console window logging
  • Architectural glue and probably some odds-and-ends.

So what wasn’t finished? Way too much to list. I don’t want to get down on myself too hard, cause I think that I accomplished a little something here. Certainly some of this stuff was not easy and, if anything, it has made me a better coder. Even in the current state I guess you could make a Pong game or a simple walk-through demo or the like. Also keep in mind this was a part-time excursion. If I were dedicated to this fully it probably would only have taken months (not counting research time). While I started with a very clean style and deliberate design, by the end I was kind of hacking things together, and some features (like the shadow mapping) became very intertwined with the core rendering code. Of course, this was very much a learning experience, and I planned to go back and clean things up later (which may or may not ever happen, we’ll see).

OK, so by now you are probably getting the idea. As to my advice, if you are trying to make a game (or game-like interactive experience) don’t bother making a custom engine. Everyone basically told me this from the start, and I didn’t listen. It’s sort of like when you see people doing stunts on TV and they tell you “don’t do this at home.” But they did it, and it made them rich and famous. So maybe I was looking for glory, or hoping finishing a big project like this would take me to another level. I guess in a way it did. I’m just not sure that was the best use of my limited time. What I mean to say is that knowledge is valuable, and I feel I learned a lot. However, unless you are really looking to be an engine programming professional, there is not much reason to try to do this.

The crux of the matter is that all-in-one engines like Unity and Unreal are just too complex and mature to expect to compete with. That’s not to say a small team or a single hero-coder can’t produce something great. They can. However, using a pre-built engine cuts out a *lot* of time and risk. Had I been working on a project for a client, I would have never even contemplated a custom engine. It just doesn’t make sense. Both Unreal and Unity have huge teams of expert engineers working solely on engine development. Unless you work for a huge AAA studio with a monster budget, I just can’t see coming up with something better in any reasonable amount of time. Even some huge companies (like Capcom and Square-Enix) are dropping in-house engine development for Unreal 4. Not a good sign for indies or bedroom coders working on their own engines.

But let’s say those big engines aren’t for you. There are a number of open-source engines and libraries out there to help you along. Something like Torque or C4 look promising (if you want a full-featured solution), or OGRE (if you don’t mind having to cobble together a bunch of different libraries). If you are interested in web publishing there are things like three.js for WebGL. With source access you can add the features you need or fix critical bugs. Really there are too many options to ignore.

For the last few weeks I’ve been playing with Unreal Engine 4, and it basically does everything I need and a whole lot more. At $19/month and a small royalty (if you sell your title) making a AAA looking game has never been more affordable. Unity may still have a leg up on ease-of-use and scalability on different platforms, but for high-end development I think Unreal is probably the one to go with. Having the source-code is a huge boon, and the price makes it attainable to almost anyone. Plus, with the visual scripting, Unreal can even be approachable to artists and designers. I’m still in the early stages of getting acquainted with the engine, but so far I am pleasantly surprised. I plan to follow up with some posts and tutorials in UE4 in the future, so don’t think this is the end of my blogging career or anything of that sort.

With all that said, there are still some things I’d like to see in engines that don’t exist today. You typically can’t use the editor in stereo 3D (assuming the engine even supports 3D natively), motion control support for placing objects is non-existent, image and model editing is usually very rudimentary (you must switch back and forth to other apps), real-time code editing and previewing can be limited. So things can certainly improve, and I guess there could be a case made for making plugins or forks to existing projects. I’m not saying things can’t improve. Just that reinventing the wheel to make incremental improvements may not be the best path.

At this point I don’t think I would say engine development is a “waste of time.” As a learning experience, I think it was fun and rewarding. Certainly I hope I didn’t just waste 2 years of my life. Doing all the work and research has brought me here to this place. So it was somewhat worthwhile. It just pains me to think how far along I might have been had I jumped on Unreal 4 when they first announced the subscription model, or spent more time with Unity over the years. If you actually want to build (and finish) a game, it’s a pretty clear choice to use an off-the-shelf solution. I’m sorry, guys. I wanted to prove everyone wrong, but they were right. Make games, not engines.

Finally, I’m sure the question you’re thinking is “will I release the source.” I’m considering it, but there are some hacked bits in there and I’m not sure it’s a great example to work off of. More likely I will pull out portions or classes from the project and use them for future blog posts highlighting a particular algorithm or technique. The full source itself is probably less useful compared to other stuff that’s out there. In any case, I hope maybe you have learned something after 2 years and 25 posts on this project. If you click the (somewhat hidden) 3 white line icon on the top right of the blog, you can see a list of all the blog updates in this series for a little history (if you weren’t following the whole time). Cheers, and happy coding.

C++, Gaming, Review

Review: Game Programming Patterns by Robert Nystrom

Game Patterns

I will start by saying this book is game programming GOLD! Whether you are a pro or a novice looking to learn, this book deserves to place on your shelf (or I guess in memory if you buy the e-book). While some of the chapters may seem like obvious things for people that have programmed games before, I think even advanced coders will discover a few things they didn’t know.

So let me talk about what this book is. Basically it covers common challenges in game programming and some useful ways of resolving the problem. Though the theme of the book is game development, a lot of this stuff is applicable to any sort of visual or object-oriented programming. Nystrom starts by revisiting the classic design patterns popularized by the seminal book by the “gang of four” in 1994. Surprisingly, 20 years later a lot of those ideas still hold up. Next he moves onto more game specific topics like double buffering (not just for graphics), a game loop, and updating objects. Then he goes into bytecode (really a simple compiler), components, event queues, singletons, object pools, dirty flag and spatial partitioning. It’s actually not the longest book out there at 354 pages, but this is a breathe of fresh air after persevering through The C++ Programming Language (which was great, just very long). The author does not waste pages, though. There are nuggets of knowledge littered throughout the text.

One thing I like is how the book is not tied to a particular API or library. The pseudo-code is in C++, but really you could implement the ideas in almost any language. He even goes as far as not using the STL (for example, rolling his own linked list for a few examples). In a real application, you would probably not want to reinvent the wheel for basic containers, but it’s nice that the examples stand alone without any nasty dependencies. I could see a lot of the code here being copied into a real game and being usable with only minor additions. Well, of course you have to modify for your platform or engine or whatever, but the concepts are solid.

Another point is that this makes design patterns concrete (please, no abstract class jokes…). I read the original Design Patterns book years ago but some of the patterns never made sense to me. They were too abstract and, though interesting, sometimes didn’t click for me. This book, on the other hand, clicked the whole way through. Everything made sense, and was immediately clear why it was useful. Sure, I’ve probably learned a lot in the past few years, making Game Programming Patterns more approachable. But I think almost any game coder (or aspiring coder) could get value from this book. I’d give it 5 stars, 10 out of 10, 2 thumbs up, and definite “buy it now.”

C++, Review

Review: The C++ Programming Language by Bjarne Stroustrup

C ++ Programming

This book could be called “Everything You Ever Wanted to Ask About C++ and a Whole Bunch of Other Stuff You Had No Clue You Didn’t Know.” It really is the most comprehensive book I’ve seen on C++ and covers just about everything you will need to know (and maybe some more). That’s not surprising, as the book is some 1,300+ pages long. And, of course, it’s written by the creator of C++, so I would guess he knows a thing or two about the language.

The C++ Programming Language by Bjarne Stroustrup does cover all the major aspects of C++, but to name a few of the topics included: pointers and arrays, namespaces, classes, lambdas, overloading, copy and moving, templates (lots of templates), the STL, strings, regular expressions, concurrency, and the C standard library. It almost does a disservice to try to list all the topics, as it touches on almost all areas of the C++ language.  I found the code snippets to be useful and relevant, while still being short enough to be clear and understandable.

Keep in mind that this text has been updated to C++11 and the author does not bother teaching older standards. There are only a couple of instances when he mentions the difference but there is a chapter all the way at the end talking about some specific features that are different in each version of the language. This can be a good or bad thing depending on how you look at it. I mean, I think it was a good choice as the book would be twice as long and twice as confusing with constant clarification. But sometimes I was left wondering if a feature was new or if I just had never heard of it.

I’ll admit, I have actually not read earlier versions of this book, but I feel that Stroustrup has done a great job here. I would NOT recommend the book for beginners as I feel it is very technical and you might become afraid of C++ before even finishing the book. While the basic stuff about types and classes and all that are covered, the majority of the book is focused more on advanced features (templates, etc.). For intermediate to advanced programmers, this will be a great addition to the collection, and required reading to be an expert in C++. For novices I would recommend picking up C++ Primer or C++ Primer Plus (no relation).

One thing to note, this book is long. I think it may be the longest book I’ve ever read. Though I enjoyed it, there were points were I was doubting I would ever finish it. I would estimate it took around 2 months of daily reading to knock it out. If you wondered what I was doing since I haven’t updated the blog in a while, I was reading this. So before you embark on this adventure, make sure you’re fully prepared for what you are getting into. Recommended.

3D Engine, C++, DirectX, Game Engine, Graphics, Physics

Creating a 3D Game Engine (Part 24)


 

It’s been some time since the last 3D engine update, but I’m still sticking with it. Currently I am working on getting a physics engine implemented. The video you see above is the first glimpse of this custom physics engine. Obviously it’s ultra basic right now, but it’s a start. The algorithm is based on a verlet integrator, and the code is running using DirectCompute on the GPU.

To be honest, it’s pretty hacked together right now, and the bounds/bouncing behavior is hard-coded. But, hey, it’s something! I also tweaked the style of the demo to more closely align with other demos from researchers (and the clean flat-shaded style looks a bit more classy).

I’m planning on expanding this significantly, but still have a lot of work ahead of me. Though I’m still questioning whether GPGPU is the way to go with this, especially since there are 8-core CPUs available for consumers (and which I am running now). There is also added difficulty and limitations of DirectCompute rather than straight C++. But if there are big gains on the GPU obviously I would like to go that route. Definitely more testing to do here, but progress is being made. Stay tuned.

3D Engine, C++, DirectX, Game Engine

Creating a 3D Game Engine (Part 23)

engine_zero_08

While I implemented frustum culling a little while ago, I never actually coded a proper bounding volume. For the  bounding test I was using a sphere, but I just set the radius to some hard-coded value. This was fine when I just had a bunch of similar sized cubes on screen, however it broke apart once I started getting varied models imported. This week I decided to do something about it.

After a quick Google search for bounding spheres, I ended up on Wikipedia. There was some good information there regarding minimal bounding spheres (also known as smallest enclosing ball or minimal enclosing ball), and I was given a few options for different algorithms. After reading the whole page I become very interested in the “bouncing bubble” algorithm, especially due to the spiffy gif animation showing it in action. The brief explanation seemed easy to follow compared to the other methods, and the error percentage was only around 1-2% which is much lower than Ritter’s algorithm (which can be as high as 20%). So far so good.

Unfortunately I found next to nothing on the internet describing the method. What I did find is a post from last year on StackOverflow by someone in the same situation as me. This lead me to the original paper describing the method, which was for sale for $18 on Grin.com. Honestly I don’t mind paying the money for quality information if it’s going to help improve my engine. The article was fairly easy to follow, and provided just enough information to base the implementation on. At first I was disappointed that no source-code was given, but I managed to pull it together using the pseudo-code. All in all I think I spent about 4 hours on it (including research) so I’m happy to have got it working so quickly.

Below is my bouncing bubble implementation. Keep in mind I have not profiled this code, it’s possible it’s not fully optimized. However, I’m only doing the calculation when a 3D model is loaded, so it shouldn’t effect performance at all really.

BoundSphere RenderCore::calculateBoundSphere(vector<Vertex> vertices){
	Vector3D center = vertices[0].position;
	float radius = 0.0001f;
	Vector3D pos, diff;
	float len, alpha, alphaSq;
	vector<Vertex>::iterator it;
 
	for (int i = 0; i < 3; i++){
		for (it = vertices.begin(); it != vertices.end(); it++){
			pos = it->position;
			diff = pos - center;
			len = diff.length();
			if (len > radius){
				if (i < 2){
					alpha = len / radius;
					alphaSq = alpha * alpha;
					radius = 0.5f * (alpha + 1 / alpha) * radius;
					center = 0.5f * ((1 + 1 / alphaSq) * center + (1 - 1 / alphaSq) * pos);
				} else {
					radius = (radius + len) / 2.0f;
					center = center + ((len - radius) / len * diff);
				}
			}
		}
	}
 
	return BoundSphere(center, radius);
}

Also, I should remind myself to do benchmarks more often. After I added all the normal mapping and shadow stuff performance has taken a big it. Before I was getting likely over 2400fps, now I’m only getting around 1600fps. Still acceptable, but maybe could be better with such a simple scene. The culling definitely helps, but I may have to look into other optimizations like batching and instancing if I want to get the speeds I need for my project. I’ll probably get started with the physics engine aspect soon and then optimize later if I can’t meet my 120fps target. Cheers.