/vr/ - Retro Games

because you can't stack sprites on an NES

>>2158514

megaman did it

>>2158467
Because there's a limit to how many palettes can be displayed on-screen at once, and each palette only has three usable colors.

Because of flickering. Even if your sprite is two tiles wide, and you stack a single tile above it, that will be three tiles. If every enemy had stacked sprites, the game would flicker like hell. The later Mega Man games show what sprite stacking can achieve.

MANY reasons.

First of all, Megaman's use of the technique is part of the reason those games are notorious for their flickering and slowdown. Keep in mind that:
-The NES's processor is so slow that even programming at a machine language level is rarely enough to process more than a few characters onscreen at once, especially if you also have to process AI, animations and the music engine every frame.
-There is an eight-sprite-per-scanline limit. This horrible limitation is what causes flickering (keep in mind, sprites on the NES are limited to either 8*8 or 8*16 pixels, so making big characters requires moving multiple sprites in unison). Layering sprites for better color depth further eats away at this limitation - the more you do it, the more susceptible to flickering you are.

Second, remember that graphics on the NES are not stored in a recognizable format like PNG or GIF. They're essentially just raw indexed bytes that you load into VRAM and assign a palette to. The NES only lets you use four background palettes and four sprite palettes. (Pic sort of related: it's two of the sprite palettes used in SMB1. I couldn't find a better picture with all four). This means you have to use color conservatively: if you use two palettes to create one detailed layered sprite, you can, but then you only have two more palettes for every other object on screen. This is why Megaman only really uses it to add detail to his face - the white and flesh tones are ambiguous enough that they can be reused in another sprite.

>>2158543
Accesible but complete explanation; thanks, anon.

>>2158543
finally! i understand this madness!

very well done.

>>2158543

>tfw there will never be a series of documentaries on the capabilities and limitations of each retro console

>>2158693
Oh there will... I can already see the kickstarter(s)

>>2158543
Create a YouTube channel please.

>>2158543
>even programming at a machine language level

There were people who didn't?

>>2158693
Get this, NES can't even scroll the screen on its own, it needs a custom memory mapper soldered onto the cartridge, which means basically 80% of the games cheated the hardware. Think of the living nightmare making a flash cart must have been.

Stacked sprites count towards the scanline sprite limit, so depending on your game there'd be more flickering. Most games had a lot of sprites, so it was more beneficial to go for less flickering over more colors.

>>2158543
>There is an eight-sprite-per-scanline limit. This horrible limitation is what causes flickering

1) that's not really a horrible limitation, it was pretty good at the time
2) flickering was something that had to be actively programmed in by the developers, otherwise it just wouldn't draw more than 8 sprites so some would be permanently invisible until other sprites moved.

Also essentially all NES programming was done in 6502 assembly. 6502 was designed to be a programmer friendly assembly language. Maybe some studio out there used C and compiled it to 6502 assembly, but that'd be very unusual. And the NES could definitely handle more than "a few" characters on screen at once, have you ever even played an NES game? Most entities in games didn't have complex AIs and just followed a trivial path, but games like Gauntlet had dozens of enemies with basic player tracking AI on screen at the same time.

>>2158860
>2) flickering was something that had to be actively programmed in by the developers

I don't know, I supposed the NES had an interrupt for sprite drawing when more than 8 sprites on screen caused it to skip drawing some of them based on hardcoded priorities (which would constantly change each frame). If the flickering was a thing programmers put in, why would "disable sprite limit" options on emulators work?

>>2158860
>Gauntlet

Gauntlet doesn't use the sprite layer IIRC. Enemies are just tiles being moved around, which is why their movement are very jerky.

>>2158838
I'm pretty sure there were basic NROM games out there that only had PRG and CHR data on their chips that could still scroll, such as the first Mario. Those games had little solder points that determined either vertical or horizontal mirroring.

What would be true is that the NES was not designed to scroll in four directions at the same time. It could scroll vertically, and it could scroll horizontally, but never both. Metroid works around this by scrolling vertically (and only vertically) in the shafts, and scrolling horizontally and only horizontally everywhere else. There were games that did multi-way direction, but they have visible artifacting at the corner of the screens as a tradeoff.

>>2158871
It basically tells the emulator "stop drawing sprites when 8 have been reached", and changes that to "stop drawing sprites when 256 have been reached". It basically just increases the limited number so that it may as well not exist. Some games used sprite masking tricks, such as Maze of Galious. When the character goes down stairs, his sprite vanishes at the door's floor. That's because they used 8 invisible sprites just below the door, where the character goes, and it effectively forces the NES to stop drawing the sprite. Disable this and the sprite will just drop through the floor.

>>2158543
Actually showcasing your technical knowledge with examples on youtube isn't half bad idea.

>>2158871
I think I can explain this. My understanding of flickering is more tailored to the Game Boy (which also has a sprite-per-scanline limit), but I'm 80% sure the NES works the same way.

As I understand it, every sprite has a "priority flag", which is a single bit in memory that essentially tells the machine, "Try to draw these sprites first". So, when it starts drawing sprites on the screen, it'll start by drawing the ones that have this bit set to 1, followed by the sprites where the bit is set to 0. (Better terminology would be, if the bit is set to 1, the sprite has priority, and if it's 0 it doesn't.)

What this means is, if the sprite limit isn't reached, that's great. The priority flags don't matter and every sprite will be drawn. If not, it'll do its best to draw the sprites with priority before anything else.

>So, how does this translate to flickering?
Simple: you program it so that each sprite's priority flag is toggled every frame. You usually try to stagger it so that about half the sprites get priority one frame, then the other half the next frame, and repeat that over and over. Some games with lots of objects do it so every sprite gets priority every 3 or 4 frames, but you usually don't want to do this because it looks awful. Ever played the original Pacman on Atari 2600? Yeah. That's kind of what it looks like.

>Why does disabling the sprite limit work?
Well, if the sprite limit is removed altogether, then switching around the priority flags doesn't do anything because everything gets drawn anyway. That's the beauty of the priority flag method: the system doesn't need to know which sprites are being drawn to flicker them. (Although, if there's some oddball game out there that doesn't utilize priority flags and actually enables and disables sprites manually, disabling the sprite limit won't do anything.)

>>2158804
I've actually considered this. Unfortunately I'm starting a new job, but I'll seriously think about it.

>one remix of stickerbrush symphony plays in a segment that lasts five seconds
>the other plays at the end of the credits and gets cut off a third of the way through

What a great idea.

>>2158543
Punch Out used the MMC2 chip which let the NES have bigger sprites at 32x32.

The 2 Fire Emblem games used the MMC4 chip which is almost the same as the MMC2 chip but with bigger banks; Fire Emblem use the chip's 16x16 mode which the main hardware lacks (caps off at 8x16) and even has more sprites (128 vs the stock 64, 32x32 mode is still at 64 sprites however) so that more stuff can show up on screen.

Star Tropics 1 & 2 which is uses the MMC6B chip also uses the bigger/larger count sprites the MMC2/4 chips have as well, it's based on the MMC3 chip but has 1 extra KB of ram in it.

Why more games did not use these chips I really don't know.

>>2159574
>Why more games did not use these chips I really don't know.

Was cost a factor? I don't know anything about electronics from that time.

>>2159580
It was very much a factor. The bigger, better mappers could drive the price of cartridges up considerably.

>>2159574

Expensive. Using them just lowered your margins on already expensive carts. Nintendo manufactured them and could only be used in NA/EU regions due to licencing agreement. Only the big dog publishers could afford to use Nintendo chips or make their own. If the publisher knew the game was going to sell well then I think they viewed the cost worth it.

>>2159580
Wait. Is this april-fools-joke-turned-minigame implemented using emulated NES or something?

>>2159747
Yes.

>>2158860
>it was pretty good at the time
Bullshit, the Atari 7800's MARIA chip could handle shit tons of sprites at once with no flicker.

>>2159858
Has somebody been able to isolate the ROM from the DS ROM?

>>2159986
Sadly no.

Just lack of interest.

>>2159574
>Punch Out used the MMC2 chip which let the NES have bigger sprites at 32x32.

Bullshit. NOTHING can be done to increase the sprite sizes on the NES, and nothing can be done to increase the number of sprites that can be drawn. Sprites are either 8*8 or 8*16 in size, there can only be 8 sprites on a single scanline, and there can only be 64 sprites on screen in total. The NES isn't like the SNES where the chips do all of the heavy lifting while the console is just the video out.

>>2159580
>>2159747
>>2159858
>>2159986
>>2160040

It's just a faux-retro game written entirely in DS language (which is LEAGUES more powerful than the NES and the language is actually readable and not a string of abbreviations). It'd be fucking pointless to write a game entirely in assembly, only for said game to not actually be made for the NES.

>>2159943
ONLY if the programmer was competent enough and if there were enough spare cycles. The 7800 was still an Atari machine that required computer scientists to figure out, which was most of Atari's programmers.

>>2159747
No. Some kids thought so, but there's obviously way more shit going on than a real NES PPU could handle.

>>2160991
Actually, you could recreate that screenshot mostly accurately, but the biggest issues would be the number of colors you could use and mixing/matching sprites with BG tiles. That and the screen looks way better than anything that was ever commercially produced for the NES. If there's a surefire way to identify whether a game is for the NES or just pretending to be one, it's to look at the art and color use. Even the most advanced NES games fail to escape the pitfalls of limited colors and obviously square backgrounds.

>>2160994
In the actual gameplay, there's a relatively complicated starfield in the background, and a ton more than 64 sprite pixels per line.

>>2160996
Star Soldier did that too, but as you mentioned, the stars here are much more dense. However, no one would be able to see there were fewer stars unless it was pointed out.

And then there's that formation where there's two rows of aliens running into eachother, which is definitely impossible without flicker. Hudson shooters used creative alien formations to bypass the scanline limit, but Raddish does not. If anything, it's to show that it ISN'T an NES game.

>>2161006
>If anything, it's to show that it ISN'T an NES game.
Yes, that's what I meant.

I wrote a small shmup demo on the Genesis once. It occurred to me that, because I exactly controlled the position of every enemy, I could arrange them carefully to just barely avoid the sprite limits. Never got done implementing a tool to build that, though.

>>2160994
Can you change the palette during hblank like you can on the Gameboy Color? Probably too CPU intensive for use in game, but lets you draw fancy title screens.

>>2161020
On the NES you need a special chip to assist in timing it.

Games that use parallax effects, like Kirby's Adventure and Megaman 3, do it by "splitting" the background layer during hblank. For some reason I don't think I've ever seen it used to change palettes, but it has to be possible.

>>2158514
mother/earthbound did it too. in two places that I've been able to verify.

>>2158543
greetings from nesdev, anon!
Maybe I'll see you around tonight without realizing :)

To everyone who says he should make a youtube channel, just lurk on nesdev.com for a while.

>>2161074
>For some reason I don't think I've ever seen it used to change palettes, but it has to be possible.
You might not have enough time to successfully write palette RAM while it's displaying. On the Sega systems, you'll cause graphical glitches if you try.

>>2158514
Wario's Woods did it in the intro.

>>2161080
Mother 1 actually did it quite a bit. Or at least, that's what I saw when I played through it. Some enemies were obviously background tiles with sprites on top for extra graphical detail.

>>2161074
http://ahefner.livejournal.com/11670.html
http://forums.nesdev.com/viewtopic.php?t=6515

>>2161080
using a sprite on top of giegue when the ship or whatever already has white seems like a waste personally. There's white, gray, and blue for giegue and the capsule, and they could've easily used the white instead.

And Ninten isn't really "stacking", it's just one sprite with a unique set of colors sitting ontop of another. The guys from Contra do the same thing.

>>2158514
Double Dragon II and III did it with Billy Lee's elbow.

Does anyone know of any source code from NES games that is available online?

I'm very interested in understanding the thought process of the developers of that time period.

Or is there any source code available from any modern hobby projects that target NES emulators?

>>2161190
Excuse my newfag.

Apparently there is this:

http://forums.nesdev.com/

>>2158538
Wrong, flickering was done intentionally by programmers so sprites would show up at all. The NES is limited to 8 sprites a scanline, any more and it simply stops drawing them

>>2160981
Yes it can, Punch Out (and a few others) have done so.

Star Raddish was made using real NES hardware/PPMCK.
>>2160991
Star Raddish uses 1 NTSC PPU and a RGB PPU.
>>2160994
You can do more with the MMC5 chip then you can with most NES mappers.

>>2161521
It really is interesting to see how good you can make a game look with the NES palette when you remove the limitations on the amount of colors a sprite can have.

>>2161694
Even if you ignore that limitation and used every color the NES was capable of, you're still pretty limited.

>>2160981
Pff. Even something as modern as DS coding is still done in ASM to a certain degree. The DS isn't very powerful.

>>2158467
You should actually see what the inside of that bitch looks like when the plastic housing is removed. It's about 4x the size of a normal NES game.

>>2161595
Punch out does this by stacking a whole group of 8*8 (I reckon they're actually 8*16) sprites, creating what's called a "metasprite". As such, there's a reason why you only fight one boxer at a time, and why they either upper cut or punch forward. A swing would be too wide to render, causing flicker. Popinski and Macho Man also do swings, but notice the use of foreshortening on some of his sprites.

Mario in SMB1 is a metasprite that is made up of four 8*8 sprites in his small form, and eight 8*8 sprites in his big form. His fireball is a single 8*8 sprite.

Regarding Star Radish, do you have any proof that it is indeed an NES game? Maybe a thread on NESDev or a link to the ROM?

>>2158467
Why are the colours all wrong on the left side

>>2163257
It will take more then 64 8X16 sprites to make a fighter in Punch Out, flicker will also be nuts.

It's why Nintendo made a chip that can do bigger sprites.

I know how almost NES games build their sprites.

2ch has dumped the rom but it was never uploaded online.

>>2163953
sounds like a hoax to me
anyone can "dump" it if it's still in the nds rom

>>2163953
sounds like a hoax to me
anyone can "dump" it if it's still in the nds rom of doki doki majo shinpan 2

>>2163953
sounds like a hoax to me
anyone can "dump" it if it's still in the nds rom of doki majo plus

>>2163953
Sauce?
Do you have a link to an archive or whatever of said 2ch thread?
I wish to read it (Japanese is no obstacle)

>>2163960
It's real, someone has ripped the NES rom off the the NDS rom but the NES rom never got uploaded.
>>2163969
No, SNK told 2ch to delete the topic and 2ch did just that.

>>2163994
but it's japan, just slap a mosaic over it and it'll be fine

>>2163953
>>2163960
>>2163994

>GUYS IT TOTALLY EXISTS
>EXCEPT THAT IT'S COMPLETELY LOST TO TIME

Are you "that kid"? Let me ask you something. Why would SNK go through the effort of developing a minigame, inside a loli witch touching game for the DS, in 6502 assembly if they had no plans to produce a functioning Famicom cartridge? For such an application, there is absolutely no use to do so that other than to earn some useless trivia points.

And for punch out, the biggest boxer, Bald Bull, is only 47*119 in size. With 64 8*16 sprites, 8 wide and 8 tall, the maximum size would be 64*128, as proven with math.

>>2164302
No I'm 24; Capcom & BandaiNamco were doing it and It really needed a solo DSi release.

Yea, but what about Little Mac on top of that in battle?

>>2161521
>Pig disgusting pillow shading

>>2164451
>Capcom, Bandai/Namco
>Doki Majo Plus
>an SNK game

As for Little Mac, here's actually something funny. Mac is actually part of the background later, which explains why his movements are relatively jerky and why his gloves/shorts change colors depending on the ring. Normally, the small player character is rendered with sprites while the big boss character is rendered as a background, but Punchout reverses this NES trope.

>>2164514
BandaiNamco did the GCCX games when Capcom did MM9 & 10 (which used post emulator effects).

Outside of battle with Mario yes.

>>2161257
You can't possibly be serious.

>>2164645
He's right, the NES can only do so many sprites so it alternated between two of them at a time to create the illusion of having more sprites than it could render.

>>2164645
This is why games from different companies have identifiably different flicker behavior.

>>2161595
>Star Raddish was made using real NES hardware/PPMCK.
still no proof whatsoever

>>2164529
>BandaiNamco did the GCCX games
they only published it in japan
it was actually a small no-name company called indieszero who did the first two games and they far exceeded the limitations of the nes
http://www.indieszero.co.jp/work/discography/index.html

jesus christ im so triggered right now please leave the thread

>>2161704
i think the point is that arm7 assembly on nds is still far more developer friendly than 6502 on nes

>>2164707
>>>2164529
i dont even think you PLAYED the fucking gccx games because in the sequel you get to unlock 16 bit versions of the games from the prequel
so your telling me they went through the effort of porting the code over to the snes too, sure, why the fuck not

>>2164529
Again, MM9 and MM10 are just designed to look like NES games. There would be absolutely no reason to develop an NES game specifically for it to be released on a platform other than the NES. Programming for the NES, by comparison to modern console programming, is like trying to sculpt Mt. Rushmore using nothing but a toothpick.

>>2164697
2ch said otherwise.
>>2164707
I know indieszero did the first 2 games when G-Rev did the 3rd, but the 3rd game used Super Grafx hardware due to most of the games going above NES standers (others use the Super NES, only 1 or 2 games use NES hardware as G.rev was founded by Ex-Taito staff who did not make home stuff in house until the PS1 as the 3rd & 4th gen stuff were outsourced to other devs like Natsume.

The NES games inside the 2 games use the MMC5 chip, it's sound bus is cut off however and the Namco 163 chip's sound bus is used instead.

indieszero also did NES Remix 1 & 2 with EAD Tokyo 3 (both however use the Wii U's OS chip which is a Cortex-A8 and they go above what the NES can do).
>>2164740
Well, both are in the 65XXX family.
>>2164991
That got debunked, both games used post emulation effects and that the DLC packs are the size of NES games as well.

>>2163310
>>2163310
It's a composite image from two different versions of Mario Bros 3.

The left half is the original Super Mario Bros 3 on the NES.
The right half is the graphically improved version of that game that was included with a bunch of other remade Mario games as part of "Super Mario All Stars" game on the SNES.

>>2165291
And yet you have absolutely NO PROOF about anything you said. NOT EVEN A FUCKING LINK. I can start a thread on NESDev right the fuck now to prove your stupid ass wrong, because the burden of proof is on you.

>>2165437
2ch has proof.

>>2165442
Then show me it.

>>2165293
It's funny as an snes kid I hate the all stars look and prefer the nes look.
Especially for smb.
The only time I got to play an nes was at my grandmas and instead of thinking it was out dated I just thought it was fun.

>>2165291
>2ch said otherwise.

Anybody can say anything on the internet...It doesn't have to be true. Are you really this gullible, or are you just lying? If you're just lying, what do you have to gain from it?

>>2165293
You and I played very different versions of Super Mario All Stars.
Bonus SMA4 for completion.

>>2158467
>Thinking that SMB3 could ever possibly look like that on an NES
Yah nah

>>2165291
Wait.
Wait wait wait.
Did you just legitimately say that Mega Man 9 and 10 are NES ROMs? Are you fucking retarded?

>>2165484
Out of the 8MB/12MB Wii Ware file sizes, only 1MB for both of them are 2A03 code, plus the DLC packs are 64-256KB which are the stander sizes of NES roms.

I'm not retarded.

>>2165628
Just go away, ok? Seriously, leave this thread.

>>2165632
Why? I know what I'm doing.

>>2165640
2ch said i fucked you're mom

>>2165683
No they did not, they don't even know this topic even exist.

Don't lie.

>>2165696
some jap guy said so, it must be true

>>2165291
Where the fuck are you getting all this shit? Post some fucking sources. If these are real NES/SNES games, then certainly at least ONE of them has a playable ROM file dumped somewhere.

>>2165628
>t
>>2165291
>>2164529
>>2163994
>>2163953

>>2165293

the one on the right is supposed to be what the NES would look like with its whole palette being used at the same time

>>2159412

>I've actually considered this. Unfortunately I'm starting a new job, but I'll seriously think about it.

Please do this. I'm not really into romhacking or anything but I still find this shit really interesting and with a proper presentation it this would be gold.

>>2165442
But you just said they deleted it...

>>2165706
Just stop.
>>2165710
Try telling that to NES Donkey Kong with Pie Factory. (a retail version was made, but the rom was never uploaded online) http://www.retrousb.com/product_info.php?cPath=29&products_id=103
>>2165864
SNK told them to deleted it before any roms were uploaded.

>>2163257
>there's a reason why you only fight one boxer at a time

Yeah, it's called "rules of boxing."

>>2165946

Fuck off you fucking sperglord.

>>2165946
w/e nerd
that's still no source

>>2165946
It's simply the DK Anniversary Edition rom ripped from the Virtual Console, which was revealed to be a sloppily-edited hack of the original.

>>2166010
Since when do the rules of boxing allow a 107 pound, 17 year old boxer to fight against a 300+ pound turk? Checkmate, atheists.

Rules of boxing: 0
RULES OF NATURE: AND THEY RUN WHEN THE SUN COMES OUT

>>2166172
How many boxing matches, real or video-game, allow for 1-vs-2(or more)?

The point was that Punch-Out!! didn't limit you to one opponent at a time, it did so because why the fuck would you fight more than one at a time?

>>2166172
How many boxing matches, real or video-game, allow for 1-vs-2(or more)?

The point was that Punch-Out!! didn't limit you to one opponent at a time because of sprite limitations, it did so because why the fuck would you fight more than one at a time?

>>2163257
>As such, there's a reason why you only fight one boxer at a time,

You, dude, are a retard and a troll.

>>2159412
Your posts are highly informative, but this one badly needs a correction. The priority bit doesn't influence sprite priority, at all. Here's how it works. The PPU effectively has two pixel output units, one for sprites and one for the background. The background is easy in theory, and most people can gather how it works so I'm not going to explain it here. One thing I will note is that the background technically has transparency too. The background color is in a layer of its own, and it's what will be output if neither a visible sprite pixel nor a visible background pixel is at any pixel location.

As for the sprites, every scanline it copies only the sprites visible on the next scanline from the OAM (place where sprite data is stored in order of priority) into an internal secondary OAM, just large enough to hold 8 sprites. During hblank, it then fetches the correct tiles and stores them into 8 shift registers respectively, capable of outputting individual pixels. Right before drawing every visible onscreen pixel, the PPU determines if any of these shift registers outputs a non-transparent pixel here, ignoring the priority bit for the moment. It does this in the same order that the sprites were ordered in OAM. The moment one of them does, it ignores the ones after it.

If neither background nor sprites has output a pixel, the background color will be drawn by default. If either one of them has, but not both, that one will be drawn. But if both try to draw a pixel at the same point, only then will the PPU look at the priority bit of the sprite unit currently trying to draw a pixel, and based on that determines which of the two will go to the screen.

>>2166405
What this means in practice is a subtle difference with what intuition would suggest: by overlapping a sprite with another higher-priority sprite that has non-transparent pixels and its priority bit set to go behind the background's visible pixels, you essentially create a mask that can partially or fully hide the first sprite. I believe SMB3 uses this technique so that the mushroom/fireflower/leaf sprites would properly be masked by the question block and still be visible over non-transparent background tiles like hills and clouds and such.

>>2166186
None. However, if they could they probably would have. A lot of Nintendo's games are dictated by what the hardware can and can't do. The reason Mac is little is because they couldn't make him transparent

>>2166739
>nintendo totally would have turned a boxing game into something not boxing if they could

you're just reaching now. if hardware allowed for more, they'd sooner make Little Mac bigger than add two opponents "cuz they can."

>>2158543

the top is mario, the bottom is luigi

>>2167430
The top is also used for Super Mushrooms and Red Koopa Troopas
The bottom is also used for 1UP Mushrooms and Green Koopa Troopas