Newbie Side Scrolling Question

As was mentioned in one of my earlier threads, I am developing a typical side scroller game in the theme of Fly With Me to keep a glider aloft with a tap on the screen. I am using juaxix’s Sprint Animal example code as a starting point, editing as I go along to get the results that I need. Again, thank you very much juaxix for providing this most helpful code and to West for the character animation example code.

My question is instead of random backgrounds and collectible objects, how would one go about incorporating pre-drawn elements? I’m not looking for code per se but a nod in the right direction would be much appreciated. Is this a good time to use tables and if so, what would be the best way to use them?

How big should the background images be in order to preserve frame rate? Is a complete screen size graphic too large or should it be broken up into several image files per screen and deleted as they roll off screen? I want to use parallax scrolling for extra eye candy (I looked at an example using parallax scrolling that I have found here but a forum search did not turn up the code or the author, sorry) and wondered how the extra graphics will come in to play.

Searching the forum, I have read conflicting reports whether off screen graphics are culled or maybe not. Perhaps I missed the decision but could someone provide a definitive answer? Two of my three splash screens are full screen and I would like to know if they should somehow be removed from memory and if so how?

Again, this project will probably never get to the app store as this is only a very fulfilling hobby to help keep my old mind ticking and to see the immediate benefits on the iPad via Codea.

If my posts are too drawn out please let me know and I will certainly contract my questions. I do not want to be a burden to this great forum by no means.

Any help would be much appreciated.

Thanks in advance for those who may reply.

I don’t think there is necessarily a right or wrong answer, it just depends what you are trying to do.

In terms of your splash screens, provided you are only calling one of them at a time from your main draw function it shouldn’t matter.

I’m guessing the size of your sprites shouldn’t matter either too much as long as you don’t have too much overlap.

The other consideration is how much storage space is used. Back in the olden days this was at a premium so smaller reusable blocks were used to make big maps. This is also an advantage that your playing area can be customised from the program rather than being hard wired into a big static image

Here is the simple demo of parallax scrolling I suggested in an earlier thread ( but I’ve stretched a sprite as the background. I’ve also added a simple array/table to control the sprite used in the ground. This could be expanded to a longer array and you could track the location within the array so you only generate the sprites that appear in the visible area.

-- Use this function to perform your initial setup
function setup()

-- This function gets called once every frame
function draw()


    for i = 1,40 do
       sprite("Small World:Tree Round Dark", xpos/4+ 25*i-100, 90,40,50) 
    for i = 1,20 do
       sprite("Small World:Tree Round", xpos/2+ 50*i-100, 60,60,70) 
    for i = 1,10 do
        if grass[i]==1 then
            sprite("Planet Cute:Grass Block", xpos+101*i-100, 0)
            sprite("Planet Cute:Brown Block", xpos+101*i-100, 0)
    --need to reset xpos at an appropriate point to get wraparound

Finally, meshes rather than sprites might be the way to go as I think they’ll give you better performance but I’ve not looked into them in much detail.

Thanks for your thoughts, West. I thought about meshes as well but like you, haven’t spent much time with them yet. I’ll try a few things and see how they work out.

Yes, this is the parallax example I was referring to that did not turn up in my forum search. Perhaps I misspelled it. Anyway, I liked it then and also how you added the new wraparound functionality. Thanks.

Uhm, i think it would be nice to create some kind of running time ground generation algorithm , such like we are talking in this post:

I’m coding the processing game in which Tiny Wings is based (Wave Spark : ) , I’m submiting the code here:
and i need help to make it real :slight_smile:
Can you help me @Keebo?
Stoling your post like a boss XD

@juaxix, I would be glad to help in any way that I can if you are serious. Being a newb with Codea/Lua, I don’t how much help I can provide but it will be a great learning experience. Plus I think a successful ground generator would be quite useful for everyone interested in this type of function.

Cutting and pasting to follow.

Thanks for all of your contributions.

Your post got me thinking so I put together a simple side scroller along the lines of the “helicopter game”. It’s super basic and not as smooth as I’d like so the next stage is to try out some meshes but meanwhile here is the code.

-- Use this function to perform your initial setup
function setup()
    --gameState is the current state of play
    -- 0 is the splash screen
    -- 1 is normal gameplay
    -- 2 is gameover

-- This function gets called once every frame
function draw()
--One if statement checks what game state we are currently in and executes the relevant code
if gameState==0 then
    --Draw the splash screen
    --Set up a title
    text("Sideways Scroller Demo",WIDTH/2,HEIGHT/2)
    --add your name
    text("by West",WIDTH/2,HEIGHT/2-50)
    --Draw a start button
    fill(127, 220, 23, 255)
    stroke(220, 217, 172, 255)
    fill(223, 230, 222, 255)
    --Calculate the distance of the edge away from the centre of the button
    --check to see if the user has touched the button
    if CurrentTouch.state==ENDED and dist<50 then
        --put into the play game state
        --Initialise some variables
        xpos=0 --used for the movement of the background
        speed=5 --initial speed
        speedCounter=0 --a counter to increment the speed
        speedMax=200 --the value at which the speed will increment
        topSpeed=50 --the top speed
        upthrust=0 --the upward force applied to the hero character
        herovel=0 --the vertical velocity of the hero character
        herox=100 --the horizontal position of the hero
        heroy=HEIGHT/2  -- the vertical position of the hero
        --an array of height values for the ground
        --add more values into the array to create a longer level
        --an array of height values for the ceiling
        --make sure that the two arrays are the same length
        t=0.1 -- a time variable used to calculate the position and velocity between frames
        acc=0  --an acceleration variable calculated each frame
        grav=-10 --a constant gravitational force
        score=0  --the current score
        restartwait=0 --a timer for restarting the game at the end

elseif gameState==1 then
--Stretch an sprite to fill the background
--As this is the furthest away thing draw first and everything else will be drawn on top

--the screen in landscape will allow 12 sprites with a width of 100 to be drawn
--try reducing the second number to 10 to see the effect (make sure you hold in landcsape)    
    for i = 1,12 do
--the value in the current position (i) of the ground array is the number of blocks high to 
--draw at the current position
        for h=1,ground[i] do
            --draw the sprite at the current x position i * width of one sprite with the xpos
            --offset which creates the movement
            --the y position is calculated as a multiplier of the the height
            sprite("Planet Cute:Ramp South",xpos+100*i-100,-40+70*h,100,100)
        --repeat the process for the ceiling
        for h=1,roof[i] do
            sprite("Planet Cute:Ramp South",xpos+100*i-100,HEIGHT+50-70*h,100,100)

--Display the hero sprite
    sprite("Planet Cute:Enemy Bug",herox,heroy,110,160)

--Simple version with no gravity, touch above the hero sprite to move up and below to move down
--handle a touch input from the user     
    if CurrentTouch.state == MOVING or CurrentTouch.state== BEGAN then
    if CurrentTouch.y > heroy then
          heroy = heroy + 3
        elseif CurrentTouch.y<heroy then
            heroy = heroy - 3
--Gravity based version, touch anywhere to provide upthrust to counter gravity
   -- if CurrentTouch.state == MOVING or CurrentTouch.state== BEGAN then    
   --     upthrust = upthrust + speed/2
   --     if upthrust>20 then
   --         upthrust=20
   --     end
   -- end
   -- if CurrentTouch.state==ENDED then
   --     upthrust=0
   -- end
   -- acc=upthrust+grav
--equation of motion to calculate the displacement in the y direction s=ut+0.5at*t
   -- heroy=heroy+herovel*t+0.5*acc*t*t
--equation of motion for the new velocity v=u+at
   -- herovel=herovel+acc*t
--stop the sprite going off the top of the screen
--redundant here, but if you wanted to have a narrower field of play then this what you would use
--try replacing both HEIGHT with HEIGHT/1.5 to try it out
    if heroy>HEIGHT then
    if heroy<0 then
--dealing with collisions
--normally we would have to check to see if the hero has hit anything on the screen
--however as we are restricting the movement to up and down only then we only 
--need to check the sprites in the same vertical location
    if heroy<(-40+70*(ground[2]+1)) then
    if heroy>(HEIGHT+70-70*(roof[2]+1)) then
--xpos is a variable used to control the position of the sprites on the screen
--the variable speed determines how much each sprite is moved each time the screen is redrawn
--score is based on distance travelled
    score = score + speed
    fill(255, 255, 255, 255)
    text("Score: "..score,WIDTH/2,HEIGHT-30)
--need to reset xpos at an appropriate point to get wraparound
    if xpos<-100 then
--store the value of the current first element of the array   
--for example, for the array {a,b,c,d} store the first element a in the variable temp
--shift the ground array along by one, overwriting the first element by the second element,
--the second element by the third element, etc, etc
--Note the last element is not overwritten yet
-- {a,b,c,d} becomes {b,c,d,d}
        for c=1,#ground-1 do
--Move the previously saved first element (saved in the temp variable)to the last position
--{b,c,d,d} becomes {b,c,d,a}
--get faster over time
    speedCounter = speedCounter + 1
    if speedCounter>speedMax then
--set an upper limit on the speed
        if speed>topSpeed then
--game over state       
elseif gameState==2 then   
    background(96, 77, 77, 255)   
    text("Game over",WIDTH/2,HEIGHT/2)
    text("Score:  "..score,WIDTH/2,HEIGHT/2-50)
--add a delay to stop overspill from the gameplay restarting the game instantly
    if restartwait>100 then
          text("Tap screen to restart",WIDTH/2,HEIGHT/2-100)
    if CurrentTouch.state==BEGAN and restartwait>100 then
    restartwait = restartwait + 1

Was messing about with it further. Using meshes does make it significantly smoother and faster

@West, this is very cool. I really like how you are not shy with commented lines. That really helps to understand what is going on in the code.

I was amazed at the speed increase with meshes in your example in the other thread as well. Keep up the great work.

Thanks again for sharing your knowledge.

No worries. Glad it was of help :slight_smile: