Hi, now I've got my scrolling backgrounds working nicely I'm back to job of getting the spacecraft movement right.

What my goal is, is to get the aircraft sprite really responsive to the input keys.

So when a key is held the spacecraft is moving and when a key is let go of, straight away the spacecraft stops so that the player feels in total control of it all the time. All the attempts I've tried so far have been really far from this ideal. The spacecraft normally only moves a while after pressing a key and for too long. I'm a bit out of my depth with event queues. I followed Thomas' advice and used the input code from the wiki so my code looks like this :-

So I'm trying to figure out what to change in order to achieve my ideal.

I'm not sure what's wrong myself, but for some reason, it's really unresponsive.

Sometimes :

1) After releasing a key (say left) the spacecraft keeps moving for a long time afterwards.

2) After pressing a key, there's a pause until the spacecraft moves.

I wondered if the scrolling backgrounds were effecting things so I commented them out but it didn't change anything.

EDIT : changing the timer from 1/60 to 1/120 makes it better.

Here's the code where I use the keystates.

Here's where I get the event's.

while(end_program == 0)
   {
      al_wait_for_event(queue, &event);
    
    switch(event.type) {
       case ALLEGRO_EVENT_TIMER:
     
      Aircraft.Process_Input(key_states);

When the scrolling is included it scrolls smoothly (at the moment I got rid of it).

Well, my only other idea is that your animations are screwed up somehow, but that shouldn't be it because you always move the spaceship when less than 3 keys are down. As long as it's always drawn at craft_x and craft_y then it should be moving properly...

Huh? What the hell is going on?

Your key state assignment code is correct. Your Process_Input function looks correct too, using the array as if it were read only (but reading directly from the array, and not a copy). All the code you have shown us so far is fine. There must be something somewhere else that is screwed up.

As for performance: you can easily remove the lines containing this:

Since those are constants(or look like that to me), you can make it a member of your class. Then call this line in your constructor. This way, the bitmap is only created once, and you don't waste cycles creating and deleting it each frame.

EDIT:
I think this is true for many other bitmaps you are constantly creating and destroying. Unless they have variable dimensions, you should just create them on construction of your class and destroy them in your destructor.

I can't make any more guesses as to why this is happening. Try posting a zip file of your source code and a binary that shows what is happening.

Well, I can't properly debug it or build it myself. all_tiles.png doesn't load properly, and it says 'problem getting b1' and 'couldn't initialise Top_BD'.

From looking at the code, I think it's something to do with Backdrop::Update_Position. If it takes a long time for your secondary thread to finish then you won't see the results of your key presses and releases until it's done. You should try timing how long it takes each thread to complete with al_get_time.

You may want to swap the position of these two blocks of code so you don't wait until the next update to start drawing the bitmap in your secondary thread :

Also, why does Update_Position redraw the current bottom backdrop and convert to alpha on each and every timer tick? Can't you just get away with drawing it once every time it changes?

It might help if you explained how your backdrop works - do you have two different backdrops that scroll along the screen? Do they change each time one disappears off the screen?

I can't build it because libdinkleblot.dll.a is missing. There are undefined references to dinkleblot functions. Also, you might want to add -static-libstdc++ and -static-libgcc to your linking options - that way you don't have to include the standard library dlls with your program.

Okay then. I misunderstood that part of the code. That shouldn't be the problem then.

I'm building with A5.1 SVN, but that shouldn't be a problem. I just made a CodeBlocks project to build it. If you include your dinkleblot library archive then I should be able to build it.

-Wall FTW. There are some whiny warnings about initialization order in your Backdrop constructor. Use the same order that you declare them in.

Okay, I got it built. Everything works fine except for when the new background is being built, and it stutters for a second. I think the problem is that the secondary thread is not finishing before al_join_thread is being called, and so it takes a while to catch up.

I'll play with it more later.

Append
Making a new blot takes anywhere from 0.04 seconds to 0.13 seconds, but that is not what is causing the stutter. Joining the thread takes almost no time at all, so that is not the problem either. Scaled drawing from new_bitmap onto b1 or b2 takes anywhere from 0.25 to 0.7 seconds, and that is a major slowdown. I suspect it is because new_bitmap is a memory bitmap. I tried to add a fourth bitmap that is video, and make Make_New_Blot() draw from the memory bitmap onto the video bitmap and use that for the scaled drawing, but the results were totally AWOL - different parts of different bitmaps kept showing up on the new bitmaps. So I guess you can't draw onto video bitmaps from the non primary thread. I'm not sure what else you can do. Maybe you would be better off not using a secondary thread. Make new_bitmap a video bitmap, and make dinkle_get_connecting_bitmap lock it in write only mode and see if that is faster. That way you can do the scaled drawing from the primary thread and it will be accelerated.

I tried another way - making the new blot on a memory bitmap and drawing it to new_bitmap(a video bitmap) in the primary thread, but that took on average 0.2 seconds, and that is really F'ing slow. Maybe it could be speeded up because they are both the same size, and all you would have to do is a memcpy from one locked region to the other.

I think Matthew has the right idea.

I got rid of the secondary thread, and drew new blots directly to a video bitmap and these were the results :

c:\downloads\forum_code\WilliamLabbett-Shmup\shmup code and application>Shmup.exe
filename = top_backdrop_ratios.rsf
getting b1.
getting b2.
filename = bottom_backdrop_ratios.rsf
getting b1.
getting b2.
starting main loop.
Making new blot took 0.145577 seconds.
Making new blot took 0.155016 seconds.
Making new blot took 0.511338 seconds.
Making new blot took 0.146441 seconds.
Making new blot took 0.126829 seconds.
Making new blot took 0.126762 seconds.
Making new blot took 0.127508 seconds.
Making new blot took 0.471624 seconds.
Making new blot took 0.147070 seconds.
Making new blot took 0.122558 seconds.
Making new blot took 0.173015 seconds.
Making new blot took 0.125226 seconds.
Making new blot took 0.493643 seconds.
Making new blot took 0.145343 seconds.
Making new blot took 0.113793 seconds.
Making new blot took 0.124747 seconds.
clearing up

You can see that the foreground bitmap takes around .12 to .15 seconds to draw, and the background bitmap takes around 0.5 seconds. If you used a cyclic array of maybe 10 to 20 smaller bitmaps for each back drop and drew the connecting bitmaps more often it would probably smooth everything out.

Another idea is to use a predrawn set of bitmaps say from 1 to 4 connecting blots, and then use a mirrored set of bitmaps underneath them. This way you have a seamless and endless connected background. I'm not sure how visible the mirrored seam would be though.

Edit - here's what it would look like :

{"name":"604745","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/6\/1\/61d24664f4c8a3be793692c8057f8d0f.png","w":640,"h":960,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/6\/1\/61d24664f4c8a3be793692c8057f8d0f"}

Not too noticeable, and if it is scrolling by you may never notice it at all.

Depends on how many cores you have and whether it runs on a separate core. And if it takes that long and you have to wait for it to finish it still doesn't matter.

The slowest thing was drawing the new blot from a memory bitmap to a video bitmap, either to one of the same size, or using scaled drawing. And if you use a secondary thread, then you're forced to use a memory bitmap and you can't draw it onto a video bitmap until you're back in the primary thread.

Can you make smaller sections of connecting blots more often and use more bitmaps to cover the screen?

XOP is awesome. There's XOP Black too...

I think a pair of bitmaps with a third bitmap as the new strip would work...

Bitmap A and Bitmap B will take turns holding the full image for the screen. Once 20 pixels have gone by, you make a connecting blot 20 pixels high with the third bitmap. Blit the new blot to the top of the unused bitmap, and then draw the rest of the blot onto it from the other bitmap. Now A and B have swapped positions, and you use B to draw onto the screen. This way all three can be video bitmaps, and it shouldn't take very long to draw any of them at all.