It is currently Fri Nov 17, 2017 10:46 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 1385 posts ]  Go to page Previous  1 ... 12, 13, 14, 15, 16, 17, 18 ... 93  Next
Author Message
 Post subject:
PostPosted: Mon Aug 15, 2011 1:50 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10112
Location: Rio de Janeiro - Brazil
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.


Top
 Profile  
 
 Post subject:
PostPosted: Mon Aug 15, 2011 2:01 pm 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7265
Location: Chexbres, VD, Switzerland
Quote:
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 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.

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.


Top
 Profile  
 
 Post subject:
PostPosted: Mon Aug 15, 2011 2:10 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10112
Location: Rio de Janeiro - Brazil
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.

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.

Quote:
Also vertical scrolling is harder because of the incomplete attribute row at the end of each NES nametable.

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.


Top
 Profile  
 
 Post subject:
PostPosted: Mon Aug 15, 2011 4:50 pm 
Offline
User avatar

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


Top
 Profile  
 
 Post subject:
PostPosted: Mon Aug 15, 2011 6:28 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10112
Location: Rio de Janeiro - Brazil
I didn't even know that Nerdy Nights went as far as scrolling... Well, if you can understand the basic concept and are feeling confident about implementing this, then go for it! =)


Top
 Profile  
 
 Post subject:
PostPosted: Tue Aug 16, 2011 1:03 am 
Offline

Joined: Sat Jan 23, 2010 11:41 pm
Posts: 1161
Drawing columns in an one-axis scroll is easiest part. The problem is with effective objects and collisions processing.


Top
 Profile  
 
 Post subject:
PostPosted: Tue Aug 16, 2011 6:38 am 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10112
Location: Rio de Janeiro - Brazil
Shiru wrote:
The problem is with effective objects and collisions processing.

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.

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


Top
 Profile  
 
 Post subject:
PostPosted: Tue Aug 16, 2011 7:02 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19219
Location: NE Indiana, USA (NTSC)
tokumaru wrote:
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

Would this GIF make the concept easier for them to grasp?

Image


Top
 Profile  
 
 Post subject:
PostPosted: Tue Aug 16, 2011 7:25 am 
Offline

Joined: Sat Jan 23, 2010 11:41 pm
Posts: 1161
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.


Top
 Profile  
 
 Post subject:
PostPosted: Tue Aug 16, 2011 8:16 am 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10112
Location: Rio de Janeiro - Brazil
Shiru wrote:
tokumaru, what about moving the objects and check collisions with them?

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.

Quote:
I hope, you don't going to process all the objects on the level all the time?

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.

Quote:
What about level size limitiation? With 12:4 you can have just 16 screens, it is not that much

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.

Quote:
What about storing the level? Without metatiles one level of SMB would take about 16K, and metatiles surely make collision more complex.

Metatiles are not specific to scrolling games though. Without map compression, even non-scrolling games can't have a lot of screens.

Quote:
It is not that easy, especially for someone who had the problems you can see above in the thread.

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.


Top
 Profile  
 
 Post subject:
PostPosted: Tue Aug 16, 2011 8:27 am 
Offline

Joined: Sat Jan 23, 2010 11:41 pm
Posts: 1161
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.


Top
 Profile  
 
 Post subject:
PostPosted: Tue Aug 16, 2011 10:56 am 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10112
Location: Rio de Janeiro - Brazil
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.

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.

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;


Top
 Profile  
 
 Post subject:
PostPosted: Tue Aug 16, 2011 11:48 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7265
Location: Chexbres, VD, Switzerland
Quote:
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.

Trust me, even if you're not scrolling, use 16-bits by all means !

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.


Top
 Profile  
 
 Post subject:
PostPosted: Tue Aug 16, 2011 12:28 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19219
Location: NE Indiana, USA (NTSC)
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.

Super Bat Puncher does exactly this, and it uses SNROM (which has PRG RAM).

Quote:
I don't know why so many games does terrible things at enemies respawning (Ninja Gaiden, Mega Man, ....)

RAM limits, I guess.


Top
 Profile  
 
 Post subject:
PostPosted: Tue Aug 16, 2011 12:35 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10112
Location: Rio de Janeiro - Brazil
Bregalad wrote:
Trust me, even if you're not scrolling, use 16-bits by all means !

I second this. Even in single-screen games you may need to scroll in and out of the screen, and smooth acceleration and deceleration.

Quote:
I wasn't able to handle sweet movement

Did you mean "smooth"? I'm trying really hard to figure out what "sweet movement" could be... XD

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

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.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 1385 posts ]  Go to page Previous  1 ... 12, 13, 14, 15, 16, 17, 18 ... 93  Next

All times are UTC - 7 hours


Who is online

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