Pinball test (with vector graphics)

[Atomic]

Warning: Ugly code within. I'm a self-taught programmer and I hate to admit it but it shows. Badly. Also I'm terrible at math so don't take my calculations as a proper way to do things.

UPDATE: It actually looks like a game now! The pinball table needs a lot of work, but the physics engine is mostly functional. There is still a tiny error where the ball will 'snag' at the end of the flippers.

[Atomic]

Hmm so my game hasn't got much attention.

Well, I rewrote the whole thing and it's been vastly improved. No more hangs, mostly proper physics (yet much faster), and working flippers!

Ball drain isn't implemented, and firing the ball is rudimentary. The table is also very simple, and you get an unlimited number of balls. There is a bug in the physics where the ball will rarely pass through the left flipper, particularly towards the tip of it. I don't have a Gamebuino yet so if anyone could test this on the actual hardware that would be awesome.

controls:
Left - left flipper
B - right flipper
Down - reset/fire ball

Only .HEX file attached this time. I'll release the source when it's finished.

[Quirby64]

This sounds interesting! Mind sharing a screenshot?

(I checked the first post an waited for someone else to reply)

[Atomic]

pinball.png (9.36 KiB) Viewed 5783 times

Not much to see in a screenshot. I did away with the zooming feature and the screen scrolls vertically.

I forgot to mention, I found another bug in the Gamebuino library, if you hold down a button for too long it resets and for a short time gb.buttons.repeat() returns false even if the button is still held. So I will have to change to press() and release() and keep track of them. Also, the pinball test is running at 40fps now and it still seems smooth in the emulator, so I'm wondering if it will work fine on the actual hardware.

[jonnection]

Good work ! I'm interested in your collision detection, please share some of your thoughts on the subject at some stage.

EDIT: OK, now I noticed you had the source in the original post.

So basically you are doing it the "proper way" with floats and trigonometry. No problem there I guess. The ball seems to "miss" some corners though.

[Atomic]

The collision detection in the more recent download is completely rewritten and although it uses the same principles it is much more advanced yet more efficient. I have turned all the sin() functions into array lookups, and all of the arctangents for level geometry are precalculated. I didn't want to release the source for it yet because the current code is sprinkled with tons of TODOs and there is a problem with colliding with the left flipper. Is there any specific place (except the left flipper) that you noticed the physics behaving incorrectly?

Also, thanks for creating a GIF! It shows much better than a still shot.

[jonnection]

Is there any specific place (except the left flipper) that you noticed the physics behaving incorrectly?
Also, thanks for creating a GIF! It shows much better than a still shot.

Don't thank me, thank Myndale == you can create a GIF right in Simbuino by pressing F12 to start & stop recording.

Right at the end of the GIF I posted, you see the ball flying from the left side flipper to the right side wall. The ball "goes in" to the wall a little bit.
I wonder if you remembered to round up / down the position on screen (integer numbers) from the float co-ords ? Because it looks like the ball is a little bit "away" from the left/upper boundaries of collision and then "goes in" to bottom/right boundaries. Just guessing, without seeing your code.

BTW, I think your physics is pretty darn good as it is.

How big lookup table are you using ?

[Atomic]

Don't thank me, thank Myndale == you can create a GIF right in Simbuino by pressing F12 to start & stop recording.

Neat, I hadn't noticed that feature.

The level geometry position is stored as ints, but the ball uses floats. The reason the ball clips that edge is probably because I forgot to put a collision point on the tip there. For efficiency I don't check collision on the ends of lines, and manually put in collision points where it is needed (on convex curves where the point is sticking out). The lookup table is 256 bytes, and currently it and the whole pinball table are stored in RAM.

I took a look at the code today after getting some sleep and it turns out the calculations for the flippers were completely wrong. I don't know how they were working at all. Mostly fixed now. I've updated the first post with the newest build, including source.