It is currently Fri Dec 15, 2017 3:29 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 24 posts ]  Go to page Previous  1, 2
Author Message
 Post subject:
PostPosted: Fri Aug 19, 2005 5:58 pm 
Offline
Site Admin
User avatar

Joined: Mon Sep 20, 2004 6:04 am
Posts: 3487
Location: Indianapolis
Hm, one program I've written (the Garage Cart intro) writes 256 bytes per frame to the pattern table. I'm sure a lot more could be done. I couldn't push it further because I ran out of both RAM and ROM, heheh.

I came up with a scheme to use in my game that I planned, since it has fast scrolling, as well as a huge amount of pattern table updates. But it costs 5 bytes of RAM for every byte in your buffer and uses self-modifying code.

I posted about it in this thread:
http://nesdev.com/bbs/viewtopic.php?t=259

And there's some other ideas in there that may be interesting.


Top
 Profile  
 
 Post subject:
PostPosted: Fri Aug 19, 2005 6:56 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10164
Location: Rio de Janeiro - Brazil
Memblers wrote:
Hm, one program I've written (the Garage Cart intro) writes 256 bytes per frame to the pattern table. I'm sure a lot more could be done. I couldn't push it further because I ran out of both RAM and ROM, heheh.

Then how come Quietust said 2 to 3 rows would be the safe limit? I know you used "tricks" to do it faster, but still... there is a BIG difference between 96 and 256, and you even say a lot more can be done! In both cases you're just writing to vram... why is the difference so big?


Top
 Profile  
 
 Post subject:
PostPosted: Fri Aug 19, 2005 7:10 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19346
Location: NE Indiana, USA (NTSC)
In a demo, intro, or other program with limited interactivity, you have a lot more leeway than you have with a game. In a game, you have a lot of objects' state to keep in the NES's 2 KB of built-in work RAM, you have to make time for the OAM update, and you have to run AI and physics during the 'draw' time. In a demo, you don't.


Top
 Profile  
 
 Post subject:
PostPosted: Fri Aug 19, 2005 8:02 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10164
Location: Rio de Janeiro - Brazil
tepples wrote:
In a demo, intro, or other program with limited interactivity, you have a lot more leeway than you have with a game. In a game, you have a lot of objects' state to keep in the NES's 2 KB of built-in work RAM, you have to make time for the OAM update, and you have to run AI and physics during the 'draw' time. In a demo, you don't.


I'll exclusively update the PPU during vblank. All the physics and object handling is done during rendering, not drawing. I'll use buffers to store everything I have to draw, so that drawing is just a matter of copying bytes. I agree with the RAM usage thing though, but that's the only difference. Besides, in the other mentioned thread, about Battletoads (a full featured game), it did update a lot of stuff and did OAM updates also.

Well, I'll just be safe and write few rows/columns per frame. The question about pattern table updates was for another project anyway, not for the platformer.


Top
 Profile  
 
 Post subject:
PostPosted: Fri Aug 19, 2005 8:17 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19346
Location: NE Indiana, USA (NTSC)
tokumaru wrote:
tepples wrote:
you have to run AI and physics during the 'draw' time.

I'll exclusively update the PPU during vblank. All the physics and object handling is done during rendering, not drawing.

Some references call rendering time "draw" or "vdraw" time. Tomayto, tomahto.


Top
 Profile  
 
 Post subject:
PostPosted: Fri Aug 19, 2005 8:45 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10164
Location: Rio de Janeiro - Brazil
tepples wrote:
Some references call rendering time "draw" or "vdraw" time. Tomayto, tomahto.

I was thinking more like:
RENDERING - PPU sending stuff to the TV;
DRAWING - PPU not sending stuff to the TV, me sending stuff to the PPU;

And if I can do everything during RENDERING time, DRAWING is just about copying the stuff I already processed earlier. So I'm not actually processing during drawing time.


Top
 Profile  
 
 Post subject:
PostPosted: Sat Aug 20, 2005 1:54 am 
Online
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7316
Location: Chexbres, VD, Switzerland
tokumaru wrote:
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?

Again, there is no bytes limit but time limit. It all depend on how you're updating them in your code.

Quote:
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 doesn't, only several infamous games such as Battletoads did (actually Battletoads was basically a PAL game ported on the NTSC, and I'm pretty sure the PAL Battletoads does simply write the stuff on the PPU during VBlank... exept that it's much longer in PAL).
Megaman 1 does 2 tiles per frame. However, Megaman 6 was able to do 4 tiles per frame.

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

Effectively, it's different from VROM. VRAM is slow, but feathure 100% custommed tiles in the whole pattern table. VROM is fast and can switch banks at a very high rate, but it only switches whole bank of tiles, without allowing you to customize your tileset or to modify tiles for effects like the FF3's water.

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


Top
 Profile  
 
 Post subject:
PostPosted: Sat Aug 20, 2005 10:20 am 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10164
Location: Rio de Janeiro - Brazil
Bregalad wrote:
Again, there is no bytes limit but time limit. It all depend on how you're updating them in your code.

I know that, I know that... let's not be so litteral here, ok? When I ask about "tiles" or "patterns" I mean how many of them people can squeeze in the avaliable time on average!

Quote:
It doesn't, only several infamous games such as Battletoads did (actually Battletoads was basically a PAL game ported on the NTSC, and I'm pretty sure the PAL Battletoads does simply write the stuff on the PPU during VBlank... exept that it's much longer in PAL).
Megaman 1 does 2 tiles per frame. However, Megaman 6 was able to do 4 tiles per frame.

I meant on screen transitions, not during a level. Like when the title screen fades and the enemy selection comes in. Maybe it turns the screen off during this little fraction of time when the first screen has faded out and next hasn't appeared yet, to load a bunch of pattern tiles at once.

Quote:
Effectively, it's different from VROM. VRAM is slow, but feathure 100% custommed tiles in the whole pattern table. VROM is fast and can switch banks at a very high rate, but it only switches whole bank of tiles, without allowing you to customize your tileset or to modify tiles for effects like the FF3's water.

I know the difference... but you have to agree that the advantages of vram are very few... what's the use of beeing able to draw dynamic effects, like FF's water, if you can only update 4-6 tiles? Not many effects can be done anyway. I think the best way to do BG animations is by using CHR ROM switching... the disadvantage is that you must have ALL BG animations share the same length (or you could duplicate frames, to give the impression of animations with different length).


Top
 Profile  
 
 Post subject:
PostPosted: Sat Aug 20, 2005 11:55 am 
Online
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7316
Location: Chexbres, VD, Switzerland
tokumaru wrote:
I know that, I know that... let's not be so litteral here, ok? When I ask about "tiles" or "patterns" I mean how many of them people can squeeze in the avaliable time on average!

Yeah, the problem is "on average". You can upload up to 16 tiles with the Membler's method, but it'll waste 16*16*5 = 1280 bytes, more than the half of the NES' CPU RAM. So, by the use of normal buffer, you can go up to 8 tiles, with an unrolled loop such as :
Code:
A=Number of tiles
X;Y = PPU Adress
bit $2002
stx $2006
sty $2006
tay
ldx #$00
_loop
.rept 16
lda Buffer,X
sta $2007
.endrept ;Write a whole tile trough an unrolled loop
txa
clc
adc #$10
tax
dey
bne _loop
rts

As you see, the "unrolled" loop wastes pretty much rom, but is way faster than doing it in a rolled loop, where only 6 tiles are allowed. Now you can also do 12 tiles by so :

Code:
A=Number of tiles
X;Y=PPU Adress

bit $2002
stx $2006
sty $2006
tsx
stx Temp
ldx #StackBufferAdress-1
txs
tay
_loop
.rept 16
pla
sta $2007
.endrept
dey
bne _loop
ldx Temp
txs
rts

This is definitely a good way to updata VRAM, but due to the limited amount of free byte in the stack, it won't work for much others things. 12 tiles are 192 bytes, or 75% of the available stack. An usual programm will not have its stack pointer going under $e0, and by doubling this space for security, $100-$1bf can be used freely for this.

Quote:
I meant on screen transitions, not during a level. Like when the title screen fades and the enemy selection comes in. Maybe it turns the screen off during this little fraction of time when the first screen has faded out and next hasn't appeared yet, to load a bunch of pattern tiles at once.

Of course, the screen is off between two screen.

Quote:
I know the difference... but you have to agree that the advantages of vram are very few... what's the use of beeing able to draw dynamic effects, like FF's water, if you can only update 4-6 tiles? Not many effects can be done anyway.

Effectively, but there is the 100% custom tileset, also. Using 1kb pages of VROM is possibly better than VRAM, but I don't think 4kb pages of VROM is enough to copete against VRAM.

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


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

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