Results 1 to 11 of 11

Thread: VB6 Cairo-Blending-Performance (Collision-Handling using the Physics-Engine)

  1. #1

    Thread Starter
    PowerPoster
    Join Date
    Jun 2013
    Posts
    7,219

    VB6 Cairo-Blending-Performance (Collision-Handling using the Physics-Engine)

    A small Demo, referring to the Blending-comparison-thread here:
    http://www.vbforums.com/showthread.p...-Cairo-Drawing

    Now covering a more realistic "2D-game-scenario" with 12 moving PNG-Sprites (5 larger and 7 smaller ones),
    which constantly change their Pixel-Contents whilst moving around on a more realistic gaming-surface-size
    in the range of 1024x768 Pixels (each Sprite also updating itself with a Text-Rendering, showing the Collision-
    Count it encountered so far).

    What Cairo achieves with that amount of semitransparently rendered Sprites is about 250FPS
    (measured on Win 8.1, on a 2.1GHz Intel-Mobile-CPU, singlethreaded) - whilst codewise consisting
    of only about 40 lines in cBall.cls and about 60 lines of code in fTest.frm.

    So the measured 250FPS in this scenario leave enough room for a lot more Sprites in the Game-Loop
    (especially when those Sprites are not as large as the ones I've choosen here).

    I consider that quite a good compromise between "convenient coding of complex graphics-stuff" -
    and achievable 2D-game-performance.

    Here's the Demo-Sources: http://vbRichClient.com/Downloads/Ca...erformance.zip

    And here a ScreenShot:



    Enhancements in a second version below (now more suited as a WireFrame for a true Gaming-Scenario,
    vbRichClient5 >= version 5.0.28 recommended):
    http://vbRichClient.com/Downloads/Cairo2DGaming.zip


    The Demo-Link above does basically the same thing as the other one, but now using a resizable Form -
    in conjunction with DX/Direct2D-Surfaces, which after Upload of a Cairo-Surface allow for fast antialiased Stretching,
    completely filling the Form, no matter which size - in a very good performance (DblClick switches the Form into FullScreen-
    Mode, without changing the Monitor-Resolution of course).

    What's also possible with this GPU-supported Surface-Type is the avoidance of tearing, due to an enabled
    WaitForVerticalBlank-Parameter in the CairoSurface-Creation-call.

    A nice side-effect of that is, that the Demo now doesn't run "full-speed" anymore (with about 250FPS) -
    but only with the Screen-Refresh-Rate, which in case of a ScreenSaver-scenario will not suck the battery
    dry that fast...

    The ScreenShot below shows the CPU-Load (only ~3.5%) in FullScreen-Mode (on a 1920x1080 HD-Resolution-Screen).



    Olaf
    Last edited by Schmidt; May 13th, 2015 at 04:44 PM.

  2. #2
    Hyperactive Member Daniel Duta's Avatar
    Join Date
    Feb 2011
    Location
    Bucharest, Romania
    Posts
    396

    Re: VB6 Cairo-Blending-Performance (Collision-Handling using the Physics-Engine)

    Hi Olaf,
    It is one of the nicest graphical demo I have seen in vb6. I just wonder if it is possible to change the spheres color in runtime so as to have a new randomly color after each collision. I have tried to adapt your code in the collision procedure but the colors are not preserved among the collision events. Thank you.
    Last edited by Daniel Duta; May 12th, 2015 at 07:13 AM.

  3. #3

    Thread Starter
    PowerPoster
    Join Date
    Jun 2013
    Posts
    7,219

    Re: VB6 Cairo-Blending-Performance (Collision-Handling using the Physics-Engine)

    Quote Originally Posted by Daniel Duta View Post
    ... I just wonder if it is possible to change the spheres color in runtime so as to have a new randomly color after each collision. I have tried to adapt your code in the collision procedure but the colors are not preserved among the collision events.
    You will have to handle the current Color-Value in the cBall-Class (either in a Private-Var,
    or in the cBall.Draw-Routine itself as a Static-Variable - as is currently done e.g. for the Txt-Path
    or the CCounter-Variable which store the state for the current Collision-Count-Rendering).

    Here's how I would change the Draw-method in cBall:

    Code:
    Public Sub Draw(CC As cCairoContext, ByVal ColorShade As Long)
    Static LastAngle As Double, CCounter As Long, Color As Long '<- use a Static-Variable for the Color, to preserve its State between renderings
    Dim IsSmallGlobe As Boolean, Alpha As Double  'just some more speaking Variables for formerly applied "direct Values"
    
      CC.Save
        CC.TranslateDrawings Shape.tC_X, Shape.tC_Y 'translate the CC to the current center of of the Shape
        
        IsSmallGlobe = (Radius < 40) 'determine, which of the two Globe-Sizes this Instance represents
        
        If Color = 0 Then Color = IIf(IsSmallGlobe, vbMagenta, vbGreen) 'set the initial Color we start with (to match with the original Demo)
        
        Alpha = 0.75 'IIf(IsSmallGlobe, ColorShade * 0.01, (50 - ColorShade) * 0.01) 'set the Alpha, depending on the current Value of 'ColorShade'
        
        'render a semitransparent Colorshade-Overlay
        CC.ARC 0, 0, Radius
        CC.SetSourceColor Color, Alpha
        CC.Fill
        
        'render the PNG-Alpha-Surface
        CC.SetSourcePattern SrfPat
        CC.Paint
        
        If Not Txt Is Nothing Then 'apply the current Collision-Counter-Textout-Path
          CC.ScaleDrawings 1, -1
          CC.AppendPath Txt
          CC.SetSourceColor vbBlue
          CC.Fill
        End If
    
        If Abs(LastAngle - Body.W) > 0.01 Then 'we had a collision (the new Txt-Path, as well as the new Color will be applied in the next refresh, which is less than 1msec away)
          CCounter = CCounter + 1
          CC.SelectFont "Tahoma", IIf(Radius < 40, 6, 8), vbBlue, True
          CC.DrawText -10 - 0.15 * Radius, 1 + 0.15 * Radius, 20, 20, CStr(CCounter), True, vbCenter, , , , , True
          Set Txt = CC.CopyPath
          
          Color = RGB(Rnd * 255, Rnd * 255, Rnd * 255) 'in case of a collision, we change to another random color-value
        End If
        LastAngle = Body.W
      CC.Restore
    End Sub
    Tried to mark the changes to the original Zip in Post #1 Magenta.

    HTH

    Olaf
    Last edited by Schmidt; May 12th, 2015 at 01:44 PM.

  4. #4
    Hyperactive Member Daniel Duta's Avatar
    Join Date
    Feb 2011
    Location
    Bucharest, Romania
    Posts
    396

    Re: VB6 Cairo-Blending-Performance (Collision-Handling using the Physics-Engine)

    Hi Olaf,
    Thank you for your details. So that static variable for colors does the trick. Now the balls behaviour is more spectacular. I intend to transform this small sample in a screensaver as a suvenir from the vb community

  5. #5

    Thread Starter
    PowerPoster
    Join Date
    Jun 2013
    Posts
    7,219

    Re: VB6 Cairo-Blending-Performance (Collision-Handling using the Physics-Engine)

    Quote Originally Posted by Daniel Duta View Post
    I intend to transform this small sample in a screensaver as a suvenir from the vb community
    I've just added a variation (at the end of Post #1), which should be more suitable for ScreenSaver-Mode (less CPU-intensive).

    It is using the RC5-Form-Engine instead of the VB-Forms in the original Version,
    so that even a VBScript-Version of this second variant could be written quite easily.
    (the *.vbs-Script then only dependent on an installed RC5).

    Though a regfree deployable VB6-Executable is probably a better idea in a ScreenSaver-scenario.

    This second Demo works best with an RC5 in version >= 5.0.28.

    Olaf

  6. #6
    Hyperactive Member Daniel Duta's Avatar
    Join Date
    Feb 2011
    Location
    Bucharest, Romania
    Posts
    396

    Re: VB6 Cairo-Blending-Performance (Collision-Handling using the Physics-Engine)

    Quote Originally Posted by Schmidt View Post
    I've just added a variation (at the end of Post #1), which should be more suitable for ScreenSaver-Mode (less CPU-intensive).
    It is using the RC5-Form-Engine instead of the VB-Forms in the original Version,
    In this new version the spheres seem to have a different behavior. The fps decreased to 60 in average and sometimes the balls are not rendered perfectly. I don't know if it is something related to velocity or RC5 form but if you look carefully we will see the border of some spheres are not perfectly circular in their moving and these border interruptions occur more often after collisions.
    Name:  Medium Ball.PNG
Views: 1005
Size:  52.7 KB
    It is true, the results are improved with your latest version 5.0.0.29 but from time to time the effect above becomes visible.
    I will do some changes in code hoping I can reduce this issue.

  7. #7

    Thread Starter
    PowerPoster
    Join Date
    Jun 2013
    Posts
    7,219

    Re: VB6 Cairo-Blending-Performance (Collision-Handling using the Physics-Engine)

    Quote Originally Posted by Daniel Duta View Post
    In this new version the spheres seem to have a different behavior. The fps decreased to 60 in average and sometimes the balls are not rendered perfectly. I don't know if it is something related to velocity or RC5 form...
    No, that's unrelated to velocity or that an RC5-Form is used now - it's simply
    stretching-artefacts which are related to the GPU (your graphics-chip) - whilst
    it works in conjunction with either DirectX (on systems up to - and including XP) -
    or with MS' new Direct2D-API (which the RC5 is using instead of DirectX on systems > XP).

    I suspect that you're running this on XP (where the GPU-based stretching
    can depend more on the global settings one has done on the graphics-card,
    e.g. disallowing Antialiasing on the GPU in question).
    Direct2D which is used instead of DirectX from Vista onwards for this task, is
    more reliable in these regards (keeping to the stretch-quality I asked it to apply).

    Also playing a role sometimes ... when you run such GPU-related stuff
    in a VM, then it depends on the support (or your settings for the guest),
    how VMWare or VirtualBox route this through to the GPU of the host-system
    (also here, Direct2D is the more reliable companion, in case you run e.g. a Win7
    or a Win8 as a Guest-System in a VM).

    As for the "decrease to 60 FPS" - I tried to explain that in post #1 - that's
    because I asked the GPU-mode to do so (WaitForVerticalBlank) - so the
    "stretched flipping" of our "fixed-size-Cairo-Surface" onto the Screen, will
    happen with the Screen-Refreh-Rate (which is apparently 60Hz also on your TFT).

    Rendering less Frames per second (due to waiting for the Screen-Blanc) is then
    causing less CPU-Load, which I thought is the better mode for a ScreenSaver.

    You could switch that off, when you leave out the last parameter in the Surface-
    Creation-Line (the last line of code in Class_Initialize of the RC5-FormClass).
    Code:
    '  Set Srf = Cairo.CreateSurface(BGWidth, BGHeight, DXSurface32Bit, , Form.hWnd, True) 
      Set Srf = Cairo.CreateSurface(BGWidth, BGHeight, DXSurface32Bit, , Form.hWnd)
    And to deactivate GPU-based stretching from our fixed sized Surface (Srf) to the
    current size of the HostWindow, you would need to change the above Line to:

    Code:
    '  Set Srf = Cairo.CreateSurface(BGWidth, BGHeight, DXSurface32Bit, , Form.hWnd, True) 
      Set Srf = Cairo.CreateSurface(BGWidth, BGHeight, ImageSurface)
    Olaf
    Last edited by Schmidt; May 16th, 2015 at 11:46 AM.

  8. #8
    Angel of Code Niya's Avatar
    Join Date
    Nov 2011
    Posts
    8,598

    Re: VB6 Cairo-Blending-Performance (Collision-Handling using the Physics-Engine)

    Quote Originally Posted by Schmidt View Post
    As for the "decrease to 60 FPS" - I tried to explain that in post #1 - that's
    because I asked the GPU-mode to do so (WaitForVerticalBlank) - so the
    "stretched flipping" of our "fixed-size-Cairo-Surface" onto the Screen, will
    happen with the Screen-Refreh-Rate (which is apparently 60Hz also on your TFT).

    Rendering less Frames per second (due to waiting for the Screen-Blanc) is then
    causing less CPU-Load, which I thought is the better mode for a ScreenSaver.
    You can go lower than that to conserve even more CPU power. 30 FPS is decent enough for most applications.
    Treeview with NodeAdded/NodesRemoved events | BlinkLabel control | Calculate Permutations | Object Enums | ComboBox with centered items | .Net Internals article(not mine) | Wizard Control | Understanding Multi-Threading | Simple file compression | Demon Arena

    Copy/move files using Windows Shell | I'm not wanted

    C++ programmers will dismiss you as a cretinous simpleton for your inability to keep track of pointers chained 6 levels deep and Java programmers will pillory you for buying into the evils of Microsoft. Meanwhile C# programmers will get paid just a little bit more than you for writing exactly the same code and VB6 programmers will continue to whitter on about "footprints". - FunkyDexter

    There's just no reason to use garbage like InputBox. - jmcilhinney

    The threads I start are Niya and Olaf free zones. No arguing about the benefits of VB6 over .NET here please. Happiness must reign. - yereverluvinuncleber

  9. #9

    Thread Starter
    PowerPoster
    Join Date
    Jun 2013
    Posts
    7,219

    Re: VB6 Cairo-Blending-Performance (Collision-Handling using the Physics-Engine)

    Here's a variation of a resizable Demo, which doesn't use DirectX or Direct2D,
    just plain Cairo-Drawing (which is entirely CPU-based).

    Introduced a rotating "Star-Wheel" in the center, to make things a bit more interesting...

    Cairo2DGaming2.zip

    ScreenShot:



    Olaf

  10. #10
    Hyperactive Member Daniel Duta's Avatar
    Join Date
    Feb 2011
    Location
    Bucharest, Romania
    Posts
    396

    Re: VB6 Cairo-Blending-Performance (Collision-Handling using the Physics-Engine)

    I suspect that you're running this on XP (where the GPU-based stretching
    can depend more on the global settings one has done on the graphics-card,
    e.g. disallowing Antialiasing on the GPU in question).
    Direct2D which is used instead of DirectX from Vista onwards for this task, is
    more reliable in these regards (keeping to the stretch-quality I asked it to apply).
    I have doubts the effect is related to my hardware components. My PC is running on Windows7 SP1, 4Gb RAM, with DirectX 11 and GeForce GTX 460 / 1024 Mb memory. I don't know if my SP1 has installed the Direct2D API's that are dependecies for RC ("the RC5 is using instead of DirectX on systems > XP") but applying yours suggestions I have noticed that removing the parameter DXWaitForVerticalBlank (the default is false) that annoying effect disappeared. In the second line case, the replacing of the DXSurface32Bit with ImageSurface doesn't remove the issue. I don't know how the RC library is built but it seems a stable version should avoid the latest parameter DXWaitForVerticalBlank in the Surface-Creation as long as it depends on the Screen-Refreh-Rate, which in my case is 60Hz. Just out of curiosity, which is the benefit of using this parameter ? At last, your sample above - Cairo2DGaming2 - works perfectly and indeed that Star-Wheel from the middle of the screen makes the balls behavior more interesting. You are an imaginative person.

  11. #11

    Thread Starter
    PowerPoster
    Join Date
    Jun 2013
    Posts
    7,219

    Re: VB6 Cairo-Blending-Performance (Collision-Handling using the Physics-Engine)

    Quote Originally Posted by Daniel Duta View Post
    I have doubts the effect is related to my hardware components. My PC is running on Windows7 SP1, 4Gb RAM, with DirectX 11 and GeForce GTX 460 / 1024 Mb memory. I don't know if my SP1 has installed the Direct2D API's that are dependecies for RC ("the RC5 is using instead of DirectX on systems > XP") but applying yours suggestions I have noticed that removing the parameter DXWaitForVerticalBlank (the default is false) that annoying effect disappeared.
    Direct2D should be shipped even with the Base-version of Win7 -
    and when the artefacts are gone, just by switching the WaitForVerticalBlank-Flag Off (to its default),
    then there's apparently nothing wrong with the GPU-based stretching itself, but with the way the
    NVidia-Driver handles the "Flipping of new content in case of the Screen-Blank-signal" he had to wait for.

    In any case I cannot do much (codewise), whilst addressing those GPU-based System-interfaces.
    Those subsystems either do what I asked them to do (whilst passing flags for the Blank-Waiting - and
    for antialiased stretch-quality along) - or they do not.

    As for the other line of code, which avoids the creation of "DX-based fixed-size-surfaces for GPU-based stretching"
    and instead sticks with a plain System-Memory Cairo-Surface instead:
    Code:
    Set Srf = Cairo.CreateSurface(BGWidth, BGHeight, ImageSurface)
    The artefacts you see also in this case - are stretching-(quality)-related as well.
    Im quite sure, when you (in addition to the above line) change the final (normal
    GDI-Blit in this case)-Line in the Render-Loop:
    Code:
      Srf.DrawToDC Form.hDC, 0, 0, Form.ScaleWidth, Form.ScaleHeight
    To this one (enabling the HalfTone-Flag for the GDI-StretchBlit-call)
    Code:
      Srf.DrawToDC Form.hDC, 0, 0, Form.ScaleWidth, Form.ScaleHeight, , , , , , True
    Because in this case the Stretch-quality would improve, the artefacts should be gone
    (or largely minimized in their effect).

    So, to be clear once again, the above mode is using a normal (fixed-size) InMemory-
    Cairo-Surface and is stretching it per GDI (in the latter code-snippet above, using the
    HalfTone-Flag which should increase Stretch-Quality, but decreases the achievable FPS).

    Quote Originally Posted by Daniel Duta View Post
    [WaitForVerticalBlank]... Just out of curiosity, which is the benefit of using this parameter ?
    Tried to explain it already - for a normal (fluent) rendering one will need only about
    24FPS (as in Movies) to "fool the eye" - 250FPS make only sense in some "player-
    reaction-time" related Game-Scenarios (e.g. Shooters) - to be "as near as possible
    with a given new scene" to the next Screen-Refresh". And since these Screen-Refreshes
    happen usually at a much lower rate (in your - and my case - with ~60Hz), most Game-
    Engines (and libraries) allow for this Blank-Waiting, to reduce stress on the CPU and
    GPU (since FPS-Framerates above the Screen-Refresh-Rate will not improve "fluency",
    they only can lower the "reaction-time-lag".


    Quote Originally Posted by Daniel Duta View Post
    At last, your sample above - Cairo2DGaming2 - works perfectly ...
    That's because I did a pre-stretching per cairo now (and only in the Form-Resize-
    Event) - though this is a different kind of stretch, because the size of the Game-
    Sprites (the balls in this case) remains constant - only the Background-Image is
    prestretched per cairo in FOrm_Resize (to allow for a faster BackGround-clearance).

    Olaf

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  



Click Here to Expand Forum to Full Width