Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[wojt_gl]

Hello, it's me back
I hope I will found an answer for my next problem here again.

How to set up a game speed to constant value? I have a problem, that I draw a background, a plane bob (which user coordinates) and some other bobs (20 about) which are enemies. The plane is moving in one direction with 2px for each 1/50 of second. But as game continues, there is less bobs on screen (plane destroys enemies) and plane moves quicker - game speeds up.

Anybody has an idea what to do to keep the constant speed of my plane?

Thanks in advance!

[512k]

The issue may fix itself once the program is compiled but here is something you can try in the meantime

Use the Timer to record your slowest frame rates then use that figure to pause the game loop until it is reached
This should slow up your game to run at a constant frame rate.

Put the pause in after all drawing operations are complete but before a screen swap

Any samples that you may have playing will also need to be adjusted as you don't want to hear an explosion before you see it.

Other tips:
Keep your game loop as small as possible
Use Sub Routines for everything you can
Avoid using procedures as these can cause problems when compiling
Include an error trapping routine to deal with things like a disk being removed from the drive
Use as few colours as possible as an 8 colour lores screen can redraw a lot faster than a 16 or 32 colour one.
Include borders to help speed up drawing operations does your game really need to fill the whole screen
Use a separate screen for score and lives as you can make this small using only 2 colours and it doesn't have to be updated in every loop only when something changes like losing a life or adding to the score.

[bruceuncle]

Good tips from 512k there.  Especially the one about keeping colour counts to a minimum.

To explain why it happens:  Bobs are nice but they have to be drawn by the blitter.  So although the blitter can splat them onto the screen pretty fast, it's never going to match the speed of sprites.  When you add in double-buffering to stop the flicker and a 32 colour screen (5 bit planes) the blitter has to draw bobs and replace backgrounds at a phenomenal rate.  The images have to be drawn on each bit plane, so the more bit planes you use the slower it will be.  As soon as you get to more than a few bobs on screen, the redrawing and checking for collisions takes longer than a vertical blank.  So at the start, the game runs slower because one or more vertical blanks pass by before the next frame synchronises with a vertical blank.  As the bobs get blown away, less time is taken doing the work and less vertical blanks get 'missed'.  So the game speeds up.

So I would only add "Have you considered using AMOS's computed sprites instead of bobs for the enemies?"

Don't be put off by the term "computed sprites" as they're still really the Amiga's 8 hardware sprites.  They're just broken into smaller chunks to make full use of a hardware sprite's maximum height which is 270 lines.  That would never fit on a 256 line screen, just a quirk of the hardware.  Still it gives you lots of moveable sprites at full sprite speed.  You can use a 16 colour screen (4 bit planes) and have the remaining 16 colours of the 32 colour palette for your sprites.  I won't go into the details of how you do it in AMOS as the manual has some good info on it in the whole of Section 7 (and look at the example help programs too).  And it would be shooting in the dark without knowing exactly what you're trying to achieve.

Also consider AMAL to move your objects as it make any vertical blank timing and skipping dead easy with the Update Every VerticalBlanks command.  So if you need everything synchronised to 3 vertical blanks between each frame, Update Every 3 does it in one simple instruction.

Maybe a bob for the plane and sprites for the enemies?

Good to see someone getting stuck into some AMOS programming  .

[512k]

bruceuncle has it right although slightly wrong for what i think you're asking.

With hardware or even computed sprites which gobble clock speed (hardware sprites excluded talking about computed here) more than 8 sprites on the same vertical line will cause disappearance of said sprites like the NES depending on priorities.

This is the beauty of blitter objects and what AMOS was really created for. (AMOS PRO excluded)

If you can write some lightning code you can have up to 20 even more blitterr objects at least 8x8 or even 16x16 (you're gona have to be good) flying around a full screen at blistering speeds.

Before i get abused i am not talking about run time within the editor but compiled code which can be hit and miss but if you write enough code and compile you'll soon understand what does and does not work.

 

[wojt_gl]

Guys!
Thanks for answering.

I will try with Timer - because I think it is easiest solution for me right now.
As I am back to AMOS after 15 years of touching it (even 15 years before I wasn't so familiar) it is somehow new for me.
I am a Java developer right now, and I know some C and C++ basics. But AMOS (with all this AMAL and bobs/sprites) is quite different. And we have no so much power as in nowadays programing languages

I will update You with my results.

[wojt_gl]

Hello
I will update the information here.
As my game evolve amount of bobs increased little bit to much (about 200 or more) - so it was impossible to manage that with bobs.
For now I have a solution with bobs stored only in memory, but when needed I am copying them to screen (not drawing). When needed update of screen part where bobs needs to be destroyed - i just use some block of screen copied before any bob was here (empty background image).
For now i have only 2 bobs animated on my palyground - and everything works fine - with double buffer enabled there is constant speed and no problems with that at all....


But... it looks like i need to store more bobs in memory for using them later :/ And here I go with new question:
- can I copy a part of screen (loaded from iff file) to some other entity than bob - and then when needed  paste/draw it to background
- or should i dynamically manage the collection of bobs, and store in memory only those which i need at the moment (for whole level)?

Thx

[SamuraiCrow]

If you need to transparent blit a screen section to another screen, you can always use the appropriate version of the Screen Copy function, but the limitation of that is that both screens have to be in CHIP memory for that to work.  A better option might be to do Bank Swap command on your BOB Banks so that they get pasted and unpasted using Paste BOB and no automated double buffering.  This will let you use the AMCAF extension's Bank To Fast and Bank To Chip if you're running out of Chip RAM.