Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[wojt_gl]

Hello anybody!
I am looking for good example or solution for my problem.
I am trying to write a game with ship traveling across some corridors.
I need to detect collision with corridors walls - those are irregular.

What I need is to find out if there is an existing function for detect bob/sprite collision with background.
My background has some walls graphics and corridors with color zero. I want to allow to move ship only on corridor and hitting the wall should finish with explosion.

I was trying almost everything (with big bob as mask also) and no result :/
I was trying with set hardcol and hardcol (but those are not well documented and dont know how to use that, and if those are proper for this feature).
Anybody has an idea how to achieve?

Thanks!

[bruceuncle]

I haven't done anything in this area myself.  BUT, if you have a look at the Planet_Zybex program on the Productivity1 disk, the programmer uses a novel technique for detecting collision with an irregularly-shaped background.
This is mentioned in the AMOS Pro Application Supplement (in Downloads here http://www.ultimateamiga.co.uk/index.php?action=tpmod;dl=item417) on page 03.02.

And if you can get hold of a copy, Amiga Game Makers Manual - With AMOS Basic should give you plenty of info on game design in general.

If your backgroud is made up of rectangular shapes, try using zone definitions and detecting zone collision.  Look at page 07.04.06 in the AMOS Pro User Manual (in Downloads here http://www.ultimateamiga.co.uk/index.php?action=tpmod;dl=item451) for more info.

Hope this helps. 

[wojt_gl]

Thank You for Your quick reply.
I will take a look on book positions You mentioned.
And my background is not rectangular shapes - its totaly irregular.

[wojt_gl]

LOL - i just noticed that my object which i want to detect colission are not so much irregular. They are possible wrapped by rectangle... so it would be easy to detect the collission.
Anyway i checked the PlanetZybex sources, and found out that they are doing it the same (checking the color of screen by point() method - as there is NO way in AMOS to check collision with background).

Anyway - why they didnt provide a method for that? Its easy to do it this way (checking the background color against an object rectangle...)?

[bruceuncle]

Pleased to hear you found a way around the problem.

AMOS does provide a way to check background collision but it's a bit convoluted.  Either you define zones and check bob/zone collision.  Or you define static bobs and check bob/bob collision.

There's probably other ways to do it using assembler and the hardcol register but I haven't explored that side of the Amiga hardware yet.  So I'm probably wrong! 

[Lonewolf10]

There's probably other ways to do it using assembler and the hardcol register but I haven't explored that side of the Amiga hardware yet.  So I'm probably wrong! 

From a quick look at the Amiga HRM (Hardware Reference Manual) I have you are correct. It is possible to detect collisions between sprites and the background. Registers CLXCON (address $DFF098) and CLXDAT (address $DFF00E) are used for sprite collision detection (both with other sprites and the screen). In assembler you can only write to CLXCON (collision control - it set's up what type/s of collision you want) and read CLXDAT (collision data - it's bits are set appropriately when certain collisions are detected). Doing so via AMOS' peek and poke command may crash your Amiga.
I don't understand why AMOS doesn't take advantage of this feature.

[bruceuncle]

From a quick look at the Amiga HRM (Hardware Reference Manual) I have you are correct. It is possible to detect collisions between sprites and the background.

Thanks Lonewolf10.  Had a quick look at my manuals (a bit out of date - A1000 - but that's a long story) and it looks very promising.  Particularly like the way you can limit it to specific bitplanes.  That makes it possible to have a full colour background, but collisions only detected with certain bits of the 'landscape'.   

I also came across one of those docs files from way back.  The ones that people typed in by hand.  I've attached the archive it came from, plus the individual file to save hunting around for it.

The file amigaocs_hardware.doc (nothing to do with being a Messysoft Word document! - it's just plain text) has one of the best talk-throughs of the original hardware that I've come across so far.  It's pre-ECS but covers all the hardware basics from the assembler programmers angle.  I read the whole thing the other night and now have a far better understanding of how the Amiga hardware really works.  If anyone knows who the author was (there's no author or acknowledgments in the doc) I'd love to find out.  Or any other docs he/she wrote.  This sort of quality doc is just what I need.  It may be well known to seasoned Amiga programmers but it's gold dust to us novices!

The attached archive is a real grab bag of assorted docs.  Quality is very variable!  But worth spending some time wading through it.  There's a useful AGA section too.   

I don't understand why AMOS doesn't take advantage of this feature.

I suspect it was maybe considered a bit too complex to inflict on AMOS programmers at the time.  I had a think about how it could be put into AMOS Basic instruction format and it's not easy to come up with something workable.  BUT, it should definitely be considered for the AMOS Pro Re-development project.

Just thinking out loud - maybe it could be implemented as:

• A set of instructions to set up the background detections and priorities required
• Instructions to put the settings into action (e.g.  Back Col On, Back Col Off, etc.)
• Instructions to test for background collisions along the lines of the current AMOS ones for Sprites and Bobs.
• Extend AMAL to do the same (hard one that!)

[Hungry Horace]

interesting reading.

I saw something about a technique used for Indy Heat...

http://www.codetapper.com/amiga/interviews/john-croudy/

.... where there is a mask for items on the track pictures, such as buildings / bridges etc, and that mask is used to stop the sprite being drawn at those points (ie. driving under a bridge etc) ... .any idea how that oculd presently be implemented, or if functions for this could be added to AMOS?

[bruceuncle]

@HungryHorace
It's possible to detect sprite collision with one or more bitplanes.  You define which bitplanes and which sprites and the hardware flags the collision for you.
You can also define the priority of the sprites both to each other and to the bitplanes. That's what's used for situations where you want a sprite to pass 'behind' parts of the background.
The 'mask' referred to is just a single bitplane.  The hardware is told to detect sprite collision with that one bitplane and ignore the rest.
All this can (and should) be incorporated into AMOS Pro redevelopment.
The tricky bits would be synchronising with the existing AMOS sprite handling and making the AMOS instructions simple enough to be usable.

I would think the hardest part comes when you try to set up a suitable background for a game.  The bitplanes determine the colours so a fair bit (sic) of planning is needed to get it right.

I enjoyed that article you linked to.  It's nice to get info on how things were done - helps to confirm how the Amiga hardware was designed to be used.  The RKM info is a bit like having  a huge Lego Technics set with no model  instructions!

[Lonewolf10]

Thanks Lonewolf10.

No problem

I also came across one of those docs files from way back.  The ones that people typed in by hand.  I've attached the archive it came from, plus the individual file to save hunting around for it.

Thanks, will download them at the weekend. You can never have too much documentation

I don't understand why AMOS doesn't take advantage of this feature.

I suspect it was maybe considered a bit too complex to inflict on AMOS programmers at the time.  I had a think about how it could be put into AMOS Basic instruction format and it's not easy to come up with something workable.

That's a good point.

Just thinking out loud - maybe it could be implemented as:

• A set of instructions to set up the background detections and priorities required
• Instructions to put the settings into action (e.g.  Back Col On, Back Col Off, etc.)
• Instructions to test for background collisions along the lines of the current AMOS ones for Sprites and Bobs.
• Extend AMAL to do the same (hard one that!)

Sounds like a good idea to me.

[HonestFlames]

Sorry to resurrect an old thread, but this is relevant to what I'm doing at the moment.

I've just read the documentation regarding the collision control register and I've deciphered it to a degree.

I must not be quite 'getting' it, because Amos Pro has a Set Hardcol command which seems to be intended for the purpose of letting me get friendly with the CLXCON register.

Set Hardcol bitmap1,bitmap2

bitmap1 corresponds to bits 12-15, which are: -

15 - Enable collision detection, sprite 7
14 - Enable collision detection, sprite 5
13 - Enable collision detection, sprite 3
12 - Enable collision detection, sprite 1

Now, as I'm using sprite 0 as a 16-colour sprite, it combines with sprite 1 and I should set bit 12.

bitmap2 corresponds to bits 0-5, which are: -
5 - Bitplane 6 collision match bit
4 - Bitplane 5 collision match bit
3 - Bitplane 4 collision match bit
2 - Bitplane 3 collision match bit
1 - Bitplane 2 collision match bit
0 - Bitplane 1 collision match bit

Setting or clearing these lets me choose any bitplanes to ignore when checking for collisions. I'm using a dual-playfield screen (3 planes each) and I only want to check the front playfield for collisions. Because I haven't done my research, I'm guessing these are planes 4,5 and 6.

In testing, though, on a simple lowres screen of any amount of bitplanes, testing Hardcol(0) never results in a collision being reported.

Now, I'm using WinUAE and I have checked and re-checked that I have switched on full collision detection, but this really has me stumped.

Has anyone ever been successful in using Set Hardcol in this way?

[SamuraiCrow]

I think you're wrong about the playfield bitplanes.  I think playfield 2 is bitplanes 1,3 and 5 while the other playfield is planes 0, 2, and 4.

[HonestFlames]

You're more than likely correct!

I'm becoming mildly frustrated though. I created a quick test app where I open a 4-colour screen, grab a 16x16 sprite and test collisions against drawn circles... I can't get a single ounce of success.

No matter what, the following never results in Hardcol(0) returning the promised -1 value.

Code: [Select]

Repeat
Set Hardcol 1,1
Sprite 0,X Mouse,Y Mouse,1
Text 16,16,"Hardcol(0)="+Str$(Hardcol(0))
Multi Wait
Until Mouse Click

[SamuraiCrow]

If you're using an emulator to test your code, make sure sprite-to-playfield collision checking is being emulated.  Usually that is a rarely-used feature and is deactivated to make the emulation go faster.

[HonestFlames]

Yes, I did check this after about 10 minutes

I'm going to start POKEing at CLXCON next. If that doesn't work, I'm not sure. Back when I first had an Amiga, I wrote an extension, so I could bodge one of those together again.

Not pretty, but it would solve this one issue.