Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!

1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


Member Since 13 Sep 2012
Online Last Active Today, 09:30 AM

#5241214 OOP design question

Posted by DishSoap on 18 July 2015 - 09:39 AM

Hi there!


So I don't dislike the inheritance scheme or necessarily have anything against that design. For me, and what I've seen in the past is to treat a projectile just like a chunk of data and have a separate modules handle the simulation of projectiles. I guess something like below is how i'd do it:

struct Projectile
  unsigned int id;
  unsigned int type; // <- maybe?

  float speed;
  float size;
  // ... Plenty of other things ... //

  bool flags;

In some sort of simulation module or class.

for (auto proj : projectiles)
  if (proj.flags & LINEAR)

  // Do specific simulation things here

  if (proj.flags & PROJ_HOMING)

  // etc ...

  // etc ...

You can achieve the same exact thing by giving the projectile knowledge on how to simulate itself via an update function and have it inherit from some sort of base class. I guess what's nice about above is you can easily mix and match different behaviors and to create a new projectile often doesn't take any new code but rather different data. 


As an example. Say you had a rocket projectile class that had its inheritance scheme and also had an acid spray projectile, or something. Now you want to create a new rocket acid spray projectile shot. Well it's possible in the inheritance scheme but you'd probably make a new sub class for it. If you treat the projectile like data you could just create a projectile and set the flags for both rocket and acid spray. Obviously, in practice, it may not always be so simple but that's the idea.


As for selecting items. I'd just give projectiles an ID or type and check on that for knowing what you have selected. 


I'm sure there's lot of right designs for this problem. This is how I'd approach it though.

#5240068 Unity or C++?

Posted by DishSoap on 13 July 2015 - 08:09 AM

Hi there!


If you would like to make a 2D game using C++ I would recommend SDL, https://www.libsdl.org/index.php or SFML http://www.sfml-dev.org/. I have not used them in a while but I believe the biggest difference between choosing one of the two is the style of the API. SDL has a C api so it does not use C++ features you might be used to like classes. SFML on the other hand has a nice class based abstraction.


If you want to make a 2D game in Unity it's completely possible as well. I think it comes down to preference, really. Unity is a great engine for building games and you will learn a ton no matter which route you go down.


As for job opportunities. In my experience, in interviews for game companies you will likely be tested on lower level knowledge. Often ideas independent of languages(the graphics pipeline, graphics theory, math, algorithms and data structures). These are things you will learn bits and pieces of no matter what tools you use. It's just a consequence of making a game. Having said that, most game companies I have seen would like you to have experience with C++, whether they use Unity or not. So I think it would be a greater benefit to know C++, if your primary goal right now is to get a job. 


In my opinion, if you are new to game creation, you shouldn't worry about it. Just worry about making games whichever way makes the most sense to you and the job will come in time.

#5237487 Lineup of Books For Beginner

Posted by DishSoap on 29 June 2015 - 08:23 AM

I have read bits and pieces of Real Time Rendering, for me it has been more of a reference when I am implementing my own collision detection than reading it from start to finish. It is a really great book from what I've seen though so I don't want to deter you from reading it start to finish, just my two cents.


I'd add a 3D mathematics book to that list. I was pleasantly surprised on the value I got from diving into some mathematics when doing things like matrix transformations, vector math and lighting, what not. The book I have read on the subject is: Mathematics for 3D Game Programming and Computer Graphics, Third Edition by Eric Lengyel. 


I'd agree with braindigitalis in that the best thing you can do is just build a game or something involving graphics in parallel with the books. It's important to practice the concepts on your own. In a book I have been reading, Computer Graphics Principles and Practice the author encourages a "3 step approach" to learning a subject, that is application-theory-application, or something similar. So try something before you seek a more theoretical understanding of it and then apply it again. It will give you a better understanding of the subject that way I think. So implement some game or some bits and knobs to an engine in your mind, go read about it and do it again. smile.png

#5195414 Unity or C++?

Posted by DishSoap on 29 November 2014 - 05:49 PM

I guess my only advice would be to use what feels right and put people's presumptuous comments aside. If you feel like you are learning and are inspired to build your game with whatever technology you pick up you are doing good.




More importantly, should I be focusing on making games with "pure" code, in other words building my own engine/physics? I'm torn here. I'm halfway through the game in Unity, but I'm not sure if it's what I want to be doing.


So there are tons of aspects to game development, if you are interested in coding physics or graphics do that. If you are interested in coding the logic or AI for your game, do that instead. Pure code is an interesting bit of vocabulary, to me if you are writing C# or Javascript or whatever Unity uses for scripting you are building pure code.


There is no right or wrong answer when it comes to what tool you should learn. If you're halfway through a game in unity finish it! Independent of platform and tools, It is awesome to be able to finish a game and say it's done.

#5195136 Critique My Implementation Of Pong?

Posted by DishSoap on 28 November 2014 - 03:49 AM

This all really good stuff guys. thank you for your time.


Hrm, I am also going to critique your file structure while trying to not change your design decisions too much:


  • You have non-game specific code in your pong implementation please separate 'engine' code out into it's own module or library
  • Separate your header and source files into different folders (include and source)
  • Remove dlls from your source folders and put them in their own external library folder
  • Shader, material, texture and other resources should be in their own resources folder
  • A Paddle shouldn't handle it's input, take that out into a PaddleController class so you can easily add AI to your paddle.
  • Remove boiler plate code from main and turn it into a Game class, inherit from that when making Pong
  • Remove all magic number values from code and put them in json or xml files that describe things like game specific data (Paddle initial positions) and engine data (window size, title etc)

Once you do this a better critique can be done.


I worked on a lot of these points tonight, It's almost ready to push. My next push, hopefully tomorrow, will be a complete reorganization of file structure, I have refactored engine code into a new project and made subdirectories include/src in both the pong and engine projects.  


The PaddleController/Game Class and file based values will definitely get my attention after my next commit. These are all really good points I should have considered from the beginning. I will need to find a decent JSON library for c++ or wrap a simple config reader into the engine. Anything is better than my magic numbers.



Seems good to me, maybe a little straight to the point: you have lots of gl* calls in various files, when them probably stay better in a single "glwrapper" thing, and the same for glfw calls (input!).

Functional, but a bigger project will deserves a bit of refactor.

Good job anyway!


Thanks! I will definitely look into a wrapper for a lot of my gl/glfw code. 

#5195053 Critique My Implementation Of Pong?

Posted by DishSoap on 27 November 2014 - 04:09 PM

Hi everyone!


I am a semi-experienced programmer but a very novice game programmer. To learn I have been building a simple implementation of pong, after it is done I plan to move onto some other simple game implementation. I was wondering if anyone wanted to critique my work? I realize it is probably very bad, so don't worry about hurting my feelings :). My hope is to build a few simple game implementations and replace piece by piece the OpenGL wrapper and math library I am using so I can learn more about those subjects. I just wanted to hear some thoughts from some of you guys.




All the source is in Pong3D/*. If you follow the readme you can run it if you so desire. The Visual Studio files are included in the repo. Game rules/score tracking have not been implemented yet. Just simple back and forth super exhilarating pong action!


Thanks and Happy Thanksgiving(to those who celebrate)

#5115372 Type of game for a newbie?

Posted by DishSoap on 08 December 2013 - 08:58 AM

If by mastering the basic games you mean you have developed a couple of the games mentioned above then I don't see why not. A top down rpg or some creative twist on 2D rpgs wouldn't be too far off. 


If you don't have much experience now and are wanting to learn C++, while building a game, find yourself a good book or reference for C++ and program a text based rpg or text based adventure game. That may not sound too interesting but I think you will learn that they are a lot of fun to create. You will be amazed at how much you learn about a language from coding that style of game as well. 

#5115266 Type of game for a newbie?

Posted by DishSoap on 07 December 2013 - 09:42 PM


I didn't answer the first part of your question so here that part goes... I would focus on creating easy clones for a while, pong, space invaders or asteroids are all excellent choices. After that you can move on to games a big larger in scale, perhaps a simple platformer or a puzzle game. The idea is to start small in scope and progress onto larger and larger projects, you can't learn to run before you can walk! Programming is the same way.



It all depends on your preference and what you know and want to learn. Is there a certain language you want to learn or one you know already?

I don't believe those aspects to be terribly important, but if your goal is to eventually program a game using technology X and Y it would be best to recommend some APIs and languages that would eventually guide you there.


I personally started game development with C# and XNA, a lot of people around here might suggest using something more current, but for a beginner I think you could still learn a ton really quickly using a XNA or MonoGame with C#.


If you know any C++ you could use a graphics library such as SFML or SDL for graphics.


There are plenty of game engines out there these days too, while I haven't personally used it, plenty of people use Unity to great effect. 


The possibilities are nearly endless smile.png. Is there a certain direction you were leaning?

#5113269 Is using static variables for input engine evil?

Posted by DishSoap on 30 November 2013 - 09:24 AM

At first, I would pass the input engine over to objects that need it, for example the Player. Every time I create a player, i would pass the input engine over to it, like this: player1->inputEngine = inputEngine;

You have bigger issues than the use of statics.People think of input as events because in event-based applications they are.Games are not event-based (there are of course events in games etc., but they are not event-based like applications are), and input in games is not an event.You don’t press a key and then directly send that to a character and make it jump.You collect input events into a queue and then the game manager reads them on each cycle, and then at a specific point inside the game loop you handle inputs and the jumping of the character. Additionally, letting the player character handle its own input is flawed; the character then needs to know more about its surroundings then it otherwise should. For example, if the character is in the air it should not be able to jump again. Now the character class needs to know about the physics engine to get information as to whether or not it is on the ground to decide if jumping is possible.The character is a slave to the physics engine, not the other way around. Note of course that that does not mean the physics engine knows what a character is, it just understands certain properties that the character has and a higher-level class (such as the engine itself) gets just that data from the character class and feeds it to the physics engine.Handling input is done at a much higher level than at the character’s level. The higher-level game class knows what characters are and what physics is and what the game rules are (hence it is the game class). I want to reiterate, the game class knows what the game rules are. The game class decides if the character is able to jump in its current situation and it is what contacts the physics engine and possibly other modules (maybe the player can’t jump while a certain light is on or when a sound is playing) before deciding, “Okay, you can jump.”With your proposed design, the character class would be absolutely monolithic, knowing about the physics engine, world lights, and sound engine, when really all it needs to be is a normal game entity with a health bar.L. Spiro

This is a really good way of handling input.

I will be implementing this from now on in my own games. Thank you.

#5111711 Help with multiple shapes/sprites (SFML)

Posted by DishSoap on 24 November 2013 - 07:17 PM


Hi, ive been able to draw as many shapes as i desire using a vector, the problem is im unsure of how to interact with them individually.



To answer this directly. You have a couple of options. You can interact with each RectangleShape within the vector by doing what you are doing in the bricks loop:

vector<sf::RectangleShape> bricks(10, sf::RectangleShape(Square));


Alternatively you can host a vector of pointers to RectangleShapes

vector<sf::RectangleShape*> bricks;

RectangleShape some_shape = sf::RectangleShape();


some_shape.setPosition(40, 40); // now bricks[0].position == (40, 40)

To address your code example explicitly, I don't think storing a bunch of drawables in a "bricks" array in this case, or many cases, is necessary. For instance, it may be better to maintain some sort of Player object or Enemy object that stores an sf::IntRect or something similar. With that IntRect you can use the intersects() method to more easily detect collision, or in the case you mention, you can detect when  enemy.collision_rect.intersects(screen_bounds), or conversely, when it does not. This way you can have a vector filled with enemies, or entities and loop through and update their screen positions.

// Say an Enemy object has the members
class Enemy
    void update(); // updates position and updates bounds based on that
    sf::IntRect bounds;
    sf::Vector2f position;

// Elsewhere you can maintain some list of enemies

std::vector<Enemy> enemies;

// add enemies



// Iterate through them and update their position and bounds

for(std::vector<Enemy>::iterator itr=enemies.begin(); itr!=enemies.end(); itr++)
    itr->update(); // move each enemy 
    if(!itr->bounds.intersects(screen_bounds)) // check if off screen
        itr = enemies.erase(itr);              // if so, delete

// Then you can check the size of enemies and add new ones if needed

if(enemies.size != 5)
    // add new enemies

// Finally draw rects by translating one rectangle to the enemies positions
sf::RectangleShape draw_me;
for(auto& e : enemies)

I'm not sure I hit all the points in your post, but I tried to hit a few here! Let me know if any of this helps.


Within the code example I purposely used two other ways of iterating through a vector(since you already showed your knowledge of stepping through based on the vector.size()). 

#5108323 How to rotate an object around a fixed point at a particular radius?

Posted by DishSoap on 10 November 2013 - 12:59 PM

You can move your objects center of rotation by first translating before rotating.


So if you want to rotate about point p.


1. Translate your object to p

2. Do your rotation

3. Translate your object somewhere else


Good luck!

#5068017 Position shadow based of lighting

Posted by DishSoap on 07 June 2013 - 08:28 AM

You could perhaps treat the light as a seperate eye from the viewer. Give it a viewing frustum that represents the area lit by that point light.


Detect which triangles are not in view within the frustum of the light and which are in view of the viewer, cast those in shadow.

#5066981 Position shadow based of lighting

Posted by DishSoap on 02 June 2013 - 07:35 PM

So I researched this a little bit. Looks like you need the plane that represents the ground and a vector representing the light position and run it through this function:


/* Create a matrix that will project the desired shadow. */
shadowMatrix(GLfloat shadowMat[4][4],GLfloat groundplane[4], GLfloat lightpos[4])
  GLfloat dot;

  /* Find dot product between light position vector and ground plane normal. */
  dot = groundplane[X] * lightpos[X] +
    groundplane[Y] * lightpos[Y] +
    groundplane[Z] * lightpos[Z] +
    groundplane[W] * lightpos[W];

  shadowMat[0][0] = dot - lightpos[X] * groundplane[X];
  shadowMat[1][0] = 0.f - lightpos[X] * groundplane[Y];
  shadowMat[2][0] = 0.f - lightpos[X] * groundplane[Z];
  shadowMat[3][0] = 0.f - lightpos[X] * groundplane[W];

  shadowMat[X][1] = 0.f - lightpos[Y] * groundplane[X];
  shadowMat[1][1] = dot - lightpos[Y] * groundplane[Y];
  shadowMat[2][1] = 0.f - lightpos[Y] * groundplane[Z];
  shadowMat[3][1] = 0.f - lightpos[Y] * groundplane[W];

  shadowMat[X][2] = 0.f - lightpos[Z] * groundplane[X];
  shadowMat[1][2] = 0.f - lightpos[Z] * groundplane[Y];
  shadowMat[2][2] = dot - lightpos[Z] * groundplane[Z];
  shadowMat[3][2] = 0.f - lightpos[Z] * groundplane[W];

  shadowMat[X][3] = 0.f - lightpos[W] * groundplane[X];
  shadowMat[1][3] = 0.f - lightpos[W] * groundplane[Y];
  shadowMat[2][3] = 0.f - lightpos[W] * groundplane[Z];
  shadowMat[3][3] = dot - lightpos[W] * groundplane[W];


Push your matrix then multiply by the shadowMat and try drawing. Let me know how that works.


I found this info from:



#5066702 Code Review - Pong clone..

Posted by DishSoap on 01 June 2013 - 12:03 PM

I can't do a full code review, I don't think I am qualified to do that. ^^


But as a few suggestions.


1. SFML's rectangle(as do most graphics API's) have functions 'contains' or 'intersects.' I'd always use one of those functions rather than reinventing a bounding box collision.


2. Personally I like to create my own Vector class so I can remove coupling between graphics and physics as much possible. Since your graphics api, SFML, provides you with sf::vector I'd make your own for the physics. This way you can override basic operations like addition, subtraction and equals with C++. Also you can also write the normalize, mag, and other vector operations in that class rather than putting them in CBall.


3. Totally preference. But when I create my headers I go by this order. Public functions/variables -> private functions/variables. You have it the other way around. I like the most general, class defining functions to be at the top and the details(private variables/functions) to be at the bottom. Simply makes it more readable and maintainable in larger projects, for me.


Other than that, it seems well engineered to me for a simple game ^^. Easily readable and logical. GJ!

#4980424 screwed up movement angles

Posted by DishSoap on 15 September 2012 - 10:57 AM

How exactly are you calculating ry? I don't really see anything wrong with your math so I'm not quite sure what is causing the 45 degree discrepancy, so it may be that. I use this quick method to calculate the direction of my camera.

[source lang="cpp"] horizontalAngle += mouseSpeed * float(ScreenWidth / 2 - xpos ); verticalAngle += mouseSpeed * float(ScreenHeight / 2 - ypos ); [/source]

Where mouseSpeed is some small floating point number(something like .005f) and xpos and ypos is your mouses x and y coordinates (Note: In this example my X axis is right to left and my Y axis is up and down. Judging from your vel.x and vel.z calculations your Z axis appears to be up and down while your Y is right to left). Then to calculate direction just use your found angles to convert from spherical coordinates to Cartesian as you do.

[source lang="cpp"]vec3 direction( cos(verticalAngle) * sin(horizontalAngle), // X-Axis left to right sin(verticalAngle), // Y-Axis up and down cos(verticalAngle) * cos(horizontalAngle) // Z-Axis in and out of screen);[/source]

You can restrict any look directions as you see fit.

Then when moving the camera you can just use position += direction*deltatime*speed and position -= direction*deltatime*speed or something similar to move forward and backward. So when you make your view matrix you can just add your direction vector to your position vector to find your "look at" vector. I hope that helped!