Jump to content

  • Log In with Google      Sign In   
  • Create Account


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

#5301417 Smooth Movement With Interpolation And All That Stuff

Posted by __SKYe 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 __SKYe 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 __SKYe 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 __SKYe 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 __SKYe 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 __SKYe 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 __SKYe 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 __SKYe 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 __SKYe 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 __SKYe 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 __SKYe 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 __SKYe 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.

#5076280 How to tell if a context has been created?

Posted by __SKYe on 08 July 2013 - 10:16 PM

If you use GLEW, you can type:

//Initialize GLEW
if(glewInit() != GLEW_OK)
    //On failure

If this fails, then normally, the context has yet to be created.


Another way, is to call


If the context has yet to be created, then it will always return GL_INVALID_OPERATION (1282).

Note, however that multiple errors issued by OpenGL calls are saved by OpenGL, so the spec says that glGetError() should always be called in a loop, until it returns GL_NO_ERROR.

Since other OpenGL calls may have triggered an invalid operation, to be sure, you could call glGetError() a large number of times in a row (1000 maybe?), and if the last return value is still GL_INVALID_OPERATION, then you know the context is not created.


Hope it helps.

#5076278 Managing objects in different game states

Posted by __SKYe on 08 July 2013 - 09:58 PM

I think it is simpler to have a single ObjectManager class that manages all objects, and every state adds it's objects to that manager.

Each state should be, however, responsible for adding it's objects to the manager when it is created, and removing then when it is destroyed. In other words the global ObjectManager doesn't have to keep checking which objects are no longer needed.


L. Spiro has a very good article about managing game state (among other things), if you're interested: http://lspiroengine.com/?p=351


About your off-topic question:


If, when you say the entity is "dead", you're referring to something like, an enemy entity was just killed and has no purpose left in the game, then i'd say removing it from the ObjectManager is a good option, simply because it's one less update call the ObjectManager must make.

However, if the ObjectManager has to check for a variable to know if the object needs to be updated, then, on top of doing the same thing the above option does (issuing update calls), it will still have to execute a branching instruction for every entity (including the ones that are not updated), so it would be slower.


Note that this, however, probably won't even be noticed, with the speed of processors nowadays.


Hope it helps, and sorry if i misunderstood the question(s).

#5071548 Loading level information based on a parameter

Posted by __SKYe on 20 June 2013 - 01:10 PM

That's great you understood it.

Also if you need help with binary files, i can help too, they aren't that much harder than text files.


I have one final piece of advice, although it wasn't solicited.

Although binary files have the advantages of being more efficient in terms of speed and space, keep in mind that text files are much easier to edit by hand (which you'll probably do unless you make some level/map editor).

So perhaps during development, unless you build a custom level/map editor that creates the binary files automatically, you may want to use text file, for the easiness of use.


Good luck!