8x16 and whatever else unreg wants to know

[unregistered]

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! Well, they will be incredibly helpful once I spend the time to explore 8.8 ...

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.

how did you do that?

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!

edit
edited again

[unregistered]

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!

[3gengames]

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.

[tokumaru]

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.

[unregistered]

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

Thanks 3gengames; I hope to achieve that.

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

[unregistered]

Now our sprite falls and lands on the ground! 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!

[qbradq]

Wow, I can't believe this thread is still going It's inspiring to see that you've got so much commitment to this!

[unregistered]

Wow, I can't believe this thread is still going 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. 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! Thank you very much qbradq.

edit
edited once more: In my input code there's this part

Code: Select all

@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 [/color]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?

[qbradq]

So I'm not going to read 52 pages back 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

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

[3gengames]

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.

[tokumaru]

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.

[tepples]

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

[tokumaru]

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.

[Bananmos]

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

[qbradq]

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