It is currently Fri Dec 14, 2018 2:11 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 1452 posts ]  Go to page Previous  1 ... 49, 50, 51, 52, 53, 54, 55 ... 97  Next
Author Message
PostPosted: Tue Oct 16, 2012 9:10 am 
Offline
User avatar

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 940
Location: cypress, texas
Kasumi wrote:
In this case it's really more of change in perception than learning anything new.

You have two bytes. Together, they represent one number.
You're probably familiar with this way.
Number = hibyte*256+lobyte for a range of 0 through 65535.

But the computer really doesn't care about what the bytes represent to you.

Number could also represent onebyte + (otherbyte/256) to you for a range of 0 through 255+(255/256). In this case "otherbyte" represents the fractional part of a number.

In both cases additions/subtractions to the bytes are done in exactly the same way, they just represent something different for you, the programmer.

A speed like this:
onebyte = #$01
otherbyte = #$00
added to the characters position means the character moves one pixel every frame.
A speed like this:
onebyte = #$00
otherbyte = #$40
added means the character moves one pixel every 4 frames. (Because that's how many adds of that amount it would take to carry 1 pixel over)

(This also means your position will need another byte to represent the fractional part of the position, which if you scroll means you'll need at least 3 bytes for the position alone, two for the speed)


At least, that's one way to set it up. Make sense?
Yes, it does finally after I read tokumaru's post. That short summary reminded me what I learned yesterday... and so coming back and reading your post again... your words are incredibly helpful during my second read! Thank you Kasumi! :D Well, they will be incredibly helpful once I spend the time to explore 8.8 ...

tokumaru wrote:
unregistered wrote:
I have kind of choose to use Q3.5 nums... on page 13 of that pdf i think I remember. Would something like that work well for this falling faster math? Or they show a Q3.13 also.

Those will make it hard to use the integer part of the values... Kasumi's suggestion of using 1 byte for the integer part and another for the fractional part (i.e. 8.8) makes much more sense. That way you easily use the high byte as the integer part as is, without having to shift bits around.

Quote:
how did you do that? :o

How did I do what? Show 8 and ) instead of the smiley? There's a checkbox in below the text area in the posting/editing page that disables smileys in the current post.
All excellent words... thanks very much tokumaru! :D

edit
edited again


Top
 Profile  
 
PostPosted: Tue Oct 16, 2012 3:56 pm 
Offline
User avatar

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 940
Location: cypress, texas
In that pdf I found yesterday... it trys to convince me that only 3 bits are needed for the integer part in Example 5 on page 9... and I am wondering could I use the 3 bits for that and then use the other 5 bits to store something else? Using and #00000111b before loading it... do you understand?

Or would it be ok to create an Q8.8? With that I could use numbers in a range from (-128 to 127.99609375). Does that work out ok? tokumaru (and Kasumi too) suggested using an 8.8 so that must be ok. :)

A Q3.8 would be able to use numbers in a range from (-4 to 3.99609375)

Which one would you pick? :) A Q3.8 or a Q8.8? Hope all my math here is correct.

edit: Woah, ok Kasumi, it doesn't have to be a signed value!!! YEAY! Thank you
a lot for this awesome help! :D


Last edited by unregistered on Tue Oct 16, 2012 4:41 pm, edited 1 time in total.

Top
 Profile  
 
PostPosted: Tue Oct 16, 2012 4:41 pm 
Offline
Formerly 65024U

Joined: Sat Mar 27, 2010 12:57 pm
Posts: 2265
I dunno what you're doing, but if you're doing something with a sub-pixel or decimal to get a fine tune on things, just use a low byte that only changes the high byte when it "rolls over" so that way you can add stuff each from but nothing happens.


Last edited by 3gengames on Tue Oct 16, 2012 4:58 pm, edited 1 time in total.

Top
 Profile  
 
PostPosted: Tue Oct 16, 2012 4:53 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 11012
Location: Rio de Janeiro - Brazil
You absolutely can't work with a range smaller than 0-255, because you need that much to represent coordinates on the screen. The obvious choice is 8.8, unsigned. Your document insists on 3.13 probably because it's focused on other applications, like trigonometry or something, but this is not your case.


Top
 Profile  
 
PostPosted: Wed Oct 17, 2012 8:22 am 
Offline
User avatar

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 940
Location: cypress, texas
3gengames wrote:
... just use a low byte that only changes the high byte when it "rolls over" so that way you can add stuff each from but nothing happens.
:D Thanks 3gengames; I hope to achieve that.

tokumaru wrote:
You absolutely can't work with a range smaller than 0-255, because you need that much to represent coordinates on the screen. The obvious choice is 8.8, unsigned. Your document insists on 3.13 probably because it's focused on other applications, like trigonometry or something, but this is not your case.
Thank you tokumaru those are three great wonderful points and they've answered all my questions! :D I'll focus on 8.8, unsigned, numbers now.

edit

edit2: 8.8 Unsigned numbers range from (0 to 255.99609375)... that works incredibly well! :D


Top
 Profile  
 
PostPosted: Mon Oct 22, 2012 8:54 am 
Offline
User avatar

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 940
Location: cypress, texas
Now our sprite falls and lands on the ground! :D Now I would like to see if I could move forward. I should just check each metatile below her feet... if it is solid she can move forward. Should I move her forward and then fix her position if needed? Yes, I should push her back if she has walked into a solid block. I can figure this out! :)


Top
 Profile  
 
PostPosted: Mon Oct 22, 2012 9:45 am 
Offline
User avatar

Joined: Wed Oct 15, 2008 11:50 am
Posts: 943
Wow, I can't believe this thread is still going :D It's inspiring to see that you've got so much commitment to this!


Top
 Profile  
 
PostPosted: Mon Oct 22, 2012 11:11 am 
Offline
User avatar

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 940
Location: cypress, texas
qbradq wrote:
Wow, I can't believe this thread is still going :D It's inspiring to see that you've got so much commitment to this!
My mom and dad have been inspiring toward me... they... well, my mom she has told me that I am going to finish programming this game. :D There is so much that has to be done; my sister has finished most of the levels... I'm enjoying collision detection working now. It has been a little more than a year since I decided on attempting collision detection. That was on page 19... now it's something like 51 pages.

I am so happy you've come back! :D Thank you very much qbradq.

edit
edited once more: In my input code there's this part
Code:
@right  lda currControllerButtons  ;Is Right down?
        and #BUTTON_RIGHT ;00000001b
      beq not_dn
      inc oX
How would you change this code? I want to replace that
inc oX with code that checks the next space to see if it is solid. I'm not shure if a method should be jsr'd to... or maybe that would take too much time? :?


Top
 Profile  
 
PostPosted: Mon Oct 22, 2012 3:53 pm 
Offline
User avatar

Joined: Wed Oct 15, 2008 11:50 am
Posts: 943
So I'm not going to read 52 pages back :D I assume from the few pages I've caught up on this is not cell-based (like Zelda II's overworld), but subpixel-based (like Mario).

Typically I use a velocity variable for every object. So in the above code snippet I would set the player's X velocity value to some value. Then during the object update routine I apply the velocity to the position, then check for collisions, and if there is a collision react to it. If you do go this route, do Y movement and collision detection first, then X. Trust me on that one :D

If you want to take the immediate route I would recommend JSR'ing to a routine that calculates what the X value would be, then sees if that movement is possible. Depending on your level data layout this routine might be pretty complex, and I personally wouldn't want it cluttering up my input routine.

Also, sounds like you've got good parents and a pretty awesome sister :D


Top
 Profile  
 
PostPosted: Mon Oct 22, 2012 6:51 pm 
Offline
Formerly 65024U

Joined: Sat Mar 27, 2010 12:57 pm
Posts: 2265
Not that I have programmed a game yet, but I always thought for velocity and stuff that a one byte value would work perfect, since I highly doubt your game can scroll 3 rows at a time, so 4.4 combined in to one byte will make you able to save a few bytes over all and work fine. Just my idea on it, but please don't let it confuse you, I'm just randomly blurbing it. :)


Top
 Profile  
 
PostPosted: Mon Oct 22, 2012 6:55 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 11012
Location: Rio de Janeiro - Brazil
Controller input shouldn't directly affect the horizontal position of the player. Instead, it should affect the horizontal velocity (just like gravity affects its vertical velocity), and the velocity, whatever it is, should be added to the player's position every frame (again, like happens with vertical movement).

If a direction is pressed, increase velocity in that direction, if no direction is pressed, gradually decrease the velocity until it reaches 0 (this creates a nice inertia effect). After adding the velocity variable to the current position, check whether the block(s) at the edge of the player in the direction of the movement are solid, in which case you need to push the character back, like we discussed before.

Ejecting from the right should be exactly same as repelling from the ground, while the formula for ejecting from the left or from the ceiling is a bit different, but I'm sure you'll figure it out.


Top
 Profile  
 
PostPosted: Mon Oct 22, 2012 7:24 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20875
Location: NE Indiana, USA (NTSC)
That is, unless you want physics like Mega Man or Contra, which don't really have a lot of inertia.


(Speaking of inertia, NovaYoshi giggled at this illustration.)


Top
 Profile  
 
PostPosted: Mon Oct 22, 2012 8:05 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 11012
Location: Rio de Janeiro - Brazil
I remember Mega Man having a tiny bit of inertia... Yup, it's there, I just checked. It seems that he just accelerates and decelerates really really fast.


Top
 Profile  
 
PostPosted: Tue Oct 23, 2012 11:52 am 
Offline

Joined: Wed Mar 09, 2005 9:08 am
Posts: 419
And additionally his speed downwards constantly grows if he's standing on a moving platform of some kind. When I was playing MM1 in the good ol' days it always puzzled me why falling off a platform would get you "down to earth" so much quicker than jumping off it. Little could I know that over 20 years later people would use such a peculiar behavior to beat each other's score in prerecorded demo modes (aka TAS) for the very same game... :)


Top
 Profile  
 
PostPosted: Tue Oct 23, 2012 1:37 pm 
Offline
User avatar

Joined: Wed Oct 15, 2008 11:50 am
Posts: 943
Yea, platformer physics can be painful at times.

So OP, here's a list of games off the top of my head you can look at that do it right:

Zelda II: Adventure of Link, The
Super Mario Bro.s
Super Mario Bro.s 3
Metroid

And here's a few that do it very poorly:

EVERY Castlevania game, but especially CV1
Most Mega Man games, especially MM1
Any Donkey Kong game
Ghosts 'n Goblins


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 1452 posts ]  Go to page Previous  1 ... 49, 50, 51, 52, 53, 54, 55 ... 97  Next

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 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