Jump to content

  • Log In with Google      Sign In   
  • Create Account

Calling all IT Pros from Canada and Australia.. we need your help! Support our site by taking a quick sponsored surveyand win a chance at a $50 Amazon gift card. Click here to get started!

Josh Petrie

Member Since 11 Jun 2003
Offline Last Active Private

Posts I've Made

In Topic: First game engine

28 August 2015 - 09:38 AM

Where do i start?



First, you give up the idea that you need to -- or should -- make a "game engine." It's a waste of your time. You don't need an engine to make a game, and given your documented level of experience you aren't capable of making one that measures up to your own standards yet anyway, because you know almost nothing about what goes into game development or game engines.


You need to learn that. Which means you just need to worry about making your game.


What design do i need to do in paper? Diagrams and such.



You don't need to do anything on paper, although you can if it helps you refine your ideas.



What does a game engine need to work? What are the main classes i will need?



That depends on what kind of game engine it is, and what its goals are. It's also not something you need to think about right now.


After I have built the basics to run the game how do I improve from there?



As you're building something, you'll come across problems you have to solve in ways that you're not super thrilled out, that you think could be solved better but which you're currently prevented from solving better by some other issue or architectural decision you've already made. Some of these you'll solve immediately. Others you'll put off. When you're "done," you can maybe consider going back to revisit the issues you've put off.



The "basics" of C++ is probably not enough to jump immediately into creating your own 2D game with OpenGL. Generally I'd recommend starting with text-mode, console-based games first, to flesh out your ability with the language and to practice some common game development idioms and techniques. Can you write a text-mode guess-the-number game? What about blackjack? Or hangman? What about a text adventure game like Zork?


If you feel comfortable tackling tasks like that you should try moving on to windowing and graphics using GLFW or the like, perhaps recreating Pong or Tetris. 


As you do this you'll have multiple projects under your belt, wherein you learned (hopefully) at least one new skill. As you complete each project you can look back at your code at the things you feel you'd reuse for your next project and you carry that code forward. Eventually, do this enough times, and that's your own basis for your own game engine.


You also should disabuse yourself of the goal to "do everything yourself" sooner rather than later. Within practical limits you are always going to be using libraries and software that other people have written for you, and you can still understand how those libraries work without having to build them yourself anyway. In fact, you're rather likely to create a disaster if you just trying to build everything yourself from scratch, because you're assuming you're going to be able invent all the same technologies that we as a collective industry have spent years building and refining. And the chance of that is rather small.


Instead, try to look at the decision like this: if you're talking about a component of your project that is unique and critical to the business success of your project, that's usually a good case for building a thing yourself. Things like gameplay mechanisms you'd like to show off, or maybe an incredibly novel method of non-photorealistic rendering, or whatnot. Things that do not constitute unique selling factors of your project you should consider "buying" (using existing implementations of, even if free). This frees up your time to focus on the unique aspects of your project that will make it shine, and decreases the risk that, for example, your crash reporting or analytics code will fail spectacularly because you made a rookie mistake instead of using a battle-tested off-the-shelf solution.


The exception would be, perhaps, things you want to be able to do unique and interesting work in but can't yet. For example, if your goal is to be an amazing graphics programmer who builds all kinds of awesome new rendering techniques or whatever, then pretty soon after you learn how the basic graphics pipeline works (by using an existing rendering API), you'll want to start tinkering on your own to develop your skills and knowledge. But if you're not interesting in pushing graphical boundaries, there's not as compelling a reason to be writing your own low-level D3D12 code to move a few hundred sprites around (for example).

In Topic: How I think game design should work

24 August 2015 - 08:00 PM

I'm not going to immediately close this thread, even though I don't see any evidence so far that this discussion is going to be any more productive than the last one. LouisZ's original account remains unbanned, and he's welcome to participate -- constructively -- in what is left of this thread. 


If it gets non-constructive, I'll close it.

In Topic: Why is this PC going slow?

21 August 2015 - 01:07 PM

1. I'm not being offensive. There's a difference between being offensive and being honest.


You are absolutely being offensive. I've already warned you privately about it, but now I'm warning you publicly. Telling somebody to "fuck off" is rude and has an extremely high degree of likelihood to offend them and others. It is nowhere near the civility bar we expect from our members.
Don't do it again.

In Topic: I love assimp but the animation part is a pain - anyone got it working with D...

19 August 2015 - 03:08 PM

Moved to graphics programming.

In Topic: Code Review

17 August 2015 - 02:17 PM

Starting in BinPacker.h.

  • Identifiers beginning with an underscore followed by a capital letter are reserved in all scopes (i.e., don't use _FOO_..." header guards).
  • BinRect inheriting Rect seems is an abuse of inheritance as code-reuse; why not just contain a rectangle instead (same with BinNode, later).
  • What is 'rotated," why is it a uint8_t that you XOR 1 into and check for > 0? Is this just a "clever" boolean? If so, use a boolean, if not then this is precisely the kind of weirdness a comment should explain somewhere.
  • You don't need to check for null before deleting a pointer; deleting a null pointer is safe and defined.
  • Unclear why CompareBinRects needs to be a template since you demand they're both of the same type anyway.
  • Similarly, I'm not sure why BinPacker needs a template argument. I'm starting to get real worried about the subclasses of BinRect I'm going to find, as that virtual CanPack() on it suggests bad things.
  • Why does BinPacker store pointers to rectangles, which you delete in the constructor? In Add you simply copy them; this looks like sloppy ownership management that can lead to double-delete bugs and other pointer tomfoolery. Unclear that pointers are necessary here at all, especially since you already have compile-time polymorphism via the template parameter *and* not much of BinRect is actually virtual.
  • "Force" is a verb. "ForceSquare" sounds like it might actually change the packing to demand everything is square, but it doesn't, it just sets a state that is presumably read later. This is not the most clear name.
  • If indices can't be negative (looking at Remove), why are they even signed values?
  • If an index is out of range, that's an error. Treat it like one. By quietly forcing the index to be in range instead, you are potentially hiding bugs in calling code that is not dealing with the index range properly, which means in the face of such a bug you or your team will spend longer trying to track it down. Assert or throw an exception or return a failure code.
  • Don't print to stdout in utility code. Throw an exception or return an error code.
  • If a null rectangle pointer is invalid, prevent a null rectangle pointer from being added to the list in Add (or better yet, don't take pointers here at all). Checking during Commit is wasteful and lets bad data or bugs manifest further from their origin.
  • CompareBinRects is used internally; if it has no external utility, don't expose it as part of your public interface.
  • That root BinNode is allocated, used to call a method, and deleted. It doesn't need to be on the heap at all.
  • GetNumPackedRects is too long to write on a single line. And it looks like it always returns 0 in a very complicated fashion.


Moving to BinPacker.cpp:

  • Mainly more of the same critique, especially concerning writing to stdout for "errors." 



  • Consider different names for the Ortho overrides, as they take slightly different parameters and it's not going to be exceedingly obvious which is which at any given call site.
  • The matrix class itself provides no hint as to its storage conventions, et cetera (column major, row major). It offers almost nothign over a bare array of 16 floats.


  • Ah, here we go, a BinRect subclass. So this looks very much like conflating responsibilities and violating SRP all over the place. BinRect has a virtual CanPack just so SpriteBinRect can check a texture? Why does a texture matter? A rectangle packer packs rectangles. That some of those rectangles may be associated with textures is irrelevant and unneccessarily couples otherwise generic code to that concept.
  • The result of texture != 0 is itself a boolean; there is no need for the subsequent use of the ternary operator to simply select true or false.
  • Somewhat excessive passing of std::string by value.
  • SpritePacker as a subclass of BinPacker has the same problems as above (for SpriteBinRect).



  • INPLACESWAP is a "clever" trick and not a good idea (especially when trying to swap the same things). Also, why the sudden capitals?
  • Consider moving the definition of the vertex/pixel shader code to some static constant area.
  • I'm going to skip the rest of this file as it seems to mostly be graphics stuff.



  • The assignment operator should usually be T& operator=(const T& other); yours (in your color structures) copy excessively.


I skipped anything that looked like Qt code, because meh.


Most of the above is not too bad, the biggest problems I would say are the way you use run- and compile-time polymorphism, the way you deal with ownership, and the apparent consideration you put in to the shape and surface area of your APIs. Those three things, especially together, do suggest a certain amount of inexperience. I still think the nature of the demo was probably more problematic for your getting the job than the specifics of the code. How much the specifics of the code matters is really up to the individuals reading the code; some people will be more picky than I am (even I would be more picky in an actual interview scenario, versus scanning this on my lunch break), but some would be less and only look at the algorithmic details. 


That said, I hope you'll find my comments informative.