Announcement

Collapse
No announcement yet.

Would this be a useful addon for PB ?

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

  • #41
    Brice,

    Please explain, I value your opinion ?

    To me its just an extra 5 KB to the DLL, but extra commands that will significantly the SDK portion of possible users (DDT has a much richer feature set when used with my sprite engine).

    Would two different versions be better then, one for DDT users, the other for SDK users ?
    Chris Boss
    Computer Workshop
    Developer of "EZGUI"
    http://cwsof.com
    http://twitter.com/EZGUIProGuy

    Comment


    • #42
      Chris: I spent much of the day in the E/R and I am beat. I will drop you an email sometime tomorrow.

      Comment


      • #43
        I have add a few new commands which can access the sprites quicker (no need to search for their names, instead an index is used).

        It increases the speed by 15% to 20%.

        As far as the maximum number of sprites, at some point there becomes a bottleneck and only so many sprites can he handled. But for the sake of benchmarking, I increased the maximum number of sprites to 1000 (the release version, I haven't decided yet on the maximum).

        I created a couple sample projects using the penguin sprite again (from IceWalk) with different numbers of sprites and here are the frame rates:

        XP Home 2.5 ghz CPU, 768 meg Ram:

        200 sprites - 13.75 FPS
        500 sprites - 6.88 FPS
        1000 sprites - 4.2 FPS
        1000 sprites - 5.51 FPS (anti-alias off)

        Vista Home Premium, 2.2 ghz CPU, 2 gig Ram (rated 4.0 "Windows Experience Index"):

        200 sprites - 22 FPS
        500 sprites - 9.58 FPS
        1000 sprites - 5.86 FPS
        1000 sprites - 7.33 FPS (anti-alias off)
        Last edited by Chris Boss; 8 Sep 2009, 09:49 PM.
        Chris Boss
        Computer Workshop
        Developer of "EZGUI"
        http://cwsof.com
        http://twitter.com/EZGUIProGuy

        Comment


        • #44
          Doing some benchmarking using a "nameless" Basic compiler which supports DirectX and sprites.

          (done on my XP system, not Vista Home Premium)

          There is a big difference between doing stuff via hardware and software.

          When I create an app with 1000 penguin sprites (just one frame), the difference between storing a sprite (bitmap) in Video memory compared to System memory is like night and day.

          If the Sprite is stored in Video memory, I can get 24 FPS for 1000 sprites, which is amazing (both windowed mode or full screen). This is of course using DirectX.

          The problem appears when you want to use different ways of drawing the sprite. For example the docs (for the nameless Basic compiler) say that certain draw modes for sprites should store images in video memory and other modes in system memory.

          It appears the directX sprite drawing (at least in the nameless compiler) is limited to certain draw modes. For example to alphablend the sprite, flip the sprite and some other options the sprite should be stored in system memory.

          Now when I store the sprites in system memory, rather than video memory, this is the frame rates I get:

          200 sprites - 6 FPS
          500 sprites - 2 FPS
          1000 sprites - barely 1 FPS

          So when it comes to such sprite animation, the hardware is what does all the work. When you fall back to software based drawing (in System memory), its tough to get good frame rates.

          Mine can get (1000 sprites not anti-aliased)

          5.51 FPS

          Has anyone worked with DirectX ?

          Why would DirectX (or at least the "nameless compiler") limit the drawing modes for sprites for some draw modes ?

          For example the docs say the AlphaBlend should be done in system memory (won't benefit from the speed of the hardware).

          I know my sprite engine can not compare to hardware driven graphic engines, thats a given. The real question is how much speed can one get out of a software based sprite engine.

          I have to say that I am impressed with the speed of Powerbasic, since my sprite engine was written using PB 6.01. I am not sure if PB 9.0 would speed it, but maybe I ought to compile using it (bigger DLL though).
          Last edited by Chris Boss; 9 Sep 2009, 08:43 PM.
          Chris Boss
          Computer Workshop
          Developer of "EZGUI"
          http://cwsof.com
          http://twitter.com/EZGUIProGuy

          Comment


          • #45
            The problem appears when you want to use different ways of drawing the sprite. For example the docs (for the nameless Basic compiler) say that certain draw modes for sprites should store images in video memory and other modes in system memory.
            For specifics, the unnamed language is using DirectDraw for 2D. It uses a deprecated (but still supported and widely compatible) method of doing 2D.

            This is because things alpha-blending are not supported by DirectDraw and must be handled by the CPU and not the GPU. Hence they must be loaded into system memory.

            If we are talking about the same product, it actually uses the open-source 2D engine CD2X.

            Now when I store the sprites in system memory, rather than video memory, this is the frame rates I get:

            200 sprites - 6 FPS
            500 sprites - 2 FPS
            1000 sprites - barely 1 FPS
            That is a pretty normal since you are using the CPU instead of the GPU, especially "normal" if you are using a celery processor.

            Has anyone worked with DirectX ?
            Extensively, especially during my time at MicroProse and Shadow Realms 3D and NeXtGeN 3D.

            Why would DirectX (or at least the "nameless compiler") limit the drawing modes for sprites for some draw modes ?
            In this particular situation, it is a limit of DirectDraw. DirectDraw is still useful for 2D because it can run well on uber-budget systems like Eees.

            Modern 2D methods use the 3D capabilities of DirectX to emulate 2D. The drawback, is budget systems will often have some trouble running it.

            I have been working on a DirectX 9 based 2D engine for use with PB. Performance is awesome, but won't run on my Eee which is important to me to keep games Netbook-friendly.

            I know my sprite engine can not compare to hardware driven graphic engines, thats a given.
            Keep in mind that on Vista/7 DirectDraw is no longer supported and at runtime, the calls are translated to equivalent DX 9 3D methods, to take full advantage of hardware acceleration in 3D cards. So older DirectDraw based stuff will be much faster under Vista/7, but not necessarily the homespun alphablending, etc.

            I have to say that I am impressed with the speed of Powerbasic, since my sprite engine was written using PB 6.01.
            I agree 100%. I am using PB 8.04. If I could afford to upgrade I would for the OOP, but I can't, so I will keep plugging away with 8.04.
            Last edited by Brice Manuel; 9 Sep 2009, 10:30 PM. Reason: tags

            Comment

            Working...
            X