Hi ...

I am looking for some guides / guidance when it comes to checking for collisions between sprites. I have found some excellent tutorials that have given me a set of strategies that I can use when working with shapes created by rectfill() and circfill() but I am struggling to bring these ideas to situations where I have created my own sprites.

All I am interested in doing right now is finding a way to check if one sprite is touching another but I am not sure how the 8x8 grid that we are given for our sprites can be read / checked for - most particularly if a sprite doesn't take up the full 8x8.

I am basically starting from scratch here and any help, guidance or suggestions for something to read / watch would be greatly appreciated.

Thanks

D.

Have you seen this? https://www.lexaloffle.com/bbs/?tid=2119 I don't know if it applies 100% to what you're trying to do, but it might be a good starting point? That's what I found when I was looking for a way to do collisions in pico-8.

Hi - Thanks for the reply. I did stumble upon that post but I got sort of lost as I worked my way through the code. It seemed as though there were two areas of focus - sprite to sprite and sprite to "wall" and I probably wasn't focused enough to pick apart the approaches as I looked at the code. I think I need to go back to it and have a second look.

If you have a sense as to which part of the code I should be focusing on, I'd appreciate some guidance.

D.

Here is a cart containing a little more easily understandable code with notes for each section of code.

BOXFACE - A simple Platform setup

I have the same frustration you are facing, so you are not alone in this endeavor.
There is plenty of documentation out there but most of it assumes you already know a moderate amount of programming.

Math is a BIG factor in programming, being able to visualize 3-dimensional space is a plus.
In order to start programming; its best to start with understanding how the interpreter operates/reads the code it is given, along with knowing the special characters/symbols for that interpreter.
Then comes the task of understanding how to write the code for the interpreter.
This tends to be the hardest part, the physical manifestation of producing your desired results, which truly means learning a new language.

My alternative advice is to spend a lot of time sifting through a lot of carts and their containing code.
There is more than one way to skin a cat when it comes to programming (meaning various ways to write code).

Here are a few links I found helpful.

Programming in LUA:
https://www.lua.org/pil/contents.html

LUA Directory:
http://lua-users.org/wiki/LuaDirectory

A list of helpful PICO-8 resources:
https://github.com/felipebueno/awesome-PICO-8#

PICO-8 WIKIA (incomplete)
http://pico-8.wikia.com/wiki/Pico-8_Wikia

Cartesian coordinate system:
https://en.wikipedia.org/wiki/Cartesian_coordinate_system

PICO-8 REDDIT
https://www.reddit.com/r/pico8/

Here are a few blog posts I've created to help me work through Programming in PICO-8.
They are more so Notes than any kind of tutorial, but documentation of working results in a simple form.

FUNCTION examples()

Movement and Animation

Scrolling Marquee

I feel the biggest problem with PICO-8 is the lack of comments within the code.

I understand the limits of PICO-8 and as to why most people that program within PICO-8 leave the comments out.
However PICO-8 is marketed as a simple beginner's tool, for those whom want to start making games with very little to no programming knowledge (This is how I interpreted it).
Well. I say all that is negated when removing a key element for teaching/learning a programming language; the comments.
It also teaches bad habits by leaving your notes restricting to your memory and no physical form for yourself or others to pickup on.

Comments within code are a good habit to start because:

1. It organizes your code as far as readability/understanding each parameter.
2. It greatly helps others who are learning or want to change/update the code.

Hi,

For sprite to sprite, instead of trying to calculate the collision of what is displayed on screen you could use invisibles hitbox.
It is not needed to make a complex shape, a simple rectangle would be enough in most cases. (Unless you would like to demake Street Fighter, in this case it would be 2-3 rectangles).

I'm not sure if we could do better but you could loop over the hitboxes like this:

for i=1,#hitboxes-1 do
 for j=i+1,#hitboxes do
  if collision(hitboxes[i],hitboxes[j]) then event(); end;
 end;
end;

For sprite to wall, given the wall is in the map, you could use mget to retrieve the ID of the sprite (it searches inside the map but as the walls doesn't move, what is displayed on screen correspond to what is in the map). Given this ID you could use fget to get one of the flags of the sprite.
You could use a function like this for example, now the difficulty is to have the right x,y coordinates.

-- verify the sprite at x,y is solid
-- floortest is to check a sprite 
-- is a passable floor (possible to jump trough it)
-- put to true for collision above and on the side of the sprite
-- put to false for collision below unless for going through the ground
-- to define a sprite to be solid activate flag 6
-- to define a sprite to be semi solid activate flag 6 and 5
function solid(x,y,floortest)
 local solid=fget(mget(x,y),6)
 local floorsolid=not fget(mget(x,y),5)
 return solid and (not floortest or floorsolid)
end

Thanks for all the help, everybody. I really appreciate it - I'm probably not going to have a chance to pick away at these ideas until the weekend but thanks for giving me some places where I can try to get started.

D

mimick do you want to demake street fighter II with me? :D lol

Did you guys ever demake street fighter?