It is currently Fri Dec 14, 2018 3:23 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 44 posts ]  Go to page Previous  1, 2, 3
Author Message
PostPosted: Mon Jun 11, 2018 8:39 am 
Offline

Joined: Tue Feb 07, 2017 2:03 am
Posts: 629
tepples wrote:
Oziphantom wrote:
Also note the birds outline is black, but the fish is dark blue, watch as it crosses the water line and switches to black.


In that particular scene, there appear to be two enemy palettes from the NES-ist point of view: one for submerged enemies and one for enemies above the water line.

True, but in others you have more enemies below and above and bullets, which is probably going to cause you to palette out. ( there is only 4 right for sprites? that is probably going to be an issue in a lot of places )

tepples wrote:
Oziphantom wrote:
https://youtu.be/ldo2ewLBt3Y?t=1865 note how mayhem is between things in front of the pink and (would be purplish mountains on a crt) but behind the green and the trees.


Crouch for five seconds on a white block in Super Mario Bros. to see a similar effect.

My understanding of NES priority is that you are in front of, or behind everything but background. Not Between colours? so Mayhem being in front on pink and blue, but behind green, brown and yellow is beyond nes spec. sms too?
tepples wrote:
Oziphantom wrote:
Then watch as he collects the invulnerability pickup and sparkles.


Or Sonic in 8-bit Sonic the Hedgehog.

?? Megadrive sonic sure but SMS sonic is a single star that flashes around him badly https://youtu.be/Psami7Mm_aU?t=20

tepples wrote:
You mean those spinning star-shaped coin things? Compare to the spinning round coin things in the background of Super Mario Bros. 3.

No it was the 2 large moles down the bottom, which are 48px wide each, + 24 for mayhem + 16 for smoke + 24 for sparkles on a single line. the large black monster is 70 pixels wide.

Yes the parallax is just a 16x16 that is rolled, however it is hires ;) But again its not also just one individual piece its all of them combined.


Top
 Profile  
 
PostPosted: Mon Jun 11, 2018 8:50 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20875
Location: NE Indiana, USA (NTSC)
Oziphantom wrote:
tepples wrote:
Oziphantom wrote:
https://youtu.be/ldo2ewLBt3Y?t=1865 note how mayhem is between things in front of the pink and (would be purplish mountains on a crt) but behind the green and the trees.


Crouch for five seconds on a white block in Super Mario Bros. to see a similar effect.

My understanding of NES priority is that you are in front of, or behind everything but background. Not Between colours? so Mayhem being in front on pink and blue, but behind green, brown and yellow is beyond nes spec. sms too?

NES and SMS differ on where the priority is set. NES sets it on each sprite; SMS sets it on each tilemap entry in the background. In either case, color 0 allows the sprite to show through, and the blue in the dots in that example is color 0.

There's also "impossible triangle" priority on NES, where sprite A with the behind bit appears in OAM before sprite B without the behind bit. This causes any pixel of A that overlaps an opaque background pixel to appear as the background pixel, covering pixels of B. SMB3 uses this to put mushrooms behind the blocks they sprout from. RHDE: Furniture Fight uses it to put the player's units behind tall furnis in a house. The Curse of Possum Hollow uses it to put Donny behind telephone poles.

Oziphantom wrote:
?? Megadrive sonic sure but SMS sonic is a single star that flashes around him badly https://youtu.be/Psami7Mm_aU?t=20

OK, then the smoke from Thwaite. Being 8-bit doesn't rule out particles, particularly if they're drawn in alternate frames.

Oziphantom wrote:
tepples wrote:
You mean those spinning star-shaped coin things? Compare to the spinning round coin things in the background of Super Mario Bros. 3.

No it was the 2 large moles down the bottom, which are 48px wide each, + 24 for mayhem + 16 for smoke + 24 for sparkles on a single line. the large black monster is 70 pixels wide.

The moles would be 32 pixels wide based on the PAR difference. You'd get 16 for Mayhem, 32 for a single mole, and 16 left for smoke/sparkles that can cover 32 if drawn in alternate frames. On Game Boy Color (which has 8x8 and 8x16 sprites, 10 sprites per line, and 160 pixels per sprite), you'd get 16 for Mayhem, 48 for two moles at 24 each, and 16 left for smoke/sparkles that can cover 32 if drawn in alternate frames.

C64 can do a few effects that NES cannot do. But vice versa as well, and art direction for each console would play to its strengths. What makes the C64's advantages over the NES more reminiscent of 16-bit platforms than the NES's advantages over the C64?


Top
 Profile  
 
PostPosted: Mon Jun 11, 2018 10:58 am 
Offline

Joined: Mon Apr 16, 2007 10:07 am
Posts: 119
Oziphantom wrote:
so Mayhem being in front on pink and blue, but behind green, brown and yellow

My understanding of C64 sprite / background priorities is that for multicolour characters sprites will always have priority over colour 01 while the background priority bit affects colours 10 and 11. Carefully drawn GFX will allow sprites to simultaneously be behind and in front of background GFX.

_________________
Insert witty sig. here...


Top
 Profile  
 
PostPosted: Tue Jun 12, 2018 2:11 am 
Offline

Joined: Tue Feb 07, 2017 2:03 am
Posts: 629
tepples wrote:
NES and SMS differ on where the priority is set. NES sets it on each sprite; SMS sets it on each tilemap entry in the background. In either case, color 0 allows the sprite to show through, and the blue in the dots in that example is color 0.

There's also "impossible triangle" priority on NES, where sprite A with the behind bit appears in OAM before sprite B without the behind bit. This causes any pixel of A that overlaps an opaque background pixel to appear as the background pixel, covering pixels of B. SMB3 uses this to put mushrooms behind the blocks they sprout from. RHDE: Furniture Fight uses it to put the player's units behind tall furnis in a house. The Curse of Possum Hollow uses it to put Donny behind telephone poles.

The C64 also has a similar bug, we call it "cookie cutter" it was mostly famously used in Caren and the Tangled Tentacles.

tepples wrote:
Oziphantom wrote:
?? Megadrive sonic sure but SMS sonic is a single star that flashes around him badly https://youtu.be/Psami7Mm_aU?t=20

OK, then the smoke from Thwaite. Being 8-bit doesn't rule out particles, particularly if they're drawn in alternate frames.

Oziphantom wrote:
tepples wrote:
You mean those spinning star-shaped coin things? Compare to the spinning round coin things in the background of Super Mario Bros. 3.

No it was the 2 large moles down the bottom, which are 48px wide each, + 24 for mayhem + 16 for smoke + 24 for sparkles on a single line. the large black monster is 70 pixels wide.

The moles would be 32 pixels wide based on the PAR difference. You'd get 16 for Mayhem, 32 for a single mole, and 16 left for smoke/sparkles that can cover 32 if drawn in alternate frames. On Game Boy Color (which has 8x8 and 8x16 sprites, 10 sprites per line, and 160 pixels per sprite), you'd get 16 for Mayhem, 48 for two moles at 24 each, and 16 left for smoke/sparkles that can cover 32 if drawn in alternate frames.

C64 can do a few effects that NES cannot do. But vice versa as well, and art direction for each console would play to its strengths. What makes the C64's advantages over the NES more reminiscent of 16-bit platforms than the NES's advantages over the C64?

You have gone through every leaf on the trees and found them all to be 8bit leaves and to which you will say its doesn't look 16bit as all of it can be done on an 8-bit. yes this is true, as it was actually done on an C64. And you have valiantly defended the NES's honor ( not that it was being attacked ) by finding an instance of each of MIM leaves in some games on the NES, and then SMS when the NES didn't quite do it. However you have missed the forest, the point is all the leaves are in MIMs forest and 25 years ago when we played it on a CRT we all said "Mate your pulling my chain, you put an A600 in the case didn't you...", it doesn't look 16 bit explicitly, it feels 16 bit, the high colour, the insane full screen scroller, the full music, the moving eyes on the trees, the way he accelerates, the way he launches of the top of slopes at full speed the way he looks down and worried when he gets to the end of the platform, the way his eyes go up and then down as he jumps, the way it has more than the fixed palette of 16 colours on screen, the smoothness of his jump, and his turn around. Since then it has been determined that it would actually be mostly possible on an A500 at EAB, but it would need some compromises, to be fair to the A500, less than the NES would need :P

Its a lot harder for the NES to look 16bits due to 3 crippling factors.
1.) Teeny tiny VBlank update, its really hard to push enough data through to add more animation, change the background etc. To make this worse you can't even access VRAM but have to spend even more time sending data through a tiny pigeon hole.
2.) RAM, tiny amounts of RAM, which limits the amount the game can remember or the size of the world it can update.
3.) 64 sprite pixels per line, flicker is decidedly cheapening and a key thing of the SNES was it got rid of most of it ( unless you were Konami )

I'm not saying (and have never said) that no NES game can be so high polish and update the wold and avoid sprite flicker to make you think you are playing something that is 16bit. I don't know of any examples but I didn't really own a NES, my friends had it. I started at SNES. I would imagine the NES could make a pretty decent shoot-em-up that would rival some 16bit platforms.


Top
 Profile  
 
PostPosted: Tue Jun 12, 2018 2:12 am 
Offline

Joined: Tue Feb 07, 2017 2:03 am
Posts: 629
Hojo_Norem wrote:
Oziphantom wrote:
so Mayhem being in front on pink and blue, but behind green, brown and yellow

My understanding of C64 sprite / background priorities is that for multicolour characters sprites will always have priority over colour 01 while the background priority bit affects colours 10 and 11. Carefully drawn GFX will allow sprites to simultaneously be behind and in front of background GFX.
Correct, allowing the careful artists to get a "dual-planefields" effect, there is also the cookie cutter bug that allows you to use a sprite to cut another sprite.


Top
 Profile  
 
PostPosted: Wed Jun 13, 2018 1:59 am 
Offline

Joined: Tue Feb 07, 2017 2:03 am
Posts: 629
Being 8-bit doesn't rule out particles.

You have me curious now, what does rule out 8-bit;what "is 16-bit" ?


Top
 Profile  
 
PostPosted: Wed Oct 03, 2018 5:19 am 
Offline
User avatar

Joined: Fri Jan 24, 2014 9:05 am
Posts: 164
Location: Hungary
psycopathicteen wrote:
I have more of a pet peeve with people who call every chip in a system a "processor" as if you can't just make circuitry that does it's specific job by itself and has to execute code. Nowadays pretty much every chip is a processor of some kind, but back in the 80s and 90s, that wasn't the case.


I feel the same way about people who call everything a "card". Talking about the NES "sound card" for example is one of those mistakes that drives me up the wall the most.


Top
 Profile  
 
PostPosted: Wed Oct 03, 2018 6:12 am 
Offline
User avatar

Joined: Thu Sep 15, 2016 6:29 am
Posts: 833
Location: Denmark (PAL)
I gotta admit I have never heard that one.

I had a long talk with someone recently who insisted that the NES has a framebuffer though.
Probably a question of definition of course, but I have a hard time thinking of the PPU RAM as a "framebuffer".

(and before anyone else jumps in, yeah, I'm aware of games/demos that use off-screen nametables as actual buffers :P)


Top
 Profile  
 
PostPosted: Wed Oct 03, 2018 6:26 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20875
Location: NE Indiana, USA (NTSC)
When someone says NES "framebuffer", I immediately think of Videomation and Oeka Kids, which are designed to store a full screen framebuffer in CHR RAM. After that, I think of pseudo-framebuffers as used in Qix, Hatris, the Block Out prototype, 3D Block, and the like.


Top
 Profile  
 
PostPosted: Wed Oct 03, 2018 7:24 am 
Offline
User avatar

Joined: Fri Jan 24, 2014 9:05 am
Posts: 164
Location: Hungary
tepples wrote:
When someone says NES "framebuffer", I immediately think of Videomation and Oeka Kids, which are designed to store a full screen framebuffer in CHR RAM. After that, I think of pseudo-framebuffers as used in Qix, Hatris, the Block Out prototype, 3D Block, and the like.


If I'm not mistaken, it could refer to the fact the NES has the 2kB CIRAM (or all the various types of memory available to the PPU) for drawing the next frame, whereas say the Atari 2600 does not.


Top
 Profile  
 
PostPosted: Wed Oct 03, 2018 8:09 am 
Online
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 11012
Location: Rio de Janeiro - Brazil
The NES has enough video memory to draw an entire frame without CPU intervention, while the 2600 only has memory for one (or half of one) scanline, and needs constant intervention in order do display anything meaningful. Maybe that's what the person was referring to.


Top
 Profile  
 
PostPosted: Wed Oct 03, 2018 9:48 am 
Offline
User avatar

Joined: Fri May 08, 2015 7:17 pm
Posts: 2354
Location: DIGDUG
tepples wrote:
When someone says NES "framebuffer", I immediately think of Videomation and Oeka Kids, which are designed to store a full screen framebuffer in CHR RAM. After that, I think of pseudo-framebuffers as used in Qix, Hatris, the Block Out prototype, 3D Block, and the like.


Also Greg Norman's Power Golf consructs the entire screen from scratch using WRAM at $6000, and copies to VRAM. I find this example much more impressive than Qix.

_________________
nesdoug.com -- blog/tutorial on programming for the NES


Top
 Profile  
 
PostPosted: Wed Oct 03, 2018 2:04 pm 
Offline
User avatar

Joined: Thu Sep 15, 2016 6:29 am
Posts: 833
Location: Denmark (PAL)
tokumaru wrote:
The NES has enough video memory to draw an entire frame without CPU intervention, while the 2600 only has memory for one (or half of one) scanline, and needs constant intervention in order do display anything meaningful. Maybe that's what the person was referring to.


Yeah I think that was the official explanation, but that's not what a "buffer" is in my world. I think the person just accidentally applied a more "modern" mindset to an older console and tried to somehow defend the statement.
The discussion started out of a supposed "inherent input lag" in the hardware of older consoles like NES and SNES.


Top
 Profile  
 
PostPosted: Wed Oct 03, 2018 3:16 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20875
Location: NE Indiana, USA (NTSC)
In the lag sense, the NES indeed has a set of buffers that the PPU uses to emit a frame. It just isn't organized as a stream of pixels.

Input lag on Atari 2600: .5 field
Controller is read at start of vblank before field T
Result displayed on field T

Input lag on ColecoVision and its successors (MSX, SG-1000, NES, Master System, TG16, Genesis, Super NES): 1.5 fields
Controller is read at start of field T
Changes calculated during field T pushed during vblank before field T+1
Result displayed on field T+1

Input lag on most polygon-based systems: at least 2.5 fields
Controller is read at start of field T
Changes calculated during field T into a display list
GPU executes display list during field T+1, collecting pixels into a frame buffer
Result displayed on field T+2

Game Boy behaves like NES.
The ColecoVision and Game Boy Advance, with their tall vblank, may behave like NES or Atari 2600 depending on game loop structure. The Game Boy Player accessory adds more fields of lag.


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

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 1 guest


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