It is currently Wed Oct 18, 2017 3:18 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 24 posts ]  Go to page 1, 2  Next
Author Message
PostPosted: Wed Aug 17, 2005 10:15 am 
Once I was told that 3 or 4 vblanks were enough to draw a whole screen, so a fairly good ammount of data could be drawn during each vblank.

But recently, I read you had time to draw, like, 2, 3 columns at most! That is insane!! Is it really this few tiles?

I'm designing a platform engine right now, and if we can really only draw this little to the screen, I'll have to rethink a lot of stuff. I was going to update the screen based on 16x16 pixel blocks, in a 4-way scroller, wich meant I could possibly have one frame draw 2 rows and 2 columns of tiles, clearly beyond what seems to be possible.

I guess I'll just have to draw it 1 column and 1 row at a time. Or even have my code smart enough to start drawing what's to come even before the player actually gets to that part, based on the direction he is currently going to. This way I'll update every frame, little by little, and won't need to worry about big writes.

I could also drop my framerate to 30, instead of 60. This way I would give my game 2 vblanks to update it's graphics... but the player might notice this game is less smooth than others...

What do you suggest?


Top
  
 
 Post subject:
PostPosted: Wed Aug 17, 2005 11:35 am 
Offline
User avatar

Joined: Sun Sep 19, 2004 10:59 pm
Posts: 1389
Indeed, 2 rows/columns per VBLANK is the safe limit. You might be able to push it to 3, but then you'd be eating into time allocated for attribute and palette updates.

Dropping your framerate to 30 isn't really an option, since the NES always renders at 60 frames per second, and any changes during the "first vblank" would be visible during the "second frame".

_________________
Quietust, QMT Productions
P.S. If you don't get this note, let me know and I'll write you another.


Top
 Profile  
 
 Post subject:
PostPosted: Wed Aug 17, 2005 12:02 pm 
Quietust wrote:
Dropping your framerate to 30 isn't really an option, since the NES always renders at 60 frames per second, and any changes during the "first vblank" would be visible during the "second frame".


I think I can drop the framerate if I make unnoticeble changes in the first frame. I can draw 1 column or half a column of blocks, not change the scroll values (and not update the sprites) in the first vblank, then draw the rest of the blocks in the 2nd vblank and change the scroll values and update sprites. This way I'll get the impression of 30 fps, wich I think is enough for a platformer.

But it turns out it is better to draw 1 full column of TILES and do change the scroll, than drawing half a column of BLOCKS and not scrolling. Unless the player actually moves more than 8 pixels. But then again, if the player moves 8 pixels at a time it would mean going through almost two full screens in 1 second, wich is quite fast for any kind of character, even for the kind of game I'm planning.

This game is supposed to be quite complex, and it is possible that 1 vblank is not enough to handle all the objects in scene, for example. Decimating the framerate may be usefull after all, but I'll try avoiding it at first. Let's just see how my prototype turns out! =)

Thanks for confirming the limit, even though it is sad news!


Top
  
 
 Post subject:
PostPosted: Wed Aug 17, 2005 12:11 pm 
Offline
User avatar

Joined: Wed Aug 03, 2005 3:15 pm
Posts: 393
I'm not sure of the capabilities/differences of the two systems yet, but have you thought about designing your game for the SNES. It sounds like you want it to be more complex than what the NES can do. Maybe if you go 16-bit you can get more of what you need for your game. I could be way off-track too, though.


Top
 Profile  
 
 Post subject:
PostPosted: Wed Aug 17, 2005 12:31 pm 
Roth wrote:
I'm not sure of the capabilities/differences of the two systems yet, but have you thought about designing your game for the SNES. It sounds like you want it to be more complex than what the NES can do. Maybe if you go 16-bit you can get more of what you need for your game. I could be way off-track too, though.


Actually you're right, this game would be more suitable for a 16-bit system. But the thing is I love the NES and I like challenges. Also, there are tons of games like this already made for 16-bit systems, so it is not fun at all making just yet another one. It's just going to be another one in the bunch, with nothing special to it.

I don't know much about SNES programming either. I've read about it a little but there is just not as much material as there is for the NES.

I love when stuff thought to be impossible for the NES is actually pulled off. And my game is not all that complex... more complex than the average NES platformer, sure, but not impossible to make.

I can say I actually fell in love with the NES. I never had one as a kid, and never really wanted one. When many of my friends had NES's (or famiclones, mostly) I had a sega genesis/megadrive, and never cared so much for nintendo's older console. I can say I used to be a sega person. Only in the emulation days I got to see how interesting NES games where. Now it had become my favorite system, and when I found out It was possible to program for it, I just went crazy.

You now... the NES is so much fun to program in... even with all the flaws and limitations... Everytime I see a more advanced game I think: "How could it be done on the NES?" and it is a great exercise, trying to figure out ways to do things the other consoles take for granted.

Now I'm talking too much, but it was just to show why I think making this game for the NES is important for me. It's not about the game, it's about the system. I don't want to see THIS particular game done, I want to make a GREAT NES GAME. If it was not the case I would just do it for the PC...

-tokumaru-


Top
  
 
 Post subject:
PostPosted: Wed Aug 17, 2005 1:28 pm 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7230
Location: Chexbres, VD, Switzerland
Please don't give up. That's not the spirit. I didn't understood your exact problem, but I think it's easily solvable.
There is no row limit or column limit at all, there is just time limit. So, by doing infamous method like a RAM buffer with only "lda $xx, sta $2007" in it, it's possible to bypas some limits, but I doubt this is needed for an usual scroller.
By 4-way scrooler, you mean that the game will scroll left/right as well than up/down during game play, right ?
If you have no status bar, I recommand using Vertical mirroring. Then, I think the best would be to build up a routine able to "split" block in the vertical axis with the attribute (2 tiles) precision, but then write the whole block horizontally. Scince you use vertical mirroring, you have a huge "marge" to work on horizontal scrooling, but a small one for vertical scrooling.
If you want a status bar, the better would be 1-screen mirroring (only possible on mappers 1 and 7), or horizontal mirroring. Then, you have to write a programm that splits the whole block in metatiles (2x2 tiles) with attributes, and write them on the screen. It's fairly hard, but not impossible. Battletoads does that on levels 1, 4, 5, 6, 8, 9, and 11. Well, Battletoads isn't a reference actually, because it turns the screen off for longer than the VBlank itself. But there is also a few games able to scroll "diagonally", Paper Boy and Hanjuku Hero comes in my mind. Also, updating the palette every frame is not necesarry, for example you can do this only if there is no other PPU writes pending during the frame.

_________________
Life is complex: it has both real and imaginary components.


Top
 Profile  
 
 Post subject:
PostPosted: Wed Aug 17, 2005 5:43 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10053
Location: Rio de Janeiro - Brazil
Actually, now that you said it, my game is actually 8-way. I can, and will, scroll diagonally. I am using vertical mirroring as you said, and am using no status bar, which makes things easier. The little info I'm giving to the player can be done only with sprites.

I can see I may have a problem scrolling vertically, as my only spare space are the rows the TV frame hides. I agree with you that I could draw full blocks horizontally, since there is a huge spare space in that direction.

The time limit can be a problem if I need to update both horizontally and vertically at the same time though, but if I do it one row/column at a time I think I'll be fine, using RAM buffers or a "lda $xx, sta $2007" sequence as you said.

I'll not give up, or at least I don't intend to! =)
The NES is a great system to program for, and overcoming the problems is a great part of the fun, in my opinion...!


Top
 Profile  
 
 Post subject:
PostPosted: Wed Aug 17, 2005 8:02 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19096
Location: NE Indiana, USA (NTSC)
-tokumaru- wrote:
But it turns out it is better to draw 1 full column of TILES and do change the scroll, than drawing half a column of BLOCKS and not scrolling. Unless the player actually moves more than 8 pixels. But then again, if the player moves 8 pixels at a time it would mean going through almost two full screens in 1 second, wich is quite fast for any kind of character, even for the kind of game I'm planning.

Sonic what?

Quote:
This game is supposed to be quite complex, and it is possible that 1 vblank is not enough to handle all the objects in scene, for example.

You could try "dead reckoning", where you only run only a few objects' AI during a given frame and then simply move the rest at a constant velocity.


Top
 Profile  
 
 Post subject:
PostPosted: Wed Aug 17, 2005 9:30 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10053
Location: Rio de Janeiro - Brazil
tepples wrote:
Sonic what?

Heh! I think that even Sonic can be limited to 8 pixels per frame with no problems. He is fast, but I don't recall him going faster than 2 screens in 1 second! Well, maybe with the speed-up shoes, but... The "pirate originals" featuring Sonic-like gameplay (Jurassic Boy, Somari and derivates) play quite well, in spite of the awful physics. My goal is something like that, only with a more proffessional look, and better physics.

Quote:
You could try "dead reckoning", where you only run only a few objects' AI during a given frame and then simply move the rest at a constant velocity.

Not really sure on what you said here, but... yeah, many objects just go back and forth without much AI going on... but I still have to check for collisions between the player and the objects, something that can take some time. Some objects even just sit there, but others must have physics, throw stuff, etc.

The one thing I'm yet not sure on how to deal with are the ojects that must be drawn in the background. Not all of my objects are sprites, and my BG drawing code is already going to be pretty tight. Maybe the object's routine checks to see if a column or row it is supposed to be in is going to be drawn in the next vblank, and then it draws itself to the buffer too... but BG objects must be updated too, wich means they can get redrawn, and that will just eat more vram writing time... I'll just have to think this through.


Top
 Profile  
 
 Post subject:
PostPosted: Thu Aug 18, 2005 8:26 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7230
Location: Chexbres, VD, Switzerland
Well, the best way to do that scrooling is definitely to write one whole metatile to the screen. That will be two rows of 32 tiles at the same time, + 8 attributes bytes and this is doable. Horizontally, there would be two colums of 8 tiles + 8 attributes bytes, which is also doable. Both at the same time aren't, but I think you can alternate between horzontal and vertical writes... in the worst case, there would be a few non-noticable glitches in the border of the screen.
I just noted that all games able to scroll diagonally uses horizontal mirroring, even without status bar. I'll try to get my hands on the exact reason of this, if any.

_________________
Life is complex: it has both real and imaginary components.


Top
 Profile  
 
 Post subject:
PostPosted: Thu Aug 18, 2005 8:49 am 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10053
Location: Rio de Janeiro - Brazil
Bregalad wrote:
Well, the best way to do that scrooling is definitely to write one whole metatile to the screen. That will be two rows of 32 tiles at the same time, + 8 attributes bytes and this is doable. Horizontally, there would be two colums of 8 tiles + 8 attributes bytes, which is also doable. Both at the same time aren't, but I think you can alternate between horzontal and vertical writes... in the worst case, there would be a few non-noticable glitches in the border of the screen.
I just noted that all games able to scroll diagonally uses horizontal mirroring, even without status bar. I'll try to get my hands on the exact reason of this, if any.


Or I could write one-tile rows or columns. Delaying one of the writes in favour of the other may be noticeble. I thought about writing half of the metatiles in the first frame, and then writing the second half + the attributes in the second frame. This way there is no risk of going past the avaliable time or ending up with jerky movement. The only drawback is the camera can't move faster than 8 pixels per frame.

I'll probably end up testing both, and see what looks/feels better. =)


Top
 Profile  
 
 Post subject:
PostPosted: Thu Aug 18, 2005 9:33 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7230
Location: Chexbres, VD, Switzerland
I'm pretty sure it's possible to write a whole row and/or a whole column of metatiles in just one VBlank, while keeping the sprites aliving during the same frame. Just test your code with Nintedulator's tracer to be sure you don't run out of time.

_________________
Life is complex: it has both real and imaginary components.


Top
 Profile  
 
 Post subject:
PostPosted: Thu Aug 18, 2005 12:10 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19096
Location: NE Indiana, USA (NTSC)
tokumaru wrote:
tepples wrote:
Sonic what?

Heh! I think that even Sonic can be limited to 8 pixels per frame with no problems. He is fast, but I don't recall him going faster than 2 screens in 1 second!

Chemical Plant 2 in Sonic the Hedgehog 2 for Sega Genesis had Sonic rolled into a ball and going down a ramp several screens long at velocities in excess of (8, 8).

Quote:
yeah, many objects just go back and forth without much AI going on... but I still have to check for collisions between the player and the objects

There are sorting methods to reduce the number of collision box tests that you must do from O(n^2) to O(n log n).

Quote:
Some objects even just sit there, but others must have physics

Plain old "physics" if I think I know what you mean is just Newton's laws (in the absence of force, velocity is unchanged; and gravity is a constant acceleration)


Top
 Profile  
 
 Post subject:
PostPosted: Thu Aug 18, 2005 12:24 pm 
tepples wrote:
Chemical Plant 2 in Sonic the Hedgehog 2 for Sega Genesis had Sonic rolled into a ball and going down a ramp several screens long at velocities in excess of (8, 8).

True, true... I remember places like this, but although Sonic can run pretty fast, the camera often lags behind him in such cases. But I can still have problems, since I have a limited ammount of screens loaded based on the camera's position, wich means my player can't go past the screen as Sonic can at higher speeds.

Quote:
There are sorting methods to reduce the number of collision box tests that you must do from O(n^2) to O(n log n).

I just hate log. Always had problems with it in school.

Quote:
Plain old "physics" if I think I know what you mean is just Newton's laws (in the absence of force, velocity is unchanged; and gravity is a constant acceleration)

Yes, it's pretty simple physics and collision detection for most objects... only the player needs more sophisticated stuff. And objects don't need to be checked for collision with each other, only with the player, wich greatly reduces the number of detections.


Top
  
 
 Post subject:
PostPosted: Fri Aug 19, 2005 4:16 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10053
Location: Rio de Janeiro - Brazil
Hey,
Let me just ask one more thing in this topic... I'd like to know how many tiles would I be able to copy to the pattern table, in a vram cart... Since you say it is safe to write 2 or 3 columns of tiles in the BG, thats like, 96 bytes. Does that mean I could copy only 6 tiles to the pattern table in 1 vblank?

That seems too slow... I've watched games like megaman 1 and they seem to do it faster than 6 tiles per frame... although I can't be sure if the game turned the screen off at some point to do a faster transfer.

It can't be that slow... it doesn't seem practical at all to use vram if it is that slow...


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 24 posts ]  Go to page 1, 2  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: Google [Bot] 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