Here is the project and code for the Sprite Speed Tester
[attachment deleted by admin]
Cool, thanks for letting me take a look at that. I see that you limited Webos to 100 Sprites, does it run slower with more than 100?
Yes, the scaling really hammers performance. 100 is a bit iffy, but more or less decent.
SIZE=10000, FPS=22.5 on my PC. Isn't that enough?
In the Pre - DO NOT use DRAWSPRITE commands for such a huge number of sprites. Use the polyvector / plynewgroup method instead. Texture changing and glDrawXX calls are so expensive on these gadgets.
I have Wumbo's Adventure (15x10 tiles, 32x32 pixles) with a sprite layer for the enemies and a background layer for the hearts running at 60 FPS on the Pre2 with OS 2.x.
I get the following error when I try to compile it for PC
..\..\Routines\TAppTime.gbas (failed to open)
"SpriteSpeedTester.gbas"(63) error : user type is not defined : TYPE TAppTime is not declared
Am I missing a plug in?
You are indeed. I've included it.
QuoteIn the Pre - DO NOT use DRAWSPRITE commands for such a huge number of sprites. Use the polyvector / plynewgroup method instead. Texture changing and glDrawXX calls are so expensive on these gadgets.
Indeed - I just tried to see what it could cope with :)
[attachment deleted by admin]
Cheers Mr Toad, always like looking at other peoples code as it always teaches me new ways of doing things
I thought my PC was pretty high spec but compared to yours Gernot I need an upgrade :) 10000 sprites was 8 or 9 fps on my Q6700 2.66Ghz quad core with a Geforce GTX 275 and 8GB ram. I dread to think what yours is running :nw:
size 10000, fps 17
Athlon Dual core 6000 (2x3000) 6gb ram
ATI radeon 4800 512mb
I get the same error as Gary_Leeds...
I guess I must add Mr Toad´s function to it right?
Edit: ops, never mind, just read the thread in full...
I'm getting an average of 23.0 FPS at SIZE=10000 and
at SIZE=1000 I get 207 to 230 FPS
Home built PC:
CPU: Quad Q6600 (G0) L728A861 @ 3.5Ghz (originally 2.4Ghz) (oldie but goody)
MOBO: GIGABYTE GA-P35-DQ6 P35
VIDEO: GIGABYTE ATI Radeon HD 4890 1GB GDDR5 256-bit
CPU COOLING: ZALMAN CNPS9700 CPU Cooling Fan/Copper Heatsink
MEMORY: G.SKILL 4GB(2x2GB)
CASE: Antec Nine Hundred with 5 Antec Variable Speed Fans
PSU: RAIDMAX VOLCANO RX-630A 630W ATX12V V2.2/ EPS12V Modular Blue LED Power Supply
STORAGE: OCZ Agility SSD Series 2.5" 120GB SATA II MLC SSD 211MB/158MB
EXT. STORAGE: Western Digital Caviar Green 1.5TB SATA 3.5" Hard Drive
Hm. Maybe I did calculate the FPS wrong?
My computer is just a DELL M6500 laptop (see signature).
I cant compile this, due missing TAppTime.Gbas and is not included. Remember to include anything, if you include source for it
Its included in my previous post.
sorry, I diddent see that. I should read the whole thread, but would been nice to edit the post to include the missing file too.
I changed MrTAToad (I hope You don't mind) code a little - added drawing sprite through Polyvector - both normal and rotozoom, to see what speed up it will give...
And I'm really surprised with results, I expected that polyvector would be much faster - Am I doing something in wrong way?
Use:
?DEFINE USEPOLY 1
?DEFINE ROTOZOOM 1
to change drawing options..
my results:
Radeon 2600XT => SIZE = 1000
GF2 mx400 (:DD) => SIZE = 100 (You can compare it to mobile devices)
min_fps / max_fps / mostly
---------------RotoZoomSprie-----DrawSprite-----RotoZoomPoly-----DrawPoly
Radeon 2600XT---56/101/~74------215/222/~218----52/147/~100------215/222/~218
GF2 mx400-------22/32/~25--------30/30/~30-------21/29/~25--------30/30/~30--
[attachment deleted by admin]
I suspect the rotating and zooming counters any possible advantages Polyvector would normally supply...
for me, rotozooming polyvectors were faster than rotozooming sprites O_O
With size at 10000:
4.5-5.5 FPS using rotozoomsprites
8-12 FPS using polyvectors
Doesn't this count as quite a bit faster?
EDIT: On PC...
The old card can definitely _NOT_ be compared to mobile devices. These lagacy cards are "optimized" for glBegin/glEnd draw calls. Newer day cards are optimized for one-batch calls. Same goes for EGL devices. Please try a real device to see the real difference.
Code looks OK from first glance.