Search the Community

So, I was looking through my folder full of WIP homebrews, and came upon Juno First. When last seen, Chris had put together a nice looking title screen: But as was mentioned in the comments, it would have been nice to make the scores a single color, instead of multicolored: So I was wondering if this would work... (I think this is what Bob mentioned in the comments, but I'm not sure): First, you have the title and some of the text, made up of sprites, as before: But then, the scores and aliens are actually created by making a large bitmap out of the sprites, that's a negative image, in black: Below that, is the tricky part that I'm not sure about. It would involve changing the playfield color on a line by line basis, to put color behind where the alien ships go. Then, putting something solid behind where the score goes. What I'm not sure of, is if you can change the playfield color to do that, or if you can somehow make a large, single-color missile or ball for that (seems to me you can't, since their colors are defined by the player sprites and playfield, if memory serves). Below that, of course, would be a black background: I'm also wondering if there would be a way to do this using flicker... since the entire logo is going to be flickering anyway (as are pretty-much all the sprites in the game). Maybe display the multicolored playfield one frame, then the solid one the next. Anyway... just wondering. Still hoping to see Chris be able to finish this someday.

I just realized, that as of yesterday, I've posted to my blog five days in a row! While this is a completely meaningless statistic, I've decided to try and go for a solid week of blog entries, and make it an even bigger completely meaningless statistic! So, with today and tomorrow left to deal with, I'd better come up with something to post about. Just putting up a mostly empty entry would be cheating. Umm... well, I did get a first pass at the Rainbow Invaders sprites done and sent off to Silvio. So... ...see you tomorrow then.

So, I've been playing a lot of Juno First lately, since I'll be making sprites for it.If you haven't checked it out in MAME, you should. It's a really challenging and fun game. Although it looks like a standard vertical shooter, there's more to it than that. By controlling forward/reverse movement of your ship, it adds a completely different dimension to the game. For about the first three waves, it doesn't make much of a difference.But then... they break out the homing missiles.These little buggers track you like the Swarmers in Defender. To escape them, you often have to back up - fast - then swing around them, and lose them off the bottom of the screen.While still avoiding all of the rest of the bad guys, and their "normal" shots.Seriously - you have to back up a lot in this game.Sprite-wise, it looks like there will be seven enemy sprites to make, plus the player's ship. It looks like each enemy has four (or five) sizes. It doesn't look like there's much if any animation on the enemy sprites, other than the size changing.Whether or not there are more sprites in the game... I haven't found that out yet.Attract screens like this one (which show all of the enemies) sure make my job a lot easier. Usually, I have to capture a movie of the game, then manually create animated GIFs of all of the sprites for reference. (One of these days, I'll have to find out how to extract sprite data directly from ROMs. I know there's a way to do it, but I have no idea how.)So that brings up the matter of... The list.Here's a list of things that sprite artists need to know, in order to be able to create sprites for an Atari 2600 game. (I'll eventually include this in a "How to" about making sprites.)In general: Number of sprites (preferably with names and/or descriptions). This includes multiple instances of the same character. For example, a running and jumping version would be considered separate. Or a flying ship and an exploding one. Are they conversions of existing sprites, or originals? File format you want the graphics provided in (what I've been doing lately is creating a color animated GIF for previewing, then monochrome .bmp files for conversion) Then, for each sprite: 1LK or 2LK? Multi-color or Monochrome? Single, Double, or Quad Width? Number of animation frames Number of different sizes (if sprite needs to be scaled) Number of rotation positions (if applicable) Does the sprite need to be animated at the different sizes and/or positions? Maximum Height Maximum Width Other things to consider: Will the game need a title screen? Will it need fonts? If a sprite is running, can it leave the ground on some frames? Can the colors of each scanline change on a per-frame basis? Or must they remain consistent? Will playfield graphics be needed? If so, what are the requirements for those? Do you want TIA colors indicated? NTSC and/or PAL? So the sprite list for Ladybug would look something like this: All sprites are 1LK, monochrome and single-width.Bug sprites must be animated in horizontal and vertical positions. (3 frames each.)| name | w | h | frames | rotation--------------------------------------------------------------------------------------Ladybug 8 14 3 yes - h,vLevel 1 bug 8 14 3 yes - h,vLevel 2 bug 8 14 3 yes - h,vLevel 3 bug 8 14 3 yes - h,vLevel 4 bug 8 14 3 yes - h,vLevel 5 bug 8 14 3 yes - h,vLevel 6 bug 8 14 3 yes - h,vLevel 7 bug 8 14 3 yes - h,vLevel 8 bug 8 14 3 yes - h,vSpare ladybug 8 11 1 noCucumber 8 11 1 noEgg Plant 8 11 1 noCarrot 8 11 1 noRadish 8 11 1 noParsley 8 11 1 noTomato 8 11 1 noPumpkin 8 11 1 noBamboo shoot 8 11 1 noJapaneseRadish 8 11 1 noMushroom 8 11 1 noPotato 8 11 1 noOnion 8 11 1 noChineseCabbage 8 11 1 noTurnip 8 11 1 noRed Pepper 8 11 1 noCelery 8 11 1 noSweet Potato 8 11 1 noHorseradish 8 11 1 noLadybug death 8 14 6 no Also, for the Ladybug death, it needs to tie into both the horizontal and vertical versions of the Ladybug, since there isn't enough ROM space for two different deaths. So things like that are important to note.Related to that, for games with multiple animations for a single character, is to have each animation listed separately.For example: Louisiana Larry2LK, multicolor, single-width.| action | w | h | frames-------------------------------Running 8 16 6 Jumping 8 20 4Climbing 6 18 4Swinging sword 8 16 8 Now... the question here is, does 2LK mean that 16 pixels height is really 8 pixels that are 2 scanlines high each?Or, does this mean that it's 16 pixels high, and each pixel is 2 scanlines high (resulting in 32 scanlines on screen)?That's an important distinction.Also, something that came up regarding Stellar Fortress, is that for animated (or rotating) sprites, can the position of the sprite change for each frame in the animation? In the case of Stellar Fortress, this helps to make the ship rotate around the cockpit, which looks much better than rotating around the center of the sprite. This effect could also be used in other animation too, such as someone swinging a sword around, but needing to keep their feet "planted" in one spot.Generally, the more frames and pixels you can give the sprite artist, the better things are going to look. The same applies with colors, too.While working on Reindeer Rescue, Bob was able to change Santa so he could have black boots. This wasn't originally going to happen, but I showed him what it would look like, and he liked it enough to make it happen. As a happy side-effect, the height of the ground sprites also changed from six to nine pixels, allowing for much better looking sprites (especially the milk & cookies). (Notice Santa also packed on an extra 50 pounds somewhere in there.) :)So, for Juno First, the first step is to identify the sprites. So I had to dig up images of the arcade sprites, and identify them somehow. (Actually, it's probably better for the programmer to do this, since he's the one who has to decide what is going to go into the game.)Assuming that's all of the enemy sprites, the list would go something like this: | name | w | h | sizes---------------------------------Player shipAlien 1Alien 2Big AlienSmall UFOLarge UFOSphereAstronautHoming missileTitle screen And then Chris would fill in all of the necessary information. The "sizes" column indicates how many different sizes of each sprite are needed to give the illusion of them moving towards or away from you. If each size required different dimensions, then those would need to be listed as well. Plus I'd need to know if this was 1LK or 2LK, monochrome or multi-color, and so on.(Meanwhile, while you're waiting for the 2600 version of Juno First , here are some links about the arcade version: ) My review of Juno First for The Games That Time Forgot KLOV entry Arcade flyer (Konami) Arcade flyer (Mylstar) In other sprite news:John has released another work-in-progress build of Ladybug. He's making remarkable progress on the game. There are a couple of bug sprites I may go back in and re-work, but I think other than the title screen, the game is pretty much done, graphics-wise.Also, Manuel has released a build of Colony 7, that shows everything blowing up. It also shows all of the game sprites flying around, and you get to shoot them down. Well, until your cannons get destroyed.Both games are coming along great, and already look like they're going to be a lot of fun. One interesting side-effect of creating sprites (at least for arcade ports) is that I end up playing the original games in MacMAME a lot. It's easy to see why the programmers chose these games (I'm still hoping for Bosconian someday, personally ).Also, Chris posted a build of PoP that's really amazing. After some of my other projects are out of the way, I may take another look at the sprites for this one.Label fun:I started sketching out the Four-Play label this weekend. I'm still trying to figure out where to go with it, but at least I'm putting some ideas down. Finally:The Seahawks lost. They started out really well, but just couldn't take advantage of enough opportunities. Plus, there were a couple of really bad calls in there, but in the end, it wouldn't have made much of a difference. They had their fair share of chances, and blew it. It's too bad, because the Steelers really didn't play all that great either. The Seahawks only had to play a little bit better than they did to win. Or perhaps, play the way they did at the beginning, for a longer period of time.Oh well.Say... isn't it about time for spring training to begin?

Well, it turns out that one is a praying mantis - not a cricket. But I was right - it is giving me trouble. The hardest thing about making these sprites (so far) is that if I were just making vertical versions (as the sprite rips shown in my previous post below are), then I could make pretty decent-looking conversions. There's enough vertical resolution (14 pixels) in the sprites to be able to make neat looking legs, spots, stripes and other stuff. And there is a lot of that kind of stuff. The problem is - when I rotate the bug 90°, I lose that resolution. So I can't make thin legs, spots or stripes, since I have to redraw the same details for the horizontal versions using only 8 pixels. I found that out pretty much on the second bug I did (the purple one, second from the top). I had made a really nice vertical version of all three frames, then tried to make the horizontal version. Yikes! I couldn't reproduce any of the really fine detail - so there went the eight spots and the thin pincers I was so proud of. I managed to keep four spots though, and I'm learning to use the differences in horizontal and vertical resolution to "cheat" part of each version a little, so each orientation will have some aspects that look better than the other, but they'll still look like the same sprite. I do this by fudging things like leg widths or pincer thicknesses, or adding more negative space for better detail, depending on what's needed to make something read correctly. The key is to keep the basic features the same (number of spots or legs, relative proportions, primary shapes), and make the differences subtle, and only for the sake of clarity. The human brain does a very good job at associating different shapes, and filling in the gaps between them. As long as the differences are minor, then the brain says, "Okay, that's the same thing, but just in a different position." That's the principle behind animation (and in fact - film itself), and it's based on persistence of vision. Also, I'm using the animation to fudge things a little bit, too. Not every frame looks "right" by itself - all that really matters is that when it's in motion, the right parts seem to be moving the right way. So if on one frame the legs don't look like legs, it doesn't matter - as long as they look like legs when played in sequence with the other frames. The brain wants to put things together like that, so it's really important (especially on the 2600) to take advantage of that wherever possible. Detail isn't as important as the overall effect. I did this on the Santa sprite for Reindeer Rescue. On some of the frames, his legs just look weird. But on the whole, he seems to be running. My approach with LadyBug now - instead of making one great-looking vertical bug, then having to destroy it in order to make a horizontal version - is to make one frame of each orientation at the same time and flip back and forth between them, to be sure they have the same overall details and look the same. Then I do the same for the other frames (making sure the overall animation for each version is working, too). So it's a lot of going back-and forth, but what I'm ending up with are sprites that work in both directions, and look very similar to each other, despite their "relative vertical resolutions"* being completely different. * That is, the bugs' heights get drawn with either 14 or 8 pixels, depending on their orientation. It doesn't refer to the sprites' heights. And of course, they need to capture the look of the arcade sprites, as much as possible. Perhaps that's not quite the right term though... maybe "reflect the essence" is more correct. Maybe that sounds a bit silly (or pretentious), but they are essentially abstractions of the originals. The trick is to make them recognizable, or better yet - familiar. Anyway, enough bugs for now. I have to go blow up Colony 7.

Well after getting sidetracked with animation for a few entries, it's back to some more on-topic stuff.Animation!...of Atari 2600 game sprites, that is. ;)I just sent off the first batch of exploding sprites to Manuel for Colony 7. I couldn't make huge, elaborate explosions due to the constraints, but I think what I came up with gets across the idea of stuff blowing apart pretty well.I'll also be working on some sprites for Chris' version of Juno First. This was a cool game I discovered while writing some reviews for Cinemarcade's "The Games That Time Forgot". Chris has made some great progress on the kernel already.The big project though, will be John's port of LadyBug. This is going to have a bunch of sprites in it. Here are some rips from the arcade game, to show you what I'll be dealing with...The LadyBug:The enemy bugs:And the LadyBug after running into an enemy bug:Each of the bug animations has four frames - but only three of them are unique. In each animation, one of the sprites gets used twice, so that will save me some work. And it'll save John some ROM space.But...I have to make two sets of each bug animation - horizontal and vertical. This is due the the 2600 not using square pixels. So that will take some doing. The death scene shouldn't be a problem, since only the first frame will be different for a horizontal or vertical death. The floating angel wings aren't animated (ie. flapping), they're just moved in a "fluttering" motion by the computer to give that illusion.In addition to the animation, there are also 18 vegetable sprites. Fortunately, they aren't animated. And then there's a title screen, letters, and some other stuff.That should keep me busy for awhile. I'd never played LadyBug before, but after getting into it for a few games, it's really different. It's hardly the Pac-Man rip-off that it appears to be on the surface. There's a lot more to the game than initially meets the eye, and it's quite a bit of fun.(I can already tell that the cricket and centipede are gonna give me trouble.)

Reindeer Rescue Wrap-upWell, it looks like Bob is done programming Reindeer Rescue. I think the game turned out great, and people are gonna love it! It's already climbed up to the fourth best-selling homebrew of all-time in the AtariAge store. That's pretty amazing! (The fact that it can be had for free may have had a little to do with that... nah. )It was a lot of fun creating the sprites and other in-game graphics for it. I want to thank Bob for inviting me to be part of the project, and giving me quite a lot of creative freedom when it came to to the graphics. He was great to work with, since on more than a couple of occasions he re-worked some code to suit the graphics (Santa's black boots for one example), and put up with a lot of nit-picking from me to make sure the graphics were just right. That really speaks of Bob's desire to make this a good game, too. Not just a quickie, one-shot deal.The more graphics I created, the more Bob kept asking for, until there were some 53 sprites in the game (some using two sprites for a single object), 16 of them were animated, plus 4 large "title screen" graphics (48 pixels-wide), a score font, and I-don't-know-how-many playfield objects, including houses, street lamps... and well, I'll leave it for you to discover what all is in there. Suffice it to say, Bob put a lot of stuff into this game. I think he's probably going to sleep for a month.Oh... and there's a PAL version, too, which Thomas Jentzsch worked on. Choosing the colors for that was interesting. I can't say I care much for the TIA PAL color palette, but it's a far sight better than doing a SECAM version. :roll:Dave Exton's label is another great illustration from him, and I'm looking forward to seeing his design for the manual, too. Ironically, due to some traveling, I probably won't see the actual cartridge until after the holidays. But I've already played the game quite a lot during testing. Favorite Christmas MusicWhile working on the graphics (and by "working on" I mean, "using Photoshop to draw them" - Bob did all of the hard work of actually getting them into the game), I listened to Christmas music to get in the mood. So I thought I'd share a couple of my favorite albums with you (you actually have to pay for them yourself, however...)Christmastime by the Swingle SingersThe Swingle Singers do close harmony a-cappella jazz - but without lyrics. It's a little hard to describe, but it's instantly recognizable. Anyway, check out the link, and listen to some of the MP3 samples. You've probably heard them before, since their style of music was used in various movies from the 60's and it's quite distinctive.This particular album was recorded in 1968, and I grew up with it. Every Christmas we'd throw this (along with a half-dozen other records) on the turntable, sit in front of the fire, and drink egg-nog (non-alcoholic) mixed with 7-Up (don't knock it 'til you try it). It just wasn't Christmas until this album was played. I searched for a CD version for years before I found it. So now you get to hear it without doing all the work. Herb Alpert and the Tijuana Brass - Christmas AlbumBelieve it or not, the Tijuana Brass were the fourth most popular recording act of the 60's, after the Beatles, Elvis and Frank Sinatra. One of the reasons was that after their initial psuedo-Mariachi hits, they evolved into a unique style all their own that was much broader in scope, and enjoyed by a wide audience. This album really showcases the masterful arrangements by Herb Alpert, and feels more like a soft jazz album (with Swingle Singer-like overtones, arranged by Shorty Rogers) than anything from Tijuana.This is another album that I grew up with, and it instantly transports me back in time, and I look forward to listening to it every year. Even more-so this year, since it's been out of print on CD for awhile, and this year sees it in a brand new re-mastered release that sounds, as Herb says on one of the tracks, "Terrific, terrific!"An Early Christmas FlashbackFinally, today at work, two of my good friends and fellow tech geeks gave me a Flashback 2 for Christmas! Of course, I immediately plugged it in (handy having video monitors in the office), so we could check it out. It's a pretty cool bit of geek-gear. I've only checked out a few of the new games on it, but I'll try and post a more in-depth review in a future blog.For now though... I think some pre-review research is in order.

I had a really nice Thanksgiving at my relatives' house. It's always nice to get away for a few days. Ate way too much turkey and mashed potatoes.And pie.Gotta have the pie, though.Anyway, I brought along an iBook and a Wacom tablet, so I could work on some more game sprites while I was down there.So far, I've done almost 50 sprites.For one game.Including the individual frames for animation I'm up to 151.Plus 30 font characters.That's a lot of pixels.Not all of it is going to get used. A few are alternate versions of the same thing. Some just may not work. But at least the programmer has some options available. (Personally, I'm hoping the weasel makes the cut.)

So... where was I?Well, I managed to wrap up the coloring on the Solar Plexus label. Jess posted a picture of it here.Still on my "to do" list is the last part (or two) of the label tutorial. I just need to make some time for it.The big project turned out to be the manual for the 2005 MiniGame MultiCart. Besides a tight deadline, it was like doing seven manuals in one, so it turned out to be quite a challenge to cram everything in there, without it turning into something the size of a phone book. But in the end, everyone seemed happy with it, and it got finished in time for Albert to have the game ready for the vgXpo in Philly last week, so it's all good. I would've liked to have done some illustrations for that one, but with seven games and very little time, it just wasn't possible.RPS didn't make the show, but hopefully that will be along soon. The label and manual are all done, I'm just waiting for the final binary to update some of the info and screenshots.Meanwhile, I've been asked to work on yet another project - this time it's some more sprites for another homebrew.The real trick with the 2600 is trying to make something look good that's only 8 pixels wide. Still, it can be done. Take a look at the Garfield prototype. Or better still, Popeye. While Olive Oyl isn't much to look at (she never was anyway), Popeye is completely recognizable - right down to his pipe! In both games, the sprites are a mere 8 pixels wide. I can only imagine how much the programmers had to agonize over every pixel to make them look right.Being able to use multiple colors for sprites can really add a lot to them. Kaboom! and Gangster Alley both make great use of color, and the programmers managed to add a lot of personality to their characters, too.In all of these cases though, you're dealing with cartoon characters. So you have an opportunity to make a pretty large face, which really helps bring the character to life. But even games like Pitfall managed to have good looking sprites. I still remember being very impressed that Pitfall Harry actually had hair! The fact that the animation of Harry running was very good really added a lot to the game, too.Conversely, you look at something like Miner 2049er, or worse yet, Quest for Quintana Roo, and you have to wonder if they put any effort into trying to make the characters look good at all. Looking at those games, it's hard to believe that the same system was also capable of a pretty faithful re-creation of Kermit and Miss Piggy.So now I'm working on some 8 pixel-wide character sprites, and they really need to look good. No Bounty Bob or Yucatan Sam here. And while I don't have the vertical height needed for a good cartoon sprite, maybe I can at least end up with something that wouldn't have looked out-of-place next to Pitfall Harry or the guy from H.E.R.O.For what it's worth though... space ships are much easier.

Okay, I think I have all of the sprites done for Colony 7. It took a little time to rip the ones from the original arcade game in MAME, but thanks to Snapz Pro X 2, I can capture movies of anything on my Mac. Then it's just a matter of taking the individual frames I need, and importing them into ImageReady, so I can see them as animation.Like this:(enlarged to 300%)The Advisor doesn't do much, does it? Although really, how much action can you expect from an Advisor?Those were pretty easy to capture, since the attract mode of the game puts all of the sprites on one screen.Well, almost all of them.In Colony 7, the enemy ships also zoom in and out of the distance. So there are sprites for those, too. For that, I had to capture gameplay, find the frames I wanted, import them into ImageReady, then realign the sprites (since they zip around the screen while they're changing size).After all that, I end up with these:So then comes the trick of making 2600 versions of these.There are a few limitations to deal with: The 2600 versions can only be a maximum of 8 pixels wide. They can only have one color per horizontal line. The 2600's pixels are twice as wide as they are tall. Now this last limitation can make it difficult to design sprites. On computers, you're dealing with square pixels. So if you draw with the correct number of pixels for the 2600, you end up with something half as wide as it will appear in the game.So to make a sprite look the way it will on a 2600, you have to draw two pixels horizontally, for every one pixel vertically. But then, you have twice as many pixels as you actually need, and it's easy to put pixels in the wrong place that way.Fortunately, Photoshop CS allows you to cheat. There's an option to change the pixel aspect ratio of the document you're working on.By setting up a custom ratio of 2, you end up with something onscreen that looks like it should, yet still has the correct number of pixels in it.This makes it much easier to draw sprites for the 2600, since you know what it's going to look like in the end, without having to fuss around. The trick though, is when you're exporting it (for a blog entry, for example) and you want it to look correct, you need to make sure to double the width of the document when you export it (use "nearest neighbor" as the scaling option).You can also use the same trick (with a custom ratio of 4) for designing double-width 2600 sprites. Cool, huh?So... for Colony 7, I wanted to try to re-create the look of the sprites as much as possible. The problem is, if I copy them as close to pixel-for-pixel as I can, it tends to make the Fighter sprite too small, and the others too large. So I had to tweak them a bit to look the right size for the game. So for that, I took a screenshot of Manuel's work-in-progress game in Stella, and would periodically drop the sprites in it, to see how they looked relative to each other and the game itself.That ended up looking about right. Not too big, not too small.Now then... I was going to post what the final sprites looked like, but the forum wouldn't let me. Some nonsense about too many images. What's the deal with that? This blog is impinging on my creative freedom!Well... phooey on that. I guess I'll just have to post them in the comments.