Roger Davis 2020-02-09 00:22 (Edited)
Hi there! I've been looking at the latest @was8bit tutorials on game programming (featuring 'PAC-MAN'), and reading the comments on there. It suddenly occurred to me that a new collision detection routine based on COLOUR, rather than the positions of walls/ objects might work better somehow for a PAC-MAN game . . IF it was possible?🤔 Here's why, and HOW it could work - IF possible! In was8bit's game (so far), PAC-MAN only comes into contact with two main colours - Blue, and Yellow. So, . . If it was possible to write a SUB where the players Sprite could detect what colours it is in contact with, wouldn't that perhaps simply matters? For instance, a statement COULD go something like this : IF (players Sprite number) HITS (touches) COLOUR (number) THEN . . . Etc. So in was8bit's PAC-MAN game : IF Yellow (the PAC-MAN players Sprite) touches another colour yellow, - or maybe you could make the 'pills' RED (?) then the game would 'know' that PAC-MAN has eaten a YELLOW/ RED PILL. Similarly, . . if Yellow (players Sprite) touches the colour Blue, then the game could recognise that PAC-MAN is touching a wall and not a 'Ghost' . . something like that anyway! Is this possible? 🤔🤔🤔
Roger Davis 2020-02-09 00:47 (Edited)
What I have in mind above, might be useful for games with a smaller colour palette. It would also be useful to beginners who have trouble with using the current collision detection methods. Only for 'simpler' games. Maybe one of you very clever coders out there could come up with a Subroutine like this? Or even a whole sub-Command set? Perhaps you could even write a 'game environment' or a tool based on this idea! Anyway, I hope someone out there can make use of this notion 😊👍
was8bit 2020-02-09 08:35 (Edited)
Yes... now you know that cell.c(x,y) yields then character's graphic reference number (what you see in CHAR DESIGNER when you tap a space to edit a graphic)
Well, cell.a(x,y) yields the attribute #... there are several editable attributes... PAL FLIP PRIO ... as long as your ONLY USING PAL attribute, and are NOT using FLIP or PRIO then this command easily yields the PAL color set for the character at the x,y coordinates....
However, since I usually use cell.c alot, it makes sense for me to not use different ways to identify items, so i stick to cell.c, and in the rare event i need to differentiate between two items of same graphic but different colors, i make a copy of the graphic to get a new char# for the other color...
For a game with ALL the same graphic, and different color palettes, then in THAT case you would only be using cell.a so that would work...
...cell.a will only yield 8 different types (PAL 0 to PAL 7) where cell.c can yield 256 different types (char 0 to char 255) so usually most games would go that route...
Additionally, if you use FLIP or PRIO you will have to use clever binary math to extract the PAL value from the attribute value...
..... just a few thoughts on it :)
Roger Davis 2020-02-09 09:17
Thanks Was8bit, things are clearer now. I wasn't criticising your method, rather I was wanting to find out for EVERYONE concerned, whether what I outlined in my comment above was feasible or not. So the quick answer is 'yes', but with the provisos that you speak of with regard to using cell.a(x,y). Interesting! Most interesting indeed. Thanks for that Was8bit! I'm afraid the use of binary math - clever or not - is far beyond my current ability level! So FLIP and PRIO go out of the window if that's the case! Lol 😂 But still, . . Yeah . . Possible! : )
was8bit 2020-02-09 09:24
:D
was8bit 2020-02-09 09:34
As a side note, similar for SPRITES ... if plain sprites size 1x1 then easily YES but otherwise, yes with binary extraction...
Roger Davis 2020-02-09 10:40
Got it Was8bit! Thank you very much! 😊👍
was8bit 2020-02-09 15:02
:)
Timo 2020-02-11 07:36
I agree that checking the cell’s character is a better approach than getting pixel colors. You won’t get pixel perfect collision detection, but for backgrounds it’s usually not so important.
Roger Davis 2020-02-13 00:12 (Edited)
Thank you @Timo, I understand now. My thoughts were only theoretical to be honest, and I didn't even know if it was AT ALL possible. I was trying to come up with what I believed may have been a "simpler" method of collision detection for beginners to toy with, and the intention was only that it be used for very simplistic games. But I can see now that it would be pretty pointless. Thank you very much for replying though! Both yourself and Was8bit do a marvellous job on here with helping people! 😀👍
was8bit 2020-02-13 02:58 (Edited)
Happy to help :)
... and your idea isn't pointless :) it is really just a matter of choice and preference... i can think of a situation where it would be helpful...
Lets say you have 8 ship shapes and you use 8 palettes so combined you have 8x8 total shipes of different shapes and different colors... in this case making 64 ships just to keep your checks limited to char# only would be tedious... in this special case using BOTH char# and pal# woud be useful...
if each of the 64 ships are unique, i would combine both checks with math to create a unique ship ID... if char# were 1-8, then my math would be...
SHIPCELL=CELL.C(X,Y)
SHIPCOLOR=CELL.A(X,Y)
SHIPID=80*SHIPCELL+SHIPCOLOR
This will yield #s 10-87 ... skipping a few #s here and there, but each ship would yield a unique #... and you all get its char# and PAL color # just in case you needed it ;)
In a game, the shipid could also double as its strength value, or perhaps its point/score value... or both....
was8bit 2020-02-13 03:02
One could also use this idea for not only ship, but for say floating notes... their char# or shape could be the note they play, and their color could be their voice... in fact, i think i will make that game to demonstrate :)
was8bit 2020-02-13 03:37
... here is my demonstration ;)
https://lowresnx.inutilis.com/topic.php?id=1014
Roger Davis 2020-02-13 09:40
That's terrific was8bit! Many thanks for the demo, and the information. I get it now! 😃
was8bit 2020-02-13 10:24
:D