Open Surge Forum

A fun 2D retro platformer inspired by Sonic games and a game creation system

You are not logged in.

Announcement

Our community has moved to Discord! https://discord.gg/w8JqM7m

#51 2018-11-06 00:02:20

Alexandre
Administrator
From: Brazil
Registered: 2009-01-27
Posts: 3,300
Website

Re: Physics update: automatic angles

I don't want to keep 0.5.0 a forever work-in-progress. I actually want to release it, and there's a well established guideline for that.

The collision system is being reworked; the old stuff will be ditched, and the new system will be A5-compatible.

In the new system, you'll be using colliders (rather than pixel-perfect collisions). Spawn a collider as a child of the object and it will detect collisions with that object.

By the way, I'm working on player colliders at this very moment.
s242.png

Last edited by Alexandre (2018-11-06 02:45:51)

Offline

#52 2018-11-06 04:24:26

KZR
Member
Registered: 2010-07-14
Posts: 1,447
Website

Re: Physics update: automatic angles

could we just make the colliders visible for debugging?


SD_sml.pngSeD_sml.pngLTot_W_sml.png
https://discord.gg/w8JqM7m ---> Open Surge's Discord server

Offline

#53 2018-11-06 11:05:47

Alexandre
Administrator
From: Brazil
Registered: 2009-01-27
Posts: 3,300
Website

Re: Physics update: automatic angles

KZR wrote:

could we just make the colliders visible for debugging?

Yes, there is already an option that allows you to do that. It will be documented soon enough, together with the Player API.

Offline

#54 2018-11-06 15:52:20

KZR
Member
Registered: 2010-07-14
Posts: 1,447
Website

Re: Physics update: automatic angles

ok, so here's my experience with this issue:

the collider disregards transparent pixels, and takes the whole frame's width and height instead of the opaque area. this produces very inaccurate object collisions.


SD_sml.pngSeD_sml.pngLTot_W_sml.png
https://discord.gg/w8JqM7m ---> Open Surge's Discord server

Offline

#55 2018-11-06 18:59:31

Alexandre
Administrator
From: Brazil
Registered: 2009-01-27
Posts: 3,300
Website

Re: Physics update: automatic angles

KZR wrote:

the collider disregards transparent pixels, and takes the whole frame's width and height instead of the opaque area. this produces very inaccurate object collisions.

Colliders can be customized and combined in SurgeScript, so it doesn't have to be inaccurate. smile

Due to architectural differences, we won't be using pixel perfect methods in A5.

Offline

#56 2018-11-07 00:47:33

svgmovement
Member
Registered: 2011-11-24
Posts: 209

Re: Physics update: automatic angles

Alexandre wrote:
KZR wrote:

the collider disregards transparent pixels, and takes the whole frame's width and height instead of the opaque area. this produces very inaccurate object collisions.

Colliders can be customized and combined in SurgeScript, so it doesn't have to be inaccurate.

Due to architectural differences, we won't be using pixel perfect methods in A5.

If I recall correctly, the pixel-perfect collision in my proof-of-concept port was implemented on top of the bitmaps themselves. I know that querying pixel information from A5 bitmaps is generally slow. I may (read: have forgotten since I wrote it) have ported an OpenSurge version that predated the collision mask feature.

If the collision masks were implemented outside of the A5 environment, maybe they could run faster than the bitmap-based version.

Just a thought. hmm


-- svgmovement

Offline

#57 2018-11-07 01:58:19

Alexandre
Administrator
From: Brazil
Registered: 2009-01-27
Posts: 3,300
Website

Re: Physics update: automatic angles

A5 bitmaps are generally stored in video memory (if we want to take advantage of hardware acceleration) and therefore, querying individual pixels is extremely slow, given an expensive bus transfer.

By working with colliders (one or more geometric shapes like boxes, balls) for detecting collisions between sprites, you can have good results with much higher performance. I believe retro games like Mortal Kombat 3 use this method.

Collision masks: I have designed a fast data structure that works on regular RAM, outside A4/A5. It allows really fast querying of pixels and other things, however it's intended for bricks (no animations). The physics engine needs it. Though masks could be adapted to sprites in the future, I won't be working this way. There's a better way. Collision masks use memory, not every sprite needs it and they're not designed for animation. I do not discard totally having sprite-compatible masks in the future, because who knows what the future brings. But that's outside the point.

What we want is fast & cheap collision detection on PC or mobile. And acceptable accuracy.

Offline

#58 2018-11-07 15:41:00

KZR
Member
Registered: 2010-07-14
Posts: 1,447
Website

Re: Physics update: automatic angles

Alexandre wrote:

What we want is fast & cheap collision detection on PC or mobile. And acceptable accuracy.


I think the answer is what practically every engine is doing nowadays - polygon collisions

However masks are the "messenger" so to speak, let me elaborate.

the user makes a sprite, assigns it a mask based on its rough shape, and the engine mathemagically computes a polygon outline. this polygon becomes the actual collider.

I'm sure there are plenty of algorithms floating online that you can study and adapt for this purpose.

more advanced game making solutions like Construct have a basic image editor where you can assign multiple hotspots as well as polygons per frame. this is off the point, as an image editor would be a great undertaking, but the way it works with animations is worth a peek.

Last edited by KZR (2018-11-07 15:44:11)


SD_sml.pngSeD_sml.pngLTot_W_sml.png
https://discord.gg/w8JqM7m ---> Open Surge's Discord server

Offline

Board footer

Powered by FluxBB  hosted by tuxfamily.org