The 2006 2D Sprite Render Test

Discussion in 'Game Development (Technical)' started by dxgame, Jun 23, 2006.

  1. Mike Wiering

    Original Member

    Joined:
    Jul 28, 2004
    Messages:
    246
    Likes Received:
    0
    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
     
    #81 Mike Wiering, Jun 28, 2006
    Last edited: Jun 30, 2006
  2. 2dnoob

    Original Member

    Joined:
    Jun 23, 2006
    Messages:
    64
    Likes Received:
    0
    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.
     
  3. Slayerizer

    Original Member

    Joined:
    Dec 13, 2004
    Messages:
    103
    Likes Received:
    0
    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
    
     
  4. Slayerizer

    Original Member

    Joined:
    Dec 13, 2004
    Messages:
    103
    Likes Received:
    0
  5. StephenZepp

    Original Member

    Joined:
    Oct 11, 2005
    Messages:
    3
    Likes Received:
    0
    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.
     
  6. Pyabo

    Original Member

    Joined:
    Jul 27, 2004
    Messages:
    1,316
    Likes Received:
    0
    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.
     
  7. StephenZepp

    Original Member

    Joined:
    Oct 11, 2005
    Messages:
    3
    Likes Received:
    0
    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.
     
  8. illume

    Original Member

    Joined:
    Jul 27, 2004
    Messages:
    207
    Likes Received:
    0
    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!
     
  9. dxgame

    Original Member

    Joined:
    Mar 11, 2005
    Messages:
    267
    Likes Received:
    0
    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. :)
     
  10. StephenZepp

    Original Member

    Joined:
    Oct 11, 2005
    Messages:
    3
    Likes Received:
    0
    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).
     
  11. aduro

    Original Member

    Joined:
    Sep 4, 2004
    Messages:
    28
    Likes Received:
    0
  12. Rubs

    Original Member

    Joined:
    Dec 16, 2005
    Messages:
    115
    Likes Received:
    0
    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?
     
  13. dxgame

    Original Member

    Joined:
    Mar 11, 2005
    Messages:
    267
    Likes Received:
    0
    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.
     
  14. Mike Wiering

    Original Member

    Joined:
    Jul 28, 2004
    Messages:
    246
    Likes Received:
    0
    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.
     
  15. Rubs

    Original Member

    Joined:
    Dec 16, 2005
    Messages:
    115
    Likes Received:
    0
    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).
     
  16. radian

    Original Member

    Joined:
    May 2, 2006
    Messages:
    4
    Likes Received:
    0
    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.
     
    #96 radian, Jun 30, 2006
    Last edited: Jun 30, 2006
  17. Rubs

    Original Member

    Joined:
    Dec 16, 2005
    Messages:
    115
    Likes Received:
    0
    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.
     
  18. radian

    Original Member

    Joined:
    May 2, 2006
    Messages:
    4
    Likes Received:
    0
    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.
     
    #98 radian, Jun 30, 2006
    Last edited: Jun 30, 2006
  19. Savant

    Original Member

    Joined:
    Feb 8, 2005
    Messages:
    1,674
    Likes Received:
    0
    Nothing distracts programmers faster than a performance test feeding frenzy.
     
  20. aduro

    Original Member

    Joined:
    Sep 4, 2004
    Messages:
    28
    Likes Received:
    0
    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.
     
    #100 aduro, Jun 30, 2006
    Last edited: Jun 30, 2006

Share This Page

  • About Indie Gamer

    When the original Dexterity Forums closed in 2004, Indie Gamer was born and a diverse community has grown out of a passion for creating great games. Here you will find over 10 years of in-depth discussion on game design, the business of game development, and marketing/sales. Indie Gamer also provides a friendly place to meet up with other Developers, Artists, Composers and Writers.
  • Buy us a beer!

    Indie Gamer is delicately held together by a single poor bastard who thankfully gets help from various community volunteers. If you frequent this site or have found value in something you've learned here, help keep the site running by donating a few dollars (for beer of course)!

    Sure, I'll Buy You a Beer