BlitzOut - new Breakout game - need help with Blitz code

[Graham Humphrey]

Hi all,

Over the last few months, I've been dipping my toe back into the murky waters that is Amiga programming (with Blitz Basic 2.1) after an absence of several years. Not wanting to jump straight into a hopelessly ambitious and huge project I'd have no hope of completing, I thought doing something reasonably simple like a Breakout game would break me in gently after such a long break.

I managed to come across an old Amiga Format tutorial on this very subject (in issue 61, pages 162 and 163) so thought it might be a decent idea to adapt some of this code to my project (provisionally naming my game after it in the process). Mine is a little different, though, in that I've got two bats, one at the top and one at the bottom of the screen - my eventual aim is to make it a competitive two-player game but for now it plays just like normal but with the player controlling two bats simultaneously.

This is very much a slow work-in-progress (I basically work on it when I feel like it and when time allows, so not often in the last two months or so) and I'm both extremely rusty and rubbish at maths, which has led to one or two minor problems involving collision detection.

The level maps are stored as IFF files where each pixel represents a 16x8 brick - each colour represents different types of bricks (in this case, three standard blocks in different colours and a fourth indestructible brick).

When the ball is moving, I ASR the ball's x value by 4, and its y value by 3 and check the corresponding pixel on the level map to see if there is a collision with a brick. If yes, then erase the brick (if destructible), everyone's happy.

Except not quite - it works, but the ball always goes through the corners of the bricks. Any other position it's fine. Also, I'm not totally sure the code for bouncing off the sides of the screen always works -the ball occasionally gets 'stuck' and I already know the bat/ball collisions aren't 100% accurate.

Also, bizarrely, the ball (a hardware sprite) changes colour when it gets to a certain point near the top of the screen - it never used to do this but since I've added more code to cater for the second bat at the top it now does. Weird.

Anyway, attached is my Blitz 2.1 code if someone wouldn't mind taking a look and helping out a total amateur It's not going to be an especially good game but I'd like the satisfaction of getting this project completed before tackling something a bit more substantial.

Thanks for reading and for taking a look at the code

[Lonewolf10]

Hehe, when I first got into AMOS back in 2002 I wrote 2 games. One of which was Breaker (available on Aminet - see link in signiture - on Games Vol. 1), based on code from the ZX Spectrum manual!! (The other was, Alutia's Jewels, based on something a schoolmate coded on the Spectrum for my birthday back in the early 90's)

I had problems when the ball was going diagonally and would go between two bricks thusly:

 __
[__]*
    []
    []


* = Ball

The only way I could solve it was to detect two areas - for example right of ball and above ball if it was moving diagonally up-right. The main loop for the game became a long list if IF's (about 40 of them).
I know it's AMOS code, but the source for Breaker should be on either Games Vol. 1 or Games Vol.2 - see my signiture for link to them on Aminet.


Regards,
Lonewolf10

[Graham Humphrey]

Cheers for that - I have dabbled in AMOS slightly in the past but not massively so AMOS code isn't totally alien to me

I'll give it a look!

[Lonewolf10]

Did you manage to find anything useful?


Regards,
Lonewolf10

[Graham Humphrey]

I admit I haven't looked in great detail (haven't had the chance yet) but I'm struggling to find the relevant source code - the game is on Games Vol.1 and I assumed the source code will be too but I'm not sure where it is? Will try again later on

[Lonewolf10]

Originally Posted by Graham Humphrey

I admit I haven't looked in great detail (haven't had the chance yet) but I'm struggling to find the relevant source code - the game is on Games Vol.1 and I assumed the source code will be too but I'm not sure where it is? Will try again later on

err... that's because I didn't release it! I honestly thought I'd put it on one of my releases, but it seems I didn't

I will hunt down the sourcecode and put it up here later.


Regards,
Lonewolf10

[Graham Humphrey]

So I'm not going mad then (or so I keep telling myself!)

Cheers, I appreciate it

[Lonewolf10]

Sorry, I searched through all my stuff and I have the source for everything except that game


Regards,
Lonewolf10

[Graham Humphrey]

No worries - thanks for having a look!

[Zener]

Hi,

I've been looking at the code, here are my findings:
-About the sprite chaning color, I think it is because the Sprites are not really drawn, they are set up. Just moving the DisplaySprite call after the call to DisplayBitmap will fix it.
-The collision errors, they are probably caused by the ball moving too fast. Try moving it one by one pixel instead of four by four pixels. If with less speed it works that's it.
Frame X
...O [brick]
Frame X+1
[brick] ...O

I hope it helps! Nice game by the way

[Graham Humphrey]

Thanks very much for that! I'll try it tomorrow

[Graham Humphrey]

Well, actually I managed to sneak a quick go in last night and I found that simply moving the DisplaySprite command worked - the ball displays perfectly now. I never realised it could make such a difference.

However, I fiddled with the speed values and it still goes through the corners of the bricks There is definitely a problem in my code it's safe to say. And it'll bug me while I'm at work all day, I'm sure...

[r0ber7]

Nice to see you're working on a game. Downloaded the source, I'll have a look later. I've had (and am still having) several problems drawing stuff on screen nicely in my own code too. So can't promise I'll be of much help, but I figure I owe you for your support on my wizard game.

[Graham Humphrey]

Awesome, thanks a lot

[Steve]

There are some glaring bugs in some of that AF code. Did you spot them. I cant exactly remember where now cos it was a few years ago when I did the tutorial. I had the same problem as you. The collision detection in the tutorial is very basic. In the end I couldn't be arsed to improve it. lol.

[Graham Humphrey]

The only one I remember spotting is where the code to move the ball horizontally was commented out - a fairly important thing to miss!

I didn't copy the collision code and added my own instead but it doesn't appear to have done much good

[r0ber7]

Alright, so I looked at the code, but I can't grasp your collision detection. I know very little about collision detection. (I check pixels for colours or use commands like SetCol and DoCol, works fine so far). I assumed it's in the .checkbricks function, but I'm confused. :P

[Graham Humphrey]

Yes, it is in the .checkbricks section. What part don't you understand?

I have been considering using commands and methods like the ones you mentioned (I guess to an extent I already do as I check the pixels on the bitmap of the level's map) but it feels a bit like a bodge and I'd rather do it properly. I guess it would work fine but for more complex games it would probably be a bit limiting - unless you very carefully designed all your graphics round it.

[r0ber7]

All depends on your approach and what kind of game you want I guess.

Ok, so I now understand the code, kinda. Took me a while. What confused me were the ASL and ASR stuff, and after reading up on them they still confuse me. So if the following text misses the point it's cause I don't understand the ASL and ASR.

Anyway, I noticed...

 m=Point(\collx,\colly) ...  If m>0 AND m<4

Does this mean you only check for one pixel? If it does, you might wanna check at other points as well. Upper left, upper right, bottom left, bottom right, of the ball. Otherwise a ball might hit a brick with its upper left corner (of the ball), while you check the bottom right pixel (of the ball) and it returns no colission, so it'd skip corners like you said. Dunno, just a suggestion.

[Graham Humphrey]

Cheers for taking a look

Basically using x ASL 4 gives the same result as x*16. And also x ASR 3 gives the same result as x/8. But I believe it's quicker than using multiplication and division.

Yes, it does check for one pixel. Problem is it checks the level map (i.e. (current ballx pos+ballx speed ASR 4; each pixel counts as one brick) for the collision rather than checking the actual bitmap the game is played on so checking to the left or right of the ball will likely make no difference (I think). I suspect using this method of collision for a game such as this simply isn't accurate enough but I'll have a play later on anyway.

Thanks