Could someone speed up the hitbox generation in this?
The main problem with it being slow is the player can be sent to a glitch level or get past obstacles while the game is still generating the hitboxes.

TheUltimatum wrote:

Could someone speed up the hitbox generation in this?
The main problem with it being slow is the player can be sent to a glitch level or get past obstacles while the game is still generating the hitboxes.

Just stop the game until the hitbox is generated. If its in some sort of loop or something, just throw in a wait until.

BKFighter wrote:

TheUltimatum wrote:

Could someone speed up the hitbox generation in this?
The main problem with it being slow is the player can be sent to a glitch level or get past obstacles while the game is still generating the hitboxes.

Just stop the game until the hitbox is generated. If its in some sort of loop or something, just throw in a wait until.

I thought of doing that but it kind of interrupts the gameplay…

TheUltimatum wrote:

BKFighter wrote:

TheUltimatum wrote:

Could someone speed up the hitbox generation in this?
The main problem with it being slow is the player can be sent to a glitch level or get past obstacles while the game is still generating the hitboxes.

Just stop the game until the hitbox is generated. If its in some sort of loop or something, just throw in a wait until.

I thought of doing that but it kind of interrupts the gameplay…

Based on your code, I think some variation of that will have to take place… Though technically if you place Link a bit above the ground, the hitboxes might load before he hits the ground. I'm not seeing any other way though in Scratch.

That's impressive.

When I did a Pac-Man clone I used a collision sprite
with 4 different colors. Each unique for up, down, left, right.

When one collided with the wall it would change a binary number in a list
from 1 “able to travel” to 0 “unable to travel” in that dir.

While I think it was faster than your costume-flip collision method,
I don't think color-checking would be suitable for your game,
as the objects you collide with aren't all one color…

That being said, maybe there's ways to speed it up.

One way might be to have it do a costume change to an intermediary check.

You create 2 costumes:
One that spans the Top and Left
and another that spans the Bottom and Right

You check collision status with this,
then further refine by determining the specific.

That way, you only ever go through 2 checks, never 4.

As it is now, it might have to go through Top, Left, Bottom, then finally Right.

If you combined Top&Left, then you can check this,
then decide if it's Top or Left with your next costume change.
…
Tho as I type this and look back at the code,
the way I'm thinking it runs,
and the way it actually runs might be a bit different.

Can you just make another list that contains a grid of the costume codes?
You already have 1-6, 0 could be free to walk through, like grass and whatnot.

00000000
01111110
01066010
01000010
01100110
00000000

Something like this?
Even faster would be to name the costumes as numbers,
so you don't have to check against the variable,
just set it and forget it.

set [L v] to [1]
set [X v] to [1]
repeat (length of [CollisionCodes v])
    repeat (length of (item (X) of [CollisionCodes v])
        switch costume to (letter (L) of (item (X) of [CollisionCodes v])
        set [CloneTypeBox v] to (letter (L) of (item (X) of [CollisionCodes v])
        change [L v] by (1)
    end
    change [X v] by (1)
end

Doyousketch2 wrote:

That's impressive.

When I did a Pac-Man clone I used a collision sprite
with 4 different colors. Each unique for up, down, left, right.

When one collided with the wall it would change a binary number in a list
from 1 “able to travel” to 0 “unable to travel” in that dir.

While I think it was faster than your costume-flip collision method,
I don't think color-checking would be suitable for your game,
as the objects you collide with aren't all one color…

That being said, maybe there's ways to speed it up.

One way might be to have it do a costume change to an intermediary check.

You create 2 costumes:
One that spans the Top and Left
and another that spans the Bottom and Right

You check collision status with this,
then further refine by determining the specific.

That way, you only ever go through 2 checks, never 4.

As it is now, it might have to go through Top, Left, Bottom, then finally Right.

If you combined Top&Left, then you can check this,
then decide if it's Top or Left with your next costume change.
…
Tho as I type this and look back at the code,
the way I'm thinking it runs,
and the way it actually runs might be a bit different.

Can you just make another list that contains a grid of the costume codes?
You already have 1-6, 0 could be free to walk through, like grass and whatnot.

00000000
01111110
01066010
01000010
01100110
00000000

Something like this?
Even faster would be to name the costumes as numbers,
so you don't have to check against the variable,
just set it and forget it.

set [L v] to [1]
set [X v] to [1]
repeat (length of [CollisionCodes v])
    repeat (length of (item (X) of [CollisionCodes v])
        switch costume to (letter (L) of (item (X) of [CollisionCodes v])
        set [CloneTypeBox v] to (letter (L) of (item (X) of [CollisionCodes v])
        change [L v] by (1)
    end
    change [X v] by (1)
end

I already have a grid that contains the tile values. I'm not very sure about what you meant in the smaller text. But it seems that my game does run a bit different than your understanding of it. A basic overview would be that every tile and the player has an invisible hitbox. The tiles have a hitbox that is a clone. The player's hitbox just checks if it is touching any clones. If it is it flags the player sprite that there is a collision. The player does not visually move back to avoid bumping while colliding but it actually changes two variables called linkX and linkY. It then sets the player x and y to those variables depending upon if there is another collision or not. This is the basic collision system. The main thing that I am having problems with is the level generation. This system is just stamping the tile's image and then creates the tile specific hitbox. at the tile's x and y. The main problem is that the level generator has to wait for the hitbox to be created and the use of a wait until block doesn't allow me to run the custom block this script is in without screen refresh. In turn this causes. The generation to be a bit slow.

Doyousketch2 wrote:

That's impressive.

When I did a Pac-Man clone I used a collision sprite
with 4 different colors. Each unique for up, down, left, right.

When one collided with the wall it would change a binary number in a list
from 1 “able to travel” to 0 “unable to travel” in that dir.

While I think it was faster than your costume-flip collision method,
I don't think color-checking would be suitable for your game,
as the objects you collide with aren't all one color…

That being said, maybe there's ways to speed it up.

One way might be to have it do a costume change to an intermediary check.

You create 2 costumes:
One that spans the Top and Left
and another that spans the Bottom and Right

You check collision status with this,
then further refine by determining the specific.

That way, you only ever go through 2 checks, never 4.

As it is now, it might have to go through Top, Left, Bottom, then finally Right.

If you combined Top&Left, then you can check this,
then decide if it's Top or Left with your next costume change.
…
Tho as I type this and look back at the code,
the way I'm thinking it runs,
and the way it actually runs might be a bit different.

Can you just make another list that contains a grid of the costume codes?
You already have 1-6, 0 could be free to walk through, like grass and whatnot.

00000000
01111110
01066010
01000010
01100110
00000000

Something like this?
Even faster would be to name the costumes as numbers,
so you don't have to check against the variable,
just set it and forget it.

set [L v] to [1]
set [X v] to [1]
repeat (length of [CollisionCodes v])
    repeat (length of (item (X) of [CollisionCodes v])
        switch costume to (letter (L) of (item (X) of [CollisionCodes v])
        set [CloneTypeBox v] to (letter (L) of (item (X) of [CollisionCodes v])
        change [L v] by (1)
    end
    change [X v] by (1)
end

I do like your idea of list based collision though it would mean I would have to change a large portion of the code.

Ok, so if I get this right, it sorta runs in reverse from what I was thinking.

Tile Hitboxes are in a loop checking if they are in contact with Link,
then it sets the variables to tell what type it is.

I would have the sprite that's moving check if it's touching the hitbox,
then send a broadcast to request the type.

when I receive [CollisionCheck v]
set [cloneHitboxType v] to (costume #)

You might need to set costume 7 as blank for this to work,
because there is no costume 0.

You also have this twice in the Tile Hitbox sprite,
so one could be safely deleted.

if <not <(linkTouchingTileType) = (cloneType)>> then
    set [linkTouchingTileType v] to (cloneType)
end

Doyousketch2 wrote:

Ok, so if I get this right, it sorta runs in reverse from what I was thinking.

Tile Hitboxes are in a loop checking if they are in contact with Link,
then it sets the variables to tell what type it is.

I would have the sprite that's moving check if it's touching the hitbox,
then send a broadcast to request the type.

when I receive [CollisionCheck v]
set [cloneHitboxType v] to (costume #)

You might need to set costume 7 as blank for this to work,
because there is no costume 0.

You also have this twice in the Tile Hitbox sprite,
so one could be safely deleted.

if <not <(linkTouchingTileType) = (cloneType)>> then
    set [linkTouchingTileType v] to (cloneType)
end

Well actually it's a mix of both. The link hitbox checks for collisions and the tile hotbox will set the linkTouchingTileType if it is touching the hitbox.

Doyousketch2 wrote:

You might need to set costume 7 as blank for this to work,
because there is no costume 0.

Oh wait, it wouldn't collide with a clone that isn't there…
so it would never broadcast a request for it.
Thus, no need for a blank tile #7.

Doyousketch2 wrote:

Doyousketch2 wrote:

You might need to set costume 7 as blank for this to work,
because there is no costume 0.

Oh wait, it wouldn't collide with a clone that isn't there…
so it would never broadcast a request for it.
Thus, no need for a blank tile #7.

Wow! your remix is pretty efficient with the hitbox generation…