It is currently Tue Jul 23, 2019 2:09 am

All times are UTC - 7 hours



Forum rules





Post new topic Reply to topic  [ 199 posts ]  Go to page Previous  1 ... 10, 11, 12, 13, 14
Author Message
PostPosted: Sat May 25, 2019 3:31 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 11376
Location: Rio de Janeiro - Brazil
supercat wrote:
Have you tried porting that to the NES? I'd say it looks pretty good.

Nope, I just wrote a script in PHP to encode the tiles (don't know if I still have it) and made a GIF of the result.

I though it looked cool too... the fluidity really compensated for the incorrect pixels, IMO. Making a demo should be trivial, all the work would be in selecting a compression scheme that worked well on the name table data. Just a little bit of forced blanking should be enough to guarantee a frame rate of 30.


Top
 Profile  
 
PostPosted: Sun May 26, 2019 10:02 am 
Offline

Joined: Thu Apr 18, 2019 9:13 am
Posts: 151
tokumaru wrote:
supercat wrote:
Have you tried porting that to the NES? I'd say it looks pretty good.

Nope, I just wrote a script in PHP to encode the tiles (don't know if I still have it) and made a GIF of the result.

I though it looked cool too... the fluidity really compensated for the incorrect pixels, IMO. Making a demo should be trivial, all the work would be in selecting a compression scheme that worked well on the name table data. Just a little bit of forced blanking should be enough to guarantee a frame rate of 30.


What do you think of the idea of using cartridge WRAM to hold a sequence of "lda #xx / sta $200x" instructions? If you're using 32x24 normal-height tiles (as opposed to using half-height tiles to enable arbitrary half-resolution pixel patterns), a worst-case update would be 4620 cycles, which is only about 40 scan lines, and significant compression could be achieved by simply evaluating the differences between frames, identifying what combination of vertical and horizontal updates could best achieve them, and arranging to have the store sequence contain mostly stores to $2007, but a few pairs of stores to $2006 and possibly one store to $2000 (to switch from horizontal to vertical updates). If one imposed a limit of 303 PPU writes per 60Hz frame, it may be possible to get by without cartridge WRAM or extended vblank. I don't know how many frames would need more than 303 tiles to change at once, but I'd guess many of those could be handled if one set the four palettes to black/white, black/black, white/white, and white/black and then used palette updates to switch set the attributes of groups of 16 tiles at once.

Bad Apple's popularity may have passed, but I think the existing demo falls far short of what the NES should be able to achieve.


Top
 Profile  
 
PostPosted: Sun May 26, 2019 11:01 am 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 11376
Location: Rio de Janeiro - Brazil
supercat wrote:
What do you think of the idea of using cartridge WRAM to hold a sequence of "lda #xx / sta $200x" instructions?

I think it's useful in other cases, but not really needed here. Since the picture is only 24 tiles high, as opposed to the full 30, there are 48 scanlines with no picture that we can blank and use for VRAM updates, plus the regular 20 of vblank. Updating all 32x24 tiles plus the 64 attribute bytes at the "slow" rate of 8 cycles per byte would take less than 60 scanlines, so you could even do 60fps video if you wanted. VRAM transfers are not the bottleneck here.

The real bottleneck IMO is PRG-ROM space, since common Nintendo mappers only go as high as 512KB. You'd need a fairly advanced compression scheme to make efficient use of the available space, meaning that the decompression process could end up being too heavy for the CPU. How many frames does the entire animation have? We need to divide the available ROM space by that in order to find out the average bitrate that the compression scheme must achieve.


Top
 Profile  
 
PostPosted: Sun May 26, 2019 11:25 am 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 11376
Location: Rio de Janeiro - Brazil
It looks like the video is 3 minutes and 39 seconds long, or 219 seconds. Times 30 frames per second, that's a total of 6570 frames. If the total PRG-ROM size is 512KB, the average data rate would have to be 524288 / 6570 = 79.8 bytes per frame. Yeah, getting 832 bytes down to 80 sounds like a real challenge. We'd need really good temporal compression, in addition to spatial compression. And there's also the program and the music stealing some of that space. Maybe CHR-ROM could be used for some extra storage?


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 199 posts ]  Go to page Previous  1 ... 10, 11, 12, 13, 14

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