It is currently Wed Apr 25, 2018 5:55 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 1443 posts ]  Go to page Previous  1 ... 30, 31, 32, 33, 34, 35, 36 ... 97  Next
Author Message
 Post subject:
PostPosted: Fri Apr 13, 2012 3:05 pm 
Offline
User avatar

Joined: Wed Apr 02, 2008 2:09 pm
Posts: 1125
unregistered wrote:
How many screens of 16x16 metatiles could fit in a page of RAM?

Just 1 whole screen uncompressed.

(256/16)*(240/16)
16*15 = 240.

Or (256/16)*(256/16) = 256
if your "screens" are defined as 256x256 like mine are.

I use 32x32 metatiles because I only have 1 page of RAM allocated to this, and I need 4 screens stored. I store my screens in RAM because otherwise I would have to battle through a few levels of compression to check every point. This method lets me do the time consuming stuff (working through the RLE compression of the screens) only on the frame a new screen is scrolled to, while the fast decompression (which 16x16 tile of the 32x32 tile are we in?) is done every time a point needs to be checked.

If it is not time consuming to decompress your data, you could certainly just read from ROM rather than doing what I do.

If it is time consuming, you can get away with using only two pages of RAM to store separate screens of 16x16 tiles for this method since your game only scrolls horizontally.


Top
 Profile  
 
 Post subject:
PostPosted: Fri Apr 13, 2012 3:29 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19949
Location: NE Indiana, USA (NTSC)
SMB1 uses two 16x13 pages to cache the decompressed map.


Top
 Profile  
 
 Post subject:
PostPosted: Mon Apr 16, 2012 10:25 am 
Offline
User avatar

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 859
Location: cypress, texas
Kasumi wrote:
unregistered wrote:
How many screens of 16x16 metatiles could fit in a page of RAM?

Just 1 whole screen uncompressed. ...

Kasumi, thank you for your explanation. That's what I just calculated too... can fit just one whole screen in a page of ram. I see what you are saying about we might only need 2 pages of ram... since we're only scrolling horizontally.

I don't know if we will use compression for our maps... Thank you for your recomendations! :D

tepples wrote:
SMB1 uses two 16x13 pages to cache the decompressed map.
I guess this works because of the blockage of 24 scanlines on the top and bottom of the NTSC SDTV screen... ? That's incredible to know! Thank you tepples! :D Do you know if they use the same two 16x13 pages in the PAL version? (PAL TVs block the same number of scanlines?)

16x13 is used by Nintendo on SMB1... They know awesome things! That's a savings of 96 bytes right? That's quite a lot! :D


Top
 Profile  
 
 Post subject:
PostPosted: Mon Apr 16, 2012 1:52 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19949
Location: NE Indiana, USA (NTSC)
The 16x13 is because the top 32 scanlines are a status bar.


Top
 Profile  
 
 Post subject:
PostPosted: Mon Apr 16, 2012 6:08 pm 
Offline
User avatar

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 859
Location: cypress, texas
tepples wrote:
The 16x13 is because the top 32 scanlines are a status bar.


Oh... ok :( thanks for replying tepples. : )
Hold on :) ...16 - 13 is 3.
3 * 16 is 48.
48 - 32 = 16.
16 / 2 = 8. So, are 8 scanlines hidden on the top and bottom edges of the screen?


Top
 Profile  
 
 Post subject:
PostPosted: Mon Apr 16, 2012 6:48 pm 
Offline
User avatar

Joined: Wed Apr 02, 2008 2:09 pm
Posts: 1125
16-13 is 3. But the screen is not 256 pixels high.

(240-32)/16 = 13.

_________________
https://kasumi.itch.io/indivisible


Top
 Profile  
 
 Post subject:
PostPosted: Tue Apr 17, 2012 9:44 am 
Offline
User avatar

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 859
Location: cypress, texas
Kasumi wrote:
16-13 is 3. But the screen is not 256 pixels high.


Ah... yes, you were able to figure out my math. :D I didn't need to color the numbers; thank you Kasumi!

Kasumi wrote:
(240 - 32)/16 = 13.


(correct screen height - status bar height)/16 = 13.
Why divide by 16? How does 13 relate to the number of hidden scanlines at the top and bottom edges of the screen?


Top
 Profile  
 
 Post subject:
PostPosted: Tue Apr 17, 2012 10:26 am 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10431
Location: Rio de Janeiro - Brazil
unregistered wrote:
(correct screen height - status bar height)/16 = 13.
Why divide by 16? How does 13 relate to the number of hidden scanlines at the top and bottom edges of the screen?

16 is the height of a metatile. When you divide by 16 you get the number of metatiles in each column, and with that you can calculate how many bytes a screen would take if stored uncompressed in RAM.

The fact that there are hidden scanlines doesn't mean every game has to do anything special about them. Most games show parts of the map in those areas normally, they just don't put important objects or structures there, but there's usually something there.


Top
 Profile  
 
 Post subject:
PostPosted: Tue Apr 17, 2012 10:40 am 
Offline
User avatar

Joined: Wed Apr 02, 2008 2:09 pm
Posts: 1125
ninja'd by Tokumaru, but as usual: Posting anyway. :D

You divide by 16 because that's the metatile size. You subtract the height of the status bar (32) from the screen height (240) and divide by the metatile height (16). You get 13.
You divide the screen width (256) by the metatile width (16). You get 16.

So, 16x13 is how much many bytes of RAM a screen takes up in Super Mario Bros. (According to Tepples, I haven't checked myself).

It's only related to the the possibilty of scanlines being hidden as a cause/effect thing. Super Mario Bros. probably couldn't store its "MARIO WORLD TIME" at the VERY top of the screen, because some TVs might cut it off. If there was just map up there, it wouldn't matter if it got cut off. But it wasn't, so they moved the bar down which happened to have the bonus of saving some extra RAM/ROM. Since the top of the screen is scroll locked to keep the status bar from moving, nothing solid could be put there anyway since it would look strange not scrolling.

I've said how I do it and why. We've said how Super Mario Bros. works. Decide if you like either, or come up with something that suits your own game's needs better. You should be making design decisions based on what YOU need. If Super Mario Bros. didn't need to display so much text, it could have used sprites to display its information. This would mean the top of the screen wouldn't need to be scroll locked, and it could use 16x15 screens. They made their decisions based on exactly what they wanted and needed, and you must do the same.


Top
 Profile  
 
 Post subject:
PostPosted: Sat Apr 28, 2012 10:34 am 
Offline
User avatar

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 859
Location: cypress, texas
When I opened the debug menu in FCEUX and pressed Step Into the PC changed from $8007 to $800A :?

Why is the PC inside $8000? My code starts at $C000...

btw, thank you tokumaru and Kasumi! I understand I can and must do this. :D


Top
 Profile  
 
 Post subject:
PostPosted: Sat Apr 28, 2012 11:30 am 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10431
Location: Rio de Janeiro - Brazil
If you don't have any subroutines (or any kind of executable code) in $8000-$BFFF there certainly is a bug somewhere. Are all your vectors properly defined at $FFFA-$FFFF? Maybe an invalid IRQ or NMI address is throwing the PC off? Can't really say without seeing more.


Top
 Profile  
 
 Post subject:
PostPosted: Mon Apr 30, 2012 8:41 am 
Offline
User avatar

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 859
Location: cypress, texas
tokumaru, thank you for your quick reply! :) My vectors ($FFFA-$FFFF) seem to be fine... in the .lst file they are listed as 9E C2 00 C0 37 C3 so they are all after $C000 i think...

The PC, within the $8000 - $BFFF range appears to be broken... it just switches between two values over and over and over again.


Top
 Profile  
 
 Post subject:
PostPosted: Mon Apr 30, 2012 9:35 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19949
Location: NE Indiana, USA (NTSC)
Try opening the ROM in FCEUX for Windows (or another similarly capable debugging emulator) and putting an execute breakpoint on $8000-$BFFF, and you may have a clue as to how you ended up there.


Top
 Profile  
 
 Post subject:
PostPosted: Mon Apr 30, 2012 9:58 am 
Offline
User avatar

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 859
Location: cypress, texas
I havent used FCEUX for Windows very much... but I tried to set an execute break point on $8000-$BFFF. The game continues to run these two lines over and over:

Code:
00:8007:AD 02 20  LDA $2002 = #$00
00:800A:10 FB     BPL $8007


Top
 Profile  
 
 Post subject:
PostPosted: Mon Apr 30, 2012 10:11 am 
Offline
NESICIDE developer
User avatar

Joined: Mon Oct 13, 2008 7:55 pm
Posts: 1060
Location: Minneapolis, MN
unregistered wrote:
I havent used FCEUX for Windows very much... but I tried to set an execute break point on $8000-$BFFF. The game continues to run these two lines over and over:

Code:
00:8007:AD 02 20  LDA $2002 = #$00
00:800A:10 FB     BPL $8007


Maybe a bug in FCEU debugger if your ROM is 16KB? Try it in some other debugging-capable tool.

EDIT: Many apologies if my response is way off the mark. I just realized I stepped into this thread on page 33!


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 1443 posts ]  Go to page Previous  1 ... 30, 31, 32, 33, 34, 35, 36 ... 97  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 8 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