It is currently Mon Aug 20, 2018 9:51 am

 All times are UTC - 7 hours

 Page 4 of 4 [ 50 posts ] Go to page Previous  1, 2, 3, 4
 Print view Previous topic | Next topic
Author Message
 Post subject: Re: Juding the mojon twins gamesPosted: Wed Feb 08, 2017 4:31 am
 Formerly WheelInventor

Joined: Thu Apr 14, 2016 2:55 am
Posts: 1724
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

 Post subject: Re: Juding the mojon twins gamesPosted: Wed Feb 08, 2017 5:04 am

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 6600
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

 Post subject: Re: Juding the mojon twins gamesPosted: Wed Feb 08, 2017 6:00 am

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

 Post subject: Re: Juding the mojon twins gamesPosted: Wed Feb 08, 2017 6:14 am
 Formerly WheelInventor

Joined: Thu Apr 14, 2016 2:55 am
Posts: 1724
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

 Post subject: Re: Juding the mojon twins gamesPosted: Wed Feb 08, 2017 7:23 am

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

 Display posts from previous: All posts1 day7 days2 weeks1 month3 months6 months1 year Sort by AuthorPost timeSubject AscendingDescending
 Page 4 of 4 [ 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 1 guest

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

Search for:
 Jump to:  Select a forum ------------------ NES / Famicom    NESdev    NESemdev    NES Graphics    NES Music    Homebrew Projects       2018 NESdev Competition       2017 NESdev Competition       2016 NESdev Competition       2014 NESdev Competition       2011 NESdev Competition    Newbie Help Center    NES Hardware and Flash Equipment       Reproduction    NESdev International       FCdev       NESdev China       NESdev Middle East Other    General Stuff    Membler Industries    Other Retro Dev       SNESdev       GBDev    Test Forum Site Issues    phpBB Issues    Web Issues    nesdevWiki