It is currently Tue Jun 27, 2017 5:19 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 50 posts ]  Go to page Previous  1, 2, 3, 4
Author Message
PostPosted: Wed Feb 08, 2017 4:31 am 
Offline
Formerly WheelInventor

Joined: Thu Apr 14, 2016 2:55 am
Posts: 528
Location: Gothenburg, Sweden
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


Last edited by FrankenGraphics on Wed Feb 08, 2017 5:12 am, edited 1 time in total.

Top
 Profile  
 
PostPosted: Wed Feb 08, 2017 5:04 am 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5324
Location: Canada
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.


Top
 Profile  
 
PostPosted: Wed Feb 08, 2017 6:00 am 
Offline

Joined: Mon May 27, 2013 9:40 am
Posts: 308
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


Top
 Profile  
 
PostPosted: Wed Feb 08, 2017 6:14 am 
Offline
Formerly WheelInventor

Joined: Thu Apr 14, 2016 2:55 am
Posts: 528
Location: Gothenburg, Sweden
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


Top
 Profile  
 
PostPosted: Wed Feb 08, 2017 7:23 am 
Offline

Joined: Mon May 27, 2013 9:40 am
Posts: 308
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


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 50 posts ]  Go to page Previous  1, 2, 3, 4

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group