Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 10 Jun 2011
Offline Last Active Today, 01:16 PM

Posts I've Made

In Topic: Opengl:why Glcolor4Fv() Does Not Change Color?

21 July 2016 - 08:57 AM

Ok, just by glancing at it, you have GL_TEXTURE_2D enabled.

Call glDisable(GL_TEXTURE_2D) before you draw non-textured polygons.


I could be wrong, but usually the vertex attributes are set after starting a drawing command



Both work.

You can put glColor*() calls both outside or inside glBegin() glEnd() calls.


I usually put it outside if using a single color for the whole polygon, and inside if using per vertex color (when I use old fixed function OpenGL anyway).

In Topic: Opengl:why Glcolor4Fv() Does Not Change Color?

21 July 2016 - 07:17 AM

I don't know exactly why this doesn't work but I recall something with opengl that if you enable texturing then colours no longer function as you expect


Yes, i thought that too, but if i recall correctly, having texturing enabled without specifying a texture ( with an ID of 0) will prevent any non-textured objects to appear at all.


The lighting could also be a problem, but even if he had light enabled by mistake, the objects should appear black (or grey?) if he didn't specify a light color/position.


And he would also have to enable texturing and lighting, because they're disabled by default.


I might be wrong though.




It might be worth showing your initialisation code.


Yeah, or the whole code, if possible.

In Topic: Opengl:why Glcolor4Fv() Does Not Change Color?

21 July 2016 - 01:09 AM

Ok, first things first.


Calling glClear(GL_COLOR_BUFFER_BIT) will clear the color buffer (ie. the screen) with the color you specify with glClearColor().

You also only need to set the clear color once, so call glClearColor() once when you initialize your program, and then, you only need to call glClear() at the start of every frame to clear the color buffer (instead of calling both everytime, like you do on your clear function).


Next, in order for transparency to work, you need to enable blending.


To do this, call

//Enable alpha blending

You also only need to do this once, when you initialize your program, just like glClearColor().


Now, inspecting your rendering code and your screen shot, it appear that the text's background box is not being drawn at all, and that every subsequent draw uses that first box' color (red).


Honestly I can't really see what's causing the problem.

Can you post you're entire code? If so I'll be able to test it in my computer, and I'll be able to help you more.

In Topic: Smooth Movement With Interpolation And All That Stuff

20 July 2016 - 02:15 AM

As for what _SKYe said above,  I tried to play around with using different speeds and in fact there are some which look somewhat better.



Yeah, keep in mind that the whole point of using interpolation, is to smooth out movement that would otherwise be choppy (depending on how much/fast the objects move).

So, the faster the objects are moving, the more you will notice the LACK of interpolation, should you not use it.


The great thing about it is that, if a user has a high end machine and another has a not-so-high-end one (especially graphically), then, one will be able to enjoy a richer experience (graphics wise), but both will have, essentially, the same gameplay experience (the game just looks smoother for the first case).



I will look into replacing my using doubles with direct calculations or storing integers.



Like frob said, floating point variables, in this case especially, should only really be used to pass time deltas, and never to be used as an accumulator.

So if you have to accumulate time (or perform any calculations), use integers (or 64-bit integers, if you're dealing with large numbers), and only cast it to float when you need to pass deltas.


Anyway, I'm glad you sorted it out.

In Topic: Smooth Movement With Interpolation And All That Stuff

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.