Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 10 Jun 2011
Offline Last Active Yesterday, 11:43 PM

#5311792 Bullet Collision

Posted by on 21 September 2016 - 11:08 AM

Essentially, it involves throwing a block, and the player teleports wherever it lands.   I have an ObjectId enum which stores my objects for the game. So far, I have a Block, Player, and Bullet (which is the thing you throw in the game) enum. Every new block/bullet that's created is passed its respective enum in its parameter. I use this tag to reference the objects.


Sorry but I'm a bit confused. Do you throw a bullet or a block?

Or do you mean you throw a bullet, that lands on a block, and then the player teleports to that block?


Either way, you need to reduce the number of objects you test for collision.


Physics/Collision libs usually have two phases for testing collisions: the broad phase and the narrow phase.


The broad phase is responsible for finding object pairs that are potentially colliding, and discarding the ones that are not.

This phase usually uses some form of spatial subdivision for the world (quadtrees, octrees, etc) and also tests for potential collisions between objects by using simple bounding volumes (like AABBs or OBBs) instead of the actual object's collision model (which can be much more expensive to test).


The narrow phase is where you check if two objects are actually colliding, using their actual bounding volumes (like you are doing in your code).


Summing it up, the broad phase very quickly and roughly discards non colliding object pairs, and the narrow phase performs the actual test to see if two objects are colliding.


This is much better explained in this article, that I came across a while ago.

It is a 3 part article that also contains physics and constraints, so give it a read if you're interested.


Anyway, hope it helps.

#5309592 Vulkan or OpenGL ES or OpenGL

Posted by on 05 September 2016 - 09:53 PM

Well, first of all OpenGL and openGL ES are pretty much the same thing, with the exception that OpenGL ES is targeted at mobile devices (ES stands for Embedded Systems).


Now for choosing between OpenGL and Vulkan.


OpenGL is very popular,and has been around for a long time now, so you won't have much of a problem finding resources about how to use it.


Vulkan however, if I may put it this way, is the future of OpenGL (and, perhaps, of graphics API in general).

This means, however, that it not only has fewer resources available (since it is pretty recent), but also that it is harder to program, because, unlike other APIs (OpenGL or DirectX), you have (mostly) full responsability of ensuring that everything works correctly (whereas other APIs are more lenient, in that they will not only manage graphics memory for you, but also ensure that your graphics card never crashes your application, etc).


I like to think of the difference between the two as somewhat like a managed language (say, C#) and C++.

C++ will allow you to do pretty much anything you want, even if it is detrimental/dangerous/etc to your application, whereas C# (or other similar managed languages) will be safer to program in, at the expense of limiting what you can do.


So, in my opinion, I'd advise you to learn OpenGL first, again, mainly because it has the most resources available, and also because it is the easier of the two to learn.


Do note that, regardless of what API you choose, most of the things you'll learn will still apply to the other APIs, so it's not time wasted by any means.


Now for resources.


For Vulkan, right here on GameDev you have a topic about Vulkan resources. You can find it here.

There's also a pretty nice article, also right here on GameDev. You can find it here.


For OpenGL, here's a few:






And of course, you can find many helpful stuff right here on GameDev, both in the forums and in the articles section.

You can also find tons of OpenGL tutorials on Google, so if you get a bit more curious, try it. These are a nice start though.


Well, as a last thing, though somewhat unrelated to your question, there's this.

GPU Gems are books that were published back in the day, and are now free to read on NVIDIAs website. 

I know that it doesn't quite relate to your question about APIs (or OpenGL/Vulkan specifically, for that matter), but I just thought I'd share it, because it contains many awesome techniques/stuff about graphics rendering, many of them used in actual commercial games.

Even if you won't need it for your project, it's always a nice read, and a good way to learn about rendering in general (and not-so-general) so, if you get curious, give it a try.


Hope it helps.

#5309400 How to design my collision code properly?

Posted by on 04 September 2016 - 10:47 AM

The problem now is that when I want to check a collision between an Object and an Enemy, I need to declare a function something like this:    check_collision( Object& obj, Enemy& enemy ).     And when I need to check collision between an object and a player, I need the same function, but with different parameters:   check_collision( Object& obj, Player& player )     And if I create another class that inherits from Character. I need to make a third check_collision() function. Is it ok to overload the function like that, or is it better to somehow use polymorphism?



One way you can deal with this, is to use Composition instead of Inheritance.


If you abstract the type of the objects (Player, Enemy, etc), then the collision code doesn't have to know the object type, only the collision polygon/surface.



And the second problem is that I have different kinds of collisions and I don't know how to structure my code. 


1st way is to make the function based on states like that:


check_collision( RAY_AABB, Object& obj, Player& player )

check_collision( SPHERE_AABB, Object& obj, Player& player )


or is it better to just make a different name for the function like this, CheckCollisionRayAABB, and CheckCollisionSphereAABB?


For the collision checks, in my opinion, it is fine, and simpler, to overload the same function.


But again, if you abstract the collision surface from the game Object (Player, Enemy, etc), then your collision functions only need to know the type of collision surface, which would, in turn, simplify them even more.


So, instead of 

check_collision( RAY_AABB, Object& obj, Player& player )
check_collision( SPHERE_AABB, Object& obj, Player& player )
check_collision( SPHERE_RAY, Object& obj, Player& player )

you'd have

check_collision( Coll_AABB &aabb, Coll_Sphere &sphere )
check_collision( Coll_AABB &aabb, Coll_Ray &ray)
check_collision( Coll_Sphere &sphere , Coll_Ray &ray ) 

The object types are stripped away, and only the collision models/surfaces remain.


It's just an idea, though. If implementing it will cost you more (in programming time) than what it will bring, just update what you have.


Hope it helps.

#5301417 Smooth Movement With Interpolation And All That Stuff

Posted by on 19 July 2016 - 03:35 PM

Sorry for the confusion.

I must admit I only skimmed through your post, and given the topic, I though it would be enough to link you to the article.


You already seem to have a proper fixedtime step loop, and to interpolate between your object's 2 last positions.


I inspected your code a bit better, and noticed you are moving your square (object) by one pixel every update.

In this case, the interpolation won't do any good, because if your screen can only display in 1 pixel increments, what is happening is that, in some frames, your object won't move at all (because until the delta reaches 0.5f, your object's position won't change by 1).


What I mean is, if the object's x coordinate is 400, and you're 40% on the way to the next update, it's interpolated position will be 400.4. But since, basically, you will only notice a difference, when the object moves by, at least 0.5 pixels (because it is rounded to 1), it will appear not to move.


Also, like Shaaringan said, the 2 pixels jump will also happen, probably, due to rounding/precision issues.


Basically, this is what I think might be responsible for the jittering.


Also notice, that the object moves properly when you don't use a fixedtime step, because you're always moving by 1 pixel and not interpolating between two positions separated by a single pixel.

The object won't always move at the same speed though, because should your loop run slower than normal, then your object will also slow down (one of the reasons you really should use one).


Again, sorry for the confusion.



That is one of several good ones.  The bigger game engines with more comprehensive feature sets will interpolate what you see between the two simulation steps as describe.



Indeed. I find that as I get more experience coding, actual program/engine design becomes more and more of an issue, so it is really cool to see how the (much) more experience programmers do it.

#5301378 Smooth Movement With Interpolation And All That Stuff

Posted by on 19 July 2016 - 10:23 AM

Hi there.


There's an excelent article written by L. Spiro about fixed timestep implementation here.


It explains really well how you should interpolate objects' positions (among other things), so, rather than trying to re-explain it here, I prefer to just link you to the article.

#5295710 SDL Input not behaving as expected.

Posted by on 08 June 2016 - 07:12 PM

Yes, as Kercyn says, your keyUpEvent and keyDownEvent are indeed swapped.


Also, just as an example, I'll post a different way you could do it.

void Player::update(int elapsed_time_ms)

    //OK, this 2 variables don't exist in your code (user_pressed_left and user_pressed_right), but they are
    //simply bools that are set, if the left or right keys are pressed.
      //EDIT: Here, there's no 'else' in the second 'if', because if the user is pressing both directional keys,
      //      the acceleration gained from both will cancel each other, and will behave as if no key is pressed.
      //Update acceleration based on user input
      acceleration_x_ -= kWalkingAcceleration * elapsed_time_ms;
      acceleration_x_ += kWalkingAcceleration * elapsed_time_ms;

      //Make sure that the acceleration doesn't exceed the maximum speed
      if(acceleration_x_ > kMaxSpeedX)
      acceleration_x_ = kMaxSpeedX;
      //Same goes for negative acceleration (moving left)
      //EDIT: Added 'else' here, because acceleration can only be either max positive or max negative
      else if(acceleration_x_ < -kMaxSpeedX)
      acceleration_x_ = -kMaxSpeedX;

    //Update player's position
    x_ += acceleration_x_;

      //Now, you can apply kSlowdownFactor (AKA friction).
      //The simplest way, is to check if the player has not pressed any direction buttons (or both),
      //and apply friction if so.
      if((!user_pressed_left && !user_pressed_right) ||  //No keys pressed
         ( user_pressed_left &&  user_pressed_left )   ) //Both keys pressed

        //EDIT: If the acceleration is 0.0f, then the player is already stopped, so don't apply friction
        //      By the way, be careful with equal comparison of floating point numbers.
        if(acceleration_x_ == 0.0f)

        //If acceleration is negative, apply friction to get it closer to 0.0f
        if(acceleration_x_ < 0.0f)
          //EDIT: If acceleration is bigger than friction, then just apply it
          if(acceleration_x_ < -kSlowdownFactor)
          acceleration_x_ += kSlowdownFactor;
          //EDIT: But if acceleration would become positive, then just set it to 0.0
          acceleration = 0.0f;

        //Same goes for positive acceleration
        //EDIT: Also added 'else' here.
        else if(acceleration_x_ > 0.0f)
          //EDIT: If acceleration is bigger than friction, then just apply it
          if(acceleration_x_ > kSlowdownFactor)
          acceleration_x_ -= kSlowdownFactor;
          //EDIT: But if acceleration would become negative, then just set it to 0.0
          acceleration = 0.0f;
​        }

      //Keep player within screen bounds
      if(x_ < 0)
      x_ = 0;
      else if(x_ > 640)
      x_ = 600;

void Player::startMovingLeft()
    user_pressed_left = true;
void Player::startMovingRight()
    user_pressed_right = true;

void Player::stopMoving()
    //Do nothing

Note that you don't need the velocity variable this way


This code is untested, so sorry if there're any errors.

I hope the explanation is concise, but if it's not (or you have any doubt) hit me up, and I'll try to explain better,


Hope it helps.


EDIT: I forgot one thing, and that is to stop applying friction when the acceleration would become 0.0. The way it is now, the player would "wiggle" in place, due to the fact that acceleration keeps jumping from positive to negative.


Also added a few "else" to make the code a bit more efficient.

Sorry for the mistake.

#5295704 Pixel Art and Screen Resolutions

Posted by on 08 June 2016 - 06:23 PM

In my understanding, tthere are 2 things you can do.


If you wish to keep the sprites aspect ratio (scale in multiples of the initial size only, like you say you currently do), you can enlarge the amount of level the user can see.

The player would see more of the world, where it would otherwise be unused (the 160 pixels, in your example).


The other is to simply scale the sprites to non-multiples of their size (scale to fullscreen), if necessary. You will get uneven scaling (how much depending on the user's screen), but your game will look the same on every resolution.


Basically, in my opinion, either you compromise screen real-estate (to achieve aspect correct scaling), you compromise your game world's view (again, also achieving correct sprite aspect) or you compromise the sprite's aspect ratio (to get full screen coverage and identical game world view).


Also, the uneven stretching (stretch to full screen) is, by far, the simplest.


As a last note, keep in mind that you may want to keep your game's aspect ratio constant, even across multiple monitors/resolutions.

For example, if your game runs in a 16:9 aspect ratio, in order to maintain it, you'd want to put letterboxes on 4:3 or 5:4 monitors, otherwise, you'd either have to show more of the game's world (possibly compromising gameplay balance), or get a pretty uneven stretching going on.


Don't know if it's the answer you are hoping for, but I hope it helps, and if my explanation is confusing, I'm happy to clarify.

#5295025 2d images and OpenGL

Posted by on 04 June 2016 - 08:03 PM

What exactly are your doubts about drawing 2D?


As far as I know, the way you describe, is the way to do it (and I wouldn't call it "mimicking" a 2D environment. It IS a 2D environment).


You set up the ortho projection, and draw textured quads.

Preferably, you set the ortho projection to match the application's window resolution and draw the quad the exact size of the texture you want to draw. That results in essentialy the same as what other APIs call 'sprites' (like Flash/Java/etc).


And, again, that's pretty much all that's needed.


Sorry if I'm misunderstanding your question (apart from me not providing articles), but there's not really much else to it that I'm aware.

#5274520 Beginner asking for advice

Posted by on 05 February 2016 - 02:31 PM

Ok, to somewhat simplify the question of whether to use a tool (GMS, Contruct, Unity, etc) or a standard language + some API (think something like C++ and DirectX), one could say tools trade freedom (as in features available, and things like that) for simplicity of use.


You don't need to use C++ or C# and OpenGL/DirectX to be a "real" developer.

It is irrelevant what tool/language/API you use, as long as it works for you.


The main advantage of those tools, is that you focus mainly on the game creation part, instead of having to write code for every little thing your game does (like you would, if you use C++, for example).

The trade here is that the tool constraints what you can do (compared to, again, a language+API), but in turn allows to create stuff much faster and easier.


Oh, and what i meant for game design/architecture, is the game itself is composed (things like objects, how to do collision detection, impementing enemy AI, how to move your characters), and not code architecture.

Basically, this game developing knowledge will stay with you, even if you move to another language, because, although, you'd obviously have to learn the language and how to implement these things in that language, you'd already know how the game elements work together and how to make the game working.

This is knowledge that remains relevant regardless of whatever language or platform you use (like Looniper said, similar to cross-platform development).


There's one thing you could think about among those tools, and that is the basic language they use.

I mean, Unity uses C#, Flash uses AS3, Contruct 2 HTML5, so you could choose one that you think would be more useful in the future, although i must reiterate myself, and say that this is secondary to the experience you'll gain in the game design.


As a side note, although i mentioned Multimedia Fusion earlier, this is one i'd recommend not using, considering the alternatives.

This advice comes not from experience, but from the developer of the infamous I Wanna Be The Guy, who says he regrets using it.


As for Flash, from the tools mentioned, it's the only one i've used, and it's pretty awesome.

ActionScript3 is similar, in sintax, to C++/Java, which made it easier for me to get into, because i was already familiar with C++.

I can't say whether it is easy or hard to learn, but i think it wouldn't be much different from the other tools.

Another good point though, is that, pretty much like GameMaker, Flash has been around for a long time, so there are a lot of tutorials for it. Just make sure to search for ActionScript 3 tutorials, if you choose to use Flash, because AS2 is deprecated.


As a last note (and the fact that it is a SHMUP is a coincidence) here's a great game made in GameMaker, that i happen to discover recently.

It's like mix of Konami's Gradius and Irem's R-Type. You can find it here.

I just mention it here, so you can have an idea of what can be done with GameMaker.


Well, that's about it. I hope this is more comprehensive. smile.png

#5274393 Beginner asking for advice

Posted by on 04 February 2016 - 10:14 PM

Well, to start of, there are platform games written in GameMaker, so given that they (the characters) require free movement (pixel by pixel), then i'm positive the movement you want would work too.

One that does uses only tile-by-tile movement is RPG Maker.


Do note that I'm not trying to sell you the idea of using GameMaker of Multimedia Fusion by any means.

In fact, i have not used either of them before, altough i am familiar with what they can achieve, and given that there are a lot of tutorials on how to use them, perhaps they would be easier for a beginner to get into.

I have used Flash before, and i have to say you can make any kind of 2D game with it, and it is pretty popular. Just check any flash games website to see what it is capable of.


About the SHMUP idea, i don't mean you have to make a carbon copy of Space Invaders, or the sort, especially if it doesn't interest you.

The thing is, altough the games are quite different, the principles are similar, it's just that a simple SHMUP is a self contained thing (think, single screen game, no overly complicated map/obstacles, etc). And these simple SHMUPS happen to be pretty popular in beginners tutorials.


A bit of a side thought here, but, i think that the biggest draw you'll get from this project, is the game design/architecture part, and not the actual tool/engine nuances themselves (unless you plan on using the same tool in the future).

I think this is especially true, if you them intend to learn an actual language later, like C++, C#, etc (as opposed to AS3, or whatever scripting language the tool uses) to use with more advances engines/APIs (like OpenGL, SDL, DirectX), because, although the language may be different, you'll already be familiar with how to structure your game and how it works.

So it's not like if you use GameMaker (or some other more simple tool) you'll be wasting time since it doesn't scale well with more advanced projects, because you'll still gain the experience of game design/structure.


So, once again, as long as the tool is capable of doing what you want, just go with the one that feels more comfortable, or looks/is more simple.


I hope this doesn't come out too confusing, and if it is, i'll be happy to (attempt) explain further.

#5274365 Beginner asking for advice

Posted by on 04 February 2016 - 07:26 PM

Hello there, and welcome to the forums.


Perhaps, since it's your first project, and you're looking for a simple tool, you should consider something like Game Maker of Multimedia Fusion?

These are pretty limited (compared, of course, to Unity and such), but they are also easier to get into, and i think would suffice for a (relatively) simple project, although Construct seems user friendly enough (don't quote me though, i've never used it, just checked their website).


The good thing about something like Game Maker, is that it has been around for a long time, so there are plenty of tutorials to go with it.


You could also try you hand at Flash (using Action Script 3), which also has many tutorials. There's lots of great games written with it.


As a side note, since this IS your first project, may i suggest you try something simpler, like a Shoot 'Em Up (something simple, like a Space invaders clone)?

I only say this, because a zelda-like game is quite a bit more involved than a simple SHMUP, and you'd get a feel for moving sprites (your ship), basic AI (the enemies), collision detection (bullets against enemies/you), etc.


Either way, you can just try each for a bit, and then choose the one you like the most, since i'm pretty sure they all allow you to do what you intend to do.


Hope it helps.

#5114803 A newbie question

Posted by on 06 December 2013 - 12:49 AM

I don't (and never did) work at a game company before, and i'm sure others who did can answer this much better than me, but the companies that you're talking about, that invest millions, they have, literally, hundreds of people working on a single game (you have programmers, artists, 3d modelers, animators, designers, script writers, audio editors, voice actors, game testers, marketing staff, business staff, etc), during the spawn of years, as some games take a year to be finished, others take as much as 10 years (games like Skyrim (even though it didn't take 10 years, it still took a long development time compared to annualy games), Starcraft 2, Diablo 3, etc).


Then, even though i'm not familiar with it, i'd assume that maintaining a studio of this magnitude (game company, or at least a branch) is costly, even without the game specific staff (things like office maintenance, R&D (i think of R&D here, as researching and developing the technology used for future games/engines, as oposed to direct development of a specific game, though if i'm wrong, please correct me).


Like i said i'm no expert in this but i think you can get an idea of how costly it is to run a business this big.


Hope it helps.

#5108578 writing 3D Model data to the game executable?

Posted by on 11 November 2013 - 07:04 PM

One way to do it is to declare the 3D model data (vertices, normals, texture coordinates, etc) as variables inside the code.


Now, i don't know if you just want to know if it's possible, and if you even care about what i'll tell you, but you should never do something like that.

This may be okay for icons, but you should always separate your code (program) from your data (graphics, sounds, 3D models, etc).

#5090885 what textures to use filtering on?

Posted by on 01 September 2013 - 04:11 PM

Assuming, I'm not misunderstanding your question and you want to use something like diffuse texture + normal map (and maybe a bump map), I'd say that a problem could arise if the normal map is much smaller than the diffuse texture, since if could convey incorrect vertex normals due to sampling.


In my opinion, if you don't see a difference, then use linear filtering, since it's the least expensive.


Hope it helps.

#5090880 Vsync with GLee

Posted by on 01 September 2013 - 04:01 PM

Have you tried enabling VSync after creating the window (on GLUT i think it was called glutCreateWindow(), not sure though), if it was not created before?


I've never actually tried to having VSync enabled at startup, i only had it possible to enable it by pressing a key.