Pixelation
Critique => Pixel Art => Topic started by: HughSpectrum on March 11, 2012, 05:00:27 am
-
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.
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 hoping to make sure the restrictions work out so hopefully BladeJunker will comment here.
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).
(http://i.imgur.com/VIAud.png)
This was fun to do. I'll probably have to make improvements in readability for the armor.
(http://i.imgur.com/tnkJ4.png)
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:
(http://i.imgur.com/44vu7.png)
-
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. :lol:
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).
(http://i.imgur.com/VIAud.png)
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.
(http://i.imgur.com/tnkJ4.png)
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/ (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:
(http://i.imgur.com/44vu7.png)
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. :)
-
Good timing, I've already been working on the readability of the lizardman some more.
(http://i.imgur.com/lKdDd.png)
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.
Preparing in advance for if I need to use sprites and whatnot to convey information needed elsewhere. Plus I'm not that concerned about the background.
How are high scores rendered anyway?
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.
It's actually more of an issue of my laptop's colors being off compared to other displays, which causes me to require changing the colors later after working with it (such as brightening a couple of colors on the lizard).
-
Good timing, I've already been working on the readability of the lizardman some more.
(http://i.imgur.com/lKdDd.png)
Looking good, I can make out the face, loin cloth, and boots quite well. I don't quite understand the armor visually, I see gaps from the color changes, are you thinking of filling those gaps in the the lizardman with Missile pixels?
Preparing in advance for if I need to use sprites and whatnot to convey information needed elsewhere. Plus I'm not that concerned about the background.
How are high scores rendered anyway?
I looked up your inspiration a bit, are you thinking of using the clipped background for HUD space and create a couple icon stacks on the left & right of the screen since that would work well?
2 common high score rendering setups include Playfield based numerals but they are kind of big that not much else will fit next to them, the other is often called the SCORE method which uses a multiplexing of Player0 and Player1 each making 3 digits but it can't do much more than 6 digits total and nothing else can occupy its scanlines since the kernel is quite demanding by itself.
It's actually more of an issue of my laptop's colors being off compared to other displays, which causes me to require changing the colors later after working with it (such as brightening a couple of colors on the lizard).
Idk maybe a conversion table, I'm not sure how to resolve differences between the displays of 2 work stations but I'm sure somebody must know something about it. :)
-
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.
-
Looking good, I can make out the face, loin cloth, and boots quite well. I don't quite understand the armor visually, I see gaps from the color changes, are you thinking of filling those gaps in the the lizardman with Missile pixels?
Nope. They're meant to be "reflective" of the background based on how I tend to shade metal. It makes more sense on a dark background (at night), but I felt I needed to make it look reasonable at daytime too.
I looked up your inspiration a bit, are you thinking of using the clipped background for HUD space and create a couple icon stacks on the left & right of the screen since that would work well?
Maybe, but only for actions specific to how one would deal with monsters before battle (attack, flee, parlay, etc), and considering this is the Atari 2600 that kind of gameplay is likely out of the question anyway.
In fact, I've decided another reason it'd be best not to care about the sides of the screen is because then I can represent different sizes of monsters by making them wider or thinner.
The actual HUD elements I've decided is a N-E-S-W compass and map coordinates because besides a mini-map, those are the most immediately useful for that type of screen. Pressing the fire button will bring up a different screen for if you need to see other information.
Later today I'll post some "camp" and battle screenshots that I'm working on, but here's the compass display I made similar to how you described a score display.
(http://i.imgur.com/ShJz2.png)
@Helm: I'm glad I'm not the only one taking interest.
-
(http://i.imgur.com/RcUU2.png)
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.
(http://i.imgur.com/H0ku3.png)
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
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.
-
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. :)
-
In fact, I've decided another reason it'd be best not to care about the sides of the screen is because then I can represent different sizes of monsters by making them wider or thinner.
Ah I see, that is a good reason to ignore the background clipping.:)
The actual HUD elements I've decided is a N-E-S-W compass and map coordinates because besides a mini-map, those are the most immediately useful for that type of screen. Pressing the fire button will bring up a different screen for if you need to see other information.
Sounds logical to have compass and mini-maps have been done in quite a few 2600 games even in ones that didn't really need them. :lol:
-
(http://i.imgur.com/RcUU2.png)
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.
(http://i.imgur.com/H0ku3.png)
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. :)
-
The one thing that would make the game implausible would be ROM storage, since it relies on a lot of bitmap graphics (I just show the ones for one type of wall and one type of enemy, but you can imagine there would be a lot more variety) as well as maps to navigate (some Atari 2600 games are lucky to even have more than one screen or level).
I'm also thinking about signing up to atariage.com's forums, just for kicks and giggles.
-
The one thing that would make the game implausible would be ROM storage, since it relies on a lot of bitmap graphics (I just show the ones for one type of wall and one type of enemy, but you can imagine there would be a lot more variety) as well as maps to navigate (some Atari 2600 games are lucky to even have more than one screen or level).
I'm also thinking about signing up to atariage.com's forums, just for kicks and giggles.
Oh they complain a lot on AtariAge about ROM sizes but there is bankswitching to help with that since only the amount of data processing is limited to 4K total while the overall storage memory footprint size is negotiable as even back in the day carts became bigger over time. I'm actually looking into special cart chips for exclusive font and text data storage uses, heck even Pitfall 2 "cheated" with a supplemental hardware addition to its cartridge. Plus I don't think its even possible to build a cartridge ROM that is literally 4K anymore just from the obsolescence of small capacities in electronics manufacturing, perhaps I'm wrong but that's what I see in most retroactively made peripherals for obsolete systems in that they are larger in capacity by default.
I will say this though, that despite hardware options for greater ROM/Memory sizes many are apprehensive to use them except for a few exceptions like using the extra memory within the Harmony cart for enhancing games.
-
I'm sort of borderline on how I feel about that, as though I'm not staying true to how Atari 2600 games are, but at the same time a game like this would likely have used storage expansion even back then to promote itself as being a bigger game.
I still think size is a concern though. Also there is no kind of saving system, besides the possibility of a password system (which I've never heard of for an Atari 2600 game, but I suppose is possible).
-
Hmm... not art related and not Atari related, but I can't help but post. I would say it's definitely not cheating or not staying true to the console if the expansion hardware existed back then. NES was limited to 32KB for PRG, 8KB for CHR. (I know, I know, way more than 2600 already.) But almost every game anyone talks about does not have these limits. Even Tetris used more space! Super Mario Bros. does not, and it impresses me so much because of this.
I guess you could choose how you feel by how common the actual practice was. I feel certain hardware expansions are cheating for making NES looking mockups based on how expensive they were back then and how few games used them, but that's like 3 out of the like 20 non pirate ones I don't like.
Now for art related: I'm actually really impressed by the stuff here. Even coming from an NES programming background, I find these restrictions totally confusing but what you've got is looking really nice. That camp screen has all the information it needs, and it's readable.
-
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.
-
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. :lol:
-
(http://i.imgur.com/RcUU2.png)
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.
The six sprite kernel spends the start of each scanline preloading the sprite pixels, and the rest of the scanline outputting them in realtime, which normally takes up all of the useful cycles in the scanline. So the differing colors between the characters and digits, and the updates on the playfield here, are improbable. (The realtime sprite drawing means you can't get any cycles from doubling the lines on the sprites either.) If you look at existing games that use this kernel, it's usually given it's own empty row as a score, or in more recent games a single color per line title graphic.
That said this looks really good. You might try rearranging things or using flickering to fix it for the hardware.
-
(http://i.imgur.com/RcUU2.png)
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.
The six sprite kernel spends the start of each scanline preloading the sprite pixels, and the rest of the scanline outputting them in realtime, which normally takes up all of the useful cycles in the scanline. So the differing colors between the characters and digits, and the updates on the playfield here, are improbable. (The realtime sprite drawing means you can't get any cycles from doubling the lines on the sprites either.) If you look at existing games that use this kernel, it's usually given it's own empty row as a score, or in more recent games a single color per line title graphic.
That said this looks really good. You might try rearranging things or using flickering to fix it for the hardware.
Well that is true in that even if the numbers get there own Player object 4 digits is heavy multiplexing to occur along one line constantly which is usually why the six sprite kernel use gets its own isolated vertical zone or lane. Still you should check out the Title Screen Kernel, based on your setup you can make a 48X96 title screen image which isn't overly large for a cartridge ROM.
I'd agree about the differing colors since going from red to white along the same scanline would create a high enough cycle cost that it would be a problem. It's annoying but invoking a different color while multiplexing the same object at the same time is too much for the 2600, most of the Pac-Man work related to the multi-colored ghosts in later games like Ms Pac-Man up to modern homebrew Pac style games leveraged more sprite objects per ghost to avoid the limitations of multiplexing a single sprite so heavily.
In general when I can't for whatever reason isolate my HUD stats to there own vertical lane isolation and they go across the entire vertical field I usually use font characters made from Missile0, Missile1, & or the Ball with skipped scanlines on offset scanlines to avoid multiplexing flicker.
However since you likely want those objects for projectile sprites perhaps you could use Playfield rendered numbers, they are kind of big and they would share the colors of the Playfield graphic on the other side of the screen without a mid-line color change split but they should be compatible under this rendering context.:)
-
(http://i.imgur.com/0idSy.png)
I don't know if this is still problematic.
-
(http://i.imgur.com/0idSy.png)
I don't know if this is still problematic.
Its a little squashed but this will work, however since everything is vertically stacked and isolated from each other your Playfield based font characters become unnecessary since both the categorical icon and its numeral could use the same sprite object since they never intrude on each others vertical zone(ref. Frogger). Still the numerals do have the advantage of being possibly rendered with more objects with less multiplexing flicker under this layout design if no projectiles are needed.
I do kind miss the old layout but this one has some strengths.:)
-
I'm not sure about how the rasterline color limitations work yet so this could be out of spec, but the critique stands. READABILITY. Detail is secondary. Consider symbolizing more.
(http://locustleaves.com/0idSy2.png)
-
I am not good at drawing fires admittedly.
(http://i.imgur.com/erML3.png)
I ended up removing the light hitting the ground and removing a lot of the light hitting the rocks.
There was more I wanted to do before posting this change, but I am not sure I'll get around to it today.
-
I'm not sure about how the rasterline color limitations work yet so this could be out of spec, but the critique stands. READABILITY. Detail is secondary. Consider symbolizing more.
(http://locustleaves.com/0idSy2.png)
Took a closer look and for the most part this is within limitations except 2 lines at the bottom of the flame that have 2 colors occurring on one scanline. Missile line segments set to the appropriate color and width could fill these exceptions but its a lot of code for something so small and I assume you're not that attached it based on the majority of the image. Otherwise your camp fire graphic is very nice, captures that iconic symbol recognition style very well. :)
-
I am not good at drawing fires admittedly.
(http://i.imgur.com/erML3.png)
I ended up removing the light hitting the ground and removing a lot of the light hitting the rocks.
There was more I wanted to do before posting this change, but I am not sure I'll get around to it today.
Your fires are pretty hard to read. I suggest looking at the above edit. It's definitely easier to tell that it's a fire.
-
As good as it is, I don't want to copy it outright.
The first fire was just plain bad and I still need to clean up a lot of rough edges on my latest fire, but I think it'd be helpful to know what you're seeing if not a fire, so I can easier fix my mistakes.
-
You don't have to use this but I thought it might benefit the forum to see a demo of what I was describing with your previous Camp screen design.
(http://i1259.photobucket.com/albums/ii552/TheBladejunker/RPGCamp_A.png)
Here's one that incorporates Playfield based fonts which as you can see are quite large. :lol: I used one mid-line color change to give the stats there own color zone which wouldn't be too expensive with only 2 zones. And moved the camp fire graphic over one Playfield pixel since it was intruding on the Playfield column next to it by only a small degree, better to confine that graphic to the first 20 bits of the register in this layout.
(http://i1259.photobucket.com/albums/ii552/TheBladejunker/RPGCamp_B.png)
Here's the same thing but without a mid-line color change where the stats share the same scanline colors as the camp fire graphic, not too bad as the gradient adds something to the numerals.
(http://i1259.photobucket.com/albums/ii552/TheBladejunker/RPGCamp_C.png)
In the last setup the icons at the top are both Player objects be multiplexed to display 2 icons each. The 4 numerals per party member are split into 2 groups of 2 numerals done by multiplexing the Player object that isn't the character sprite while the second set of 2 numerals is rendered using bit constructed sprites made from Missile1 which uses 2 copies and multiplexes to produce the 4 pixel segments needed for both numerals.
While flicker is needed it would likely be minimal and perhaps with a mid-line color change applied to Missile1 and the Ball may allow them to fill in the spots being multiplexed by Missile0 instead which could get rid of the flicker or at least reduce it.
At the bottom I included the closer spacing option just for comparison.
-
I think the shape of the new fire is good, I just dont get why its only an outline. I think if you fill it in orange it will read more as a fire. Heres a quick edit making it a solid shape and probably way out of spec
(http://img687.imageshack.us/img687/866/atari.png)
Im not sure what all the letters are in this screen either. first one looks like "HP", then a backwards R, then D, then some kind of D E combination.
-
You don't have to use this but I thought it might benefit the forum to see a demo of what I was describing with your previous Camp screen design.
(http://i1259.photobucket.com/albums/ii552/TheBladejunker/RPGCamp_A.png)
Here's one that incorporates Playfield based fonts which as you can see are quite large. :lol: I used one mid-line color change to give the stats there own color zone which wouldn't be too expensive with only 2 zones. And moved the camp fire graphic over one Playfield pixel since it was intruding on the Playfield column next to it by only a small degree, better to confine that graphic to the first 20 bits of the register in this layout.
(http://i1259.photobucket.com/albums/ii552/TheBladejunker/RPGCamp_B.png)
Here's the same thing but without a mid-line color change where the stats share the same scanline colors as the camp fire graphic, not too bad as the gradient adds something to the numerals.
(http://i1259.photobucket.com/albums/ii552/TheBladejunker/RPGCamp_C.png)
In the last setup the icons at the top are both Player objects be multiplexed to display 2 icons each. The 4 numerals per party member are split into 2 groups of 2 numerals done by multiplexing the Player object that isn't the character sprite while the second set of 2 numerals is rendered using bit constructed sprites made from Missile1 which uses 2 copies and multiplexes to produce the 4 pixel segments needed for both numerals.
While flicker is needed it would likely be minimal and perhaps with a mid-line color change applied to Missile1 and the Ball may allow them to fill in the spots being multiplexed by Missile0 instead which could get rid of the flicker or at least reduce it.
At the bottom I included the closer spacing option just for comparison.
Actually scratch what I said here since I forgot about the SCORE bit which makes this design completely easy to do as the 50 50 screen split of color for the Playfield is supported in hardware. So duh on my part for calling this a mid-line color change. :B