I've updated my table of results, here it is: Code: 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 Computer: P4, 2.0 GHz Video card: NVIDIA GeForce4 MX 460 OS: WinXP
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. 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. 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. 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).
c++ and d3dxsprite i'm not sure if anyone tried this using the d3dxsprite class, so here is one (103Kb): http://www.adurogames.com/misc/adurospriterendertest.zip with 2000 sprites, i get 289 fps fullscreen, 255 fps windowed. 1.66 core duo radeon x1400
PopCap Framework Sprite Tester Here it goes: http://www.cubic-games.com/public/PopCapSpriteTester.zip Implemented the tester using latest PopCap frameworka and I'm not very imressed: For 2000 sprites: Windowed (without rotation): 37 Windowed (with rotation): 35 Fullscreen (without rotation): 61 Fullscreen (with rotation): 39 On AMD Athlon 2500+, GeForce4 MX 440 Could you test it on your machines and post your opinions here?
Hi aduro - Your test fails to run on my Intel Extreme Box. All other tests work fine. Also, please state which DX version it's using, thanks. Hey Rubs - Thanks for adding a PopCap Framework test. Works great on my Intel Box. Getting 49fps in full screen mode with 2000 sprites which puts it near the top of the list on my box at least. "I'm not very imressed.." I am! I've never used PopCap, but if the frame work is at a fairly high level, combined with good rendering speed, sounds like a winner to me.
Why on earth use this kind of key combinations? I have hot keys installed in Windows and that one brings up my DOS box, I don't feel like changing it to be able to see the frame rate in your program. You seem to have vsync() on anyway so it's always 85 fps for me.
Sorry man, I've used PopCap's internal FPS measurement and these keys are hardcoded. Didn't mean to make any harm . Hmm, I turned VSync off with my own err... keyboard. I wonder if it's happening because the framework uses time-based animation, but then you should be stuck at 100 fps (that's their default update speed).
Game Maker version http://www.radiangames.com/SpriteTestGameMaker.zip Two versions. 1 is using objects, 2 is using the built-in particle system (which only has random color per particle, so everything is the same alpha with variable brightness instead). Controls: ESC - quit F4 - toggle fullscreen/windowed F - toggle FPS/sprite count Arrow keys - Add/subtract sprites Sorry about the large EXE size, but that's about as small as a GM game gets. Should be DX 8.1.
Tried the GameMaker test. 34 fps both in Windowed and FullScreen mode for 2000 sprites. AMD Athlon 2500+, GeForce4 MX 440. Two drawbacks found: 1) When you switch to other app (even if the window is not visible) rendering process still continues and eats all CPU power. While PopCap pauses all its processes and thus does not load the system when out of focus. 2) It seems that GameMaker uses simple window size change and putting it on top of other windows for full-screen mode. I.e. does not use "real" full screen.
Oops. That can be fixed. I'll let you know when I get a new version up (probably the same time as the particle version). EDIT: Ok, both versions included in new zip above, hopefully with the problems Rubs noted fixed (note new URL). The particle-version is only marginally faster on my machine at work.
i used the dx9 libs from the latest directx sdk. if you run it with '> console.log' you'll get some success/fail test output. i just ran it on an intel graphics chip, it works if you have the latest directx.