Reply With QuoteOGL only... I'm not clever enough to learn a new API now in my dotage. Seriously. My brain hurts.
Cas
just downloaded 2 of your games.. they look great! do you use OGL for windows also, or you have a DX fallback renderer?Originally Posted by princec
If you wanted to write one of my sorts of game though you'd be a bit buggered by the abysmal fill rate though... and we still maintain 60fps is the minimum acceptable
Also quite probable a software renderer would be even slower on OSX due to the fact that the surfaces are effectively then fed back through OpenGL when you could be going direct.
Cas
OGL only... I'm not clever enough to learn a new API now in my dotage. Seriously. My brain hurts.
Cas
Have you got any figures for the Java 6 VM? (Client and server). Interestingly I didn't get any speed increase at all when using -server, which is odd as it usually gives you a 20-50% boost.
Cas
I updated mine - I didn't realize I had the frame rate clamped at 73. Not relevant for the 2000 sprite test but relevant at lower #s. I also added an 'A' toggle to disable alpha blending.
With 500 sprites (512,000 pixels, plus the memset of the background to black), I'm at about 85-105 FPS with alpha (FPS is not real stable), 140 with no alpha.
Here is the Blitz3D version
At first I wanted to use my crude 3D/2D framework but I realized the performance was far from competitive with the other examples uploaded so I rewrote everything from scratch using single surface sprites (not used in my engine because I want maximum texture quality).
keys: up/down (size of sprites) and left/right (number of sprites:100<>2000)
Download
Last edited by electronicStar; 06-26-2006 at 11:06 PM.
electronicStar - yours is only 640 x 480 - the others are 800 x 600. Also, your sprites don't appear to be alpha'd
Okay I reuploaded a new version in 800X600 with alpha, at the same link.
[EDIT] ...and a third version with a good FPS counter
Last edited by electronicStar; 06-26-2006 at 08:54 PM.
It doesn't seem to work on my work Dell GX280 (Intel 82915G Express gfx). I get a window with menus at the top but the rest of the window just shows the desktop behind it as if it's never being drawn on. Just thought I'd mention it
The philSteinmeyer software demo works surprisingly well on my crappy work's computer (that generally doesn't run sh*t) at a steady 30 FPS.
Thanks to everyone who has participated in the test. I still don't understand why a version from TGB or PopCap framework hasn't been coded. I don't know that much about either of those, but am I wrong in thinking those are two of the more "high level" solutions?
Hi !
Here's the Asphyre version(Delphi,DX9)
http://www.afterwarp.net/forum/
Download:
http://www.afterwarp.net/forum/attac...0&d=1151400335
The sprite engine I use is very high level too (hence it's a bit slower than the others)
Cas
Hi DraculaLin -
Cool to see a DX9 sprite engine running for comparison to my own early DX9 efforts. (I'm getting very similar results to yours btw.) Are you using the D3DXSprite Object by any chance? That seems amazingly fast for doing 2d sprites in DX9. Disclaimer: I still think requiring DX9 for a 2D app is crazy.
FYI: Your demo runs TWICE as fast as any of the other demos tested on my intel box.
Hey Cas -
"The sprite engine I use is very high level too (hence it's a bit slower than the others)"
I doubt it's higher level that the generic sprite engine I use. Hell, even the pong movement was automated.
No,Asphyre doesn't use D3DXSprite.Are you using the D3DXSprite Object by any chance?
It's made up of two triangle texture and four vertices.
Yeah, it's about the same... mostly configured with XML and such.I doubt it's higher level that the generic sprite engine I use. Hell, even the pong movement was automated.
Cas
my own renderer
please, can someone test my own renderer
http://www.woxxom.com/slayerizer-cpp-dx.zip
Information:
- DirectX 8
- C++
- directly set to 2000 alpha blended sprites
- sprites rendered via 2xtriangles (not using the pointsprite function)
I got 130fps on my laptop at work (with Intel video card)
thanks!
I get 133 windowed and 153 fullscreen. Hope that helps
WinXP
Athlon XP 1900+
GeForce Ti 200 (128MB)
512 MB RAM
More of the x-platform stuff please.... I've got me a MacBook here and I intend to use it (it's just lovely).
I tried MCF Huntsville on my G5 the other day (trying to wrest Charlotte off of my dev laptop y'see) but it was so shit and slow and crappy feeling vs. the Windows one it's unbelievable. I'd never have bought it for the Mac. That's software rendering for you
Cas
"please, can someone test my own renderer:
http://www.woxxom.com/slayerizer-cpp-dx.zip"
39fps on my intel box. Which is pretty much inline with the other DX8 tests offered.
584 fullscreen
540 windowed
Win XP Pro
3.2Ghz Dual cpu
nVidia geForce 6800 (256M)
4 Gig Ram
I've updated my table of results, here it is:
Computer: P4, 2.0 GHzCode:100 500 1000 2000 4000 ------------------------------------------------------------- VB DX window 460 226 140 80 - (dxgame) full 428 216 138 80 - ------------------------------------------------------------- C++/DirectX window 512 250 155 86 46 (undersan) full 808 312 173 94 50 ------------------------------------------------------------- BlitzMax DX window 636 342 216 126 68 full 1150 462 266 144 76 GL window 596 292 180 102 54 (indiepath) full 676 380 214 116 60 ------------------------------------------------------------- OpenGL GL window 912 408 240 133 70 (wiering) full 950 425 252 139 73 ------------------------------------------------------------- Java (princec) full 760 280 158 85 45 ------------------------------------------------------------- PTK DX window 256 252 202 115 61 full 85 85 85 85 63 GL window 85 85 85 83 42 (Emmanuel) full 75 75 75 75 74 ------------------------------------------------------------- DelphiX DX window 544 235 137 75 39 (wiering) full 578 248 145 79 40 ------------------------------------------------------------- NC (Phil - window 63 32 20 11 6 Steinmeyer) full 63 33 20 11 5 ------------------------------------------------------------- Blitz3D window 253 210 160 95 - (electronicStar) ------------------------------------------------------------- Asphyre window 650 366 237 139 76 (DraculaLin) full 1712 684 395 214 111 ------------------------------------------------------------- slayerizer DX window 686 370 233 135 - full 1220 480 273 147 - ------------------------------------------------------------- GameMaker window 500 144 80 43 22 (radian) full 402 130 75 42 23
Video card: NVIDIA GeForce4 MX 460
OS: WinXP
Last edited by Mike Wiering; 06-30-2006 at 06:55 AM.
Mike Wiering
Wiering Software - http://www.wieringsoftware.nl/
Thank you Mike Wiering for updating the charts, if you have time it would be useful to add to the chart which versions of DirectX the tests are using.
chart update!
Since Mike updated his scoreboard, I decided to follow up
Code:------------------------------------------------------------- VB DX window 145 (dxgame) full 145 ------------------------------------------------------------- C++/DirectX window 473 (undersan) full 480 ------------------------------------------------------------- BlitzMax DX window 520 DX full 530 GL window 892 GL full 1020 ------------------------------------------------------------- OpenGL GL window 894+ (wiering) full 950+ ------------------------------------------------------------- PTK DX window 253 full 253 GL window 256 full 256 ------------------------------------------------------------- DelphiX DX window 820 (wiering) full 871 ------------------------------------------------------------- NC soft window 30 soft full 31 ------------------------------------------------------------- Asphyre window 473 (DraculaLin) full 481 ------------------------------------------------------------- slayerizer window 980 full 1020
updated version!
I have updated my demo. It's now possible to increase/decrease the sprites count from 100 to 2000
http://www.woxxom.com/slayerizer-dist-v2.zip
I optimized something, I,m now getting better FPS..
I would be willing to work on a TGB demo of the above scenario, but there are a few issues with how the scenario was defined:
Not a big issue, but TGB provides a debugging information banner that already includes this type of information, so I plan on just using that.Frame rate display should be toggled on/off by pressing the "F" key. When turned off, we can validate the frame rate by using something like Fraps, etc. Even though the Fraps I have only supports DX8 and up?
Number of sprites on displayed should be toggled on/off by pressing the "S" key.
This one is a pretty big issue--the requirement has some implied assumptions regarding how the underlying simulation is managed, both in processing and rendering.Sprites move 1 pixel per frame update. (No time based code, etc.)
For example, TGB abstracts all rendering away from the developer by design--if you don't want to worry about direct rendering calls, you never need to see them. Part of that abstraction however is that you don't have any type of concept at the higher "build your game" level regarding the screen itself--the screen could be on a Mac, or an OpenGL device, or a D3D device, or an XBox360. TGB has a world coordinate system that abstracts out the underlying screen entirely, and instead you work with world coordinate for your object's location, as well as object updates.
In other words, TGB intentionally does not expose any ability to move an object based on pixels, but on world coordinates. Of course, with a source code license, you can change this, but changing it would take away quite a bit of the cross-platform and cross-device functionality, so it's not exposed by default.
In addition, TGB's movement physics are abstracted away from frame updates--the underlying simulation is written to make your game behaviour act as independent as possible from the player's current frame rate, and therefore your movement velocities are independent of frames per second.
For example, I downloaded and ran one of the demo's written by others, and when there were 100 sprites on the screen, each sprite moved at a very high velocity. As more and more sprites were added, their individual velocities slowed down greatly. TGB wouldn't display this effect at all using stock--the objects would all move at their individually set speeds regardless of the frame rate (up to boundary conditions of course).
In other words, the condition "no time based code" would actually require extensive re-writing of the abstraction layers of TGB, and by design it doesn't work that way, so as long as we can ignore this condition, we can meet the rest of the test, but meeting that condition as a hard and fast rule is basically a breakdown of the design intent of TGB, and really not worth hitting from our perspective.
The final thing I'd like to comment on regarding a TGB benchmark of this test would be that each of the renderers above (as far as I can tell anyway) were custom written for the test case, or at least fine tuned to be optimized for the case. As was mentioned in the second post of the thread, the benchmark doesn't really capture an accurate game scenario, and a higher level tool like TGB isn't going to be optimized for a specific case like this. Of course, our benchmark wouldn't be giving up all the rest of the functionality TGB provides either!
Stephen Zepp
GarageGames, Inc.
Oh shut up and show us the numbers.
Re: fine tuning/customing for the test case... baloney. You have 2000 sprites. Blit() them. Display frame rate. End of story.
TGB doesn't use blit, and doesn't expose blit as an option to the developer in stock--and more importantly, we don't think that this type of low level implementation requirement is something that's appropriate for the TGB target market.Oh shut up and show us the numbers.
Re: fine tuning/customing for the test case... baloney. You have 2000 sprites. Blit() them. Display frame rate. End of story.
Absolutely, end users that do want that type of control (assuming they have a source code license) can do whatever they want regarding the low level rendering implementation, but the purpose of TGB in a nutshell is making it so that it isn't required.
Pygame has a testsprite.py example...
There is no executable, since I couldn't be bothered.
It's in the pyame examples... I added per pixel alpha to its options in svn. but you can get it here: http://rene.f0o.com/~rene/stuff/examples.zip
You'll need pygame. http://www.pygame.org/
It gets *way* lower speeds for per pixel alpha blitting compared to opengl. Hopefully the new SDL will fix that problem... once it's opengl, and new dx backends make it out in SDL 1.3.
However it gets pretty high speeds for other simple image types. Since it uses 2D hardware acceleration. Within 5% of the C SDL speed anyway.
-- Just for giggles...
NOTE: this uses a different sprite image so you can't really compare(I'm lazy). You can tell that doing lots of alpha blended sprites is slow with pygame/SDL. Probably 300 per pixel alpha blended sprites is the maximum at this resolution for a slow computer. If you need to do lots of alpha blended sprites, use an opengl/dx based solution.
Duron 850, gf4 mx, agp1, debian, xorg, SDL 1.2.9(without the faster alpha blitting routines in 1.2.11)
software, alpha, dirty rects.
python2.4 testsprite.py -alpha -sw -psyco -update -update_rects -width 800 -height 600 2000
2000 sprites 3.3fps
python2.4 testsprite.py -alpha -sw -psyco -update -update_rects -width 800 -height 600 1000
1000 sprites 7fps
python2.4 testsprite.py -alpha -sw -psyco -update -update_rects -width 800 -height 600 500
500 sprites 14fps
python2.4 testsprite.py -alpha -sw -psyco -update -update_rects -width 800 -height 600 100
100 sprites 70fps
python2.4 testsprite.py -alpha -sw -psyco -update -update_rects -width 800 -height 600 50
50 sprites 130fps
Have fun!
Hi Stephen Zepp,
Yah, the whole frame based vs time based movement is moot. I think the majority of us just want to see how many objects (sprites) we can easily move around the screen. With eye candy becoming more and more important even in casual games, render speed is very important.
Throw up a demo with a bunch of sprites moving around in a 800x600x32 screen, if TGB is half as easy as the hype, it should be a piece of cake!
BTW - I downloaded the TGB PC demo (40mb+ on dial up!) and ran the included demos, the render speed looks about on par with anything else I've been running.
I was curious if anyone had just gone ahead and done this on their own with the trial (it is pretty easy to accomplish once you get rid of the single pixel movement requirement). As a company employee I have to go through the right channels (this is our first major public exposure test case, so it's caught some attention) so anything from me will be delayed a bit, but it's not too difficult to do with the level builder and just a couple of scripts (you don't want to use the level builder to create 2000-4000 sprites, so it should be done procedurally).Hi Stephen Zepp,
Yah, the whole frame based vs time based movement is moot. I think the majority of us just want to see how many objects (sprites) we can easily move around the screen. With eye candy becoming more and more important even in casual games, render speed is very important.
Throw up a demo with a bunch of sprites moving around in a 800x600x32 screen, if TGB is half as easy as the hype, it should be a piece of cake!
BTW - I downloaded the TGB PC demo (40mb+ on dial up!) and ran the included demos, the render speed looks about on par with anything else I've been running.
Posting Permissions