It is currently Tue Mar 26, 2019 5:10 pm

 All times are UTC - 7 hours

 Page 52 of 98 [ 1457 posts ] Go to page Previous  1 ... 49, 50, 51, 52, 53, 54, 55 ... 98  Next
 Print view Previous topic | Next topic
Author Message
 Post subject: Re: 8x16 sprite is really a 16x32 pixel image?Posted: Tue Oct 16, 2012 9:10 am

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 973
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! 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?

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

Top

 Post subject: Re: 8x16 sprite is really a 16x32 pixel image?Posted: Tue Oct 16, 2012 3:56 pm

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 973
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!

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

Top

 Post subject: Re: 8x16 sprite is really a 16x32 pixel image?Posted: Tue Oct 16, 2012 4:41 pm
 Formerly 65024U

Joined: Sat Mar 27, 2010 12:57 pm
Posts: 2268
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

 Post subject: Re: 8x16 sprite is really a 16x32 pixel image?Posted: Tue Oct 16, 2012 4:53 pm

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 11246
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

 Post subject: Re: 8x16 sprite is really a 16x32 pixel image?Posted: Wed Oct 17, 2012 8:22 am

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 973
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.
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! 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!

Top

 Post subject: Re: 8x16 sprite is really a 16x32 pixel image?Posted: Mon Oct 22, 2012 8:54 am

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 973
Location: cypress, texas
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!

Top

 Post subject: Re: 8x16 sprite is really a 16x32 pixel image?Posted: Mon Oct 22, 2012 9:45 am

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

Top

 Post subject: Re: 8x16 sprite is really a 16x32 pixel image?Posted: Mon Oct 22, 2012 11:11 am

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 973
Location: cypress, texas
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:
@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

 Post subject: Re: 8x16 sprite is really a 16x32 pixel image?Posted: Mon Oct 22, 2012 3:53 pm

Joined: Wed Oct 15, 2008 11:50 am
Posts: 943
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

Top

 Post subject: Re: 8x16 sprite is really a 16x32 pixel image?Posted: Mon Oct 22, 2012 6:51 pm
 Formerly 65024U

Joined: Sat Mar 27, 2010 12:57 pm
Posts: 2268
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

 Post subject: Re: 8x16 sprite is really a 16x32 pixel image?Posted: Mon Oct 22, 2012 6:55 pm

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 11246
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

 Post subject: Re: 8x16 sprite is really a 16x32 pixel image?Posted: Mon Oct 22, 2012 7:24 pm

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 21216
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

 Post subject: Re: 8x16 sprite is really a 16x32 pixel image?Posted: Mon Oct 22, 2012 8:05 pm

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 11246
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

 Post subject: Re: 8x16 sprite is really a 16x32 pixel image?Posted: Tue Oct 23, 2012 11:52 am

Joined: Wed Mar 09, 2005 9:08 am
Posts: 446
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

 Post subject: Re: 8x16 sprite is really a 16x32 pixel image?Posted: Tue Oct 23, 2012 1:37 pm

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:

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

 Display posts from previous: All posts1 day7 days2 weeks1 month3 months6 months1 year Sort by AuthorPost timeSubject AscendingDescending
 Page 52 of 98 [ 1457 posts ] Go to page Previous  1 ... 49, 50, 51, 52, 53, 54, 55 ... 98  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 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