You have a point with mentioning other consoles.  I'll just go ahead and consider this an 8K game or whatever it would need.  A game like this is unorthodox for the Atari 2600 to begin with (unless you count the Swordquest games) so I can probably consider this a game that would have been bigger and premium of back then.

Thanks for the compliments as well.

Kasumi makes good points about Nes game capacities over the life of the console and the parallels with regards to added hardware. Please don't think I totally disregard authenticity or the impressive accomplishments of those that have made 4K games I just think the minimum size is way too confining and I am most pleased to see you mention 8K as a ROM size option since many a 2600 project benefit greatly from this simple upgrade.

Just saw your name change, I like the new name HughSpectrum but I had a lot of fun speculating about what a "Kittenmaster" would be.

Camp screen.  Heart = HP, S = Strength, I = Intelligence, D = Dexterity.  Made the stat scale so that only one digit would need to be kept track of for each stat.


Combat screen.  I originally envisioned a lineup of Player 1 sprites and the enemies being Player 2 sprites on the right, but I figured this setup would make it so that the 2600 wouldn't have to keep track of as many enemies and their stats.

Wow looking good, you're like a duck to water with this 2600 work. So much of what I do is exploring the inside of the box that is the 2600 but only a small percentage of my posts have ever been said to be plausible. I can't say for sure you'd get a programmer collaboration at AtariAge but based on your approach I don't think it would be rejected as an impossibility to actually make.

Missile sprite for showing whose turn it is, and I envision damage done for physical attacks being a simple animation and a missile sprite being flung towards a target, and "DAMAGE #" on top of the screen.  Magic would be larger missiles, and the background flashing colors while it's flung.

The icons are for the Cleric, and they're Attack, Turn Undead, Magic, and Inventory.

I altered the Lizard image a bit and moved his right leg to our left a bit.

EDIT: Fixed an unintended error on the lizard image.

Well that all sounds great, you're really grasping the limitations and object alignments very well towards leveraging your sprite objects.

I'm afaid I don't have much critique at this point because I can't wrap my head around the restrictions from the other thread, yet. But I do consider this to be pixel art (to an even greater degree than working on 8-bit spec systems, even) and I see no need for this to be moved to low-spec at all. I doubt I'll be able to understand what's going on here, but I wanted to say that 1. I am trying and 2. the information and dialogue between you two is a benefit to all Pixelation users to come that will be interested in the 2600. Very glad to see the knowledge drop.

First I'd like to say thanks for your endorsement as I am a big fan of your work and I'm glad you approve of its status as pixel art. Yes the 2600 is quite foreign to every other platform on this forum that people have drawn mockups for. Sorry I probably skipped over too many basics on 2600 pixel rendering than I should have but I think I was just anxious to get to the meat of the subject or the application of the sprite objects towards common pixel art tasks.

I would say most of time 2600 pixel art critiquing lies in the basics of implied form or the iconic shape, the best possible arrangement of pixels from abstract to the clear intentions of the form within imho. Although I am trying to find ways to inject 2600 graphics with more shading depth and traditional pixeling techniques that more typical CCs can be made.

Inspired by BladeJunker's thread, I decided I wanted to try and make a mockup within Atari 2600 restrictions.  If this isn't considered true pixel art (and I can see why it wouldn't be) go ahead and move it to Low-spec or something.

You and me both on where to put 2600 stuff, hard to say where to file it?

The mockup is inspired by Strategic Simulations' AD&D games where map navigation is on a first person view, and baddies walk up to you before you go into combat (which is a separate screen which I haven't tried to draw yet).

I'm not familiar with the inspiration so I'll have to look into that. I will say that separation of activities into different screens or modes is something I can recommend for any 2600 game since the lack of drawing units is not unlike a polygon limit in that isolation and concentration of rendering power to one focused subject matter will reap rewards.

I'm hoping to make sure the restrictions work out so hopefully BladeJunker will comment here.

The restrictions look to me that they will work, 2 line kernel Playfield render with per scanline color changes. You're a lot more conservative than I was when first started trying this stuff out, I went overboard so many times.

Not a bad choice clipping the background for the sake of changing the monsters color scheme as its a good method to get familiar with. However you're already so trim with your rendering use you could probably use a mid-line color change within the middle 16 pixels of the Playfield and preserve most of background on the sides and use any of the movable object sprites to fill in the remainder of your background clipping losses.

Another option is to render the monster using both Player objects as an overlay stretched to maximum width, if you don't need any Missile bits within that vertical zone this would completely avoid any background clipping issues. Since your backgrounds are mirrored using Player objects for the monster would avoid the extra costs of drawing an asymmetrical Playfield to insert the monster tile made of Playfield pixels.

Designed this so that the sky color can change and still look alright on daytime sky colors (also I just realized that I didn't adjust the colors on my desktop computer so the colors will most likely change).

Sounds good, plenty of color shifting routines on the 2600. As far as the colors being off its the same old story of NTSC or Never The Same Color, most posts on AtariAge tend to vary between emulator results and changes needed when running on actual hardware plus NTSC and PAL differences. Manual tweaking at actual run time isn't so bad since we're not using that many colors to begin with.

This was fun to do.  I'll probably have to make improvements in readability for the armor.

I think I'd recommend trying for more iconic readability as large chunky pixels turn into noise very easily, might want to try one color first for composition and then consider color zones afterwards with some tweaking. I saw some good examples by Pac-Man-Red over at AtariAge on utilizing per scanline color changes, he's quite good at drawing sprites in general and he often draws within a 2 line kernel resolution. Here take a look.http://www.atariage.com/forums/topic/169238-free-sprites-for-the-taking/

Not sure what I want to do about the HUD at the bottom.  Not even sure what I want to put there to begin with since imitating the full statistical gameplay is out of the question.

EDIT:

I'm looking into HUD/stat related limitations soon so I'll post that under my discussion asap. You're right to be doubtful about full statistical tracking as the 6502 CPU is limited in speed but any kind of turn based gameplay should help so it only has to do 1 or few things at a time.

Anyway looking good in my opinion.

I know that the 2600 is different from other consoles and that it's on a per-scanline basis instead of a per-screen one, but I'm still failing to grasp what is actually going on in your example.  Are you telling the 2600 to draw the player sprite's line again with different data and then on the next scanline starting from the leftmost sprite again, or are you changing the data of the player sprite when going to the next instance of a copied sprite?

I am thinking of just making a note in my summary about things changing within scanlines.

Please show mercy, no more questions. JK

The 3 copies possible with both Player objects and Missiles are guaranteed horizontally, you set a gap distance and the number of copies to 1, 2, or 3 and it draws every copy wanted with a single pass of all the scanlines the sprite occupies within its height. Changing sprite data in Frogger is done within isolated vertical sections of the screen or lanes of any height(Your choice on the height of the vertical zones as its defined by the Player objects height.).

The only instance where you have 2 or more passes of the same scanline involving the same sprite object is when you multiplex flicker one Player object to draw 2 or more different sprites within the same vertical zone or when you draw the same sprite but along the same scanlines at random distances from each other EG. Pac-Man ghosts move independently through the maze so they can't keep a set distance from each other within the same scanlines so they are rendered using multiple passes instead of one like fixed distance copies do.

Its usually costly to change things per scanline thus the vertical isolation and stacking layouts common to 2600 games. I've been mostly trying to work around this limit since it restricts the types of games you can make, how many variations on Pong and Kaboom can the human race endure?