Screen glitches with mouse movement or key press

[Sparticle]

Hi,

I'm still working on the game I mentioned in my previous post.
The game doesn't flicker any more as its being drawn but when I move the mouse or press the keyboard I get screen glitches.

Here's the paint function I'm using:

void GamePaint()
{
  struct RastPort rp;
  struct BitMap* bm;
  bm = AllocBitMap(1024,1024,4,BMF_DISPLAYABLE|BMF_CLEAR,NULL);
 
  InitRastPort( &rp );
  rp.BitMap = bm;
 
   MoveSprite(vp, &my_sprite,X,Y);
     
  DrawImage(&rp, &BG,BitMapOrigin.X, BitMapOrigin.Y);
  Pipes[0].DrawPipe(&rp);
  Pipes[1].DrawPipe(&rp);       
 
 DrawImage(&rp, &Ground,X2, BitMapOrigin.Y+WINDOW_HEIGHT - Ground.Height);
           
         
 DrawImage(&rp, &Ground2,X3,  BitMapOrigin.Y+WINDOW_HEIGHT -Ground2.Height);
            
          
  BltBitMapRastPort(bm,
            BitMapOrigin.X,
            BitMapOrigin.Y,
            App.GetWindow()->RPort,App.GetWindow()->BorderLeft-4, 
           App.GetWindow()->BorderTop-12,WINDOW_WIDTH,WINDOW_HEIGHT,
          0xC0);

}

[thomas]

A bitmap of 1024 x 1024 x 4 needs 512 KB continuous Chip RAM. It will never run on a A500. You should rather allocate the bitmap with a size of WINDOW_WIDTH x WINDOW_HEIGHT.

You should also specify the screen's bitmap as friend to AllocBitMap. This way the system will optimize the allocation in such a way that blitting into the screen is as fast as possible.

I would put MoveSprite after BltBitMapRastPort. Otherwise the sprite moves faster than the background.

Regarding your blitting dimensions, BorderLeft and BorderTop are font-sensitive, 4 and 12 are not. What do you intend with this calculation? If your window has a border, you overwrite part of it. If it does not have a border, you blit outside of the window. For a borderless window 0,0 should be right and for a window with border BorderLeft,BorderTop without substraction.

BitMapOrigin is not needed at all if your bitmap has the same size as the window (my first point above).

Talking about glitches, how do you wait for the next frame?

[Sparticle]

Originally Posted by thomas

A bitmap of 1024 x 1024 x 4 needs 512 KB continuous Chip RAM. It will never run on a A500. You should rather allocate the bitmap with a size of WINDOW_WIDTH x WINDOW_HEIGHT.

You should also specify the screen's bitmap as friend to AllocBitMap. This way the system will optimize the allocation in such a way that blitting into the screen is as fast as possible.

I would put MoveSprite after BltBitMapRastPort. Otherwise the sprite moves faster than the background.

Regarding your blitting dimensions, BorderLeft and BorderTop are font-sensitive, 4 and 12 are not. What do you intend with this calculation? If your window has a border, you overwrite part of it. If it does not have a border, you blit outside of the window. For a borderless window 0,0 should be right and for a window with border BorderLeft,BorderTop without substraction.

BitMapOrigin is not needed at all if your bitmap has the same size as the window (my first point above).

Talking about glitches, how do you wait for the next frame?

Thanks for the reply.

The Window does have a border. I used subtraction as it wasn't drawing from the top left corner of the window. I will change it as recommended.

I thought I would use a bigger bitmap because the pipes are tall and placed randomly vertically and didn't want them to be drawn outside the bitmap storage.

Im not sure about the next frame. The game is cycled through the windows outer main message loop like this:

while( !EndMsgLoop)
	{
	   
          
		while(Message = (struct IntuiMessage *) GetMsg(MyWindow->UserPort))
		{
                   // Handle messages etc
                }
GameCycle();
GamePaint();
        }

All the positions etc are updated in the GameCycle function and the drawing in GamePaint. Im not sure if this is the right way to go about it.

[thomas]

Originally Posted by Sparticle

I thought I would use a bigger bitmap because the pipes are tall and placed randomly vertically and didn't want them to be drawn outside the bitmap storage.

If you need clipping, here is an example how to use layers.library on an off-screen bitmap: http://thomas-rapp.homepage.t-online.de/examples/clip.c

Im not sure about the next frame. The game is cycled through the windows outer main message loop like this:

I don't see any synchronisation with the display or with the clock. Is it really so that you just draw as fast as you can, without any synchronisation? This means on a fast machine the game might become unplayable fast?

I would expect a WaitTOF() or WaitBOVP() somewhere in the loop. Or some use of timer.device or IDCMP_INTUITICKS.

[Thorham]

Originally Posted by thomas

I would expect a WaitTOF() or WaitBOVP() somewhere in the loop.

You shouldn't use WaitBOVP() because it busy-waits. If you want to sync with the bottom of the frame, use a copper interrupt handler and send a signal.

[Sparticle]

Originally Posted by thomas

If you need clipping, here is an example how to use layers.library on an off-screen bitmap: http://thomas-rapp.homepage.t-online.de/examples/clip.c

I've tried to use clipping but still having the same problem. WaitTOF() doesn't solve the issue either no matter where i put it in the loop. Same as WaitBOVP().
Ive also tried controlling the frame rate using timing and still makes no difference even at 1 fps.

Iv'e noticed if I dont use a custom screen in the game and set the screenmode to 16 colors the issue goes away but only in hires. changing to lores still gives me the same problem

[Sparticle]

Originally Posted by Thorham

You shouldn't use WaitBOVP() because it busy-waits. If you want to sync with the bottom of the frame, use a copper interrupt handler and send a signal.

Thanks for the reply.

I don't have a clue how to set up a copper interupt handler.
Are there any examples on how to do this?

[Jherek Carnelia]

You will find examples of using interrupts with C in the RKM - Libraries. I have attached an extract from the relevant chapter.