[gameprogrammer] Re: 2d side scroller
- From: Alan Wolfe <alan.wolfe@xxxxxxxxx>
- To: gameprogrammer@xxxxxxxxxxxxx
- Date: Wed, 9 Nov 2005 09:30:37 -0800
cool idea on the culling to only what you can see, something i should have
known to do but for some reason forgot :P
right now i have all my physics etc use the time since last frame as part of
the equations like this...
//dtime = time since last frame
playerinfo.posy+=playerinfo.momentumy*dtime;
which i know you are going to say "that sucks!", your update every 30ms idea
is nice and i'm going to convert the code over. Right now since the time
between frames can vary, physics isnt the same every time something happens
like if you hit a jump pad you might go higher than when you did it before
:P totaly sucky and your idea would fix that.
Thanks a bunch (:
PS my map is tile based, but does anyone know how games like this can have
rounded or sloped smooth looking ground?
On 11/9/05, Josh Stewart <aek@xxxxxxxxx> wrote:
>
> I would leave threads out of it for now.
> Get a timer going, render as fast as you can to keep framerate up, and
> update the scene (collision detection / response, movement, physics)
> every ~30ms
> input is event driven so that can be processed straight away to change
> to state of your game world (ie fire key spawns a new bullet object with
> a certain position/vector/sprite), then return to rendering/updating.
> while (1)
> has30ms passed since i was last here?
> update world(elapsed Time) - updates the world, player, physics,
> enemy, move platforms, check for trigged events etc
> reset timer
> renderEverything()
> end while
>
> You can further optimise this game loop by allocating less time for AI
> updates or similar.. eg only update AI strategy twice a second..
>
> As for optimising there are two things (if you arent already doing these)
>
> Optimise the gfx pipeline... dont draw everything and count on opengl to
> do the culling for you. Instead add a bounding square/circle around
> everything, and if it is outside of your screen view, then dont render
> it. this might mean breaking your backgrounds down into half screen
> sized chunks.. each one is an object you need to check if it is
> inside/intersecting your view before sending it to opengl
> its a simple test before rendering,
> for each object
> if objects bounding sphere/square is inside or intersecting my screen
> object.draw()
> else
> nothing
> end for
> - Use display lists for the static geometry so it is stored on the gfx
> card.
>
> Optimise the collision detection - using the same bounding square/circle
> example for bullet
> if the bullet isnt inside the bounding circle of the player or any
> objects, ignore it this update
> if the bullet is inside the bounding circle, then do per pixel
> collision test against the bullet.
> example for enemy
> if the enemy is outside of my view, dont update his positon, dont
> process his AI, etc (unless he has seen the player and is chasing or
> hunting the level for you)
>
> this requires that you have a bounding square/circle for your platforms
> floor/boxes/roof etc and you will need to check for collisions with them
> also (these can be automatically generated from the models as they are
> loaded)
> If you have diagonal passages, this might be more difficult, as you
> might have to do point in polygon test.. not sure how that works.
>
> I dont know what language you are using, but if its OO you should be
> able to make this general behaviour that can apply to
> players/enemies/projectiles in the same way.
>
> -Josh
>
> Nick Howes wrote:
>
> > Yes it's best to do rendering and logic in two separate loops. The
> > looping itself isn't intensive so you won't get any slowdown from that
> > (until you have massive numbers of entities). The extra advantage of
> > this is you don't necessarily have to render each time you update the
> > world. They could even be separate threads running at their own speed
> > (provided everything is thread-safe). You could control the frame rate
> > without affecting the actual running speed of the game world.
> >
> > Alan Wolfe wrote:
> >
> >> Thats a good point. I was trying to be more efficient by taking
> >> advantage of loops as they happened, ie instead of looping through
> >> all enemies and doing movement/physics/logic and then looping through
> >> them all again later to do the drawing, i tried to make it all part
> >> of the same loop.
> >>
> >> Guess that's not the best idea eh? :P
> >>
> >> Thanks for pointing that out, that probably explains some wierdness I
> >> was having with the moving platforms.
> >>
> >>
> >> On 11/7/05, *Ken Johnson* <johnsk16@xxxxxxxxx
> >> <mailto:johnsk16@xxxxxxxxx>> wrote:
> >>
> >> One thing that I noticed is that I would render the screen as the
> >> last operation. You render enemies/player before you test if an
> >> enemy may have been killed by a players bullet and you also render
> >> the player before you test if he needs to be moved from a moving
> >> platform.
> >>
> >>
> >> On 11/7/05, *Alan Wolfe* < alan.wolfe@xxxxxxxxx
> >> <mailto:alan.wolfe@xxxxxxxxx> > wrote:
> >>
> >> Hey everybody!
> >>
> >> I'm working on a 2d side scroller in SDL/OpenGL and this is
> >> the first actual one i have ever made. Because of that, I
> >> have found some things I did which were not the most efficient
> >> way to do things and have changed them, but I have found other
> >> things which i know must not be the best way, but am unsure of
> >> what the best way would be.
> >>
> >> Here is my order of operations in my game loop:
> >>
> >> 1) Check which keys are down and move the player accordingly
> >> or spawn bullets etc. (movement checks that there are no
> >> blocks in the way, as well as checks if they touch spikes
> >> etc). This section also figures out which frame of animation
> >> to draw for the main character whether he looks like he is
> >> jumping running shooting etc.
> >>
> >> 2) Handle gravity and other physics for player, moving as
> >> necesary
> >>
> >> 3) Handle the scrolling of the camera to keep player on screen
> >> (the game uses mouse look so the screen really scrolls based
> >> on mouse coordinates.
> >>
> >> 4) Draw paralax layers that are behind the map
> >>
> >> 5) Draw the map
> >>
> >> 6) Draw the main character
> >>
> >> 7) Draw and handle enemies - draws enemies as well as handles
> >> enemy physics and logic (AI)
> >>
> >> 8) Draw projectiles - both enemy and player projectiles.
> >> Draws them and does physics and logic, also checks to see if
> >> friendly bullets have hit enemies (if so take away life from
> >> the enemy it hit) and checks to see if enemy bullets have hit
> >> the player (if so take away life from the player).
> >>
> >> 9) Draw game objects such as powerups etc. Does physics and
> >> logic as well for each.
> >>
> >> 10) Draw moving platforms (along with path logic as well -
> >> such as if it moves in a circle, it will move it the next
> >> step). This part also checks to see if each moving platform is
> >> going to hit the player when it moves. If so, it pushes the
> >> player out of the way (checking to make sure it doesnt push
> >> the player through a wall or anything like that).
> >>
> >> 11) Draw paralax layers that are in front of the map
> >>
> >> 12) Draw game GUI such as lives left etc
> >>
> >> 13) see if the player has touched any bad guys. If so, take
> >> away life and mark the player as being in the "injured"
> >> animation state.
> >>
> >> 14) see if the player has touched any power ups. If so, give
> >> them energy, extra life, or whatever.
> >>
> >> Does anyone see anything sticking out which might be optomized
> >> or done in a better way?
> >>
> >>
> >>
> >> A secondary question is how is the best way to program moving
> >> platforms? I am in the middle of implementing them and right
> >> now my tactic is this...
> >>
> >> -----
> >> Loop through each moving platform...
> >>
> >> If the player is on the current platform, move them the same
> >> amount as the platform is moving (this makes sure if they are
> >> standing on a platform that it carries the player with it) -
> >> (taking into account other walls etc so you don't push them
> >> into space etc)
> >>
> >> Move the platform.
> >>
> >> If the player wasnt on a platform but is now, move the player
> >> the same amount as the platform is moving (taking into account
> >> other walls etc so you don't push them into space etc)
> >> -----
> >>
> >> I know this isnt the best way because this makes the player
> >> "float" slightly above the platform at times and rarely, the
> >> player will get stuck inside the platform.
> >>
> >> Is there a better way to do this?
> >>
> >> Thanks!
> >> Alan
> >>
> >>
> >>
>
>
> ---------------------
> To unsubscribe go to http://gameprogrammer.com/mailinglist.html
>
>
>
Other related posts:
