Support NeoGAF

[maniac-kun]

This guy produced a video about how the technical side of 8 bit graphics actualy worked:

https://www.youtube.com/watch?v=Tfh0ytz8S0k

So far part 1 is done.

 

[Khalifa Jayy]

This guy produced a video about how the technical side of 8 bit graphics actualy worked:

https://www.youtube.com/watch?v=Tfh0ytz8S0k

So far part 1 is done.

Saw that on reddit, too. Can't wait to watch this at home.

 

[Razlo]

I'm finding out about this first hand right now. Turning my card game Billionaire Banshee into an NES game. It's not easy!

 

[Apath]

Is there a tutorial somewhere to learn how to program games like this? Sounds extremely interesting.

 

[maniac-kun]

Is there a tutorial somewhere to learn how to program games like this? Sounds extremely interesting.

http://nintendoage.com/forum/messageview.cfm?catid=22&threadid=7155

 

[Nanashrew]

Oh, this is really cool! Watching now!

 

[chrisPjelly]

I love these amazing insights into oldschool video game development

 

[Dizzy-4U]

That was really neat.

 

[UncleSporky]

http://nintendoage.com/forum/messageview.cfm?catid=22&threadid=7155

Good man. This is the best tutorial out there.

I had to learn from a crap tutorial full of mistakes and misconceptions.

 

[Brashnir]

get your peek and poke on, son.

 

[The Goat]

What they were able to accomplish with such limitations is mind boggling. I'm ready for part 2!

 

[Rushersauce]

What an amazing video. I subscribed to that guy. He deserves it.

 

[Emedan]

Very interesting, thanks for sharing!

Edit:
Is this guy an electrical engineer?

 

[Phediuk]

Great video.

 

[Dreamwriter]

Nice little video, though I'm not sure where he got the idea that tiles were called "color cells", they were (and still are) called tiles, both in magazines of the time (Compute!) and in official SDK documentation (at least for the Gameboy Color). BTW, the colors that can be displayed in one tile are known as a "palette" - the NES could display 4 colors per background tile (mostly...), so those 4 colors are a single palette, and it can display four palettes per screen (meaning, each tile can choose from premade color palette 0, 1, 2, or 3).

Is there a tutorial somewhere to learn how to program games like this? Sounds extremely interesting.

http://nintendoage.com/forum/messageview.cfm?catid=22&threadid=7155

Also check the NESDev forums.

 

[DJ_Lae]

That was really cool - and something I didn't know before, too. Would love to see more like that.

 

[Pinky]

Very cool!

 

[Srey Plaughtered]

Saw it on reddit, really really cool. especially the bit about hardware sprites. Hopefully Part 2 comes out soon.

 

[MrCunningham]

This is a great video, and it is only 7 minutes long too. Pixel artists had to work with some pretty incredible limitations back them. Most weren't even working with paint programs and had to create all their art on graph paper and insert the values into a computer manually. That is crazy. The last machines to use that cell colour method are the Game Boy Color, NeoGeo Pocket Color and probably even the WonderSwan color (what a weird trend that was in the late '90's with monochrome handhelds going colour).

I would imagine that the early Nintendo developed NES games from 1983 used the graph paper method, but a lot of the later games from the mid 80's onwards were created with much better tools and proper paint programs.

 

[SonyToo!™]

Cool vid.

It's interesting to find out about multi colour mode that most C64 games used, (trading more colour for half the resolution) As a kid I always wondered why C64 (I think the Amstrad used it too) were so blocky when looking at comparison screenshots of the 8bit home computers. Often I actually preferred the more detailed but much less colourful Spectrum +2 128k graphics to the C64 and Amstrad, Spectrum graphics were very notorious for the colours not matching up to the artwork due to the blocks of single colour.

 

[UncleSporky]

I would imagine that the early Nintendo developed NES games from 1983 used the graph paper method, but a lot of the later games from the mid 80's onwards were created with much better tools and proper paint programs.

They shared some of their original design documents in some of the old Iwata Asks columns. Not pixel-by-pixel graph paper but similar ideas, for how sprites would be laid out in memory to fit well and such.

For Zelda, obviously:

Those background planning sheets are incredibly important. Even though individual 8x8 tiles could display up to 4 colors, to save further on memory, backgrounds were assigned palettes in 16x16 pixel chunks. You had to make sure that you only needed 4 colors for every 16x16 block of graphics in the background - not a problem most of the time since standard blocks in Mario and Zelda were 16x16, but for more detailed artwork it could get quite difficult.

 

[Dreamwriter]

\The last machines to use that cell colour method are the Game Boy Color, NeoGeo Pocket Color and probably even the WonderSwan color (what a weird trend that was in the late '90's with monochrome handhelds going colour).

Don't forget SNES, Genesis, GBA, Turbografx-16, Neo Geo! It's been a while, but I *think* Nintendo DS even had a palette-limited tile mode, and I wouldn't be surprised if PS1 did too.

 

[Kadin]

Alright that was pretty cool. I remember the first time I got the Starship Enterprise on my C64 and had it fly across the screen. Sadly, that was the pinnacle of my programming career.

 

[Apath]

http://nintendoage.com/forum/messageview.cfm?catid=22&threadid=7155

Nice little video, though I'm not sure where he got the idea that tiles were called "color cells", they were (and still are) called tiles, both in magazines of the time (Compute!) and in official SDK documentation (at least for the Gameboy Color). BTW, the colors that can be displayed in one tile are known as a "palette" - the NES could display 4 colors per background tile (mostly...), so those 4 colors are a single palette, and it can display four palettes per screen (meaning, each tile can choose from premade color palette 0, 1, 2, or 3).


Also check the NESDev forums.

You guys have made my night.

 

[Neff]

Aaah, memories. I remember patiently drawing an Autobot logo in a 24x24 grid and converting it from binary to decimal so I could watch it fly around the screen.

Holy shit, Halo Jones!

 

[firebricks3]

I've written a few console emulators and this is basically how they do it. A chunk of the RAM is designated for the frame buffer and you iterate over that to create the image. The NES did do a few other funny things like jumping between pallettes and such. You could always skip the fancy color business and have 1 bit per pixel ala space invaders and throw a color overlay on the monitor.

 

[beril]

I kindof feel he shouldn't have mentioned the NES at all in the video, because that's a terrible explanation for nes graphics, given that it's entirely tilebased and the graphics data isn't even stored in RAM so most of what he says just doesn't apply at all

 

[MrCunningham]

Don't forget SNES, Genesis, GBA, Turbografx-16, Neo Geo! It's been a while, but I *think* Nintendo DS even had a palette-limited tile mode, and I wouldn't be surprised if PS1 did too.

Well, I meant machines that were kind of limited to that 2/4 colour tile method seen in the video. The machines you listed all have different colour models that are much more advanced.

They shared some of their original design documents in some of the old Iwata Asks columns. Not pixel-by-pixel graph paper but similar ideas, for how sprites would be laid out in memory to fit well and such.

For Zelda, obviously:


Those background planning sheets are incredibly important. Even though individual 8x8 tiles could display up to 4 colors, to save further on memory, backgrounds were assigned palettes in 16x16 pixel chunks. You had to make sure that you only needed 4 colors for every 16x16 block of graphics in the background - not a problem most of the time since standard blocks in Mario and Zelda were 16x16, but for more detailed artwork it could get quite difficult.

Oh yeah, I could still see that being useful for designing game maps and laying out all the tiles in memory. They were using graph paper to design the levels for Super Mario 64. But for the sprite art, I was thinking even older than Zelda and Super Mario Bros. 1.

This is for the Donkey Kong arcade game from 1981:

You can see the 8x8 tiles and where all the pixels and colours would fit in. Maybe they were still doing this for the earliest Famicom games from 1983 and so?

 

[entremet]

Great video!

 

[bloodreign]

That was great to watch, thanks!

 

[Schrade]

This is fantastic! Thanks for posting it. Please keep us updated on the other ones.

 

[Pimpbaa]

Don't forget SNES, Genesis, GBA, Turbografx-16, Neo Geo! It's been a while, but I *think* Nintendo DS even had a palette-limited tile mode, and I wouldn't be surprised if PS1 did too.

I don't think the neo geo did it like that at all. It had no background layers support, not even one (other 16-bit could have several for parallax scrolling). Backgrounds on neo geo consisted of tiled sprites and since the system had the ability to scale sprites, some of the fighting games could zoom the whole screen in and out. It also meant backgrounds could be more animated. The downside would be you are blowing a lot of your sprite budget just for backgrounds, more so if you wanted multiple layers. As for the ps1, I think most 2d was done with flat polygons. So it didn't have palette limitations.

 

[CharminUltra]

That was illuminating. Thanks for posting!

 

[Imbarkus]

Neat. Thanks for posting. I still have some sprite data from a C-64 game I started and gave up on making a couple of decades ago. I should actually double-check this code, I OCR'd it from a daisy-wheel printout, I think. Maybe someday I'll make a video, I captured some footage of the sprites.

20 PRINT"LABYRINTH"
25 PRINT"BY IMBARKUS"
30 POKE 53280,12:POKE 53281,0:PRINT"":POKE53282,11:POKE53283,9
40 POKE53284,15:POKE 53265, PEEK(53265) OR 64
50 FORHM=0T0511:READUM%:POKE14336+HM,UM%:NEXTHM:POKE53272,31
60 DATA 24,24,24,31,31,24,24,24,96,28,34,34,62,34,66,1,0,124,34,60,34,34,62,64
61 DATA28,34,68,64,64,67,60,0,60,82,17,33,33,33,114,140,62,81,16,44,32,113,142,0
62 DATA62,81,16,44,36,32,112,128,24,24,24,255,255,0,0,0,3,118,18,30,36,36,54,64
63 DATA 1,126,8,8,16,17,126,000,24,24,24,24,0,0,0,0,0,0,0,240,240,0,0,0
64 DATA16,48,80,16,32,32,57,70,192,118,85,73,73,66,98,129,65,34,50,42,42,38,66
65 DATA128,28,34,65,65,66,66,60,0,32,94,17,17,62,32,48,192,0,0.,0,15,15,0,0,0
66 DATA0,124,34,60,34,34,38,65,28,34,65,56,6,1,114,140,66,61,8,8,16,16,24,32
67 DATA51,81,17,34,34,66,60,0,0,0,0,0,24,24,24,24,33,82,18,33,77,77,54,0
68 DATA0,0,0,31,31,24,24,24,0,67,68,40,16,16,24,32,24,24,24,31,31,0,0,0
69 DATA24,24,24,248,248,0,0,0,0,0,0,248,248,24,24,24,0,0,0,255,255,24,24,24
70 DATA8,8,62,73,73,8,8,28,0,132,194,127,194,132,0,0,0,0,0,0,0,0,0,
71 DATA62,28,24,24,0,0,48,48,146,37,74,148,41,82,164,73,24,24,24,248,248,24,24,24
72 DATA24,24,24,255,255,24,24,24,24,24,24,24,24,24,24,24,0,0,0,255,255,0,0,0
73 DATA129,195,231,247,109,231,195,129,1,3,7,13,31,59,95,254
74 DATA128,64,224,240,104,252,246,255,119,127,95,125,111,123,95,127,0,8,8,62,8,8,
75 DATA0,127,239,254,191,247,255,223,251,0,0,0,62,0,0,0,0,1,3,7,13,31,59,95,126
76 DATA190,254,246,222,252,254,190,246,28,34,37,73,81,98,60,0,8,56,8,16,16,16,56,
77 DATA62,65,6,8,16,32,249,6,50,78,2,12,2,65,63,0,33,34,66,97,68,5,14,16
78 DATA113,78,112,14,1,65,62,0,14,17,32,94,65,65,62,0,63,33,66,4,8,16,56,0
79 DATA1,30,33,62,65,65,62,0,60,66,66,52,12,8,112,0,128,64,224,240,104,252,246,25
80 DATA126,122,94,126,118,126,62,124,254,95,59,31,13,7,3,1
81 DATA255,246,252,104,240,224,64,128,254,246,252,104,240,224,64,128
82 DATA126,95,59,31,13,7,3,1
100 FORWH=15808TO16363:READSD:POKEWH,SD:NEXTWH
110 POKE53269,255:POKE2040,247:POKE2041,248:POKE2042,249:POKE2043,250
120 POKE2044,251:POKE2045,252:POKE2046,253:POKE2047,254
149 REM ---- SPRITE-OA-"DEAD"-----
150 DATA255,255,255,,,,,,,255,255,255,,,,,,,225,231,28,185,5,151,137,4,145
151 DATA137,231,145,137,4,145,137,4,145,185,4,151,225,228,156,,,,,,,255,255,255
152 DATA,,,,,,255,255,255,,,0,0
153 REM ---- SPRITE-l-"PLAYER"---
154 DATA,,,,,,,,,,,,,,,,,,,,,,,,,,,,16,,,40,,,16,,,,,,,,,,,,,,,,,,,,,,,,,,,,,0
155 REM ---- SPRITE-2-"ORCOLLE"---
156 DATA ,,,5,,80,7,85,208,199,215,211,199,255,211,214,255,151,214,190,151
157 DATA213,190,87,245,125,95,245,255,95,247,255,223,21,85,84,22,105,148,26,105,16
158 DATA26,170,164,22,170,148,7,170,208,5,235,80,1,125,64,,85,,,20,0,0
159 REM, ---- SPRITE-3-"SORCERTROLL"---
160 DATA60,42,,124,149,128,84,183,128,20,149,128,168,149,128,168,166,128,40,42,0
161 DATA40,170,160,40,170,168,42,170,40,42,170,168,32,170,40,,170,20,,168,168
162 DATA,168,168,,170,20,,170,148,2,170,160,2,170,160,1,64,80,5,64,80,0
163 REM ---- SPRITE-4-"SCUTTERLASH" ----
164 DATA,16,,,112,,64,112,64,208,144,64,208,161,65,104,161,69,8,33,b9,10,33,69
165 DATA82,161,69,86,169,69,70,170,81,70,170,97,70,170,97,68,170,97,68,10,97
166 DATA65,,65,65,,65,65,1,4,16,65,4,16,65,4,16,65,4,0
167 REM ---- SPRITE-5-"CROSSBOW"-----
168 DATA,,,,48,2,3,207,10,12,,232,52,,176,196,2,176,1,10,140,1,42,12,,104,12
169 DATA2,96,12,10,96,12,42,144,48,42,4,48,38,1,48,168,,192,160,3,,160,,,160,0
170 DATA,,,,,,,O: REM ---- SPRITE-6-"POTION"-----
171 DATA,60,,,255...255,,,44,,,56,,,40,,,154,,2,106,128,2,170,128,9,170,160
172 DATA10,170,160,9,170,160,10,170,160,10,170,160,2,170,128,,170,,,40,,,130,,,40
173 DATA,,,,,,0
174 REM ---- SPRITE-7-"DISTANT OBJ."---
175 DATA,,,,,,,,,,,,,,,,,,,,,,,,,,,,28,,,52,,,28,,,,,,,,,,,,,,,,,,,,,,,,,,,,,0
176 REM ---- SPRITE-OB-"TAKEN -----
177 DATA255,255,255,,,,,,,255,255,255,,,,,,,251,146,233,34,146,141,38,222,141
178 DATA36,88,235,39,214,134,36,82,137,36,82,137,36,82,233,,,,,,,255,255,255,,,0
179 DATA,,,255,255,255,,,0,0
180 POKE53276,252:POKE53285,10:POKE53286,2:POKE53269,255
190 POKE53287,1:POKE53288,01:POKE53289,0:POKE53290,12:POKE53291,6:POKE53292,6
200 POKE53293,5:POKE53294,0

Wish I still had the graph paper charts I used to figure out the math to make the sprites. Good times. I ignored learning Algebra to make those sprites.

 

[Iva Demilcol]

This is totally amazing!

Thanks for sharing.

 

[Imbarkus]

You could work up the binary conversion using graph paper alone (and din't have much choice but to do so) back in the day like so:

| 1 |   |   |   |   |   |   |   |
| 2 | 6 | 3 | 1 |   |   |   |   |
| 8 | 4 | 2 | 6 | 8 | 4 | 2 | 1 |
---------------------------------
| X |   | X | X | X | X |   | X |

Each column is a new factor (or something) in binary, or Base2 uh if that's still a thing, so when each unique column gets a pixel, you add the number from that column. Each combination of pixels results in a unique number in binary which is a unique decimal number between 1 and 256. Oof math from memory, should have paid more attention in class I guess.

Anyway, in example above:

128 + 32 + 16 + 8 + 4 + 1 = 189
So 189 describes an eight pixel line with the penultimate pixels on both ends clear. Then on to the next line.

C-64 spites could be the size of the Pac-Man like this guy showed, or also be double-size and thus half-res, you could double vertical-only, horizontal-only, or both. They were only ever one color but you would overlap a couple to make a multi-color sprite, IIRC.

 

[Dreamwriter]

Well, I meant machines that were kind of limited to that 2/4 colour tile method seen in the video. The machines you listed all have different colour models that are much more advanced

That's what I'm talking about too. Genesis can do 16 colors per tile, for example. GBA also had a mode for up to 16-colors per background tile, from 16 sixteen-color palettes. Quite a lot more colors than NES of course, but still limited and requiring special art skills to look good. GBA did have an unlimited 256-color palette mode, but the tiles took up twice the memory, so most games didn't use that (or mixed palette modes). SNES is similar, and even had a 4-color-per-tile mode. Neo Geo did 15 colors per tile (but the tiles could be stretched different ways to be different sizes).

 

[Purple Cheeto]

I kindof feel he shouldn't have mentioned the NES at all in the video, because that's a terrible explanation for nes graphics, given that it's entirely tilebased and the graphics data isn't even stored in RAM so most of what he says just doesn't apply at all

I'm trying to find in my book marks but I had a cool article where a guy breaks down on a tile basis how some of the color effects and graphics were achieved in Castlevania.

Edit: http://www.dustmop.io/blog/2015/04/28/nes-graphics-part-1/#terminology

This is probably a better technical explanation for NES graphics than this video.

 

[hateradio]

Simpler times weren't much simpler, were they.

 

[xir]

if anyone else is interested in this and a real NES head, pick up the book I AM ERROR from MIT Press, it's a deep dive into the guts and history of the NES/Famicom. Really digging it, even if when I gloss over the hexadecimals, now I really understand how ROB and the zapper worked

 

[Krejlooc]

Nice little video, though I'm not sure where he got the idea that tiles were called "color cells", they were (and still are) called tiles, both in magazines of the time (Compute!) and in official SDK documentation (at least for the Gameboy Color). BTW, the colors that can be displayed in one tile are known as a "palette" - the NES could display 4 colors per background tile (mostly...), so those 4 colors are a single palette, and it can display four palettes per screen (meaning, each tile can choose from premade color palette 0, 1, 2, or 3).

He's not talking about tiles, he's talking about color cells, also commonly referred to as attribute blocks which are independent regions of color palette mappings for the screen to draw. The guy uses poor examples to explain color cells, because the systems he demonstrates them with - C64, NES, etc - came from an era where color cells were typically self contained within a sprite object or tile definiton itself. Which is to say, for modern-enough systems, color cells and tiles are indistinguishable.

An example of a type of machine which has these blocks independent of drawn sprites is the ZX Spectrum. This is where color clash or attribute clash occurs.

 

[Krejlooc]

Perfect example of color cells vs sprites/tiles and the ensuing attribute clash:

 

[Weetrick]

This was great! Subbing to this thread in anticipation for Part 2!

 

[Gren]

That was great, it was explained in a way even I could understand. How little I truly know about the hobby I love so much.

 

[Vlaphor]

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.

 

[RM8]

This video has the side effect of explaining why so many indie games fail at nailing the retro look (and yes, I'm especifically talking about those who use words like "retro" and "8-bit" to describe their graphics).

 

[foxuzamaki]

This was pretty awesome.

 

[Hawk269]

That was pretty cool. Not a fan of the zoom in on his face...I think he zoomed the camera way too much, didn't need to see his nose hairs. lol

Looking forward to the other video's however.

 

[Imbarkus]

the systems he demonstrates them with - C64, NES, etc - came from an era where color cells were typically self contained within a sprite object or tile definiton itself.

The way I learned C-64 tile memory set also included the font or text for the system itself. I can't remember if this was my only option or just the easiest one (I seem to remember some sort of graphics mode that flummoxed me).

But because of this and because I was making a maze game I decided to sacrifice certain characters to use to make the maze pathway graphics. This worked fine but led to some awkward wording in the intro attract mode, which turned out to be as far as my coding skills would take me. I had to word everything without certain letters, though I don't remember which ones. V was used as a maze piece that also doubled as a period:

510 PRINT"ORCOLLE"
520 PRINT"+200 PTSV"
530 PRINT"AN ORCOLLE IS A SUBTERRA-"
540 PRINT"NEAN CREATURE DREADED BE-"
545 PRINT"CAUSE IT HAS SUCH POWER IN"
550 PRINT"BATTLEV IT ALSO HAS A HIDE"
560 PRINT"ALMOST AS IMPENETRABLE AS"
570 PRINT"ARMORV DESPITE THIS-IT IS"
580 PRINT"SLOW CREATURE AND ALWAYS"
590 PRINT"IS THE SECOND TO HITV"
592 FORFC=OT0400:GOSUB60000:NEXTFC
595 POKE53252,0:POKE53253,0:POKE53269,0:GOSUB1000
600 POKE53254,136:POKE53255,108:POKE53269,8
605 GOSUB60005
607 PRINT"SORCERTROLL"
610 PRINV+400 PTSV"
615 PRINT"SORCERTROLLS ARE THE CHIL-"
620 PRINT"DREN MADE BY THE HIDEOUS"
625 PRINT"SORCERER-DEMON TORMENTUSV"
630 PRINT"THEY ARE NOT COMPLETELY"
635 PRINT"MATURE AND SHOW LOW POWER"
640 PRINVAND SPEEDV ON OCCASION-"
641 PRINT"THEY ARE ABLE TO CAST A"
642 PRINT"POWERED-UP DEATH SPELLV"
643 FORFC=0TO400:GOSUB60000:NEXTFC
645 POKE53254,0:POKE53255,0:POKE53269,0:GOSUB1000
650 POKE53256,136:POKE53257,108:POKE53269,16
652 GOSUB60005
655 PRINT"SCUTTERLASH"
660 PRINV+300 PTSV"
665 PRINT"THE SCUTTERLASH-ALBEIT NOT"
670 PRINT"A CREATURE OF POWER-IS A"
675 PRINT"DREADED CREATURE-MAINLY"
680 PRINT"DUE TO ITS SPEEDV IT AL-"
685 PRINT"WAYS LEAPS INTO BATTLE"
690 PRINT"PRIOR TO ANY OPPONENTS AND"
691 PRINT"CAN HIT AN ENEMY AND LEAP"
692 PRINT"CLEAR-BEFORE THE ENEMY CAN"
693 PRINT"TRY TO HITV"
694 FORFC=OT0400:GOSUB60000:NEXTFC
695 POKE53256,0:POKE53257,0:POKE53269,0:GOSUB1000
700 POKE53258,136:POKE53259,108:POKE53269,32
702 GOSUB60005
705 PRINT"CROSSBOW"
710 PRINT'1+50 PTSV"
715 PRINT"TO ENCOUNTER A MYSTIC"
720 PRINT"CROSSBOW IS THE ONLY"
725 PRINT"MEANS OF ARMAMENTV EACH"
730 PRINT"CROSSBOW CAN BE USED UP"
735 PRINVALL AT ONCE AS A MYSTIC"
740 PRINT"BLAST BOLT OR CAN BE USED"
741 PRINT"SEPARATELY-EACH CROSSBOW"
742 PRINT"WITH 7 NORMAL BOLTSV MYS-"
743 PRINT"TIC BOLTS ALWAYS DESTROY"
744 PRINT"CREATURES THEY ARE FIRED"
745 PRINT"ATV"
746 FORFC=OT0400:GOSUB60000:NEXTFC
747 POKE53256,0:POKE53257,0:POKE53269,0:GOSUB1000
750 POKE53260,136:POKE53261,108:POKE53269,64
752 GOSUB60005
755 PRINT"POTION"
760 PRINV+50 PTSV"
765 PRINT"POTIONS RESTORE HEALTH"
770 PRINT"LOST IN BATTLEV THE AM-"
775 PRINT"OUNT RESTORED IS ALTERED"
780 PRINVEACH TIME BUT POTIONS"
785 PRINT"WILL NOT DETRACT HEALTHV"
790 PRINT"YOU MAY ENCOUNTER POTIONS"
791 PRINT"WHILE COMPLETELY HEALTHY-"
792 PRINT"BUT YOU WONJT USE THEMV"
795 FORFC=OT0400:GOSUB60000:NEXTFC
796 POKE53258,0:POKE53259,0:POKE53269,0:GOSUB1000
1000 PRINT""
1100 FORFC=OT015
1200 PRINT""
1300 NEXTFC
1400 RETURN
1500 PRINT"A LAND IN PERIL&&&&&&&&&&&&&&&"
1505 GOSUB60005"
1510 PRINT"ONCE-IN A DISTANT LAND
1520 PRINT"CALLED MALAMAR-THERE WAS"
1530 PRINT"PEACE AND CONTENTMENTV ALL"
1540 PRINT"WERE HAPPY AND THE PRINCE"
1550 PRINT"RULED WITH A FAIR HANDV"
1560 PRINT"IT WAS A LAND LIBERATED OF"
1570 PRINT"ALL FEARVVV UNTILVVV"
1590 FORFC=OT0400:GOSUB60000:NEXTFC
1595 GOSUB1000
1597 GOSUB60005
1600 PRINT"HE CAME FROM UNDER THE"
1610 PRINT"EARTH WITH A HORDE OF HID-"
1620 PRINT"EOUS CREATURES BEFORE HIMV"
1630 PRINT"HE WAS TORMENTUS-A CRUEL"
1640 PRINT"SORCERER-DEMON WITH IN-"
1650 PRINT"CREDIBLE POWER- AND HE"
1660 PRINT"ROBBED THE LAND OF ITS"
1670 PRINT"PEACE AND FREEDOM AND"
1672 PRINT"STRIPPED IT OF ITS PROS-"
1674 PRINT"PERITY-AND NONE COULD STOP"
1676 PRINT"HIMV"
1690 FORFC=OT0400:GOSUB60000:NEXTFC
1695 GOSUB1000
1697 GOSUB60005
1700 PRINT"AND NOW YOU-THE PRINCE OF"
1710 PRINT"A RUINED LAND-STAND BEFORE"
1720 PRINT"THE ENTRANCE OF HIS FORT-"
1730 PRINT"RESSV AHEAD-YOU FACE LABY-"
1740 PRINT"RINTHINE CORRIDORS-MYSTIC"
1750 PRINT"SPELLS OF IMMENSE POWER-"
1760 PRINT"AND FIFTEEN FLOORS OF AB-"
1770 PRINT"SOLUTE HORROR-EACH WITH"
1772 PRINT"ONLY ONE WAY OUTV"
1790 FORFC=OT0400:GOSUB60000:NEXTFC
1794 GOSUB1000
1795 GOSUB60005
1800 PRINT"YOU WILL NEED ALL YOUR"
1810 PRINT"MUSCLE-ALL YOUR MIND- AND"
1820 PRINT"ALL YOUR SPEED- PLUS A"
1830 PRINT"LITTLE HELP FROM FATE-TO"
1840 PRINT"BEAT THIS TESTV BUT MAYBE"
1850 PRINT"YOU CAN SUCCEED- MAYBE YOU"
1860 PRINT"CAN ASSEMBLE THE MYSTICAL"
1870 PRINVINCANTATION NEEDED TO DE-"
1880 PRINT"STROY TORMENTUSV MAYBEVVV"
1890 FORFC=OT0400:GOSUB60000:NEXTFC
1895 GOSUB1000
1900 RETURN

 

[Krejlooc]

The way I learned C-64 tile memory set also included the font or text for the system itself. I can't remember if this was my only option or just the easiest one (I seem to remember some sort of graphics mode that flummoxed me).

But because of this and because I was making a maze game I decided to sacrifice certain characters to use to make the maze pathway graphics. This worked fine but led to some awkward wording in the intro attract mode, which turned out to be as far as my coding skills would take me. I had to word everything without certain letters, though I don't remember which ones. V was used as a maze piece that also doubled as a period:

So there are a few ways to display "sprites" on the C64, and one of the ways, which you apparently used, was to overwrite the system character map which subjects you to attribute clash. Lots of earlier C64 games had this problem. This has an added side effect of giving you, essentially, unlimited "sprites" (although they're not really sprites). This is the single easiest method of getting something outputted to the screen, as the memory that the character map occupies is easily accessible and can be overwritten with ease. In this mode, each "tile" is actually an 8x8 character, displaying on the screen at character-width spacing (i.e. 8x8 tiles). Systems like the MSX used this in games like Gradius, resulting in character width scrolling (a very common complaint - in other words, the background scrolls 8 pixels at a time, not 1 pixel at a time). This basically limits you to a giant 8x8 display.

Now, some ancient PC games used this mode to display really awesome graphics, exactly like I explained. Paku Paku is the single best example of this - it's a CGA demo that uses the 1-bit big text display mode in order to display way more colors than a CGA graphics adapter should be able to, treating the display in 8x8 chunks:

Extremely blocky looking, but it looks so much better than stereotypical awful CGA graphics:

(NOTE:This CGA trick actually uses a CGA specific work around to the problem - in this particular display mode, which lets you access every color the CGA display could work at once, text characters are essentially halved and grouped together (i.e. each character is actually 8x16 big). The 1-bit flag selects between two colors. What they did in this instance is divided the individual characters up in half, treating each as 2-pixels wide. They then overwrote the character map to include every single possible 2-pixel wide combination (i.e. 1 blue 1 yellow pixel, 1 blue 1 green pixel, 1 blue 1 red pixel, 1 blue 1 white pixel, 1 blue 1 black pixel, 1 yellow 1 blue pixel, 1 yellow 1 red pixel, 1 yellow 1 green pixel, etc) then figured out where they should apply on the character map by examining an internal "framebuffer.")

EDIT: Interestingly enough, Paku Paku has also been ported to the C64, using the exact same character-width "sprites." It doesn't need to do the double pixel stuff, however:

The other way, and they briefly touch upon it in the video, is to use the actual sprite hardware in the C64 to draw a sprite directly to the screen, which is not subject to attribute clash (as each sprite has it's own attribute block), but the major limiting drawback of this is that the C64 can only display 8 hardware sprites at once.

What this lead to was sprite multiplexing which is a way of dividing your screen realestate up into horizontal bands that update the sprite information on the fly. There was a common half-method that was taught in many magazines called Zoning that works as a precursor to true sprite multiplexing.

Essentially, you'd draw a complex object like so:

The fist from turrican - turrican doesn't use zoning (it uses a complex multiplexer) but the fist is a great example of a sprite that could be accomplished by zoning. If you look up the sprite id of each "tile" that makes up the fist, it would be mapped like so:

45678
45678
45678
45678

This is simple and easy to understand - as the raster line moves between "zones" of the sprite (i.e. 8 vertical lines, or every 8th hblank) you rewrite the tile information for those 5 tiles, so that it looks like you're drawing many different sprites, when you're really only drawing the same 5 sprites over and over again, just with different tile information.

The downside of this is that you can't do vertical movement while this occurs, or else the "count" of the "zone" will be thrown off. This only really works for horizontal scrolling objects.

True sprite multiplexing involves quite a bit of quick sorting, but the idea is to order all your draws for sprite objects from top to bottom such that the raster line will always be drawing new tiles as it reaches the end. This imposes a hard limit of 8 sprites per raster line (this is actually where future systems, like the NES and Sega Genesis and SNES and all that stuff gets their sprite per raster line limit from - those systems included sprite multiplexing in hardware).

Thus, your steps for sprite multiplexing are as follows:

1) Order all "sprite" objects (a block of memory, not an actual physical sprite) from top to bottom according to Y position
2) map "sprite" object to 8 physical sprites as they pass through horizontal band of raster line

This type of sprite multiplexing wasn't taught in magazines, it was picked up from demoscene, but a popular example of a game that uses it would be Ghouls n Ghosts. It's typical to see scenes that look like this:

Each bird and arthur are made up of two sprites, hence it is actually displaying 8 sprites for characters (3 birds X 2 = 6, plus 2 for arthur) plus 2 sprites for the guiotines, plus 1 sprite for the lance, meaning it's drawing 11 sprites at once.

Ordered, it draws them like so:

You can see the order reads from left to right, up to down. This is much more difficult than Zoning, because the "virtual" sprite can be made up of different physical sprites on any given frame. How quick you can sort and map the physical sprite objects determines how well your program runs. To demonstrate how sprite multiplexing is different from zoning, let's consider an example - say one of those birds didn't exist. The mapping would then go as follows:

See in one example, the arthur sprite on screen is made up of physical sprites 7 and 2 in one frame, and in the other example he is made up of physical sprites 5 and 8. Depending on the situation, and what is on screen, the physical sprites that make up the object can change on the fly. This is what sprite multiplexing does - it arranges the physical sprites between hblanks such that the process is invisible, both to the end user and to the programmer (they feed "virtual" sprites that they set up into a process they write to do the multiplexing). With Zoning, which physical sprites make up the "virtual" sprite never change.

Like I said, ultimately, this method became dominant and built into hardware, and virtually every 2D system afterwards used a similar multiplexing method. The number of draws hardware can do per raster line clues you in to how many physical sprites it can draw at once.