Xojo Conferences
MBSSep2018MunichDE
XDCMay2019MiamiUSA

Spritesurface and speed of display drawing (Real Studio games Mailinglist archive)

Back to the thread list
Previous thread: Down or Right movement
Next thread: fmod, quicktime, other alternatives?


Spritesurface and speed of display drawing   -   Heinz J. Gattringer
  Re: Spritesurface and speed of display drawing   -   Joseph J. Strout
  Re: Spritesurface and speed of display drawing   -   Heinz J. Gattringer

Spritesurface and speed of display drawing
Date: 17.01.05 23:39 (Mon, 17 Jan 2005 17:39:29 -0500)
From: Heinz J. Gattringer

Hello,

I am moving along with my RTS sort of game. I have performed some code
optimization so that the A.I. that controls the behavior of the sprites
or objects in the game performs reasonably fast. There are quite a
number of objects in the game.

What worries me is that in my frames per second gauges I have noticed
that the numerous A.I. routines performed do not nearly have as much an
impact on the fps count than the number of sprites on screen at a
certain point in time. This despite the fact that the A.I. routines are
run through no matter if an object is currently in the visible screen
area or not. This leads me to the conclusion that what takes the cpu
the most time to complete is the drawing of the sprites to the screen,
which is handled by Realbasic. This makes me wonder whether Realbasic
is using the graphics card hardware or not for this operation. So my
question in short:

Does Realbasic make use of graphics-card hardware in its Spritesurface
implementation and if not, is there a way of instructing Realbasic to
use graphics-card acceleration from within code for the handling of
sprites?

greetings,
Heinz Jose

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Spritesurface and speed of display drawing
Date: 18.01.05 00:10 (Mon, 17 Jan 2005 17:10:37 -0600)
From: Joseph J. Strout
At 5:39 PM -0500 1/17/05, Heinz J. Gattringer wrote:

>What worries me is that in my frames per second gauges I have
>noticed that the numerous A.I. routines performed do not nearly have
>as much an impact on the fps count than the number of sprites on
>screen at a certain point in time. This despite the fact that the
>A.I. routines are run through no matter if an object is currently in
>the visible screen area or not. This leads me to the conclusion that
>what takes the cpu the most time to complete is the drawing of the
>sprites to the screen, which is handled by Realbasic.

That's a good start, but you should actually measure it and find out.
Run a case where you turn off the display entirely, and run another
where you turn off the AI (it may be hard to make that case
comparable of course -- to really do it properly, you'd have to
record all the unit movements and shape changes, so you can play them
back without doing the hard AI computations).

Another thing you could do is simply profile your running app. If
you're using OS X, then Shark (a free tool from Apple, part of the
CHUD tools) is a great one.

> This makes me wonder whether Realbasic is using the graphics card
>hardware or not for this operation.

It is not. If you want hardware acceleration, then use the Rb3DSpace
instead. See "Three Ways to Animate" in issue 1.1 of REALbasic
Developer for more info.

Best,
- Joe

Re: Spritesurface and speed of display drawing
Date: 20.01.05 16:34 (Thu, 20 Jan 2005 10:34:43 -0500)
From: Heinz J. Gattringer

On Jan 18, 2005, at 1:00 PM,
<email address removed> wrote:

> That's a good start, but you should actually measure it and find out.
> Run a case where you turn off the display entirely, and run another
> where you turn off the AI (it may be hard to make that case
> comparable of course -- to really do it properly, you'd have to
> record all the unit movements and shape changes, so you can play them
> back without doing the hard AI computations).

Well, I have sort of done this measurements, albeit maybe not very
scientifically.
1- Checking the speed of the display drawing: I scroll to a part of
the game area where no sprites are located, so that there is no
redrawing of the screen, although the A.I. keeps tracking and
controlling all the offscreen objects: the fps count about triples. (By
the way, when scrolling the fps count really drops steeply, although I
find this not to be much of a negative influence on the game).
2- Timing only the A.I.: I check the microseconds before and after
the A.I. routines, not including the spritesurface.update call, which
does the actual screen drawing. Comparing this number to the fps I get
while the game runs with a full compliment of sprites in the visible
screen area, the A.I. does not take up much time.

> Another thing you could do is simply profile your running app. If
> you're using OS X, then Shark (a free tool from Apple, part of the
> CHUD tools) is a great one.
>

Sounds interesting, will try.

> It is not. If you want hardware acceleration, then use the Rb3DSpace
> instead. See "Three Ways to Animate" in issue 1.1 of REALbasic
> Developer for more info.

Thinking about it, although it would be neat also to get the game to
run smoothly without hardware acceleration and have wide ranging low
end compatibility. I actually downloaded REALbasic Developer 1.1 as the
'demo' issue, but unfortunatly the "Three ways to animate" article was
grayed out :•p. But I think I will buy that issue just for that article
(or even subscribe).

Thanks
Heinz Jose_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>