Support NeoGAF

[Krejlooc]

Definitely possible, but freaking hard because of how NES scrolling works - if you are updating scrolling mid-scanline, you have to set four bytes to change the scroll position (rather than just X and Y like you do normally), and some of the scroll changes start to happen as you write the bytes. So there would probably be a bit of corruption. You'd probably want the scroll values pre-calculated and stored in RAM before the screen got to the lines where the split happens.

What they would do in some early sonic games to hide palette corruption (because they'd do it in hblank, and the original method they'd do would take several hblanks) is sacrifice sprites that would purposely flicker across the corruption to mask it.

Hey, they could even tie it in with the object attribution cycling I mentioned previously, lol.

 

[Kjell]

So now I'm wondering if the quirks I'm describing and heavy reliance on hblank is something just common with Sega machines.

Nope, same thing on SEGA consoles. VDP operations are slower during the active scan period than during vblank ( around twice as slow on SMS / GG and up to 10 times as slow for DMA operations on Genesis ), but other than that you can use the CPU as normal .. which is why games where the "frame loop" doesn't fit in the vblank generally update the graphics first.

 

[pswii60]

Fantastic.

As someone who grew up with a C64 (which I loved to bits), this actually blew my mind. I knew about the sprites, but I didn't know about the colour cells, nor did I know why some games were really blocky (low-res full colour mode). Really interesting!

Oh how I miss the C64 days! So much fun back then.

 

[Graphics Horse]

That train demo was meant to be using animated tilesets, but I think they would need some sprites on the train for the sections that don't fill a full 8x8 tile and show the wall behind.
Anyone got a link to the video? I need to see it again!

 

[marvelharvey]

Kinda off topic, but does anyone have a link to how these kind of roads were drawn?

Obviously everything else on screen is a sprite, but the roads in 8/16bit driving games are still a mystery to me. Especially the dips and hills.

 

[beril]

Nope, same thing on SEGA consoles. VDP operations are slower during the active scan period than during vblank ( around twice as slow on SMS / GG and up to 10 times as slow for DMA operations on Genesis ), but other than that you can use the CPU as normal .. which is why games where the "frame loop" doesn't fit in the vblank generally first update graphics before logic & audio.

Thank you for the confirmation. I've looked at some megadrive documentation in the past and it seemed fairly similar to other 2D systems; nothing that would require the CPUs attention during draw except for certain effects (even less than on most nintendo hardware because it can do per line scrolling without raster counting); and the CPU being busy during the screendraw just doesn't make any sense to me.

 

[lazygecko]

Kinda off topic, but does anyone have a link to how these kind of roads were drawn?

Obviously everything else on screen is a sprite, but the roads in 8/16bit driving games are still a mystery to me. Especially the dips and hills.

I believe that basically it was just a form of rapid color swapping (similar to how waterfalls and such were animated in 8 and 16-bit games)?

I vastly prefer the way those games looked compared to the unnaturally flat perspective of Mode7. I wish there was some modern indie game that took this graphical format and pushed its potential further, as it was quickly abandoned with the advent of polygon 3D racers.

 

[Imbarkus]

Most people were not drawing sprites by hand using binary calculations. That was basically limited to extremely tiny eastern european developers contracted out by US Gold to do shit ports of arcade titles to microcomputers in the span of weeks for dirt cheap, lol.

Also, teenage hobbyists.

I may not have persisted with development, but since designing and seeing my created graphics was as far as my interest took me, I'm gratified my adult career has included so much graphic and motion graphic design. The collection of technical knowledge you and others have displayed here is impressive!

 

[Branduil]

Kinda off topic, but does anyone have a link to how these kind of roads were drawn?

Obviously everything else on screen is a sprite, but the roads in 8/16bit driving games are still a mystery to me. Especially the dips and hills.

Some kind of animated tileset with a parallax effect I would assume. I'm hardly an expert on retro graphics but the trick there seems fairly obvious. The Madden games on the Genesis used the same kind of effect.

On the SNES they could just use mode 7, of course.

 

[M3d10n]

I worked on a Nintendo DS game years ago. Since we wanted the game to run at 60fps and we needed UI to be displayed on both screens, I used the DS 2D hardware for the UI: a 2D BG layer with all static elements and sprites for buttons, text and dynamic elements.

But a problem showed up: the DS can only display 128 sprites per screen. That's quite generous compared to 8-bit and 16-bit consoles, but any screen with a large multi line text box could easily go over that limit. I considered using a tile layer to render text, but I would either have to use fixed-width characters or software-render the text into a buffer.

Instead, I decided to use H-BLANK IRQ to "increase" the number of sprites, like in ye old days. It was grueling, but fun. The UI would use "virtual" sprites while a sprite manager would use the hardware sprites to display them, by organizing the virtual sprites in 128-sprite buckets and calculating at which scanlines it would need to swap the buckets to get everything displayed.

 

[Dreamwriter]

Also, teenage hobbyists.

Yeah, way way back in the day I was drawing Vic-20 art out by hand on graph paper and then manually doing the math to turn it into bytes so I could redefine the character set. And I'm glad I had to do it that way, that taught me my powers of 2 math real quick.

 

[Branduil]

Kinda off topic, but does anyone have a link to how these kind of roads were drawn?

Obviously everything else on screen is a sprite, but the roads in 8/16bit driving games are still a mystery to me. Especially the dips and hills.

Okay, I actually looked this game up on Youtube and it just looks like primitive 3D rendering to me: https://www.youtube.com/watch?v=5p4cswI3tdI

You can see the difference in the arcade version versus the Genesis port of the sequel: https://www.youtube.com/watch?v=skv43Nfr_tY

And the Master System version: https://www.youtube.com/watch?v=HMr_82oCug8

 

[beril]

Kinda off topic, but does anyone have a link to how these kind of roads were drawn?

Obviously everything else on screen is a sprite, but the roads in 8/16bit driving games are still a mystery to me. Especially the dips and hills.

a bit simplified
Draw a straight road with perspective, with normal bg tiles.
then scroll the image differently for each raster line; horizotally to make curves and vertically to make hills and dipps.
swap palette colours each line to achieve the roadlines and ground color animation

I'm not entirely sure how they do stuff like the Y junctions in outrun though

 

[Kjell]

Kinda off topic, but does anyone have a link to how these kind of roads were drawn?

As beril described .. horizontal / vertical scrolling per scanline for corners & hills ( and palette cycling to simulate forward movement ). You can find a extensive explanation here.

I'm not entirely sure how they do stuff like the Y junctions in outrun though

The road is split down the middle so that the left & right side are on separate background layers ;-)

 

[Imbarkus]

Yeah, way way back in the day I was drawing Vic-20 art out by hand on graph paper and then manually doing the math to turn it into bytes so I could redefine the character set. And I'm glad I had to do it that way, that taught me my powers of 2 math real quick.

I did my entire first set of custom fonts and graphics including fancy old-timely letters (for the ones I didn't sacrifice) and poked it in there and started typing before I realized I had to build the space between characters into the character itself. So in a way, I kind of learned about bleed that way.

They stopped calling that math Base2, didn't they?

 

[StudioTan]

The part with the graph paper brought back memories. That's how I first started to draw on computers on my Vic20 when I was a kid. The difference was instead of sprites I found a program in a computer magazine that showed how to remap the graphics of each letter on the keyboard. So instead of the "A" key making an "A" shape it would make any 8x8 pixel shape I wanted.

So I would do the same thing he did, map out the picture on graph paper split into 8x8 sections, add up all the rows in binary and then put those values into the basic program. Then when I typed something like:

QWERTY
ASDFGG
ZXCVBN

it would make a picture!

EDIT:

Yeah, way way back in the day I was drawing Vic-20 art out by hand on graph paper and then manually doing the math to turn it into bytes so I could redefine the character set. And I'm glad I had to do it that way, that taught me my powers of 2 math real quick.

Seems like I wasn't the only one

 

[beril]

As beril described .. horizontal / vertical scrolling per scanline for corners & hills ( and palette cycling to simulate forward movement ). You can find a extensive explanation here.



The road is split down the middle so that the left & right side are on separate background layers ;-)

ah of course, thanks

 

[UncleSporky]

This was just about the only reason I could think one would want to mess with something like that mid scanout. It's neat to hear someone has actually pulled it off. Do you have any links to such an example?

I saw a topic recently about "retro style games" or whatever, and someone posted a gif of a game that featured some train segments separating, and people were complaining that something of that sort couldn't be accomplished on actual NES hardware. Well, the dev was a demoscene coder in the NES hacking scene, and he cryptically said it could have been done "with a large cartridge." Assuming the CPU/drawing limitation I mentioned before, I thought he just meant relying on bankswitching the entire background like a huge flip book, with one half of the background being devoted to each train segment (hence the huge cart part), but now I'm wondering if someone could pull it off with vertical screen splitting...

Here's one I found...but no emulators can display it correctly. You have to load it onto actual hardware to see it.

As for the train, that was me talking about it! And I emphasized there that a true vertical split would be incredibly difficult and impractical. He argued that later mappers natively supported vertical screen splitting but I wasn't able to find any documentation about it. Supposedly Bandit Kings of Ancient China does it in the credits, but again, no emulators can show the effect properly.

 

[Branduil]

Not exactly retro gaming, but reading about HAM on the Amiga a few years ago blew my mind:

https://en.wikipedia.org/wiki/Hold-And-Modify

A HAM picture that contains up to 4,096 colors in 352×480 resolution, made in 1989

 

[Graphics Horse]

The UI would use "virtual" sprites while a sprite manager would use the hardware sprites to display them, by organizing the virtual sprites in 128-sprite buckets and calculating at which scanlines it would need to swap the buckets to get everything displayed.

Nice, I'd been wondering if there were any modern attempts at that in a commercial game, I remember a gba demo that was a bullet hell shooter that did software multiplexing if that's what it's called.
http://www.gbadev.org/demos.php?showinfo=1333


http://www.gbadev.org/demos.php?showinfo=1276
Both of those I think.

 

[Chev]

Kinda off topic, but does anyone have a link to how these kind of roads were drawn?

Obviously everything else on screen is a sprite, but the roads in 8/16bit driving games are still a mystery to me. Especially the dips and hills.

Lou's Pseudo 3d Page is exactly what you want.

 

[DavionStriker]

Wow, that was really fantastic. As a gamer from the Atari days, I remember seeing some of these things. Looking forward to episode 2.

 

[Brashnir]

Not exactly retro gaming, but reading about HAM on the Amiga a few years ago blew my mind:

https://en.wikipedia.org/wiki/Hold-And-Modify

Yeah, the Amiga was pretty mind-blowing back in its day. So much so that people typically think of it as being a contemporary of the Genesis and SNES, even though it launched the same year (1985) as the NES in the west.

 

[Vex_]

Wow. That was a great video op! Thanks for that. Also gonna check out more of his vids.

 

[Crankshaft]

Thank you for posting that video. That was great!

 

[dark10x]

I gotta say, that was an excellent video. He did an excellent job breaking down those aspects. Kind of miss that stuff.

 

[FrozenCell]

ought to also cover sprite layers

 

[MikeDip]

Very cool vid, thanks for showing me

 

[Booker.DeWitt]

awesome, thank you for sharing

 

[system11]

If you really want a nuts & bolts look at early graphics hardware, try digesting this at some point:

http://www.arcade-museum.com/manuals-videogames/D/Defender.pdf

Companies weren't shy about telling customers exactly how their products worked, back then. That will tell you how the whole brain of a Defender machine works.

 

[JetBlackPanda]

this is fascinating. Subbed.

 

[MikeDip]

I worked on a Nintendo DS game years ago. Since we wanted the game to run at 60fps and we needed UI to be displayed on both screens, I used the DS 2D hardware for the UI: a 2D BG layer with all static elements and sprites for buttons, text and dynamic elements.

But a problem showed up: the DS can only display 128 sprites per screen. That's quite generous compared to 8-bit and 16-bit consoles, but any screen with a large multi line text box could easily go over that limit. I considered using a tile layer to render text, but I would either have to use fixed-width characters or software-render the text into a buffer.

Instead, I decided to use H-BLANK IRQ to "increase" the number of sprites, like in ye old days. It was grueling, but fun. The UI would use "virtual" sprites while a sprite manager would use the hardware sprites to display them, by organizing the virtual sprites in 128-sprite buckets and calculating at which scanlines it would need to swap the buckets to get everything displayed.

This is amazing too, what game was it if you are allowed to say? I want to see if I own it and go look at what you did and see how it turned out.

 

[Purple Cheeto]

There's actually a bit of additional information on this subject in the article "Fuck the Super Game Boy"

http://loveconquersallgam.es/post/2350461718/fuck-the-super-game-boy-introduction

Which discusses various graphical limitations inherent with the Super Game Boy and how developers got around them.

This was an awesome series to read. Thanks for sharing!

 

[LamerDeluxe]

On my VIC-20, when I wanted to define my own characters, I always wrote a small piece of code, at line 3000 for instance, that converted an 8x8 image of asterisks and spaces that I would have typed out at the top left corner of the display, to a line of data. Made things much easier than using paper.

I did use paper to create multi-color graphics on the VIC-20, made Garfield, Odie and Jon and a small animation of them, it looked really cool.

Later on I did a lot of pixel graphics using DPaint, for TV show graphics as well. For PC there is an expanded DPaint clone called ProMotion. I also hand-pixeled and dithered textures for early 3D games.

The Atari Lynx, from the same year as the original Gameboy, doesn't use any tiles at all. All graphics are made out of sprites, including the backgrounds. They can be of an almost unlimited size, an amount only limited by framerate, hardware scaled and compressed and placed anywhere in a 32768 x 32768 pixel world. They aren't like traditional sprites, more like a list of blitter objects. The Lynx was way ahead of its time.

 

[MightyHedgehog]

The Atari Lynx, from the same year as the original Gameboy, doesn't use any tiles at all. All graphics are made out of sprites, including the backgrounds. They can be of an almost unlimited size, an amount only limited by framerate, hardware scaled and compressed and placed anywhere in a 32768 x 32768 pixel world. They aren't like traditional sprites, more like a list of blitter objects. The Lynx was way ahead of its time.

Wow, that's pretty incredible, especially since that capability is built for a freaking handheld.

 

[Dreamwriter]

Later on I did a lot of pixel graphics using DPaint, for TV show graphics as well. For PC there is an expanded DPaint clone called ProMotion. I also hand-pixeled and dithered textures for early 3D games.

I'm currently using ProMotion to make art and screens for the NES game I'm making.

 

[Zultan]

Given the amount of hoops and complexities the developers back then had to go through, no Internet, and extremely limited debugging capabilities of the systems... it's a wonder these games worked at all.

And then add in that most of these programmers likely only had a year or two of experience and are charting mostly uncharted territory with limited documentation and few other people to talk to to ask for advise.

Amazing.

We are so coddled today. I can't live without my step-through debugger.

 

[mrklaw]

Lou's Pseudo 3d Page is exactly what you want.

thanks, this is awesome.

I love all this old tech stuff. Partly because it is amazing how they got so much out of so little, but partly because it is simple enough to get your head around - modern systems are so powerful and abstracted from the hardware in comparison.

 

[Imbarkus]

On my VIC-20, when I wanted to define my own characters, I always wrote a small piece of code, at line 3000 for instance, that converted an 8x8 image of asterisks and spaces that I would have typed out at the top left corner of the display, to a line of data. Made things much easier than using paper.

I did use paper to create multi-color graphics on the VIC-20, made Garfield, Odie and Jon and a small animation of them, it looked really cool.

I got a simple C-64 sprite maker program too, from either Loadstar or Compute's Gazette. I ended up adding on to it quite a bit as I tinkered with it.

The Atari Lynx, from the same year as the original Gameboy, doesn't use any tiles at all. All graphics are made out of sprites, including the backgrounds. They can be of an almost unlimited size, an amount only limited by framerate, hardware scaled and compressed and placed anywhere in a 32768 x 32768 pixel world. They aren't like traditional sprites, more like a list of blitter objects. The Lynx was way ahead of its time.

Loved the Lynx. When someone asked earlier how you accomplish the faux-perspective roadway effect, I instantly thought of Lynx and S.T.U.N. Runner, and I was all "just make the road out of thousands of sprites and zoom them towards you really fast."

 

[Chev]

Given the amount of hoops and complexities the developers back then had to go through, no Internet, and extremely limited debugging capabilities of the systems... it's a wonder these games worked at all.

The complexity's the thing though: Those systems were reasonably simple compared to the ones we have now. You could, back then, have a whole program charted in your head, or modify a program you'd bought, or even poke and peek around to reverse-engineer the machine language of your platform. Nowadays it's beyond tricky.

 

[Bydobob]

Great video, explains the science behind why C64 games often appeared "blocky" as programmers prioritised colour over pixel density.

Thread has provided some fascinating debate too, conducted in the best of spirits. Thanks all for sharing.

 

[MrCunningham]

From about 1986 onward, an Amiga with Deluxe Paint was basically industry standard. So many game companies -- including Sega -- used it.

Most people were not drawing sprites by hand using binary calculations. That was basically limited to extremely tiny eastern european developers contracted out by US Gold to do shit ports of arcade titles to microcomputers in the span of weeks for dirt cheap, lol.

That's what I assumed, you can see a pretty big jump between the sprite art of older NES games in comparison to something that was made after 1986, like Doki Doki Panic. Switching over to Amiga's and using Deluxe Paint must have helped their work flow a lot. I wonder what computers they were using before that?

 

[marvelharvey]

a bit simplified
Draw a straight road with perspective, with normal bg tiles.
then scroll the image differently for each raster line; horizotally to make curves and vertically to make hills and dipps.
swap palette colours each line to achieve the roadlines and ground color animation

I'm not entirely sure how they do stuff like the Y junctions in outrun though

As beril described .. horizontal / vertical scrolling per scanline for corners & hills ( and palette cycling to simulate forward movement ). You can find a extensive explanation here.



The road is split down the middle so that the left & right side are on separate background layers ;-)

Lou's Pseudo 3d Page is exactly what you want.

Thank you all! Very interesting reading.

 

[Lemming_JRS]

Thanks for correcting/clarifying the info in my post, Dreamwriter and Krejlooc. I'd forgotten the 2600 was 6502-based. And for the fascinating discussion that followed.

 

[Boogalogist]

This was a damn interesting watch. Back in the 80s, I was typing in programs in my Speccy 48k according to the magazine, without knowing what it most of it all meant. Gradually, I came to understand more and more. This video clears up even more things. Subbed.

Thanks for the share guys!

 

[LamerDeluxe]

Wow, that's pretty incredible, especially since that capability is built for a freaking handheld.

Absolutely. Designed by the same people who worked on the Amiga chipset, also way ahead of its time. It is really pleasant to work with, you can actually do a tile system but it becomes a list of tiles that you add to and remove from as new tiles come into view.
But just building your world out of (scaling) sprites is usually a much better idea.

I'm currently using ProMotion to make art and screens for the NES game I'm making.

It is really great software for that. I don't know how much it has advanced since I last used it.

I got a simple C-64 sprite maker program too, from either Loadstar or Compute's Gazette. I ended up adding on to it quite a bit as I tinkered with it.

And you could then just save and load the sprite data into your own game? I should have made something like that for my VIC-20.

Loved the Lynx. When someone asked earlier how you accomplish the faux-perspective roadway effect, I instantly thought of Lynx and S.T.U.N. Runner, and I was all "just make the road out of thousands of sprites and zoom them towards you really fast."

STUN runner has a really awesome way of drawing its tracks. It draws sections back to front, using four quadrants of scaled sprites for each section.

Roadblasters also uses a really neat trick. Hardware sprite compression on the Lynx works by stating the next color you want to draw, combined with the number of horizontal pixels it is to repeat over. Roadblasters has a single compressed sprite for the whole road and then just alters the number of pixels for the grass on the left, for each horizontal line of the sprite, to bend the road in real-time.
(you cannot do that with raster interrupts on the Lynx, as sprites are drawn completely independently of the display refresh).

What the Lynx can do with sprites however, is to increase or decrease the horizontal and vertical scaling of a sprite, per horizontal line (for a tapering and perspective effect). Combined with that it can also skew sprites horizontally. With this you can build a whole perspective-correct scaling and and panning ground plane out of sprites.
This is what they do to generate the landscape in Blue Lightning.

 

[Clear]

I thought it was an OK video, but it made things a bit more complex sounding than they needed to be.

Its just a case of bit-mapping versus character mapping, and the core ability to handle independent multiple level playfields in hardware (or not).

The way he describes stuff is fine, but by not emphasising how character/tile based screens can facilitate stuff like (cpu) cheap scrolling playfields and screen wide animations he's kind of selling the differences short.

The thing is, on something like the c64, each 8x8 "cell" or character is a reference to a specific bitmap. So, for sake of a simple example imagine you have a screen full of text, by changing the bitmap referenced as the letter 'a' every instance where the letter is used onscreen will change instantly and simultaneously. It had a whole bunch of interesting uses, especially as you could produce animation and scrolling effects by simply operating on single/groups of characters. This for instance was used to create simple parallax effects.

 

[mrklaw]

I thought it was an OK video, but it made things a bit more complex sounding than they needed to be.

Its just a case of bit-mapping versus character mapping, and the core ability to handle independent multiple level playfields in hardware (or not).

The way he describes stuff is fine, but by not emphasising how character/tile based screens can facilitate stuff like (cpu) cheap scrolling playfields and screen wide animations he's kind of selling the differences short.

Could the C64 do that though? Focus seemed to be on that computer. I'd like an entire episode looki at scrolling with tiled backgrounds using the NES as an example.

 

[Branduil]

Yeah, the Amiga was pretty mind-blowing back in its day. So much so that people typically think of it as being a contemporary of the Genesis and SNES, even though it launched the same year (1985) as the NES in the west.

Yeah, even with its regular graphics mode, it blew away the consoles at the time.

 

[chromatic9]

Takes me back to being a kid on my C64, typing out code for hours just to get a red ball bouncing around the screen.

Deluxe paint was one of the main programs I used on my Amiga 500, mainly for just drawing and animation, video capture, digitizing. When PC's took over in the 1990s I thought the paint programs would get more advanced and something pretty comprehensive would come built into windows, yet even MS paint today is just laughable compared to what I used in the late 1980s.

Fond memories launching boulders at castles and sword fighting with that game.