Announcement

Collapse
No announcement yet.

Speaking of sprite engine

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • RyanCross
    replied
    Originally posted by Brice Manuel View Post
    It has been my experience that you should take what Patrice says with a grain of salt.
    Well I wasn't actually knocking Patrice. He helped me a lot with loading PNG graphics as textures and some other things back in the day when I started this software.

    Leave a comment:


  • Brice Manuel
    replied
    Its funny that you mention my PantherVST software not running on an eMachine, because the computer that my employeer provided me to develop Panther is an eMachine.
    It has been my experience that you should take what Patrice says with a grain of salt.

    Leave a comment:


  • RyanCross
    replied
    Its funny that you mention my PantherVST software not running on an eMachine, because the computer that my employeer provided me to develop Panther is an eMachine.

    My software was not designed to run on a high-end computer because it was created to run on a Proface/Xycom 1341 Industrial PC. Here are the specs of this PC:
    • PC is completely fanless
    • Intel ® Celeron® M 1.3 GHz
    • 512MB RAM
    • ATI Radeon 9250 PCI Graphics Card w/256MB RAM (added by us)


    As you can see the stats of this computer are nothing great. Even the video card we add is about 7 or 8 years old technology wise now.

    Leave a comment:


  • Paul Dixon
    replied
    I did some more benchmarking:..
    On Windows XP Home (SP2),
    ..
    GDImage (100 sprites) (I modified the program to up it to 100 sprites)
    9 FPS

    EZSPrite (100 sprites)
    14 to 21 FPS (averaged around 19 FPS) (200% faster)
    Out of curiosity I tried a little benchmarking of my own and on my 5 year old AthlonXP 1.9GHz WinXP computer my code will do 100 HalRed sprites of 140x140 pixels on a 800x600 screen, in 15ms which equates to about 66fps.
    With Patrice's code from post 89 changed to 100 sprites I get 18fps.

    On the assumption that if I get twice the frame rate for Patrice's code that Chris gets then my PC is twice as fast as Chris's (which is surprising considering the age of mine!) then I'd expect Chris's code to also run twice as fast at 2 x 19fps = 38fps.
    Mine is then 66/38 = 1.75 times as fast. That's 75% faster than the fastest so far.

    Do I win?

    Paul.

    Leave a comment:


  • Patrice Terrier
    replied
    Some things that I would really need in a sprite system is the following:
    • Write-access to raw pixel data, even after loading a sprite from a file
    • Transparancy for sprites
    • Basic resizing (stretch) routines would be more than welcome
    • Same applies to features like horizontal mirroring of sprites, though the last three items of this list are not strictly necessary when we have access to the raw pixels.
    That is something you can do with GDImage, and much more ...

    Leave a comment:


  • Patrice Terrier
    replied
    on XP I could blit over 80,000 images with transparency per second
    ???

    ...

    Leave a comment:


  • Brice Manuel
    replied
    Originally posted by Chris Boss View Post
    Note, the speed improvements will really most likely be most noticable on Windows Vista.
    TransBlt should show a huge speed increase on XP, too. I know with my old TransparentBlt routines, on XP I could blit over 80,000 images with transparency per second.

    Leave a comment:


  • Chris Boss
    replied
    Patrice added two new drawing modes in GDImage.

    My tests and others show the two new modes:

    AlphaBlend mode - to be 200% faster than the previous composite drawing mode

    TransBlt mode - to be 300% faster than the previous composite mode.

    Where fast graphics, we are talking here!

    Very good Patrice!

    Note, the speed improvements will really most likely be most noticable on Windows Vista.

    Leave a comment:


  • jcfuller
    replied
    I forgot os and video.

    Vista HP64 SP2
    Nvidia gforce 9800gt

    James

    Leave a comment:


  • Patrice Terrier
    replied
    Thank you very much James,

    I was really looking for that one!

    That is a gain of ~ 30% over my Core 2 Duo, these computers are realy playing in another category.

    ...

    Leave a comment:


  • jcfuller
    replied
    Originally posted by Patrice Terrier View Post
    I would be very interrested if someone using a Quad Core, could check the sprite.zip that is attached two posts above this one, and tell me both the FPS and CPU % he/she gets with it.

    Thank you!

    ...
    q6600 @ 2.4 GHz

    123-126 fps
    cpu ~ 34%

    James

    Leave a comment:


  • Patrice Terrier
    replied
    Jim,

    I have attached new zip file, with only the GDImage.DLL.

    Please, note that the lattest sprite.zip has been designed to hog the CPU for the purpose of benchmarking only.
    This example is not suitable for real life application.

    On single core computer, dirty rectangle + cooperative loop, should be the best combination to create 100% GDI based animation.

    ...
    Attached Files
    Last edited by Patrice Terrier; 7 Sep 2009, 07:54 AM.

    Leave a comment:


  • Jim Padgett
    replied
    sprite.zip

    The GDImage.dll fails CRC check and will not unzip.

    Leave a comment:


  • Patrice Terrier
    replied
    Chris,

    One reason for the greater range of the FPS, is because my sprite engine uses the "Dirty Rectangle" technique which means only updates the region that has been changed, so it depends upon where the sprites are (their position) how much area is redrawn.
    Using antialias or not this will not make a big difference in GDImage. However you are right about the "Dirty Rectangle" technique.

    I can't use it myself, because i choosed to support DWM in composited mode, thus i have to redraw everything, not just the sprite. The reason is that i could have an animated background. And in the most unfavourable case, when using a transparent skinned interface, i even have to redraw the whole window, just in case the location has changed, like in the Crystal demo.

    This is the reason why VISTA/W7 DWM AERO is so valuable, because everything is drawn into the back buffer then sent to the screen in an eye blink, however at a slower FPS than when working in exclusive mode. Dual Core are making this possible, because even when redrawing the whole screen, the system is still responsive. Remember orange and apple

    Thinking of the future, i hope i have done the good choice.

    PS: I am still looking for someone who could check the latest demo on a Quad Core.

    Added:
    Oops, "heart" = "hurt" of course (Barry).
    ...
    Last edited by Patrice Terrier; 7 Sep 2009, 03:49 AM.

    Leave a comment:


  • Tom Hanlin
    replied
    Guys, your inexhaustible enthusiasm is a sight to see. This thread is getting mighty long, though, and I suspect the topic has been thoroughly covered for the moment. Perhaps we might let it wind down for a bit, awaiting new developments.

    Leave a comment:


  • Barry Marks
    replied
    Originally posted by Patrice Terrier View Post
    Barry,

    Pragmatism and egotism are two different things.

    Both Chris and i, have been always helpful with the other members of this community. However i never realised that there was so many hobbyists and retired programmers around

    Please accept my apologize if i heart you with my remarks.

    ...
    Apology accepted. And please accept mine. I came back after I posted that and tried to delete it and couldn't find any way to do it.

    I try not to be a troublemaker in forums and I'm afraid I let myself get a little out of control this time.

    Barry

    Leave a comment:


  • Chris Boss
    replied
    I did some more benchmarking:

    First, I didn't notice at first in your last demo you turned off anti-aliasing on your sprites, which speeds things up.

    I had to turn off anti-aliasing in mine to make it fair.

    On Windows XP Home (SP2), 2.5 ghz CPU, 768 Ram, NVidia card:

    GDImage (24 sprites)
    24 FPS

    EZSPrite (24 sprites)
    50 to 60 FPS (200% faster)

    GDImage (100 sprites) (I modified the program to up it to 100 sprites)
    9 FPS

    EZSPrite (100 sprites)
    14 to 21 FPS (averaged around 19 FPS) (200% faster)


    On Windows Vista Home Premium (64 bit), 2.2 ghz CPU, 2 gig ram:

    GDImage (24 sprites)
    60 FPS

    EZSPrite (24 sprites)
    75 to 80 FPS (25% faster)

    GDImage (100 sprites) (I modified the program to up it to 100 sprites)
    19 to 20 9 FPS

    EZSPrite (100 sprites)
    24 to 25 FPS (averaged around 19 FPS) (25% faster)

    It appears GDImage benefits greatly from Vista Home Premium (64 bit)

    Leave a comment:


  • Chris Boss
    replied
    Patrice,

    I tested your latest sprite demo on my PC:

    Windows XP Home (SP2)
    2.5 ghz Celeron CPU (768 meg Ram)
    NVidia GForce4 MX 4000 video card (1680 x 1050 resolution - 32 bit color)

    Your sprite demo got:

    100% CPU usage (by design of course)
    22 to 24 frames per second

    My sprite engine demo with same number of sprites, same size (140 x 140 pixel), same background size and similiar movement around the background:

    100% CPU usage (by design of course)
    48 to 55 frames per second (usually stayed around 48 to 50 FPS)

    Even using alphablending of the entire sprites image to background and other sprites, I got 36 to 40 FPS.

    One reason for the greater range of the FPS, is because my sprite engine uses the "Dirty Rectangle" technique which means only updates the region that has been changed, so it depends upon where the sprites are (their position) how much area is redrawn.

    Leave a comment:


  • Patrice Terrier
    replied
    I would be very interrested if someone using a Quad Core, could check the sprite.zip that is attached two posts above this one, and tell me both the FPS and CPU % he/she gets with it.

    Thank you!

    ...

    Leave a comment:


  • Patrice Terrier
    replied
    Forget to say that the latest Sprite demo hogs the CPU by design, especially on single core computer.
    This is because i am using a non-cooperative game loop (and i simulate it in the cooperative mode) to get the higest FPS possible.

    To reduce the CPU foot print, use the COOPERATIVE mode with only one TIMER instead of five, then on dual core you should get a 65 FPS, but on a single core it could be much smaller.

    And to further reduce the CPU foot print in the cooperative mode, use a value of 40 or 80 millsecond in the single timer.

    ...

    Leave a comment:

Working...
X