GameCanvas strange behaviour

Bodevinaat

Summary

Sprites moving in the GameCanvas where CollidesWithBoundary = True and SpriteBoundaryCollision is used show strange behaviour. Often the boundaries are not respected, sometimes the trajectory of the sprite changes in the middle of the GameCanvas. Trying to change X or Y speed gives strange results.

Besides that, I noticed lots of flickering. The sprites do move with many hiccups. The main reason for this test was to detect a X/Y speed where behaviour was smooth. It looks like hardware acceleration doesn't work.

[Edit] The flickering is system dependent. Other Windows machines show no flickering

Objo Studio Version

26.7.1

Operating System

Select the operating system(s) affected as tags for this post.

Steps To Reproduce

Expected Result

Actual Result

Screenshots, Logs, Or Sample Project

See attached project

gamecanvas.objo

595kB

Garry

Thanks for the sample project. I’ve looked into this and there are two separate things going on.

The flickering looks machine-dependent. I can’t reproduce that here, and your edit notes that other Windows machines don’t show it either, so I’ll need more information before treating that as a confirmed GameCanvas rendering bug: Windows version, GPU model, driver version, display scaling, and ideally a short screen recording.

The boundary behaviour is clearer. CollidesWithBoundary = True means “fire SpriteBoundaryCollision when this sprite touches or crosses a boundary”. It does not automatically keep the sprite inside the GameCanvas. In the sample project, the collision handler reverses velocity, but it does not move the sprite back inside the canvas. If a frame overshoots the bottom edge, the sprite can remain partly outside the canvas and keep firing boundary collisions on following frames.

A safer bounce handler clamps the sprite to the edge and sets the outgoing velocity direction explicitly:

Sub PlayCanvas_SpriteBoundaryCollision(sprite As Sprite, boundary As Integer)
    If boundary = GameCanvas.LEFT Then
        sprite.X = sprite.Width * sprite.OriginX
        sprite.VelocityX = sprite.VelocityX.Abs()
    ElseIf boundary = GameCanvas.RIGHT Then
        sprite.X = PlayCanvas.Width - (sprite.Width * (1.0 - sprite.OriginX))
        sprite.VelocityX = 0.0 - sprite.VelocityX.Abs()
    ElseIf boundary = GameCanvas.TOP Then
        sprite.Y = sprite.Height * sprite.OriginY
        sprite.VelocityY = sprite.VelocityY.Abs()
    ElseIf boundary = GameCanvas.BOTTOM Then
        sprite.Y = PlayCanvas.Height - (sprite.Height * (1.0 - sprite.OriginY))
        sprite.VelocityY = 0.0 - sprite.VelocityY.Abs()
    End If
End Sub

The sliders in the sample also always write a positive velocity, so moving a slider can force the ball to start moving right/down even if it was previously travelling left/up. That can make it look as though the trajectory changed in the middle of the canvas.

I’ve updated the GameCanvas documentation to make this clearer and to show the safer clamp-and-bounce pattern.

Bodevinaat

Thanks for looking into this. The GameCanvas handles some difficult to code things as collisions, boundary checking etc. So I was under the impression that the canvas was handling this as well.

BTW I coded a collision simulator in both Xojo and Delphi that handles > 500 bouncing balls in a canvas. So I was happy to see a control that could do the heavy lifting for me. But in the Xojo and Delphi app the canvas is not doing anything at all besides displaying G.FillOval(). The calculation of movement and collisions is done off screen ofcourse, not in the Canvas. It's a specific math area where different approaches exist how to optimize the expensive calculations. The Xojo Canvas is doing rather well.

Cheers

Garry

I couldn't help myself - I've been tweaking the game canvas. Here's Objo running 1000 sprites at 60 FPS:

https://objostudio.lon1.cdn.digitaloceanspaces.com/forum-media/sprites-1024.mov

The example app will be bundled in with Studio in the next release 🙂

Bodevinaat

Impressive... but the REAL challenge is when you use collision detection. This is a Xojo app running in the debugger doing collision detection and reactions (based on mass, speed, vector). That calculation is a beast.

collision3.mp4

5MB

Garry

Here's the video of it running at 30 FPS with 500 sprites and real physics and collision detection. This is running in the debugger (is faster in a built app):

https://objostudio.lon1.cdn.digitaloceanspaces.com/forum-media/sprites-collision-1080p.mov

Bodevinaat

my, you're quick! The Xojo app is created with g.filloval() which gives a lot of overhead. I see that the game canvas handles collisions well. I wonder what the algorithm is behind the scenes and if proximity testing is used.

Thanks!