Display sprite too slow

[yabune]

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!

[Num3]

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

[yabune]

fast answer

that helps!!!

thanks!

[Psychophanta]

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

[Heathen]

Also, you should use SetFrameRate().

[dracflamloc]

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.

[Kaeru Gaman]

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()

[pg]

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

[Kaeru Gaman]

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?

[pg]

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 

[Kaeru Gaman]

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.

[pg]

It is still faster to copy cpu mem to screen mem
You can try it with CopyMemory() or Poke Commands....

[Kaeru Gaman]

> 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!

[pg]

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

[Kaeru Gaman]