Scratch

I am been tring this myself and I haven't been able to work right yet. This is what I have so far.
http://scratch.mit.edu/projects/archtest/320593

Please help 

yambanshee wrote:

I'll look into it. You might end up with just having to put all the points on a list and having a constant cheak through every part of the list to see if its x/y is the same as the one n the list. The big problem is that scratch doesint run on the same speed something like flash does, so it wont really work. Speaking of witch, can you teach me more about shapeflag hitTests?

For this, you will have to check the arrays to see if the black tiles are in the way.
http://www.tonypa.pri.ee/tbw/tut05.html

This is how it is done in flash, but unfortunately I can't use it in scratch.

This isn't easy stuff, I tried to work on this and get it to work but it always has glitches.
Language speed isn't really an issue here. I just have to check in the right places.

Also, for shapeflag hitTests just check google.

Last edited by archmage (2008-11-14 09:00:21)

Hi archmage, it's been a while.
Ok, so you're trying to make a list based collision detection?

The idea is about the same as you would normally do it in scratch,
The sprite is in a 2d location: x, y  It has to determine if it is touching something solid, so it senses if it's touching your collision color. (like black) If it passes the test, it goes through, if not, it doesn't.

Your background acts like a 2d array- every x and y location on the screen is either the collision color or not.

So to do this with lists you need to fake a 2d array.
Lets say this is your level full of X bricks:

X XXXXXXXX
X X       
X X  XXX X
X   X    X
XXXXXXXXXX

Lets number this so we know where everything is:

 x
 4 X XXXXXXXX
 3 X X       
 2 X X  XXX X
 1 X   X    X
 0 XXXXXXXXXX
   12345678910 y

The player will drop from the top at x=2, y=4 and and will have to exit at right- x=10, y=3

It's 10 x wide and  5 y tall. that is 2d information that you need to store and retrieve.

BUT lists in scratch are just 1d, so you either need to have multiple x lists for every y row:

list level_x_y4 = [X, ,X,X,X,X,X,X,X,X]
list level_x_y3 = [X, ,X, , , , , , , ]
list level_x_y2 = [X, ,X, , ,X,X,X, ,X]
list level_x_y1 = [X, , , ,X, , , , ,X]
list level_x_y0 = [X,X,X,X,X,X,X,X,X,X]

But your code will have to refer to every row list and that will get complicated fast if you have a tall level.  bad.

OR you can put all the rows into the same list:

list level_x_y = [X, ,X,X,X,X,X,X,X,X,X, ,X, , , , , , , ,X, ,X, , ,X,X,X, ,X,X, , , ,X, , , , ,X,X,X,X,X,X,X,X,X,X,X]

It's a bit harder to read here, but it will be MUCH easier to code for.  good.

But we also need a "level_x_width" variable that we set to 10, so that your code knows to skip 10 in the list to look at the next row.

Currently the player is at:
player_x=2
player_y=4

Here's how the collision code can work:

set player_x_temp to player_x
set player_y_temp to player_y
(store the player's x and y into temporary variables so that we can change them back if the new location was solid and the player couldn't move there.)

* put the gravity and movement code here. In this case it made the user move down to player_x=2, player_y=3 *

If level_x_y's item# [player_x + [player_y * level_x_width]] = "X"
   set player_x to player_x_temp
   set player_y to player_y_temp 
(There was something in the level there, so lets put the player back to the temp position.)

So in the last part, It tested a certain item number in the list for an "X":
In this case it was testing for x=2, y=3 in our level list.
So it looked in x+(y*width of the level)
2+(3*10) which is list item number 32.
(This is why we started the row numbering at 0, otherwise we'd also need to subtract 10.)
There was no "X" there so it didn't move the player back to the temp location,


The player does not have to move a whole cell at a time, it could move .15 of y, but you'll have to modify the test code to test for [[rounded [player_y - .5]]+1]
(or something like that.)
So when player_y = 3.943 it tests 'row 3' in the level list.


If you want one cell in your level to be 25 pixels large on the screen, then you position the player sprite to x = player_x * 25 (and + your scroll location and offset to match your background.)

Does that help?
Please let me know if this makes sense-  or if I need to explain it better.

Last edited by AddZero (2008-11-14 18:09:39)

AddZero wrote:

Hi archmage, it's been a while.
Ok, so you're trying to make a list based collision detection?

The idea is about the same as you would normally do it in scratch,
The sprite is in a 2d location: x, y  It has to determine if it is touching something solid, so it senses if it's touching your collision color. (like black) If it passes the test, it goes through, if not, it doesn't.

Your background acts like a 2d array- every x and y location on the screen is either the collision color or not.

So to do this with lists you need to fake a 2d array.
Lets say this is your level full of X bricks:

Code:

X XXXXXXXX
X X       
X X  XXX X
X   X    X
XXXXXXXXXX

Lets number this so we know where everything is:

Code:

 x
 4 X XXXXXXXX
 3 X X       
 2 X X  XXX X
 1 X   X    X
 0 XXXXXXXXXX
   12345678910 y

The player will drop from the top at x=2, y=4 and and will have to exit at right- x=10, y=3

It's 10 x wide and  5 y tall. that is 2d information that you need to store and retrieve.

BUT lists in scratch are just 1d, so you either need to have multiple x lists for every y row:

Code:

list level_x_y4 = [X, ,X,X,X,X,X,X,X,X]
list level_x_y3 = [X, ,X, , , , , , , ]
list level_x_y2 = [X, ,X, , ,X,X,X, ,X]
list level_x_y1 = [X, , , ,X, , , , ,X]
list level_x_y0 = [X,X,X,X,X,X,X,X,X,X]

But your code will have to refer to every row list and that will get complicated fast if you have a tall level.  bad.

OR you can put all the rows into the same list:

Code:

list level_x_y = [X, ,X,X,X,X,X,X,X,X,X, ,X, , , , , , , ,X, ,X, , ,X,X,X, ,X,X, , , ,X, , , , ,X,X,X,X,X,X,X,X,X,X,X]

It's a bit harder to read here, but it will be MUCH easier to code for.  good.

But we also need a "level_x_width" variable that we set to 10, so that your code knows to skip 10 in the list to look at the next row.

Currently the player is at:
player_x=2
player_y=4

Here's how the collision code can work:

set player_x_temp to player_x
set player_y_temp to player_y
(store the player's x and y into temporary variables so that we can change them back if the new location was solid and the player couldn't move there.)

* put the gravity and movement code here. In this case it made the user move down to player_x=2, player_y=3 *

If level_x_y's item# [player_x + [player_y * level_x_width]] = "X"
   set player_x to player_x_temp
   set player_y to player_y_temp 
(There was something in the level there, so lets put the player back to the temp position.)

So in the last part, It tested a certain item number in the list for an "X":
In this case it was testing for x=2, y=3 in our level list.
So it looked in x+(y*width of the level)
2+(3*10) which is list item number 32.
(This is why we started the row numbering at 0, otherwise we'd also need to subtract 10.)
There was no "X" there so it didn't move the player back to the temp location,


The player does not have to move a whole cell at a time, it could move .15 of y, but you'll have to modify the test code to test for [[rounded [player_y - .5]]+1]
(or something like that.)
So when player_y = 3.943 it tests 'row 3' in the level list.


If you want one cell in your level to be 25 pixels large on the screen, then you position the player sprite to x = player_x * 25 (and + your scroll location and offset to match your background.)

Does that help?
Please let me know if this makes sense-  or if I need to explain it better.

This is pretty helpful to know.