PureBasic Forums - English

Posted: **Wed Jul 16, 2008 7:00 pm**

Hi,

I'm trying to create a very simple game, where I move a rectangle with the mouse.

The problem is that the move of the box isn't smooth, it looks like the game is using a lot of cpu...

Here is the code:

Code: Select all



If InitSprite() = 0 Or InitKeyboard() = 0 Or InitMouse() = 0
  MessageRequester("Error", "Error", 0)
  End
EndIf

UsePNGImageDecoder()

If OpenScreen(640, 480, 16, "Sprite")

  LoadSprite(0, "box.png", 0)
  
  Repeat

    FlipBuffers()
    ClearScreen(RGB(0,0,0))
    
    ExamineMouse()
    
    x = MouseX()
    y = MouseY()
    
    DisplaySprite(0, x, y)
    
    ExamineKeyboard()
    
  Until KeyboardPushed(#PB_Key_Escape)

EndIf

End

Any help?

Thanks!

Posted: **Wed Jul 16, 2008 7:27 pm**

Ok, no easy answer here...

1) Too much CPU

Try using FlipBuffers(2) for smart CPU saving, or else put a delay(1) before doing the flipbuffer()

2) Box isn't smooth

That is because the mouse coordinates are being updated on screen at least 60 times a second (for a 60mhz refresh rate).

And it's almost impossible you get the same position twice.

There is nothing else going on the the screen at the moment, so the effect is more noticeable.

Once you get more stuff in you won't notice that because the CPU has more work and the graphic card too

Posted: **Wed Jul 16, 2008 7:56 pm**

fast answer

that helps!!!

thanks!

Posted: **Wed Jul 16, 2008 9:20 pm**

However:
http://www.purebasic.fr/english/viewtopic.php?t=32398

Posted: **Thu Jul 17, 2008 8:32 am**

Also, you should use SetFrameRate().

Posted: **Thu Jul 17, 2008 3:11 pm**

Be wary of setframerate and windowed screen games. It does seem to work, however every now and then I've found it thrashes the CPU for 5-10 seconds at a time and causes major framerate hits. I'm 90% sure that its Setframerate causing it but YMMV.

Posted: **Thu Jul 17, 2008 4:09 pm**

that's right, a windowedscreen always is synced to the desktop, wich should be 60Hz in general.

on a fullscreen, SetFrameRate() causes FlipBuffers() to wait for the desired time,
that will cause your CPU to lock up on 100%.

better implement a timer-controlled object movement and let the system decide about the FPS,
or combine a preset framerate with an adjusted Delay()

Posted: **Sat Jul 19, 2008 9:16 am**

You should use #PB_Sprite_Memory to load the Sprite, it's faster.

Posted: **Sat Jul 19, 2008 12:34 pm**

pg wrote:You should use #PB_Sprite_Memory to load the Sprite, it's faster.

I'm sorry, but this is simply not true, how did you get to this idea?

Posted: **Sat Jul 19, 2008 3:07 pm**

it's correct ... it's not true

I have tested it now and it's even slower.
I get this idea because it's faster to access memory locations of a sprite, but this does aparently not happen when using the DisplaySprite command.

Code: Select all

If InitSprite() = 0 Or InitKeyboard() = 0 Or InitMouse() = 0 
  MessageRequester("Error", "Error", 0) 
  End 
EndIf 

UsePNGImageDecoder() 

If OpenScreen(800, 600, 32, "Sprite") 

  LoadSprite(0, "box.png", 0)   
  LoadSprite(1, "box.png", #PB_Sprite_Memory) 
  
  StartDrawing(SpriteOutput(0))
  addr1=DrawingBuffer()
  StopDrawing()
  
  StartDrawing(SpriteOutput(1))
  addr2=DrawingBuffer()
  StopDrawing()
  
  
  t1=GetTickCount_()  
  x=0  
  Repeat     
    m=PeekB(addr1)
    x=x+1 
  Until x=5000000
  t2=GetTickCount_()
  t3=t2-t1



  t1=GetTickCount_()  
  x=0  
  Repeat     
    m=PeekB(addr2)
    x=x+1 
  Until x=5000000
  t2=GetTickCount_()
  t4=t2-t1
  
  
  
EndIf 
CloseScreen()

MessageRequester("Time","without #PB_Sprite_Memory = "+Str(t3)+Chr(13)+Chr(10)+" with #PB_Sprite_Memory = "+Str(t4))


End

Posted: **Sat Jul 19, 2008 6:45 pm**

I get this idea because it's faster to access memory locations of a sprite, but this does aparently not happen when using the DisplaySprite command.

that's exactly the point.

processing graphical data e.g. creating a cloud by a complex calculation is an action that is performed by the CPU.
if you are doing such things, sure it's faster to do it in the main memory, wich the CPU can access directly,
than to do it in the GMEM, wich means that each single value has to be pushed thru the GPort.

when taking a bunch of pictures and displaying them on a screen,
it's faster to store the pictures from the beginning in the GMEM where also the screen itself is placed.
not a single byte has to pass the GPort back or forth, you just tell the GPU
wich part of it's GMEM to push where else in it's GMEM, thats all.

Posted: **Sat Jul 19, 2008 7:32 pm**

It is still faster to copy cpu mem to screen mem

You can try it with CopyMemory() or Poke Commands....

Posted: **Sat Jul 19, 2008 8:25 pm**

> It is still faster to copy cpu mem to screen mem
faster than what.
writing screen mem to screen mem?

you can't test this with CopyMemory or Poke, because both methods work via CPU,
so when writing screenmem to screenmem using this commands,
you'll pass the GPort bottleneck TWICE!

Posted: **Sat Jul 19, 2008 9:13 pm**

you are assuming that every computer uses a GPU? Right?

Posted: **Sat Jul 19, 2008 9:22 pm**

PureBasic Forums - English

Display sprite too slow

Display sprite too slow