Horizontal scrolling is easier to implement than vertical, and infinitely easier than horizontal + vertical. If you design your drawing routines to work in columns from the start, implementing the horizontal scroll should be fairly simple.
I have to agree that any scrolling is kinda tough for absolute beginners (people who are new to the NES as well as game programming in general). If you have never programmed a game/engine for any platform before, it would be a good idea to practice with something simpler on the NES before messing with scrolling.
8x16 and whatever else unreg wants to know
Moderator: Moderators
I can definitely confirm this. At first it seems weird, you'd think it would be 2 times more complex to implement horizontal and vertical, but unfortunately no.Horizontal scrolling is easier to implement than vertical, and infinitely easier than horizontal + vertical. If you design your drawing routines to work in columns from the start, implementing the horizontal scroll should be fairly simple.
Also vertical scrolling is harder because of the incomplete attribute row at the end of each NES nametable.
Life is complex: it has both real and imaginary components.
Yeah, it's more than twice as hard because one type of scrolling interferes with the other, which ends up complicating both of them. Making sure that both types of scrolling play nice with each other is not such a trivial thing. It's obviously not impossible either, it's just something you have to put a lot of thought into.Bregalad wrote:At first it seems weird, you'd think it would be 2 times more complex to implement horizontal and vertical, but unfortunately no.
That and because 30 (the number of tiles in a name table column) is not a power of 2. Attributes are definitely the worst part, though.Also vertical scrolling is harder because of the incomplete attribute row at the end of each NES nametable.
-
unregistered
- Posts: 1071
- Joined: Thu Apr 23, 2009 11:21 pm
- Location: cypress, texas
Thank you all for the honest and helpfull advice. Scrolling will be ok for me to attempt, I think, because there are two big thick books that remind me of programming with Torque, a 3D game engine. It was a hard and immensly difficult task, but God was there with me and he helped me figure it out. 
We made an A and I got credit for an internship for that class! 
My mom helped me remember the last part of that. I think I can do this scrolling... my sister helped me to find this Nerdy Nights scrolling article. And it has made some sense so far... I've made it to the drawing new columns part. Will read this again after supper.
We made an A and I got credit for an internship for that class! My mom helped me remember the last part of that. I think I can do this scrolling... my sister helped me to find this Nerdy Nights scrolling article. And it has made some sense so far... I've made it to the drawing new columns part. Will read this again after supper.I disagree. As long as you use 16-bit coordinates for everything (meaning that all objects are inside a "room" larger than 256x256) it shouldn't be much different from single screen games.Shiru wrote:The problem is with effective objects and collisions processing.
The only real difference is that you can't directly use the objects' coordinates for their sprites, instead you have to subtract the camera's coordinates from them in order to find the coordinates of the sprites on the screen.
Seriously, scrolling in one axis only is dead simple, I just don't recommend it to newbies because sometimes it's hard for them to grasp the concept of the progressive name table updates (because all tutorials just dump the whole screen to VRAM at once and they don't really know how to do it any other way).
tokumaru, what about moving the objects and check collisions with them? I hope, you don't going to process all the objects on the level all the time? What about level size limitiation? With 12:4 you can have just 16 screens, it is not that much - it is about the same width as one SMB level. What about storing the level? Without metatiles one level of SMB would take about 16K, and metatiles surely make collision more complex. It is not that easy, especially for someone who had the problems you can see above in the thread.
It's the same as in single-screen games, only the "screen" is actually the level, and it can be much larger than 256x256. Instead of 8-bit comparisons you'll be making 16-bit ones, that's the only difference in movement and collisions.Shiru wrote:tokumaru, what about moving the objects and check collisions with them?
Ah, object spawning is a very different thing. Not very complex if done in only one axis though. It can be confusing for a newbie, that's for sure.I hope, you don't going to process all the objects on the level all the time?
But then it's your fault for being stingy and not using 3 bytes for coordinates. Most operations (such as collisions and sprite drawing) can be done in 16-bits, and only objects that need sub-pixel movement have one (or two, if horizontal and vertical precision is needed) extra byte, used exclusively for physics.What about level size limitiation? With 12:4 you can have just 16 screens, it is not that much
Metatiles are not specific to scrolling games though. Without map compression, even non-scrolling games can't have a lot of screens.What about storing the level? Without metatiles one level of SMB would take about 16K, and metatiles surely make collision more complex.
Agreed. Even if the scrolling itself isn't such a big challenge, typical platformers make use of many other concepts that are not trivial for new programmers.It is not that easy, especially for someone who had the problems you can see above in the thread.
I see. Well, in scrolling games you can use the same type of progressive updates you use for the name tables with the collision data, it's basically the same principle.Shiru wrote:With single screen game you can just unpack level from metatiles or anything in RAM buffer as simple tile/collision map, and have simple collision code, that's what I meant.
Personally, I prefer to access level data directly from ROM, using compression schemes that allow random access.
Let me try to classify all the important parts of a scrolling game, the ones that might differ from single-screen games.
First there's the scrolling engine itself, which handles the rendering of the background:
- A "camera" that hovers over the level and decides when it's necessary to draw new rows/columns;
- A method to extract the required rows/columns of tiles and attributes from the level map;
- A method to calculate the target address for the tiles/attributes in VRAM and a procedure to write them there during VBlank;
Then there's the game logic:
- Management of object/enemy (re)spawning based on a sorted list of entities;
- Collisions between objects, which can be done by directly comparing their coordinates (coordinates must have a number of bits compatible with the dimensions of the largest level);
- Collisions between objects and the background, which require access to the level's collision data (can be progressively decompressed or accessed directly from ROM);
And finally there's the sprites:
- Some objects are positioned with absolute coordinates, such as the HUD or anything else that's part of the screen rather than the level;
- Level objects/enemies must have their screen coordinates calculated by subtracting the camera's position from their own;
Trust me, even if you're not scrolling, use 16-bits by all means !It's the same as in single-screen games, only the "screen" is actually the level, and it can be much larger than 256x256. Instead of 8-bit comparisons you'll be making 16-bit ones, that's the only difference in movement and collisions.
I had to rewrite everything to convert from 8-bits to 16-bits because I wasn't able to handle sweet movement, and couldn't handle overflows properly.
I like to use the low 4-bits for sub-pixel movement, the mid 8-bits for pixels and the high 4-bits for screens. I only use screen 0, 1 and -1 (1 and -1 are overflow) in my game but you could go up to 16 screens in both directions with this system.
About object spawning I've never actually tried this but if I were to do it, I'd just do it so that the game engine computes the distance between the edge of the screen and the object, and if too high just don't call that object's AI routine, so that it freezes. It makes sense to me and it will automatically work again if the player enters that area again. I don't know why so many games does terrible things at enemies respawning (Ninja Gaiden, Mega Man, ....)
And when I say "computes the distance", I of course not mean the true pythagorian distance, but just use the min of X and Y distance.
Life is complex: it has both real and imaginary components.
Super Bat Puncher does exactly this, and it uses SNROM (which has PRG RAM).Bregalad wrote:if I were to do it, I'd just do it so that the game engine computes the distance between the edge of the screen and the object, and if too high just don't call that object's AI routine, so that it freezes.
RAM limits, I guess.I don't know why so many games does terrible things at enemies respawning (Ninja Gaiden, Mega Man, ....)
I second this. Even in single-screen games you may need to scroll in and out of the screen, and smooth acceleration and deceleration.Bregalad wrote:Trust me, even if you're not scrolling, use 16-bits by all means !
Did you mean "smooth"? I'm trying really hard to figure out what "sweet movement" could be... XDI wasn't able to handle sweet movement
Depending on the total number of objects, even just checking how far they are from the camera could be too slow. With 200 or so objects/enemies in a level you would spend several (like, around 50 I'm guessing) scanlines just comparing coordinates.I'd just do it so that the game engine computes the distance between the edge of the screen and the object, and if too high just don't call that object's AI routine, so that it freezes.