Jump to content

  • Log In with Google      Sign In   
  • Create Account

We need your help!

We need 7 developers from Canada and 18 more from Australia to help us complete a research survey.

Support our site by taking a quick sponsored survey and win a chance at a $50 Amazon gift card. Click here to get started!


Member Since 08 Sep 2013
Offline Last Active Yesterday, 01:01 PM

#5247931 Scrolling background logic?

Posted by noodleBowl on 20 August 2015 - 02:29 PM

Right now I am thinking of it like a typewriter. When the head gets to the end, it jumps back to the first position and repeats that. Am I clos?


You are definitely on the right track. Basically, you draw your background twice.


So you have two instances of your background: A and B. As background A moves along you draw background B trailing behind it right behind it. Then when background A completely passes your screen threshold you can "jump" background A back to its starting position and background B should then follow. Jumping right behind, creating a endless scrolling effect.

Microsoft has an example article using their XNA framework, which should be super easy to get going in whatever framework you are working in

#5247657 Different Resolutions

Posted by noodleBowl on 19 August 2015 - 08:36 AM

I have thought about this for a bit and trying to figure out what to do. As of now what I got:
So I have a min and max aspect ratio. Where my min aspect ratio is 3:2 and my max aspect ratio is 5:3
I draw all of my sprites, background, HUD elements, etc geared towards the 5:3 ratio. The resolution of this ratio also engulfs all of my other aspect ratios.
When it comes to the devices and graphics, I determine the scale factor by doing
xScale = deviceResWidth / TARGET_RES_WIDTH_53;
yScale = deviceResHeight / TARGET_RES_HEIGHT_53;
and scale it up or down based on this value.
Then when it comes to the logic and playing field these things are all geared towards the 3:2 resolution. Allowing everyone to be on the same playing field, no pun intended.
My other thought was to maybe just draw all the sprites geared towards the 3:2 resolution. Then have the backgrounds (maybe HUD too) drawn to the 5:3 resolution.
Then each one gets scaled accordingly

xScale = deviceResWidth / TARGET_RES_WIDTH_32;
yScale = deviceResHeight / TARGET_RES_HEIGHT_32;

xScaleBackgrounds = deviceResWidth / TARGET_RES_WIDTH_53;
yScaleBackgrounds = deviceResHeight / TARGET_RES_HEIGHT_53;

#5245145 Velocity and deltatime confusion

Posted by noodleBowl on 08 August 2015 - 02:33 PM

deltaTime should be used when the change in velocity is a force. If it's a one-time instantaneous change, then you can do it like you've written there.

So the question is: The next frame, if the player is still in the water, are you going to halve their velocity again? (If so, use a force) Or do you only halve their velocity when they first enter the water? (If so, do what you're doing now)


In this case it would be a one time deal. If the player hits the object, half their current velocity.



You're moving at 600 units per what? Per second? Per minute? Per hour?

Normally we assume it's per second.
If we're simulating at 16.67ms per frame, then the object is moving at 10 units per frame.

Likewise, if the deacceleration is instantaneous, then you just divide the velocity by 2. Because it happens in that frame. Think in frames. Because you're dividing time (which is contiguous) into discrete frames.


Now if instead, hitting the poodle deaccelerates the object over a second, then you need subtract half of the velocity during 60 frames over and over again and multiply it by delta time (16.67ms). Because 60 times 0.016666667 is 1.


Think in time and frames.


I was thinking in terms of I'm just moving at a rate of 600 units or that is my current velocity.


But either way in the case I was talking about it would be all in the one frame so it would just be:

velocity -= velocity * 0.5f;

Now in the case where I hit the poodle ;)

And the poodle makes me slow down my velocity over the time I'm colliding with them by half (or over a 60 frames assuming we are stimulating 16.67ms )

Then if I am correct my equation should be:

    player.velocity -= player.velocity * 0.5f * deltatime;

#5244479 High Speed Collision Detection

Posted by noodleBowl on 04 August 2015 - 06:58 AM

What you described there has actually a name smile.png

It's Continuous Collision Detection (see here for example: https://en.wikipedia.org/wiki/Collision_detection#A_posteriori_.28discrete.29_versus_a_priori_.28continuous.29 )


Most Physics engines have switches to enable CCD for certain bodies (e.g. bullets, rockets, stuff like that) but often have it disabled by default since it is more costly than the standard simulation.


Edit: This page has some nice graphics explaining the stuff as well: http://www.stencyl.com/help/view/continuous-collision-detection/


Awesome! Thanks for the links


Is it really that costly? I means its just a line test right?

#5244338 High Speed Collision Detection

Posted by noodleBowl on 03 August 2015 - 12:00 PM

I have objects that gain velocity over time and eventually they move pretty fast. Which makes me worried about my collision detection holding up. I mean eventually I know they are going to be moving so fast they tunnel. So I was wondering if this method would work?


My idea is to cast a ray out in the direction that the object is moving. This ray would start from the object's edge at the center and its length would be the current velocity of the object. During the collision detection phase I would do a line intersection test with the hitbox of my other collidable objects. If the test passes I can assume that a collision will occur and handle it next frame


Has anyone tried something like this? Or what have you guys done?


#5243617 2D Platformer Camera

Posted by noodleBowl on 30 July 2015 - 12:16 PM

I know how to scroll the camera by altering its (X,Y) coordinates within the overworld width and height, but how do I figure out which tiles to draw on the canvas (only the tiles within the camera's view, including partial tiles)?

TBH, I don't think its worth it to try to "cull" the tiles

I'm not sure what framework / lib you are using, but I am assuming since this is a 2D game you are using a sprite batcher to draw stuff. Internally, I would think that the sprite batcher would cull off things that are not on the screen. Basically speaking in terms of the GPU, sprites added to a batch that are actually off screen wont make it past the fragment shader stage. Saving you some GPU time.

However, they are not being culled off on the CPU side of things. In order to cull them off on the CPU side of things, this would require some kind of check. Such as:

for(int i = 0; i < tiles.length; ++i)

BUT the reason I say its not worth it is because this check still costs CPU time. So in the end you are probably going to end up spending more CPU time just doing the check, then just telling the sprite batcher to draw it and have the GPU deal with culling it. 

#5240103 Why is my constructor/Renderer class being called twice?

Posted by noodleBowl on 13 July 2015 - 11:59 AM

View constructors can be called *a lot* on Android. For example, configurations changes (such as rotating your device from portrait to landscape) cause the entire view stack to be torn down and recreated. I'd trace through the View constructor that is calling setRenderer(), and make absolutely sure it is only being called once.

What swiftcoder says is very very true here


When your screen changes orientation or your activity gets paused, your OpenGL context is destroyed and recreated.

Actually when the screen orientation changes IIRC the whole activity gets destroyed and recreated


Personally I would follow haegarrs advice and set a break point. Place it on the first line of the onCreate method that you override, that way you can step through from the beginning of your apps creation.

#5236734 Me and the gameloop are not friends

Posted by noodleBowl on 25 June 2015 - 08:22 AM

Me and my gameloop are not friends...
Ok, on a more serious note I have a ton of trouble when it comes to the gameloop and would appreciate some help in this matter.

I have read the infamous http://gafferongames.com/game-physics/fix-your-timestep/ article and the equally http://www.koonsolo.com/news/dewitters-gameloop/ article, but for some reason I can't ever implement a fixed timestep gameloop correctly sad.png

I chose to go with the Gafferon Games approach as it seems to be the article that is referred to the most. I understand the article (what the article is saying), but there seems to be something wrong with my implementation all the time.

No matter what, I seem to always have a constant hiccup or stutter. It is like my app is trying to play catch up all the time? Maybe it comes down to the interpolation calculation being off? Can someone please tell me what I am doing wrong, at this point I'm not really sure what I should do.
I am trying to target 60 FPS just as a FYI, I have tried to target 30 FPS as well but that seems to make it worse (hiccups / stutter).

Also I am developing for Android using OpenGL ES 2.0, My testing hardware is a Kyocera Hydro Edge [ http://www.boostmobile.com/shop/phones/kyocera-hydro-edge/ ].

I have tested on other android phones too, but I still have the same issues


If you have question please ask, I would really like to solve this problem once and for all. Thanks smile.png

Update game logic method and render method

public void Update(float deltatime)
        //Update the position of the 1st scrolling background
	prevBack1X = back1X;
	back1X -= 120.0f * deltatime;
	if(back1X + space1.getWidth() <= 0.0f) //Warp the background to the start position because it has gone offscreen
		back1X = 0.0f;
		prevBack1X = 0.0f;

	//Update the position of the 2nd scrolling background
	prevBack2X = back2X;
	back2X -= 360.0f * deltatime;
	if(back2X + space2.getWidth() <= 0.0f) //Warp the background to the start position because it has gone offscreen
		back2X = 0.0f;
		prevBack2X = 0.0f;

public void Render(float alpha)
	//Interpolation (LERP) to get render position
	pos = prevBack1X + (back1X - prevBack1X) * alpha;
	pos2 = prevBack2X + (back2X - prevBack2X) * alpha;
	//Draw the first background and the background that follows
	//to complete the scrolling background illusion 
	batch.Draw(background1, pos, 0.0f);
	batch.Draw(background1, pos + background1.getWidth(), 0.0f);
	//Draw the second background and the background that follows
	//to complete the scrolling background illusion 
	batch.Draw(background2, pos2, 0.0f);
	batch.Draw(background2, pos + background1.getWidth(), 0.0f);

The Gameloop! And frame time calculation

private long nowTime = System.nanoTime();
private long lastTime = nowTime;
private float accum = 0.0f;
private float frameTime = 0.0f;
private float fixedDT = 1.0f / 60.0f; //Target 60 FPS for game update speed

public void onDrawFrame(GL10 gl)
    CalculateFrameTime(); //Calc the frametime in secs

    accum += frameTime;
    while(accum >= fixedDT)
        accum -= fixedDT;
    alpha = accum / fixedDT;

    //System.out.println("FrameTime: " + frameTime + " | Accum: " + accum + " | Alpha: " + alpha);


private void CalculateFrameTime()
    //Calc the frame time in seconds
    nowTime = System.nanoTime();
    frameTime = (nowTime - lastTime) / 1000000000.0f;
    lastTime = nowTime;

Sample of FrameTime (in secs), Accum value, and alpha (println statement above)

FrameTime: 0.015107584 | Accum: 0.001972055 | Alpha: 0.1183233
FrameTime: 0.013520525 | Accum: 0.01549258 | Alpha: 0.92955476
FrameTime: 0.016633602 | Accum: 0.015459513 | Alpha: 0.92757076
FrameTime: 0.018495347 | Accum: 6.215237E-4 | Alpha: 0.03729142
FrameTime: 0.016633604 | Accum: 5.884599E-4 | Alpha: 0.035307594
FrameTime: 0.019990845 | Accum: 0.003912637 | Alpha: 0.23475821
FrameTime: 0.014893942 | Accum: 0.002139911 | Alpha: 0.12839466
FrameTime: 0.013428963 | Accum: 0.015568874 | Alpha: 0.9341324
FrameTime: 0.016664123 | Accum: 0.015566329 | Alpha: 0.9339797
FrameTime: 0.018495345 | Accum: 7.2833896E-4 | Alpha: 0.043700334
FrameTime: 0.016603082 | Accum: 6.6475384E-4 | Alpha: 0.039885227
FrameTime: 0.020021364 | Accum: 0.0040194504 | Alpha: 0.24116701
FrameTime: 0.014863421 | Accum: 0.0022162031 | Alpha: 0.13297218
FrameTime: 0.014130932 | Accum: 0.016347136 | Alpha: 0.9808281
FrameTime: 0.015931634 | Accum: 0.015612101 | Alpha: 0.93672603
FrameTime: 0.018525865 | Accum: 8.046292E-4 | Alpha: 0.048277747
FrameTime: 0.016603084 | Accum: 7.410459E-4 | Alpha: 0.04446275
FrameTime: 0.021577904 | Accum: 0.0056522824 | Alpha: 0.33913693
FrameTime: 0.039188158 | Accum: 0.011507105 | Alpha: 0.6904263
FrameTime: 0.005829391 | Accum: 6.698277E-4 | Alpha: 0.040189657
FrameTime: 0.007019686 | Accum: 0.0076895137 | Alpha: 0.4613708
FrameTime: 0.007874256 | Accum: 0.015563769 | Alpha: 0.9338261
FrameTime: 0.016816728 | Accum: 0.015713831 | Alpha: 0.94282985
FrameTime: 0.02145582 | Accum: 0.0038363151 | Alpha: 0.2301789
FrameTime: 0.031435985 | Accum: 0.0019389652 | Alpha: 0.1163379
FrameTime: 0.001800702 | Accum: 0.0037396671 | Alpha: 0.22438002
FrameTime: 0.014985503 | Accum: 0.0020585023 | Alpha: 0.12351013
FrameTime: 0.017366093 | Accum: 0.0027579274 | Alpha: 0.16547564
FrameTime: 0.012574393 | Accum: 0.015332321 | Alpha: 0.9199392
FrameTime: 0.016572561 | Accum: 0.015238216 | Alpha: 0.91429293
FrameTime: 0.0179765 | Accum: 0.01654805 | Alpha: 0.99288297
FrameTime: 0.015321227 | Accum: 0.01520261 | Alpha: 0.9121565
FrameTime: 0.016694643 | Accum: 0.015230587 | Alpha: 0.91383517
FrameTime: 0.019136272 | Accum: 0.0010335259 | Alpha: 0.06201155
FrameTime: 0.016572561 | Accum: 9.394195E-4 | Alpha: 0.056365166
FrameTime: 0.017823897 | Accum: 0.0020966493 | Alpha: 0.12579896
FrameTime: 0.015595911 | Accum: 0.0010258928 | Alpha: 0.061553564
FrameTime: 0.014222493 | Accum: 0.015248386 | Alpha: 0.9149031
FrameTime: 0.016694643 | Accum: 0.015276363 | Alpha: 0.91658175
FrameTime: 0.016908286 | Accum: 0.015517982 | Alpha: 0.93107885
FrameTime: 0.016603084 | Accum: 0.0154543985 | Alpha: 0.92726386
FrameTime: 0.016694644 | Accum: 0.015482375 | Alpha: 0.9289425
FrameTime: 0.018983671 | Accum: 0.0011327118 | Alpha: 0.067962706
FrameTime: 0.014222493 | Accum: 0.015355205 | Alpha: 0.9213123
FrameTime: 0.016633604 | Accum: 0.0153221395 | Alpha: 0.91932833
FrameTime: 0.016938806 | Accum: 0.015594279 | Alpha: 0.9356567
FrameTime: 0.016603082 | Accum: 0.015530696 | Alpha: 0.93184173
FrameTime: 0.016664123 | Accum: 0.015528152 | Alpha: 0.9316891
FrameTime: 0.019044712 | Accum: 0.001239527 | Alpha: 0.07437161

#5228788 Trouble with if statment in shader and loading array of mat4 to uniform

Posted by noodleBowl on 13 May 2015 - 07:58 AM

To me, when it comes to the matrix uniform, it looks like you're trying to allocate too many bytes. I would think it should be:
ByteBuffer shadowPVbuff=BufferUtils.createByteBuffer(16*4);

because of the 16 floats for the matrix and then times 4 for each of the bytes

Also, I'm not too sure on this, but if you are calling this code (the byte buffer put code) every frame, which I assume you are. I believe the call to flip might be messing you up. I believe you need to call clear first at the top of that code bit, before the put calls. As clear will set the byte buffer's position back to 0 and flags it for writing.

#5226496 Sprite Batcher and Map Buffer Range

Posted by noodleBowl on 30 April 2015 - 07:22 AM

OK, this is easy.  Let's break it down into a simpler form for the purposes of demonstration.  Say you have 12 vertices, the first 6 must be drawn with one set of states and the second set with a different set of states and this is your entire frame.  The larger example in your question is just an extension of that.

I don't know why I didn't see what you were talking about. I think I got hung up on the singular buffer part, because I was imagining a super mega buffer. Basically a global buffer that all my systems used. Maybe you are actually are saying that, but I would think that would be a bad design choice the way I'm doing things now. But on just the level of the sprite batcher, I'm already doing this

I basically fill my sprite batcher's buffer with all the data I can, considering any changes in state and draw accordingly. The only time I get a new buffer is when the buffer has been completely filled

#5218979 OpenGL Method Variable Type Explanation

Posted by noodleBowl on 24 March 2015 - 11:19 PM

I was wondering if someone could explain to me this variable


I am trying to use a OpenGL function called glTransformFeedbackVaryings(), where its third parameter according to my compiler is:

const GLchar *const *varyings


This may sound stupid, but I kind of don't know what its expecting. When I try to make a variable of this type I run into some issue like "requires initializer" GLchar *const myVaryings[1] or "GLchar const ** is incompatible with type GLchar *const *" when I declare a variable like so: GLchar *const *myVaryings[1];

#5218168 Nothing visible when doing indexed drawing

Posted by noodleBowl on 21 March 2015 - 05:53 PM

I'm curious, how do you even get anything to show without binding a buffer of some kind for your vertex data?

#5215346 Map Buffer Range Super Slow?

Posted by noodleBowl on 08 March 2015 - 09:19 PM

I found the problem!
The problem lies in here

for (int i = 0; i < 12 * MAX_SPRITE_BATCH_SIZE; i += 12)
pointer[i] = pos[i];
pointer[i + 1] = pos[i + 1];
pointer[i + 2] = 0.0f;
pointer[i + 3] = pointer[i];
pointer[i + 4] = pointer[i + 1] + 32.0f;
pointer[i + 5] = 0.0f;
pointer[i + 6] = pointer[i] + 32.0f;
pointer[i + 7] = pointer[i + 1] + 32.0f;
pointer[i + 8] = 0.0f;
pointer[i + 9] = pointer[i] + 32.0f;
pointer[i + 10] = pointer[i + 1];
pointer[i + 11] = 0.0f;

Turns out lines like these: pointer[i + 9] = pointer[i] + 32.0f;
Count as reading the buffer!


So after changing all the lines to just use the pos array like the first 2 lines my FPS shot up to ~1050 FPS!

#5214952 Intel gives better FPS than NVidia?

Posted by noodleBowl on 06 March 2015 - 08:29 AM

I got to the part where I finally started to rewrite my spritebatcher and I noticed something strange.

My Intel 4600 HD was returning more FPS than the dedicated GTX 850m card. I tried just a normal window test

where the window was 800x600 and I was drawing nothing (the only happening was glClear and the SDL swap buffer call).


Intel gives me 4.5K FPS on average, where my nvidia card gives me only 1.8K?

I also tried doing a 3DMark test (I think this uses DirectX) and the Nvidia out performed the Intel card significantly, so I;m not sure whats going on? 


I have tried the newest drivers for the nvidia card, I tried old nividia drivers, the same results sad.png

Has this happened to anyone? Anyone have a solution?


This is a laptop with optimus just in case that matters

#5214010 Dynamic Memory and throwing Exceptions

Posted by noodleBowl on 02 March 2015 - 02:00 PM

Don't catch exceptions you can't handle, and don't write (...) blocks

What is a (...) block?

Most professional software these days has a top-level crash handler that will catch exceptions and crashes, perform a memory dump, and allow the user to submit a bug report. (You don't need exceptions to do that though, in Windows, a Structured Exception Handler will be enough)

From what I understand, isn't this just like a Structured Exception Handler?

int main()
{   try
       /*All of my other code*/

       TypeObject obj = CreateType(4);

       /* Some other code in my main funciton */
    catch(exception &e)
       //Logging of e.what() to file