nesdev.com

Well, I just spent the last 4 hours reading through to the end of this thread. I started on page 40. And I have just remembered that my post about attribute tables was destroyed... I don't remember why. I did find my post on page 48 kind of confusing because I didn't find all the attribute table info that was in my destroyed post... ugh. Time to prepare supper for tonight... yall have a good evening!

MIND = VERY BLOWN

Wow, that's quite awesome tepples! THANK YOU!!! I get it now... with the PPU set to +32 you set the address to 0 and then write the entries for 0 (now the PPU increments to 32) and 32... thats just two writes with the PPU incrementing by 32 after each write!!!!!! VERY BLOWN thanks tepples

And um well... you did say that this would be possible if our levels were 12 metatiles high... why? It is so grand and I don't understand why it wouldn't work with regular 15 metatile high land. I'm afraid of your answer. Please respond.

When tepples mentioned that in the case of 12 metatiles, he said you'd write bytes 0 and 4, 1 and 5, 2, then 3 (meaning you don't have to write attribute bytes 6 and 7), but the technique works just fine with 15 metatiles, you just have to write all 8 attribute bytes.

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! THANKS TOKUMARU!!!

...
No, not the attribute table... the collision table. I need to check the collision so our girl can fall into the non-solid water at the end of the second screen that kind of... visually scrolls over. How can we get the collision table to scroll with the screen? Wait... I remember that I didn't even have to create a collision table... it's already accessable right? Or does that sound crazy too... uhmmm... ...? : )

How are you storing your collision data? That has a lot to do with how to scroll it

Typically I just keep a buffer of the metatiles that are on screen, and use the tile ID to index a table of flags that include collision information. To "scroll" this, you simply update the metatile buffer every time you scroll the screen to be in synch with it.

Or if you've got WRAM you can just store the entire level in RAM at once and not have to worry about scrolling the data, just the screen.

I think that the problem is that your current design is still based on the NES screen and the name tables. Most people start out that way, because it's simpler to move objects around that small area, but once you start messing with scrolling, you have to see things differently: the screen and the name tables are not the containers of the objects anymore, they are merely used as a viewport, to show a representation of part of the level, and the level is the actual container of the objects.

You should forget about the screen and the name tables for a moment, and think of the level map as the basis for your game world. Your objects exist in the level, so everything about them is relative to the level map. Sprite coordinates are not restricted to 8 bits anymore, since levels can be much wider than 256 pixels. To test for collisions, you have to do some math with the object coordinates (like we discussed before), and since the sprite coordinates are in the same domain as level map coordinates, scrolling is absolutely irrelevant to collisions.

To make things easier, ideally you'd have access to the whole map, either by decompressing it to WRAM or storing it uncompressed (or compressed in a way that allows for random access) in the ROM. Having access to the complete level makes it easy to move objects around and have them collide with the level regardless of what the screen and the name tables are showing.

Don't think of scrolling as "the level going by", but rather as "a camera panning across the level". The level is stationary, but a virtual "camera" moves around in order to display different parts of the level, and it's this camera that dictates what gets written to the name tables and the OAM. You camera must have its own coordinates, which are used to convert level coordinates into screen coordinates (i.e. level coordinates - camera coordinates = screen coordinates), and you'll have to perform this conversion whenever you render sprites to OAM or metatile to the name tables.

I know it sounds complicated, but nobody said that scrolling was easy, specially if done right. If you do it the wrong way and keep everything oriented to screen coordinates, things will surely get out of hand (like the problem you are having now, where objects aren't aligning with the collision data).

levels can be wider than 256 pixels... according to my math I could have a level with 256 256pixel wide screens... or a have a level at the amount of 65536 pixels wide with 16bit algebra... from 0 to 65535. That's BIG! Though, I wonder how do you use 16bit algebra in 8bit CPU? Let's say we are using the number (8192+1)... tha'd be 8193 or 00100000 00000001b ...woah this is kind of like using the number 256 or 00000001 00000000b with numbers 0 to 255... but that works because there are 256 numbers... 255 and the 0. There are not 65536 numbers are there?

This is my beginning step with 16 bit math, I think... sorry.

You can't fit a 16-bit number in one byte, but you can fit it in two. Here's how to do 16 bit addition, using the example of 508 + 8 = 516 ($01FC + $0008 = $0204):

When you add two 8-bit numbers and the result is more than 256, the CPU subtracts 256 and turns on the carry flag. The carry flag tells the CPU to add one extra the next time it adds anything, just as you'd carry the 1 when adding multi-digit base 10 numbers in first grade. Most of the time, an addition will start with the carry off; that's what the clc does. (Clearing a flag means turning it off; setting means turning it on.)

What tepples said. We only have 10 different digits for representing numbers (0 to 9) but that doesn't mean it's impossible to count to 10: if we use more places for digits, we can represent bigger numbers.

With one digit we can only represent 10 different numbers (0 to 9), but with one more digit we have a total of 100 combinations (0 to 99: each new digit multiplies the number of possible combinations by 10). With bytes it's the same thing. A single byte can only represent 256 different numbers (0 to 255), but if we use a second byte we get a total of 65536 possible combinations (0 to 65535: each new byte multiplies the number of possible combinations by 256).

16, 32 and 64-bit CPUs make the whole thing easier (and faster) by manipulating multiples bytes at a time, while 8-bit CPUs have to do it byte by byte, but they can still perform math with big numbers.

Wow, Awesome! Thank you so very much tokumaru!! Your words speak to me; they've spoken to me about this new way of thinking about the level staticly... it will all be accessable just like collision is? I'll probably see that answer when I read these important words once again. Thank you very incredibly much for them!!

Thank you so much tepples! This explains how to do 16 bit math on an 8 bit cpu; it will help me alot. It has simplified and enritched the way I think about the CPU subtraction! ...And I will continue to keep 3gengames' "Set subtract. Clear add." in my head too!

This is so excellent and helpful to me too tokumaru... THANK YOU!!!

edit.
edited again.
last edit.

My sister doesn't like me asking questions... so I went to the nesdev wiki and searched for "wram". I learned that it stands for (Work RAM (Random Access Memory)). And then I read some of the 300 character search results and have concluded that WRAM is available on a mapper. And after another search I learned that MMC5 is the biggest mapper on then NES. So then I went to retrousb.com and discovered that MMC5 support on the powerpak is buggy. (I think mapper 5 is for MMC5.) And I also learned that my powerpak has enough hardware to run MMC5 games! So now I'd like to ask yall what are some reasons I shouldn't choose and try to use MMC5 for having WRAM? (And I'm aware of ideas that MMC5 is expensive... is it still expensive in todays market? The American economy isn't doing well... so that may be a yes. )

edit: Thank you qbradq for help!

WRAM is great to have, I suggest you use it if you want it, it's cheap today. Especially for 32KB of it. But MMC5 would be bad because while it can support it, it's still a long ways from anywhere near 100% understood and nowhere near workable, it doesn't even work for most games with loopys latest release. Plus it'd be super expensive to recreate. MMC3 would offer the best features and price, and has WRAM support, I'd suggest looking at that if you need a mapper. That, UNROM, or MMC1 are the most commonly used.

Ok thank you 3gengames!!

WRAM can be added to any cart, even NROM (i.e. no mapper) ones. The wiki has some information about it.


Because it's the most complex mapper there is. It's overkill to use such an advanced mapper just for the WRAM, while many other simpler and common mappers have support for WRAM as well. Also, the MMC5 still hasn't been fully cloned by anyone in the community, so it's not possible to make carts of new MMC5 games unless you use donor cartridges (MMC5 ones aren't even very common).


Current economy has very little to do with this. The MMC5 chip used in Nintendo cartridges simply isn't manufactured anymore, because they were never used for anything besides game cartridges, and Nintendo hasn't released an NES cart in over 15 years. The chips that are currently used to replicate mappers (CPLDs, FPGAs, etc.) become more expensive as they become more complex, so implementing an MMC5 clone will always be more expensive than implementing an MMC3 clone.

My advice is: don't chose a mapper just because of WRAM. Any cart, even NROM ones, can have WRAM. If you're gonna use a mapper, pick the simplest one that has the features you need.