nesdev.com

What would happen if you change that sequence to: Attempt at adding Vy to y (the above condition check + collision goes here)?

My reasoning: In order for the procedure to be more lightweight, something that takes down the frequency of the procedure should be plugged in somewhere, preferrably near the root of causality. If vy isn't added to y because of a check, no movement needs to happen. Though, i think you'd need to keep upwards and downwards y alterations separate for it to work with jumping. (Edit: a state flag should be enough)

_________________
http://www.frankengraphics.com - personal NES blog

You might get a lot more mileage out of just rewriting the collision check in assembly instead of trying to do it less?

In my game a point collision against the background takes less than 100 cycles; it's not inappropriate or a problem to be doing 30 or 40 checks in a frame. If it was taking, e.g. 1000 cycles because it was written in C, it would be out of the question to do that.

No, you misunderstood me. I don't have problems with the collision check, it's *very* lightweight, no need to translate to assembly. I have my data very well organized and calculations are few and fast. My concerns have to do with the fact that:

- Maybe storing the safe spot *when* you are on the floor instead of just when the player jumps would be more fair to the player.
- Storing all the actors positions could take some time.
- Every Nth frame, when you are on the floor, the collision is detected. This happens because the way G affects VY and VY affects Y causes subpixel increments during a couple of frames, so collision doesn't register as it is calculated at a pixel scale. So detecting the transition of "I am falling" -> "I am on the floor" happens very often while just walking.

I don't think I'm making myself clear, sorry, I'll try to use numbers. I am using 4 bits of subpixel precision (1/16th of a pixel).

Let's start with the player on the floor, y_pixel = 32; y = y_pixel<<4 = 512, vy = 0; . Player is standing on a tile (floor).

- Frame 1, vy += G -> vy = 4; y += vy -> y = 516. y_pixel = 516>>4 = 32. No collision.
- Frame 2, vy += G -> vy = 8; y += vy -> y = 524. y_pixel = 524>>4 = 32. No collision.
- Frame 3, vy += G -> vy = 12; y+= vy -> y = 536. y_pixel = 536>>4 = 33. Collision!

In frame 3, collision is registered in the bottom of the sprite (there's a platform there and the lower end of the bounding box is inside such platform), so vy = 0 and y is repositioned just over the floor (y_pixel = 32).

Then back to frame 1.

Notice how during frames 1 and 2 the player is actually falling, in a subpixel scale.

_________________
http://www.mojontwins.com

So, is this statement correct? the continous flip-flopping between "is falling" and "is standing" while walking needs to be conditioned into a continous "is standing".

For the record, i think your current checkpoint mechanism works perfectly fine for this particular game and level layout, simply because of the high and relatively stable frequency a player will trig it. Introducing more (and varying reasons for) checkpoints potentially also means opening more gateways to hard-to-foresee glitches, cheats, bugs. And the edge between "is falling" / "is standing" as a replacement for "is jumping" poses the possibility of placing the player in a tough spot. Just maybe. Feels like a thing that needs to be tested for a while. Probably not too bad?

_________________
http://www.frankengraphics.com - personal NES blog

I must have been blind.

If you check the walkably of the pixel right beneath the player (just outside the bounding box), it doesn't matter which subpixel value the y coordinate has. It will detect the floor whenever there's one and not if the player is airborne.

Checking when this variable changes, and then saving the respawn info, plus saving it when the player jumps as well looks like the optimal solution.

But, as you say, saving when jumping is enough for this game. I won't touch it.

_________________
http://www.mojontwins.com