• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
doyleman77

Entity Screen bound checking

8 posts in this topic

I have just finally changed my movement from frame based to time based, but have since experienced problems with having the enemies move out of screen space and disappear off screen.

Some lame representation here:

Player -> <-Enemies

the enemies are only able to move left, down the X axis. Their Y is randomized upon creation. The problem is, since having them run off of delta time, they may not continue past the window; example:

<-enemy || player->

where || is the far left side of the screen. If they move slow enough, they stop right at the X(0), and stay. if I up their velocity a little bit higher, they slow down at the 0, but continue to move on past the screen space until their out-of-bounds check erases them. Here's some listings from their move, and their draw, if it'll help:

Move():
[code]void move(Uint32 dt)
{
xVel = 0.01 * dt;
x -= xVel * dt;
colBox.x = x;
colBox.y = y;
if (this->x <= -60) // is enemy off of screen?
{
tempSprite[selfIndex] = NULL;
DELETEOBJECT = this;
}
}[/code]


Draw():
[code] void draw(SDL_Surface* dest)
{
Draw(dest, this->image, this->x, this->y);
}[/code]


the Inner Draw() function is defined in a header, and works like so:

[code]bool Draw(SDL_Surface* destination, SDL_Surface* source, int x, int y)
{
if(destination == NULL || source == NULL)
{
return false;
}

SDL_Rect Dest_Rect;
Dest_Rect.x = x;
Dest_Rect.y = y;

SDL_BlitSurface(source, NULL, destination, &Dest_Rect);

return true;
}[/code]



I can't see any reason for this problem to pop up, and have been tinkering with this for the last good 15 hours or so.
0

Share this post


Link to post
Share on other sites
[quote name='doyleman77' timestamp='1315542172' post='4859345']
If they move slow enough, they stop right at the X(0), and stay. if I up their velocity a little bit higher, they slow down at the 0, but continue to move on past the screen space until their out-of-bounds check erases them.
[/quote]

Why is velocity decreasing when X approaches 0? Is this by design? If not, then xVel must be getting modifying somewhere else in the code. Either that, or "dt" is being calculated incorrectly. You can try running the debugger through the Move() method to see how xVel is being calculated, or set a conditional breakpoint, or log the velocity calcs to debug window, depending on you development environment.
1

Share this post


Link to post
Share on other sites
Your dt is of the type Uint32, which I suppose means unsigned int (32 bits). Normally a deltaTime value (or any time value for that matter) is represented with a floating point value (float or double). In addition to that, you're applying deltaTime twice, once for the velocity and the once more when you're applying the velocity. This is probably not what you intended to do? What you're essentially doing is this:
[code]
x -= xVel * dt *dt;
[/code]
meaning that your code is still not frame-rate independent. In fact it will go faster with a lower frame rate (as dt gets larger with a lower frame rate).

One other small thing, assuming you're using c++, using "this->x" is not wrong but its generally accepted to just use "x". make sure to use something that works for you.
1

Share this post


Link to post
Share on other sites
[quote name='laztrezort' timestamp='1315544456' post='4859350']
Why is velocity decreasing when X approaches 0? Is this by design? If not, then xVel must be getting modifying somewhere else in the code. Either that, or "dt" is being calculated incorrectly. You can try running the debugger through the Move() method to see how xVel is being calculated, or set a conditional breakpoint, or log the velocity calcs to debug window, depending on you development environment.
[/quote]

velocity doesn't decrease at all; or rather, nowhere in the code do I see it being decreased. i will try logging the variables as the ship moves towards me, and see what it produces.


thanks for the catch, jvdo; fixed the this-> and the twice application of dt.



edit:
Logged the stats, here are the last few results before and at x=0:

[code]

x:5 y:240 vel:0.09 dt:9
x:4 y:240 vel:0.09 dt:9
x:3 y:240 vel:0.08 dt:8
x:2 y:240 vel:0.09 dt:9
x:1 y:240 vel:0.09 dt:9
x:0 y:240 vel:0.09 dt:9
x:0 y:240 vel:0.08 dt:8
x:0 y:240 vel:0.09 dt:9
x:0 y:240 vel:0.1 dt:10
x:0 y:240 vel:0.09 dt:9
[/code]


and the list afterwords is of course, a long list of x = 0. Maybe, because X is an int, velocity is a float, and delta time is a int, maybe it's rounding up (round towards zero)? that could explain why, if his velocity is high enough, it continues to move left. Edited by doyleman77
0

Share this post


Link to post
Share on other sites
[quote name='doyleman77' timestamp='1315566504' post='4859433']
and the list afterwords is of course, a long list of x = 0. Maybe, because X is an int, velocity is a float, and delta time is a int, maybe it's rounding up (round towards zero)? that could explain why, if his velocity is high enough, it continues to move left.
[/quote]

Most likely this. I would advice to change both the position and the velocity as well as the deltaTime to floating point values. Right before you're doing the drawing, cast the (float) position to an integer. This way the the object stays moving even if the speed is <1. It might not look very nice, as sometimes the objects will move one pixel and the next frame it will move two or none at all. But at least the system keeps working.

Also, I noticed that the deltaTime have a value between [8..10]. What do these values mean?? The only plausible meaning I can think if would be milliseconds; meaning that the game would run at around 100~125 fps.
A much more accurate approach would be using the real time value (for example in seconds) as a float or double.
1

Share this post


Link to post
Share on other sites
[quote name='Jvdo' timestamp='1315568677' post='4859442']
Most likely this. I would advice to change both the position and the velocity as well as the deltaTime to floating point values. Right before you're doing the drawing, cast the (float) position to an integer. This way the the object stays moving even if the speed is <1. It might not look very nice, as sometimes the objects will move one pixel and the next frame it will move two or none at all. But at least the system keeps working.

Also, I noticed that the deltaTime have a value between [8..10]. What do these values mean?? The only plausible meaning I can think if would be milliseconds; meaning that the game would run at around 100~125 fps.
A much more accurate approach would be using the real time value (for example in seconds) as a float or double.
[/quote]


I am not sure I follow what you mean with real time value. are you suggesting I multiply the value by 1000?
I will update my code tonight; thank you kindly for your advice. :)

edit: yes, as I can tell, it is ms. Edited by doyleman77
0

Share this post


Link to post
Share on other sites
Multiplying the value by 1000 does not makes a whole lot of sense, this would give you the time in Micro seconds, but would still not give you any extra precision.

It is important to know what an bool, char, short, integer, float and double can store, and more importantly what it cannot store.
an integer can store values from -2,147,483,648 to 2,147,483,647. It can however only store [b]real[/b] numbers (1, 2, 42, 1337) but no [b]rational[/b] numbers (3.1415, 4/3, ?[font="Arial"][size="2"], etc), you can uses floats or doubles for that.[/size][/font]
[font="Arial"][size="2"]For thinks like time, and distance floating point values are more natural, for graphics on a screen real numbers are more useful as it makes no sense to set half a pixel to a certain colour.[/size][/font]

0

Share this post


Link to post
Share on other sites
Actually, him keeping the time in miliseconds is fine, so long as he makes sure his velocity accounts for it. He can't measure time in fractions of a millisecond, so the added precision that using a float would give him is of no use.

If he divides dt by 1000 to get the time in seconds, he'd need to divide vel by 1000 to keep the speed he currently has. Or would, in theory. There's a more insidious problem he has to deal with first.

His problem is storing the position in an int. Casting a float to int eliminates everything after the decimal point. This works 'fine' when you want to decrease x. Say x starts at 10:

10 - 0.1 = 9.9 -> casted to int -> 9
9 - 0.1 = 8.9 -> casted to int -> 8

The problem is you can't represent speeds smaller than 1 pixel per frame, because decreasing x by either 0.01 or 0.9 results in the same decrease of 1.

What happens when you reach x = 0 is

0 - 0.1 = - 0.1 -> casted to int -> 0
0 - 0.1 = - 0.1 -> casted to int -> 0
0 - 0.1 = - 0.1 -> casted to int -> 0
0 - 0.1 = - 0.1 -> casted to int -> 0
...

The solution is simple, just store position as a float. This will mean that your position only changes when the accumulated vel*dt reaches 1. If you just set the position to float, however, you'll probably notice a significant slow down. That's because you calibrated speed to work at 1 pixel per frame. If you want to keep the speed as it is now, you'll need to up vel a bit.

Also, a bit of a nitpick, pi is not a rational number, it is irrational. float and double can't store it, they can however approximate it with varying degrees of precision. You could store pi as 3 in an int, even, although that would probably lead to some strange results.
1

Share this post


Link to post
Share on other sites
[quote name='Jvdo' timestamp='1315570359' post='4859455']
Multiplying the value by 1000 does not makes a whole lot of sense, this would give you the time in Micro seconds, but would still not give you any extra precision.

It is important to know what an bool, char, short, integer, float and double can store, and more importantly what it cannot store.
an integer can store values from -2,147,483,648 to 2,147,483,647. It can however only store [b]real[/b] numbers (1, 2, 42, 1337) but no [b]rational[/b] numbers (3.1415, 4/3, ?[font="Arial"][size="2"], etc), you can uses floats or doubles for that.[/size][/font]
[font="Arial"][size="2"]For thinks like time, and distance floating point values are more natural, for graphics on a screen real numbers are more useful as it makes no sense to set half a pixel to a certain colour.[/size][/font]


[/quote]

No no, I understand that. I had totally forgot I had stored X and Y coordinates as integers, because well, I haven't looked at the parent class (sprite class) since it's implementation, some 5 months ago. sorry for the confusion!

edit: and by the pronoun that, I mean the variable storage capabilities. Edited by doyleman77
0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0