Intellivision Pixel Art Guide.

[BladeJunker]

Well I haven't given up on my Atari 2600 pixel art guide I just needed a break from it so I decided to try one for the Intellivision since its much more straight forward from an artists perspective and the INTV could use some new games if anyone is inclined to propose a mockup.  

The screen resolution is 160X192 but since the scanlines are doubled its 160X96 in practice. If you want to use any double tall resolution graphics you'll have to use a 320X192 canvas instead.

Yeah its pretty tight as resolutions go but I think many lo-fi artists could have fun here.

I guess your best references at this point in time would be the Atari Lynx, Game Boy Color, Game Gear, or any of the other portable with low resolution screens. This should help with understanding on how to get the most of layout designs with so little resolution.
Other close cousins to Intellivision would include the SG-1000, TI-99/4A, Colecovision, ZX Spectrum, really any platform with 1-bit color sprites & tiles. I try to find similar platforms whenever possible which gets harder the further back you go since hardware costs were tight back then that you really see a splintering to a myriad of seemingly bizarre setups compared to the tilemapping we know and love that became a standard (EG. 2600 & Apple II, quite unique to say the least.).


There is scrolling for both the X & Y axis so this will help with the tight constraints of the screen resolution.

The graphics are split into 2 distinct groups of GROM & GRAM. GROM is a 214 character table that includes a font and many common tiles used in most games. Why 214 instead of 256? Well space was skimmed off for the EXEC ROM, those noise tiles are actually funny enough program code. Apparently B-17 Bomber ran out of sprite space and used those noise tiles of program code for explosion sprites. Regardless GROM is pre-programmed on an EPROM within the console so it can not be altered.

Here's the GROM table. If you've seen an INTV game you've seen these characters.

Just a partial glance you can see all the usual bordering tiles used to form level graphics like corners,straights, diagonals. You have basic control over the GROM characters to make them either game sprites(opaque & alpha) or background tiles(2 colors opaque).

I should give you the hexidecimal map for the GROM.

The noise or program code tiles aren't listed here, I can't say for sure if they are stable in pattern.


And the GRAM. Sorry I had this all wrong initially.

The GRAM is 64 individual 8X8 or 8X16 sprites or "cards" meaning all animation isn't confined to a single 64X64 image page which is great since that would have been seriously hard to deal with. So the number of cards used total is the true limit while animation per card is a secondary lesser concern, this means in the case of sprite rotation states each rotation equals an individual card per visible state on screen rather than each state belonging to a single image file. While you can mirror a GRAM or GROM card as a foreground sprite a background can't thus the L,R,U,D instances of the same tiles in the GROM.
For another example in a platform game the main player sprite could be confined to 1 or 2 cards depending on size since its animation is confined to a single visible entity while enemy sprites can and will differ in animation even with copies of the same sprite, therefore each animation seen equals an individual card so differing animations can be seen at the same time.
The GRAM card Foreground Background system has its limitations but it seems like an elegant solution for the time period with both sprites and tiles getting a crack at those 64 cards plus animation can increase or decrease per card at multiple frame rates rather than image page divisions among multiple characters.


The INTV is fairly capable for animation for its time as the infamous "running man" had a whopping 7 frames in his cycle so unless you're doing Prince of Persia or Street Fighter 3 I think moderate animation frame limits should work.


Best sprite I could find which has a 2600 Waterworld guy behind him, not a lot of vintage sprites to find I'm afraid.


Here was my initial inquiry into INTV performance, a treatment of Gauntlet.

A pretty savy programmer DZ-Jay gave me some INTV info but what surprised me most was that he questioned my plans to use the GROM characters so much as my Gauntlet spec plan barely used any GRAM, in my defense I didn't realize the GRAM was 64 individual sprite files so I had taken an extreme approach at saving what little image space I thought I had( The now defunct 64X64 sheet, again sorry.).
Still that inquiry really opened my eyes on what the INTV can do as layering and double resolution sprites didn't seem like such an extreme expense anymore. So while I can still recommend using the GROM characters whenever possible the use of GRAM for background tiles isn't as restrictive as I thought.
Back to Gauntlet, some things in my plan sounded possible primarily the use of background cycling to create the monster bunching which I gleaned from the Nes port on how to produce so many monsters with so little sprites. I truncated the HUD to a smaller trimmer layout, I had tried the full original density but it was too big and dominant to the main game space. I might stick with the Bird's Eye perspective to keep the number of rotation states minimal if it can aid in layering in more colors but if it doesn't I may change to a Top Down perspective for increased visual depth.

Actually congrats to DZ-Jay's homebrew, its out of testing so its practically done and I guess carts will be produced soon.
http://www.techunlimited.net/xmas_carol/story.xhtml
Here's some teaser trailers for Christmas Carol.
http://www.atariage.com/forums/topic/196380-christmas-carol-teaser-1/
http://www.atariage.com/forums/topic/196562-christmas-carol-teaser-2/
http://www.atariage.com/forums/topic/196869-christmas-carol-teaser-3/


Here is the 16 color palette of which all can be used at once on screen. The friendly person who directed me to this RGB bitmap said flatout that it was not accurate, N(ever)T(he)S(ame)C(olor) analog strikes again. Still there is only 16 colors that even if they are off we're not talking fine gradients here since the color palette is saturated and mostly split into primary colors.

Its close enough you can make most of the broad assumptions everyone does when looking at a color palette. As you can see it includes the usual suspects of primary colors, B&W, Medium Grey, some Fleshy earth tones, and 2 Magentas since the real world is full of magenta.  


Despite layering costs I thought I'd put the palette through its paces. Some gradients have good contrast others not so much. Black works as a "go to" color for shadows but in some ways you're better off going for a hue approximation with brighter and darker shades of differing color. Overall a very saturated palette not unlike a Crayon box that does a decent job of covering most basic game settings and character sprite color needs.

I think anyone familiar with ZX Spectrum pixel art will likely be pro-efficient at drawing anything for the Intellivision as the same 2 colors per block rule applies. Other connections lay in ANSI style art as well since level construction especially games that involve a series or art slides(Adventure genre) built with blocks graphics aids in the compression of the game overall. Also if you've done the work of layering NES sprites to exceed 3 colors you're more than ready to try 2 or 3 color Intellivision sprites.

There are some palette restrictions, I haven't been able to wrap my head around it yet but I don't want to misinform so here's some info.
http://wiki.intellivision.us/index.php?title=STIC#Moveable_Objects



Sprites are in 1bit color so opaque and alpha.

-Sprites can be 8X8 or 8X16 individually or stuck together to make larger sprites.

-The default is 8 sprites or MOBs per screen. Fun Fact: Marketing forbid multiplexing of sprites on the INTV initially because it caused flicker, this didn't last fortunately and games like Space Armada, Star Strike, and Tron Solar Sailer broke this rule.

-Because of hardware limitations the only way to increase the number of colors in a game sprite is to layer sprites which is easy to do. The main drawback of this is the expense in cards and MOBs.

-Stretching: Horizontal (1× or 2×) and vertical (1×, 2×, 4× or 8×)

-Something unique to GRAM is that you can draw sprites double tall and use the 192 scanlines the GROM is incapable of using. The cost of this is 2 cards per 8X8 block as one double tall card will only cover an 8X4 dimension onscreen.

-Mirroring: Horizontal and vertical


The Atari 2600 has the Harmony Cart and the Intellivision has the Cuttle Cart 3.http://www.schells.com/cc3.shtml They both represent the easy way to develop homebrew since you can revise the game ROM with updates without burning through actual cart ROMs. Anyway nothing new here as there is the EverDrive among other commercially available flash carts.

Also found something called a Intellicart which actually does incorporate bank switching for more expansive games, it appears to be made by the same guy Chad Schell. http://wiki.intellivision.us/index.php?title=Intellicart

Here's a modern homebrew called DK2 Arcade that Elektronite is making.http://www.elektronite.com/d2k.htm


http://www.youtube.com/watch?v=-N1b7R4s6G0&feature=player_embedded#!


I know the INTV controller is less than comfortable but we're starting from scratch here so why not turn the controller on its side, man that feels good.

It won't help existing INTV games but any homebrew can just flip the inputs around EG. Up=Right or Fire1=Start & Fire2=Select, etc. .
I posted the subject and got mostly positive feedback as well as some tips for operating the INTV more comfortably in its vertical position.
http://www.atariage.com/forums/topic/196230-intv-controller-sideways/

Yeah the button symbols don't line up but we could just cover that with an overlay graphic designed for horizontal orientation instead of vertical.


Other than a few non common screen modes I'll add here when I can understand them and discussing color techniques I think that covers it. I just started delving into this hardware so I'm not sure how much is left to say. Anyway if you appreciate video gaming roots perhaps you'll give this restriction limit a try.  

[Helm]

Again, thank you so much for the info. This is one of the main reasons pixelation's here for.

[BladeJunker]

Again, thank you so much for the info. This is one of the main reasons pixelation's here for.

Hey no problem, if I can't find much to anything on a subject might as well post what I find.

[Player 3]

Having grown up with an Intellivision (along with a Genesis), it feels great finding some form of graphical standards for this. Just lacking a Cuttle Cart.

Anyway, I whipped up some mockups and am wondering if they'd fit in with the restrictions of the Intellivision.

[BladeJunker]

Having grown up with an Intellivision (along with a Genesis), it feels great finding some form of graphical standards for this. Just lacking a Cuttle Cart.

Anyway, I whipped up some mockups and am wondering if they'd fit in with the restrictions of the Intellivision.

Neat stuff, I actually saw this first at the "Please say this is going to be a game" thread on TIGForums. Actually could you let me in on the joke you alluded to in that thread?
http://forums.tigsource.com/index.php?topic=7091.4710

Well it looks reasonable enough to me, even at 16X16 per fighter I think the INTV is more than capable to run this. Both fighters together would be 4 MOBs(sprites) with 4 to spare for anything else (fireballs/spectators).

It makes me think of SF2 Anime with Ryu and Sagat fighting in the field, although its sunny so maybe SFA1 fighting Bison idk.

[Player 3]

The joke? Not really, but to see who can memorize an Intellivision game by the title screen. Plus I managed to get my mockup title into part of the program itself.

Before:

After:

The GRAM is 64 individual 8X8 or 8X16 sprites or "cards" meaning all animation isn't confined to a single 64X64 image page which is great since that would have been seriously hard to deal with. So the number of cards used total is the true limit while animation per card is a secondary lesser concern, this means in the case of sprite rotation states each rotation equals an individual card per visible state on screen rather than each state belonging to a single image file. While you can mirror a GRAM or GROM card as a foreground sprite a background can't thus the L,R,U,D instances of the same tiles in the GROM.

And reading through this, it's hard to kind of see what you mean. So it's possible to have any amount of these 64x64 (or 512-bytes) images, but only enough to fit one can be visible at the time? And I see that only foreground sprites can go with rotations, while background ones can't.

[BladeJunker]

The joke? Not really, but to see who can memorize an Intellivision game by the title screen. Plus I managed to get my mockup title into part of the program itself.

Lol okay that is funny, yeah I don't know where the standardized INTV title screen came from but it was probably a space saving effort. Still custom approaches to title screens and menus aren't restricted unless you absolutely want your ROM sizes the same as they were back in the day.

Before:



After:

Very cool, did you use a premade code setup or do you know Assembler?

The GRAM is 64 individual 8X8 or 8X16 sprites or "cards" meaning all animation isn't confined to a single 64X64 image page which is great since that would have been seriously hard to deal with. So the number of cards used total is the true limit while animation per card is a secondary lesser concern, this means in the case of sprite rotation states each rotation equals an individual card per visible state on screen rather than each state belonging to a single image file. While you can mirror a GRAM or GROM card as a foreground sprite a background can't thus the L,R,U,D instances of the same tiles in the GROM.

And reading through this, it's hard to kind of see what you mean. So it's possible to have any amount of these 64x64 (or 512-bytes) images, but only enough to fit one can be visible at the time? And I see that only foreground sprites can go with rotations, while background ones can't.

I guess this description needs revisement. Okay each card is 8X8 or 8X16 pixels not 64X64 and there are 64 cards total with cards being individual image files not a sheet, I added spaces to the visual example to imply division in the files so it wouldn't look like a sheet. I guess a good analogy would be that a INTV Card is like an animated GIF with all the animation frames contained within but belonging to itself like a container. If you had a directory of cards they would be several files not one, hope I'm driving that point hard enough.

The issue of increased card use comes from having sprites animate differently from each other on screen such as one walking and one attacking would use 2 cards instead of 1 even if its the same enemy sprite. If they all moved in unison that would only require one card regardless of the number of copies used on screen. Its mostly an issue of enemy sprite needs since they would be cycling multiple GRAM cards almost constantly while a single main player sprite can swap between animations using one single card.

In regards to rotation states in foreground active sprites you have horizontal and vertical flopping which would allow an 8 state rotation of a Top Down sprite to only need 5 states but to achieve the same thing with a Background tile would require the full 8 rotation states since it can't flop. In this regard the INTV is more optimal with pure Side or Top views while Top Down or Isometric perspectives are harder to achieve as they require fewer total on screen units to make up for the number of GRAM cards consumed at any given time.
Actually Top Down and Isometric views would probably be best served through approximations using the GROM characters in an ANSI style manner, someone suggested Prince of Persia INTV at AtariAge and I've been trying to make basic environmental graphics using GROM characters mostly to free GRAMs for characters and items better served with custom graphics.

[BladeJunker]

Well I thought I should try ANSI based images for the INTV to see if it would work and it did, kinda.

First I'll credit enz0 for this fine ANSI art.

I started with the assumption I could use existing GROM characters at least partially with some added shapes & dither blocks through the GRAM. For the most part it works but the scale of block is so large to the screen scale I ran out of space quickly and the cells looked quite macro.


So I reduce the cell size to 2X2 pixels which gave me enough screen space to fit the entire image in. Some characters didn't work at 2X2 (Big surprise.) but for the most the basic ANSI blocks look okay. The biggest thing here is the increase in GRAM use from the reduced cell size which reduces the degree at which 8X8 pixel blocks can be tiled repeatedly. To decrease the number of image flops used in GRAM when set as Background Cards I'd likely make blocks with the highest degree of re-usability Foreground sprites so I can flop them horizontal and vertically.


And here I went for broke and increased height resolution to the dither related blocks for a more crisp picture. Overall except for the first try its not very ANSI in rendering setup, what we really have here is an ANSI style image which will be broken down into a tile set that will vary from image to image rather than using a single character table. Still it should offer a least some image compression and fit into the 64 card limit better since there isn't enough GRAM cards to fill every grid space with a unique character and the GROM characters alone can only offer more abstract images overall. Definitely need some kind of editor and converter program as this would be tedious to transpose manually.


Not sure who composed this, "Ask the Whale" was my only clue.

Anyway more basic and angular but at 4X4 pixel cells it should produce a much smaller tile set on average per image being 1/4 of the default cell size (8X8 pixels) compared to the 1/8(2X2 pixels) of my finer detail example.

[Player 3]

Very cool, did you use a premade code setup or do you know Assembler?

A bit of assembler, actually. It's not as scary as 6502 assembly, shockingly enough..

And I come bearing gifts.





It should also be noted that Sears Super Video Arcades, Sears's Intellivision clone, has its own EXEC.BIN that erases all text from the fourth and fifth rows from the top.

[BladeJunker]

Very cool, did you use a premade code setup or do you know Assembler?

A bit of assembler, actually. It's not as scary as 6502 assembly, shockingly enough..

And I come bearing gifts.





It should also be noted that Sears Super Video Arcades, Sears's Intellivision clone, has its own EXEC.BIN that erases all text from the fourth and fifth rows from the top.

Yeah native 6502 coding is tricky I've heard but its the only way to push the 2600 harder, less abstraction layers. Still the 16-bit CPU in the INTV should offer a little leeway in code structure having more muscle.

What a lovely gift it is too, you should add an exclamation point to the title to complete the sentiment. I really like the basic layout and colors, I find it relaxing to look at and it feels just right for fishing. Even though I like the Orange I think maybe you should switch the fisherman to Yellow as his hue matches the sky hue so he's blending in instead of popping.

Oh Sears why did you do that? Well that is a good chunk out of the font losing most of the lowercase and a bit of uppercase plus some useful symbols, that does put more burden on the GRAM to fill them in order to support the Sears Super Video Arcades(What a mouth full lol.). Damn what an annoying variable but I'm still glad you brought that to my attention so thank you.