/vr/ - Retro Games

Actually it's much simpler than it looks on a system like the NES with hardware sprites and tile graphics. If you'd tried to do that on a PC with a dumb frame buffer, it would be far more difficult.

>>3150716
try reading next time

CV III uses the MMC5 mapper if that's what you were asking; it adds more VRAM and allows higher detail levels than are normally possibly.

>>3150606
I wish I knew. I want to do tile graphics, but it feels like you'd need some hefty tool support for that.
as for the uniqueness: it depends on the number of tiles your hardware allows. It's higher than you may think. You got 256 tiles for background. Take your screenshot, divide it into tiles and start counting. Probably few more than a couple dozen in there. The real challenge is in actually designing these sets.

I remember reading an article about how the Megaman NES games actually used two sprites for the character:

http://shmuplations.com/wp-content/uploads/2016/02/megaman16.png

and the full article with interview explaining more how the creators of old games got creative with pallettes and limitations:

http://shmuplations.com/megaman/

>>3150834
>two sprites
Try more like 6-8. Remember that NES sprites are only 8x8 so it takes a lot of them to make one object.

>>3150606
The amount of trickery to squeeze the most out of these systems knew no end. But actually a lot of the tricks aren't complicated.

Castlevania looks good because each area is fairly small, so tiles don't have to be reused to the point where repetition is noticeable. In fact, almost every door, every elevator, every room transition etc. is a loading point in video games where graphics, palettes, and level data are updated.

When the screen can't be blacked out during a transition for a huge update, other techniques can be employed to extend the graphical detail. For instance, in OP's Castlevania image the gears rotate. Since every gear has the same phase, the same graphic can be applied to all the gears (duh, that's tiling). The trick though is that instead of having all the frames of the gear in memory at once, you can update the gear graphic data each frame such that one gear graphic needs to be in memory at a time. You trade away letting the gears have different phases, but you gain 64x64 pixels. Palettes could be updated per frame well for animation and special effects.

Special cart hardware (called mappers, although they did a lot more than memory map) also allowed special techniques to be applied to the game. OP's Castlevania uses such hardware to draw the status bar by generating an interrupt to tell the NES it's time to update some background scroll values. You can see the imperfect interrupt timing in OPs image (look at the slightly glitched scanline underneath ENEMY).

Lastly, it just takes a tremendous amount of skill to make good tile graphics. To be able to hide the redundancy of reused graphics and the regular grid of tiles takes experience and effort. Folks like at Konami got plenty of experience doing pixel art. Things like taking advantage of contrasting colors to bring out more detail are the hallmarks of good pixelmanship (Mario's famous mustache is an example).

Also, a big ole' ROM doesn't hurt either.

>>3150838
>Things like taking advantage of contrasting colors to bring out more detail are the hallmarks of good pixelmanship

Nintendo learned quite a bit over time; SMB3's graphics are very bright, sharp, and tastefully colored compared to the muddy brown and green mess of SMB1. They also learned to outline everything with black to improve contrast and reduce dot crawl.

>>3150836
What he's trying to get at is that Mega Man's face contains 5 colors (clear, white, black, blue, tan) in an 8x8 pixel area, whereas the NES only supported up to 4 on a single 8x8 tile. The trick is not that they made several sprites move in tandem like every video game ever, but that they overlaid extra sprites on Mega Man's face to give him extra colors by stacking 2 tiles from different palettes on top of each other.

Sure, once you state the technique, it's obvious. But please bear in mind this is anything but obvious, it was an innovation, and every little trick that made your game better looking helped edge out the competition.

>>3150834
>>3150836
combining sprites is a very common technique on these systems

>>3150846
After looking at Kirby, older titles just feel so much muddier.

>>3150852
Combing sprites is almost universal.
Overlaying sprites strictly for more colors isn't.

>>3150861
I used combining in the sense of using multiple hardware sprites to produce one visual sprite. That includes tiling, overlays and many other techniques, you nitpicking dimwit

>>3150873
Notice how Ducktales is a Capcom game like Mega Man, and they both use overlain sprites to get more colors? That is actually pretty uncommon except for in Capcom games. It's not an obvious use of sprites, even if combining and overlaying sprites is.

You can call it nitpicking if you want, but I think you are just saying that because you are aware of the technique and think it's obvious in hindsight. Here's a challenge for you: give 3 examples of other popular games that aren't from Capcom that obviously use this technique, like in the Ducktails image. I'm having a really hard time coming up with 1.

>>3150861

>>3150894
Except for capcom, rare and nintendo games?
It's hardly seen because it fucks over your sprite count with very little gain and a huge penalty. You use it only in games where you have a low number of other objects on screen

>>3150895
I have to applaud you for coming up with that one so fast. I found some random top 100 list. Scanning this grid, I can only identify a few examples that have this technique, and they seem to be all Capcom. Surprisingly Battletoads isn't in this matrix. Can you think of 2 more guys?

>>3150916
This one's merely splitting the sprite at the right position to increase the perceived color density.

>Can you think of 2 more guys?
I'm just one guy, and I'm not even an NES player, so I don't know much of the library.
I also have Little Mermaid, but it's Crapom, so you'll dismiss it.
I could whip out a few more on the GBC, but you'd dismiss them, being too late or something.
Again, it's not done often because of little benefit and a huge penalty. You know how often NES games hit the sprite limit. Overlaying sprites is pushing a game one closer to the limit without gaining another enemy, bullet or whathaveyou. So you tend to find it on games that have few enemies, large sprites and possibly slow pacing, which is also the way I found these images, by thinking of games that fit these criteria.

>>3150916

>>3150982
Nope, the head is a standard single 8x8, 4-color tile.

>>3150957
I actually think your Battletoads example is valid. I would have to look at VRAM to be sure, but the way the face and torso blend with the rest of the body, and the way the head and torso aren't an independently moving part of the sprite, I think it's legit.

>>3150916
>mega man 5 the second best one
what is this guy smoking?

>>3151204
what are you smoking?

>>3151267
Everyone knows MM5 is the weakest NES Megaman game.

>>3151290
I thought /vr/'s consensus was that 1 was the shittest.

>>3150838
thank you
how much of that is applicable or relevant by the 16-bit era?

>>3152197
Confession time: I've never played any of them except MM1

>>3150838

Great answer. It really was all about ingenuity and creativity.

>>3152316
I've only played Mega Man X.

>>3151290
I liked part 5. Might be nostalgia but me and Johnny Rodriguez played the fuck outta that mutha back in the dayz,and it twas fun

>>3152379
>>3152316

I've only played 2, Wily's Revenge and Xtreme

>>3150791
No, that has nothing to do with it and you are a fucking moron.

The only reason a MMC5 was used here was for vertical scrolling since the VRC6 that was used in Japan was not nintendo-kosher for the US. The MMC5 and VRC6 were not capable of boosting the resolution or number of tiles the NES PPU could hold. They did allow for more name tables to be used, but not more actual graphical tiles. These name tables were mainly used for scrolling purposes.

>>3153374
Not only was it not NOA kosher, it also would've required some method of accessing the pins on the NES's expansion slot.

I wonder, would an NA copy of Castlevania III work on a Famicom with a 72pin converter? I know CV III won't work on most famiclones, but I wonder if this is just due to the bugginess of NOAC chips or if it's because they're based more on the Famicom than the NES.

>>3150606
Cleverness and letting the details be easy to interpret was also part of it. For instance, I took that pic and I changed the colors around. It now uses 12 colors as opposed to 14, and the cogs are now rusted and bloody, the stone blocks have blood on them, and the background looks like it's made from actual brickwork and not painted green.

>>3156712
That looks better and clever, pre 89 NES games used some really akward palette choices.

>>3156712
are the colors you used part of the NES palette?

>>3156712
>>3156884
IIRC that was because luminescense of the screen depends on vibrance of the colors. If majority of them are bright, screen is well lit, but if the details are dark and bleak, people playing in a well lit room wont be able to see shit.

>>3156910
Probably not.

>>3156967
makes a big impact. It's a good recolor in concept, and I think it should be adjusted for the actual palette, to see what remains. Many colors you'd love to use just aren't available on the NES, leading to "awkward palette choices" as >>3156884 called them

>>3156971
Used the NES palette from wikipedia for reference, including on colors I didn't originally change.

>>3157001
quite a change. Makes it a bit difficult to see what's going on. How come you swapped the light grey of the floor and the dark grey of the walls?

>>3157001
>>3157013
False alarm, the cogs in the background and by extension the grey floors aren't on the pallet. I fail at life.

It looks bright as fuck without. I guess someone at Konami thought the same thing.

>>3157013
indeed, the NES palette is fairly bright. Many "dark" themed games go for purple and similar colors for that reason.

Frankly, I do like that you did this little experiment, because it shows first hand (second hand for those reading) how not-trivial the palette choices on the NES are, and how much skill it took to actually create moody visuals with it.

>>3156712
>>3157018
>>3157027
on that note it should also be mentioned, the original screenshot is using over a quarter of all the colors available to the NES. In theory that's practically rainbow colored

>>3157001
I tried my own and i included my own palette

>>3150606
>hardware sprites
never heard of this

i guess i always assumed it was no different than a frame buffer of today.

so is hardware sprite analogous to a VCR inserting some characters over your live antena feed ?

i just read some about it on wikipedia, but i still didnt get
whats the advantage, did 3rd 4th gen only show max fps for the foreground sprites and secondary elements were being shown at a slower rate?

>>3158145
hardware sprites have nothing to do with framerate, or performance.
These old systems don't have a frame buffer, at all. Instead, each line is rendered just in time, when it's about to be sent to the display.

What's it rendering? Tiles and sprites. Instead of defining individual pixels, a developer declares sprites (what data they show, where they are on the screen), and backgrounds, a grid of tiles, that can be moved arbitrarily.

The difference is vast. Think of something as simple as a platformer, like Mario. To scroll on a framebuffer, the system would have to "move" all pixels, then add new pixels. Compare to a hardware sprites system, where the background is just a huge map of tile references. The difference between one frame and the next is merely a number saying how much that map is shifted on the screen.

Hardware sprites and tile maps (they go hand in hand) are the reason why consoles in the 80s would not just shit on desktops, they'd take a mighty taco bell dump all over them, and add sprinkles, just because they could.

>>3158174
>Hardware sprites and tile maps (they go hand in hand) are the reason why consoles in the 80s would not just shit on desktops, they'd take a mighty taco bell dump all over them, and add sprinkles, just because they could.
The C64, Amiga, and Atari 400/800 would like to have a word with you.

>>3158174
which is where my confusion came in, for some reason I thought the sprites were tile sized (I did read they can be 8x8 or 8x16 on the NES and some other dimensions on other hardware, I guess I overestimated the pixel size)
was there a mode or something where the pixels were bigger? it feels like some games have more detail
(also you're making seem a bit more trivial than it is, you still have to draw the tile map and sprites and draw everything in the correct place and with the correct pallet)

>>3158276
>I thought the sprites were tile sized
They are. If you see games with bigger "sprites", they're actually assembled out of multiple hardware sprites.

>was there a mode or something where the pixels were bigger?
no

>it feels like some games have more detail
That may well be. There's a lot of trickery you can do with these modes.

>you still have to draw the tile map
No, you just declare which position in the grid refers to which tile, and what palette it uses. And you declare the offset of the map on the screen

>and sprites
You just declare which tile represents a sprite, and its location, as well as the palette

>draw everything
That's the really important thing with tile hardware. You do not draw anything. There are no draw calls. The hardware takes all the info of sprite locations, background map and offsets and palettes, and generates the picture from that.

>>3158295
>>I thought the sprites were tile sized
>They are. If you see games with bigger "sprites", they're actually assembled out of multiple hardware sprites.
What I mean is a lot of things have big old squares making up a lot of the background, but now I'm pretty sure the tiles being referred to are-- here, I found it, pic related.>>3158295
>>draw everything
>That's the really important thing with tile hardware. You do not draw anything. There are no draw calls. The hardware takes all the info of sprite locations, background map and offsets and palettes, and generates the picture from that.
>generates the picture from that
That's what I meant by "draw", I know there are no software calls unless they're pulling some trickery to make better use of the hardware. You still have to get all your ducks in a row (duck=pixel) by the time a given memory area is being turned into video signals and sent down the line as part of a frame. That was famously a challenge on the Atari and as someone pointed out, even by the NES era, there were sometimes issues doing this consistently-- the jittering status area on StarTropics comes to mind.

>>3158295
>>I thought the sprites were tile sized
>They are. If you see games with bigger "sprites", they're actually assembled out of multiple hardware sprites.
What I mean is a lot of things have big old squares making up a lot of the background, but now I'm pretty sure the tiles being referred to are-- here, I found it, pic related.
>That's the really important thing with tile hardware. You do not draw anything. There are no draw calls. The hardware takes all the info of sprite locations, background map and offsets and palettes, and generates the picture from that.
>generates the picture from that
That's what I meant by "draw", I know there's no rendering as we thinking of it today. You still have to get all your ducks in a row (duck=pixel) by the time a given memory area is being turned into video signals and sent down the line as part of a frame. That was famously a challenge on the Atari and as >>3150838 pointed out, even by the NES era, there were sometimes issues doing this consistently if you tried to get fancy-- the jittering status area on StarTropics comes to mind.