Megalextoria
Retro computing and gaming, sci-fi books, tv and movies and other geeky stuff.

Home » Digital Archaeology » Computer Arcana » Commodore » Commodore 8-bit » C128: Background and Collission questions
Show: Today's Messages :: Show Polls :: Message Navigator
E-mail to friend 
Switch to threaded view of this topic Create a new topic Submit Reply
C128: Background and Collission questions [message #176] Mon, 02 January 2012 01:17 Go to next message
Martin Brunner is currently offline  Martin Brunner
Messages: 147
Registered: January 2012
Karma: 0
Senior Member
From Newsgroup: comp.sys.cbm

Hello Again!

My plans for a C128 basic game are still ongoing, but I have some
questions about the COLLISSION function and the background images.

I'd try to do some top down view race game, e.g. like BMX Simulator.

So my questions are:

Is it somehow possible to design the tracks in an extra programme, save
them and load them as background image?

How will the collission function work then? How can I specify the area
of the background which won't be any collission?

Thank you


--- Synchronet 3.13a-Win32 NewsLink 1.83
Re: C128: Background and Collission questions [message #200 is a reply to message #176] Mon, 02 January 2012 21:20 Go to previous messageGo to next message
RobertB is currently offline  RobertB
Messages: 4993
Registered: December 2011
Karma: 0
Senior Member
From Newsgroup: comp.sys.cbm

On Jan 1, 10:17 pm, Martin Brunner wrote:

> Is it somehow possible to design the tracks in an extra programme, save
> them and load them as background image?
>
> How will the collission function work then? How can I specify the area
> of the background which won't be any collission?

I know of 2 C128 game programmers who may be able
to help you out. Would you like me to contact them?

Then there are the C128 people who hang out at

http://www.commodore128.org/index.php?action=forum

Perhaps they can help.

Happy New Year!
Robert Bernardo
Fresno Commodore User Group
http://videocam.net.au/fcug
--- Synchronet 3.13a-Win32 NewsLink 1.83
Re: C128: Background and Collission questions [message #233 is a reply to message #176] Tue, 03 January 2012 20:38 Go to previous messageGo to next message
Andreas Kohlbach is currently offline  Andreas Kohlbach
Messages: 1456
Registered: December 2011
Karma: 0
Senior Member
From Newsgroup: comp.sys.cbm

Groepaz wrote on 02. January 2012:
>
> in a typical c64 game collisions are done by doing boundary box checks for
> the sprites.

Oops. I always thought it's a "pixel check". That a pixel must be set to
trigger the collision.
--
Andreas
My Commodore 64 classic game music page at
http://www.ankman.de/commodore-64-sid-music/
--- Synchronet 3.13a-Win32 NewsLink 1.83
Re: C128: Background and Collission questions [message #238 is a reply to message #233] Wed, 04 January 2012 13:55 Go to previous messageGo to next message
Groepaz is currently offline  Groepaz
Messages: 640
Registered: December 2011
Karma: 0
Senior Member
From Newsgroup: comp.sys.cbm

Andreas Kohlbach wrote:

> Groepaz wrote on 02. January 2012:
>>
>> in a typical c64 game collisions are done by doing boundary box checks
>> for the sprites.
>
> Oops. I always thought it's a "pixel check". That a pixel must be set to
> trigger the collision.

in reality its ofcourse down to the programmer, and there also exist games
that use pixel-perfect collision detection (usually implemented using
masking). the point was that the usage of hardware collision detection is
not very common, and on the other hand boundary boxes are :)

--

http://www.hitmen-console.org http://magicdisk.untergrund.net
http://www.pokefinder.org http://ftp.pokefinder.org

Terror ist der Krieg der Armen gegen die Reichen. Krieg ist der Terror der
Reichen gegen die Armen.



--- Synchronet 3.13a-Win32 NewsLink 1.83
Re: C128: Background and Collission questions [message #239 is a reply to message #176] Wed, 04 January 2012 15:58 Go to previous messageGo to next message
Andreas Kohlbach is currently offline  Andreas Kohlbach
Messages: 1456
Registered: December 2011
Karma: 0
Senior Member
From Newsgroup: comp.sys.cbm

Groepaz wrote on 04. January 2012:
>
> Andreas Kohlbach wrote:
>
>> Groepaz wrote on 02. January 2012:
>>>
>>> in a typical c64 game collisions are done by doing boundary box checks
>>> for the sprites.
>>
>> Oops. I always thought it's a "pixel check". That a pixel must be set to
>> trigger the collision.
>
> in reality its ofcourse down to the programmer, and there also exist games
> that use pixel-perfect collision detection (usually implemented using
> masking). the point was that the usage of hardware collision detection is
> not very common, and on the other hand boundary boxes are :)

I thought it was really just the "hardware". Just when a (set) pixel has
the same position as a pixel on the background a certain register would
also be set. And not if a sprite boundary, which shall not have a pixel
set in this case, has the same position as a background pixel.

But am not sure, so I assume I am wrong. :-)
--
Andreas
My Commodore 64 classic game music page at
http://www.ankman.de/commodore-64-sid-music/
--- Synchronet 3.13a-Win32 NewsLink 1.83
Re: C128: Background and Collission questions [message #254 is a reply to message #239] Thu, 05 January 2012 11:30 Go to previous messageGo to next message
Groepaz is currently offline  Groepaz
Messages: 640
Registered: December 2011
Karma: 0
Senior Member
From Newsgroup: comp.sys.cbm

Andreas Kohlbach wrote:

> Groepaz wrote on 04. January 2012:
>>
>> Andreas Kohlbach wrote:
>>
>>> Groepaz wrote on 02. January 2012:
>>>>
>>>> in a typical c64 game collisions are done by doing boundary box checks
>>>> for the sprites.
>>>
>>> Oops. I always thought it's a "pixel check". That a pixel must be set to
>>> trigger the collision.
>>
>> in reality its ofcourse down to the programmer, and there also exist
>> games that use pixel-perfect collision detection (usually implemented
>> using masking). the point was that the usage of hardware collision
>> detection is not very common, and on the other hand boundary boxes are :)
>
> I thought it was really just the "hardware". Just when a (set) pixel has
> the same position as a pixel on the background a certain register would
> also be set.

this is how the hardware sprite detection works, yes.

> And not if a sprite boundary, which shall not have a pixel
> set in this case, has the same position as a background pixel.

boundary box checks are ofcourse done in software, not hardware

--

http://www.hitmen-console.org http://magicdisk.untergrund.net
http://www.pokefinder.org http://ftp.pokefinder.org

....the harm was done: the topic became known as "computer science"---which,
actually, is like referring to surgery as "knife science"---and it was
firmly implanted in people's minds that computing science is about machines
and their peripheral equipment.



--- Synchronet 3.13a-Win32 NewsLink 1.83
Re: C128: Background and Collission questions [message #255 is a reply to message #254] Thu, 05 January 2012 12:59 Go to previous messageGo to next message
Alan Jones is currently offline  Alan Jones
Messages: 70
Registered: January 2012
Karma: 0
Member
From Newsgroup: comp.sys.cbm

On Thu, 05 Jan 2012 17:30:14 +0100, Groepaz wrote:

>Andreas Kohlbach wrote:
>
>> Groepaz wrote on 04. January 2012:
>>>
>>> Andreas Kohlbach wrote:
>>>
>>>> Groepaz wrote on 02. January 2012:
>>>>>
>>>>> in a typical c64 game collisions are done by doing boundary box checks
>>>>> for the sprites.
>>>>
>>>> Oops. I always thought it's a "pixel check". That a pixel must be set to
>>>> trigger the collision.
>>>
>>> in reality its ofcourse down to the programmer, and there also exist
>>> games that use pixel-perfect collision detection (usually implemented
>>> using masking). the point was that the usage of hardware collision
>>> detection is not very common, and on the other hand boundary boxes are :)
>>
>> I thought it was really just the "hardware". Just when a (set) pixel has
>> the same position as a pixel on the background a certain register would
>> also be set.
>
>this is how the hardware sprite detection works, yes.

I've always been intrigued by the hardware sprite collision detection.
I'm not at all interested in playing or programming games, just useful
programming, like engineering apps. Still, we have this built in
hardware resource, and naturally I wanted to take advantage of it. I
was unable to think of a more a general programming technique or app
where the use of the hardware sprite collision detection would be
advantageous. I was thinking along the lines of matching keys to
locks, but I failed to think of anything where sprite collision
detection would be advantageous over HOL programming, other than
games.
>
>> And not if a sprite boundary, which shall not have a pixel
>> set in this case, has the same position as a background pixel.
>
>boundary box checks are ofcourse done in software, not hardware

--- Synchronet 3.13a-Win32 NewsLink 1.83
Re: C128: Background and Collission questions [message #257 is a reply to message #176] Mon, 02 January 2012 22:58 Go to previous messageGo to next message
Groepaz is currently offline  Groepaz
Messages: 640
Registered: December 2011
Karma: 0
Senior Member
From Newsgroup: comp.sys.cbm

Martin Brunner wrote:

> Hello Again!
>
> My plans for a C128 basic game are still ongoing, but I have some
> questions about the COLLISSION function and the background images.
>
> I'd try to do some top down view race game, e.g. like BMX Simulator.
>
> So my questions are:
>
> Is it somehow possible to design the tracks in an extra programme, save
> them and load them as background image?
>
> How will the collission function work then? How can I specify the area
> of the background which won't be any collission?

in a typical c64 game collisions are done by doing boundary box checks for
the sprites. in bmx simulator it works by just dividing the sprite
coordinates by 8, and then using the result as an index into a 1k collision
map.

i am not aware of a generic tool to create/edit such maps, codemasters
supposedly had some inhouse tools for this (they created a bunch of games
using that "engine").

--

http://www.hitmen-console.org http://magicdisk.untergrund.net
http://www.pokefinder.org http://ftp.pokefinder.org

Very few people do anything creative after the age of thirty-five. The
reason is that very few people do anything creative before the age of
thirty-five



--- Synchronet 3.13a-Win32 NewsLink 1.83
Re: C128: Background and Collission questions [message #258 is a reply to message #176] Thu, 05 January 2012 20:27 Go to previous messageGo to next message
Andreas Kohlbach is currently offline  Andreas Kohlbach
Messages: 1456
Registered: December 2011
Karma: 0
Senior Member
From Newsgroup: comp.sys.cbm

Groepaz wrote on 05. January 2012:
>
> Andreas Kohlbach wrote:
>
>> I thought it was really just the "hardware". Just when a (set) pixel has
>> the same position as a pixel on the background a certain register would
>> also be set.
>
> this is how the hardware sprite detection works, yes.
>
>> And not if a sprite boundary, which shall not have a pixel
>> set in this case, has the same position as a background pixel.
>
> boundary box checks are ofcourse done in software, not hardware

Thanks. Now I understand.

But I wonder why you would have the effort and lost of performance to
write software routines for it if the hardware does it already "for free".
--
Andreas

--- Synchronet 3.13a-Win32 NewsLink 1.83
Re: C128: Background and Collission questions [message #274 is a reply to message #258] Fri, 06 January 2012 11:34 Go to previous messageGo to next message
Groepaz is currently offline  Groepaz
Messages: 640
Registered: December 2011
Karma: 0
Senior Member
From Newsgroup: comp.sys.cbm

Andreas Kohlbach wrote:

> Groepaz wrote on 05. January 2012:
>>
>> Andreas Kohlbach wrote:
>>
>>> I thought it was really just the "hardware". Just when a (set) pixel has
>>> the same position as a pixel on the background a certain register would
>>> also be set.
>>
>> this is how the hardware sprite detection works, yes.
>>
>>> And not if a sprite boundary, which shall not have a pixel
>>> set in this case, has the same position as a background pixel.
>>
>> boundary box checks are ofcourse done in software, not hardware
>
> Thanks. Now I understand.
>
> But I wonder why you would have the effort and lost of performance to
> write software routines for it if the hardware does it already "for free".

thats because the hardware collision isnt really terribly useful because of
the way it works. in a typical ("modern") game you will have background
graphics of which only some parts are supposed to be "collision objects",
and the rest is just cosmetic and irrelevant for gameplay. the hardware
collision would however report collisions for all of them, which makes it a
bit useless (you will then have to check what kind of background it really
is anyway). another awkward thing is to deal with the hardware collision in
a sprite multiplexer, where doing this correctly is probably more overhead
than simply checking completely in software :)

so, typically you will find usage of hardware collision in old games where
there is no background graphics behind sprites, and no sprite multiplexer.
in such a setup its actually useable (and fast). in more modern games its
rarely used, because you will have to keep track of positions of various
objects anyway, and checking boundary rectangles isnt *that* expensive
either.

--

http://www.hitmen-console.org http://magicdisk.untergrund.net
http://www.pokefinder.org http://ftp.pokefinder.org

The only purpose for a pistol is to fight your way back to the rifle you
should have never laid down


--- Synchronet 3.13a-Win32 NewsLink 1.83
Re: C128: Background and Collission questions [message #275 is a reply to message #274] Fri, 06 January 2012 12:34 Go to previous messageGo to next message
Hg is currently offline  Hg
Messages: 162
Registered: January 2012
Karma: 0
Senior Member
From Newsgroup: comp.sys.cbm

On 06/01/2012 21:34, Groepaz wrote:
> Andreas Kohlbach wrote:
>
>> Groepaz wrote on 05. January 2012:
>>>
>>> Andreas Kohlbach wrote:
>>>
>>>> I thought it was really just the "hardware". Just when a (set) pixel has
>>>> the same position as a pixel on the background a certain register would
>>>> also be set.
>>>
>>> this is how the hardware sprite detection works, yes.
>>>
>>>> And not if a sprite boundary, which shall not have a pixel
>>>> set in this case, has the same position as a background pixel.
>>>
>>> boundary box checks are ofcourse done in software, not hardware
>>
>> Thanks. Now I understand.
>>
>> But I wonder why you would have the effort and lost of performance to
>> write software routines for it if the hardware does it already "for free".
>
> thats because the hardware collision isnt really terribly useful because of
> the way it works. in a typical ("modern") game you will have background
> graphics of which only some parts are supposed to be "collision objects",
> and the rest is just cosmetic and irrelevant for gameplay. the hardware
> collision would however report collisions for all of them, which makes it a
> bit useless (you will then have to check what kind of background it really
> is anyway). another awkward thing is to deal with the hardware collision in
> a sprite multiplexer, where doing this correctly is probably more overhead
> than simply checking completely in software :)
>
> so, typically you will find usage of hardware collision in old games where
> there is no background graphics behind sprites, and no sprite multiplexer.
> in such a setup its actually useable (and fast). in more modern games its
> rarely used, because you will have to keep track of positions of various
> objects anyway, and checking boundary rectangles isnt *that* expensive
> either.
>

Yes, I've always thought about sprite collision detection that way -
in that it speeds up a simple process which doesn't really need
speeding up anyway.
The VIC-II designers should have saved the silicon they implemented
Col Det with and replaced it with something more useful, like my
personal wish which would have been bitmap line drawing in hardware.

--
T
--- Synchronet 3.13a-Win32 NewsLink 1.83
Re: C128: Background and Collission questions [message #277 is a reply to message #257] Sat, 07 January 2012 03:50 Go to previous messageGo to next message
Martin Brunner is currently offline  Martin Brunner
Messages: 147
Registered: January 2012
Karma: 0
Senior Member
From Newsgroup: comp.sys.cbm

Groepaz schrieb:

> in a typical c64 game collisions are done by doing boundary box checks for
> the sprites. in bmx simulator it works by just dividing the sprite
> coordinates by 8, and then using the result as an index into a 1k collision
> map.

Well, I would like to try my best with the C128 Basic 7.0 functions and
there is a function called "collission". Unfortunately that function is
very slow, so it won't be suitable for games like Arkanoid (because the
ball still will move on a little bit after the collission). But it
should be good enough for make something like BMX-Simulator where a
crash just will be a crash.

By the way: When talking about BMX Simulator, I noticed that there was a
4-player version. Will there ever be a patch for using the
4-joystick-adapter?


--- Synchronet 3.13a-Win32 NewsLink 1.83
Re: C128: Background and Collission questions [message #278 is a reply to message #275] Sat, 07 January 2012 07:31 Go to previous messageGo to next message
Dombo is currently offline  Dombo
Messages: 210
Registered: December 2011
Karma: 0
Senior Member
From Newsgroup: comp.sys.cbm

Op 06-Jan-12 18:34, Hg schreef:
> On 06/01/2012 21:34, Groepaz wrote:
>> Andreas Kohlbach wrote:
>>
>>> Groepaz wrote on 05. January 2012:
>>>>
>>>> Andreas Kohlbach wrote:
>>>>
>>>>> I thought it was really just the "hardware". Just when a (set)
>>>>> pixel has
>>>>> the same position as a pixel on the background a certain register
>>>>> would
>>>>> also be set.
>>>>
>>>> this is how the hardware sprite detection works, yes.
>>>>
>>>>> And not if a sprite boundary, which shall not have a pixel
>>>>> set in this case, has the same position as a background pixel.
>>>>
>>>> boundary box checks are ofcourse done in software, not hardware
>>>
>>> Thanks. Now I understand.
>>>
>>> But I wonder why you would have the effort and lost of performance to
>>> write software routines for it if the hardware does it already "for
>>> free".
>>
>> thats because the hardware collision isnt really terribly useful
>> because of
>> the way it works. in a typical ("modern") game you will have background
>> graphics of which only some parts are supposed to be "collision objects",
>> and the rest is just cosmetic and irrelevant for gameplay. the hardware
>> collision would however report collisions for all of them, which makes
>> it a
>> bit useless (you will then have to check what kind of background it
>> really
>> is anyway). another awkward thing is to deal with the hardware
>> collision in
>> a sprite multiplexer, where doing this correctly is probably more
>> overhead
>> than simply checking completely in software :)
>>
>> so, typically you will find usage of hardware collision in old games
>> where
>> there is no background graphics behind sprites, and no sprite
>> multiplexer.
>> in such a setup its actually useable (and fast). in more modern games its
>> rarely used, because you will have to keep track of positions of various
>> objects anyway, and checking boundary rectangles isnt *that* expensive
>> either.
>>
>
> Yes, I've always thought about sprite collision detection that way -
> in that it speeds up a simple process which doesn't really need
> speeding up anyway.
> The VIC-II designers should have saved the silicon they implemented
> Col Det with and replaced it with something more useful, like my
> personal wish which would have been bitmap line drawing in hardware.

The silicon area saved by omitting collision detect would be
insufficient to replace it with bitmap line drawing in hardware.
Collision detect requires little more than an AND port at the point
where the sprite graphics and bitmap graphics come together and a
flip-flop to hold the result. For drawing lines you need quite a bit
more hardware, and some fundamental changes to the chip design. The
VIC-II chip as we know it only reads from memory, for line drawing it
must also write to memory, and that without interfering with the regular
memory accesses needed to generate a video signal.

Another constraint was engineering time, the C64 and its chips were
designed in an incredibly short time (IIRC a little over 6 months).
Considering this the VIC-II is an amazing piece of work.
--- Synchronet 3.13a-Win32 NewsLink 1.83
Re: C128: Background and Collission questions [message #279 is a reply to message #277] Sat, 07 January 2012 11:38 Go to previous messageGo to next message
Groepaz is currently offline  Groepaz
Messages: 640
Registered: December 2011
Karma: 0
Senior Member
From Newsgroup: comp.sys.cbm

Martin Brunner wrote:

> Groepaz schrieb:
>
>> in a typical c64 game collisions are done by doing boundary box checks
>> for the sprites. in bmx simulator it works by just dividing the sprite
>> coordinates by 8, and then using the result as an index into a 1k
>> collision map.
>
> Well, I would like to try my best with the C128 Basic 7.0 functions and
> there is a function called "collission". Unfortunately that function is
> very slow, so it won't be suitable for games like Arkanoid (because the
> ball still will move on a little bit after the collission). But it
> should be good enough for make something like BMX-Simulator where a
> crash just will be a crash.
>
> By the way: When talking about BMX Simulator, I noticed that there was a
> 4-player version. Will there ever be a patch for using the
> 4-joystick-adapter?

i have been working on that.... maybe some day i will finish my version :)

--

http://www.hitmen-console.org http://magicdisk.untergrund.net
http://www.pokefinder.org http://ftp.pokefinder.org

Three things are certain: Death, Taxes, and lost Data.


--- Synchronet 3.13a-Win32 NewsLink 1.83
Re: C128: Background and Collission questions [message #294 is a reply to message #278] Sun, 08 January 2012 00:26 Go to previous message
Charles Richmond is currently offline  Charles Richmond
Messages: 2754
Registered: December 2011
Karma: 0
Senior Member
From Newsgroup: comp.sys.cbm

"Dombo" wrote in message
news:4f083af0$0$14719$5fc3050@news.tiscali.nl...
> Op 06-Jan-12 18:34, Hg schreef:
>> On 06/01/2012 21:34, Groepaz wrote:
>>> Andreas Kohlbach wrote:
>>>
>>>> Groepaz wrote on 05. January 2012:
>>>>>
>>>>> Andreas Kohlbach wrote:
>>>>>
>>>>>> I thought it was really just the "hardware". Just when a (set)
>>>>>> pixel has
>>>>>> the same position as a pixel on the background a certain register
>>>>>> would
>>>>>> also be set.
>>>>>
>>>>> this is how the hardware sprite detection works, yes.
>>>>>
>>>>>> And not if a sprite boundary, which shall not have a pixel
>>>>>> set in this case, has the same position as a background pixel.
>>>>>
>>>>> boundary box checks are ofcourse done in software, not hardware
>>>>
>>>> Thanks. Now I understand.
>>>>
>>>> But I wonder why you would have the effort and lost of performance to
>>>> write software routines for it if the hardware does it already "for
>>>> free".
>>>
>>> thats because the hardware collision isnt really terribly useful
>>> because of
>>> the way it works. in a typical ("modern") game you will have background
>>> graphics of which only some parts are supposed to be "collision
>>> objects",
>>> and the rest is just cosmetic and irrelevant for gameplay. the hardware
>>> collision would however report collisions for all of them, which makes
>>> it a
>>> bit useless (you will then have to check what kind of background it
>>> really
>>> is anyway). another awkward thing is to deal with the hardware
>>> collision in
>>> a sprite multiplexer, where doing this correctly is probably more
>>> overhead
>>> than simply checking completely in software :)
>>>
>>> so, typically you will find usage of hardware collision in old games
>>> where
>>> there is no background graphics behind sprites, and no sprite
>>> multiplexer.
>>> in such a setup its actually useable (and fast). in more modern games
>>> its
>>> rarely used, because you will have to keep track of positions of various
>>> objects anyway, and checking boundary rectangles isnt *that* expensive
>>> either.
>>>
>>
>> Yes, I've always thought about sprite collision detection that way -
>> in that it speeds up a simple process which doesn't really need
>> speeding up anyway.
>> The VIC-II designers should have saved the silicon they implemented
>> Col Det with and replaced it with something more useful, like my
>> personal wish which would have been bitmap line drawing in hardware.
>
> The silicon area saved by omitting collision detect would be insufficient
> to replace it with bitmap line drawing in hardware. Collision detect
> requires little more than an AND port at the point where the sprite
> graphics and bitmap graphics come together and a flip-flop to hold the
> result. For drawing lines you need quite a bit more hardware, and some
> fundamental changes to the chip design. The VIC-II chip as we know it only
> reads from memory, for line drawing it must also write to memory, and that
> without interfering with the regular memory accesses needed to generate a
> video signal.
>
> Another constraint was engineering time, the C64 and its chips were
> designed in an incredibly short time (IIRC a little over 6 months).
> Considering this the VIC-II is an amazing piece of work.

Besides, Jim Butterfield wrote some assembly routines (callable from BASIC
on the C64) that will draw lines pretty darn fast. I think this program
appeared in a Commodore magazine back in the 80's.

--
+<><><><><><><><><><><><><><><><><><><>+
| Charles Richmond numerist@aquaporin4.com |
+<><><><><><><><><><><><><><><><><><><>+

--- Synchronet 3.13a-Win32 NewsLink 1.83
  Switch to threaded view of this topic Create a new topic Submit Reply
Previous Topic: CBM-Command Version 2.1 Release Candidate 3
Next Topic: Re: Anyone playing with Commodore Vision OS?
Goto Forum:
  

-=] Back to Top [=-
[ Syndicate this forum (XML) ] [ RSS ] [ PDF ]

Current Time: Thu Mar 28 12:26:11 EDT 2024

Total time taken to generate the page: 0.03296 seconds