Raycasting 3D render -- Blocks Edition

Found a glitch where if you have a second sprite and have it follow you, it will move not in the way its supposed to. Screenshot of my code down below

can you send the link pls? Then maybe I could help.

In 3D world overlay condition is a little difference from 2D world. I modified some of your project.

  • Jump condition.

    Focus on Z direction, use overlaps in Z dimension block to filter touching in Z first.
    Then, filter falling state by sprite.ZVelocity<0
    Then, optional, sprite.ZPosition> otherSprite.ZPosition + [Height of otherSprite after scale] - AFewToleranceHeight
  • Delay with Throttle block of Timer after hurt.
    Avoid pause in event function
  • Animation setting.
    Raycasting provided animation setting is more efficient, though the animation of Character extension works, but it update by setImage(), which will trigger many update calculations repeatly we needn’t in our case .(image size, hitbox, overlay objects. etc.)
2 Likes

Could you share your project?

what about a top-down view

@AqeeAqee I made a version of your extension (I hope its ok to post it here) that uses the grayscale color palette, and has a nice fade-in effect to objects while preserving textures! It was made in inspiration by the game that @richard is making in the livestream, and I figured it could be expanded so as to not take up like 15 tiles but instead render at runtime! (sprites not supported in the effect)

The extension is:
kiwiphoenix364/pxt-raycasting-mod-grayscale

I made a test project (only uses 2 blocks):

There is a new block at the bottom of the list, and the darkness modifier is normally 1, but you can change it with 0 being no darkness at all. The texture visibility determines how bright the textures are, ranging from 0 and higher, with 1 being normal, 0 being white, and colors above 1 getting (quickly) darker as they get higher (you don’t usually want to go above 2). The texture visibility isn’t a recommended setting to change, because leaving it at 1 is optimal most of the time.

1 Like

No problem! Glad to see someone improve it.
Grayscale color is good idea, it render shodow more linear.
I missed that livestream, let me know which ep and start point, if need me to sync up the context.

BTW, try to change

  • dis / 4 * this.darknessMod

to

  • dis / this.darknessMod

that should means how many tiles away get 1 step darker. More easy to understand and not increase dark so fast, I think.
Just a quick idea, didn’t tested :rofl:

1 Like

This is amazing, not capping I love it

1 Like

You are right about the code, but it should be “/ 2” instead. The current code divides the lighting and the textures, so certain textures don’t just dissapear when they get too dim, bc that’s awkward imo. It only currently renders half of the colors because of this, but if you set the textureVisibility to 2 and the darknessMod to 0, you would see the full textures. I may change this in the future, but thx! I didn’t mean to divide by 4 there! I made a release that fixes that.

Oh~ the key point I mean is " / this.darknessMod ", instead of " * this.darknessMod "
Have you try it?

1 Like

After a while of troubleshooting of how to not entirely divide brightness from textures, I found the solution. I ran the loop in reverse, so it would dim the texture from the dimmest to the brightest instead of the brightest to the dimmest. When it was doing this, it just went black because the color was made darker, then the darker color was iterated making it darker, and so on. With 15 colors of brightness it looks more smooth. I expected the darker colors fading into nothingness earlier than the lighter ones to be weird, but apparently that’s realistic anyways and looks totally normal in-game (once I took an hour to troubleshoot something I probably should have figured out a lot sooner.) I also implemented division like you said. It makes decimals below 1 darker faster than normal, and numbers above 1 slower. The negative numbers no longer have the white fog effect, but I guess that’s OK (I might add a block for that in the future). I like how smooth this mod looks, and it barely has an impact on perf from what I’ve seen because it’s only replace color! Maybe eventually I’ll add fade-in for sprites, but not for this update… I made a release for the current features!

1 Like

could i use this code in a game im creating?

ive made the exact same thing 2 days ago, but how it works is that it checks if using a wait condition instead of a sprites overlap condition.

No problem! Feel free to use these code.

And, the wait condition is fliped by a fix timespan, right? The time could be vary, eg: ducks can jump. Overlap in Z is the touch condition in Z infact.

1 Like

Something.

3 Likes

i forgot to put the code, heres the platformer btw if anyone wanna try it

1 Like

Nice! Are you gonna add to this? If so I’d love to help! (i’m doing a project right now) but I’m able to do art if needed!

1 Like