I never had either of these systems growing up, I had all Nintendo stuff as a kid. However, when I got Sonic Adventure DX, I had the opportunity to try the various Game Gear titles, and later played most of the Master System Sonic games on emulator. I'm working on designing an 8-bit themed fangame, and since I don't know much about the system's limitations (mostly graphics), I thought that I'd ask for a bit of clarification. (I'll admit, I'm planning on a "Shovel Knight" approach to limitations, where I'll fudge things a touch if I feel the end result is worth it, but knowing the original limitations would be best so I know how far I can push things, and I think that a "true demake" mode would make a fun unlockable.) Looking on the Wiki, it states that the Master System can do "up to 32 simultaneous colors (16 for sprites, 16 for background) available from a palette of 64 colors (6-bit RGB), 16 colors (4-bit) per pixel/tile/sprite". It also says "Mid-frame palette swap allows up to 64 simultaneous colors, 105 color palette (all on screen) possible with static image". First, when it says "per pixel/tile/sprite", are we talking 8x8 tiles or 16x16 tiles? Late NES games (such as Darkwing Duck) did a sneaky trick where they would overlap two sprites together to create a single character and thus get away with things like using more colors than normally possible on Darkwing himself. Would a similar trick have been possible on the Master System, or is it a set 16 colors spread between all sprites loaded at once, and such a trick would be ultimately useless? Second, I've gotten a reference image that shows all 64 colors that the Master System had available. However, the Wiki said that a static image could show a 105 color palette. Where are those additional colors coming from? Was the "Mid-frame palette swap" thing something used for static images like title screens, or was it something that could be implemented in an actual level? On a less-technical note, is there anywhere that shows common color ramps picked from the Master System's palette? The usual 8x8 square of colors gives some funky optical illusion effects, such as making it near impossible to find the grey colors. I had to actually look on another site where somebody had the same problem and another person had to point out where they were.
Yeah, if you change the palette mid-frame you can have different sets of colors in different regions of the screen. I don't know what the deal is with that 105 color figure though... If the master palette has 64 colors, the maximum you can get on screen should be 64 colors. The NES has something called "color emphasis", which can slightly tint the whole palette towards 8 different hues, but I don't think the SMS has anything like that. For the background, it's always 8x8 tiles. Sprites can use either 8x8 or 8x16 tiles, but AFAIK sprites always use the same palette, so it doesn't matter. On the NES, sprites use one of 4 3-color palettes, so you can make more colorful characters by overlapping sprites that use different palettes. On the SMS, all sprites use the same 15-color palette, so like you said, this trick is useless. I'm wondering that myself. In Sonic games (Chaos, Triple Trouble and Blast) this is often used in water levels, to tint the parts of the map that are submerged, same as in the Genesis games. Grays are formed by equal amounts of red, green, and blue. Since the SMS only has 2 bits per channel (i.e. the possible intensities are 0, 1, 2 and 3), there are only 4 grays (black and white included). To properly view the SMS palette you have to think of it as a cube, where each axis represents one of the color channels (red, green, blue). The grays can be found in a line going from (0, 0, 0) to (3, 3, 3). The best graphics come from combining colors in less obvious ways, though. Look at Deep Duck Trouble for example, that game is gorgeous!
Okay, let me see if I have this right. Out of the Master System's selection of 64 colors, I can pick 16 for all in-level graphics as well as another 16 for all in-level sprites. The system was designed to build levels out of 8x8 tiles, but I have complete per-pixel freedom anyways, as long as I stay within my 16 color limitation. I only have one actual layer to work with, but for things like cutscenes, I can have each row of tiles scroll independently of each other to simulate parallax scrolling, sort of how the HUD would have functioned in Super Mario Bros. 3. This is why the tileset rip on Spriter's Resource has multiple identical terrain pieces with the background placed directly in it. Is this correct, as far as graphic design goes?
Well, sort of kind of. If you feel like giving myself (or, preferably, Tokumaru - He's amazing!) a jab over instant messaging, I think we'd be more than willing to clarify some things. I'd love to help clear some things up, but it feels like it'd take a lot of posts clarifying these things over many days when it can mostly be done in a few hours over a private conversation.
Flygon is right when he says that answering tons of little questions like these in a forum thread can take a while and look a little messy, but since it seems you don't want to follow the restrictions very strictly, I don't mind answering a few questions here. Yes, but one very important detail is that the background can also use the sprite palette, while the opposite isn't true. The 8x8-pixel grid is important because the background can use the two palettes, which are selectable per-tile. If you're drawing with per-pixel freedom, you have to be careful to not mix colors from the separate palettes within the same 8x8-pixel block. Depending on how authentic you want the graphics to look, you might want to hold back with all that per-pixel freedom, since the actual console has less than 500 tiles available for everything. These can be changed over time (usually to animate the main character), but keep in mind that there is a limit to how much unique art you can have visible at any given time. You can actually have each row of PIXELS scroll independently, as long as it's the horizontal scroll you're changing, since the SMS can't change the vertical scroll mid-frame. This isn't limited to cutscenes either, several games change the scroll mid-screen to move large bosses (drawn on the background rather than using sprites) and the like. This means you can have scrolling-based parallax effects in-game, as long as no other background elements overlap the parallax areas. Here's an example of an effect made possible by mid-screen scroll changes on the SMS: https://youtu.be/R4HsAsMy1D8#t=02m55s There is another way to implement parallax effects which consists in modifying the tile graphics themselves, rather than the scroll. The basic idea is to rotate the tile graphics to cancel out some of the camera movement, effectively making it seem like those tiles are scrolling at a slower pace. I can't think of any SMS games that use this effect right now, but look at Sword Master or Metal Storm (among many others!) on the NES, preferably in an emulator with a pattern table viewer, to get a better sense of how this works. The main advantage of this type of parallax effect is that you CAN have static stuff overlapping parallax areas.
Gonna rant privately about this specific little point. This is the most infuriating thing I've encountered trying to art plan around the Master System. Drawing dialogue boxes becomes a whole lot harder when you want grid-free movement combined with this limitation! Also kinda shamefully means a port of Super Mario Bros. 3 probably wouldn't be possible. Not as it currently stands. I know there's a borky workaround, but it's borky as fuck for a reason :< California Games would be the only Master System title I can think of that actually does simulate multi-layered scrolling that way. A bit of a shame VDP writes are so slow. Nothing as simple as switching CHR-ROM banks on the NES.
Okay, I think I've got just about everything that I need. If I can set up palette changes depending on the section of the screen, rather than using it for water effects, I think that means that I could pull off an imitation of a really rudimentary lighting system without breaking any of the rules. (Sonic goes into a cave-like area and his sprite darkens) I suppose I've only got one question left. When you said that there's room in memory for roughly 500 unique tiles at once, would flipped/mirrored tiles count as a single entry, or would each version count as a separate one? I found a really neat graphic that was originally designed for a top-down view that's based off of a rip from Contra, that I think would look neat as a sort-of foreground effect. If flipped/mirrored graphics count as multiple entries, then it wouldn't take up any more room than a typical Green Hill-styled indent pattern. If it's a single entry for flipped tiles, then I might want to consider removing it or simplifying it for an accurate recreation.
You actually get about 448 tiles max. The entire upper section of the VRAM is occupied by the nametables involved for the background and sprites. Attempting to address the higher end of the tiles ends up rendering the nametables as tiles instead. :v: But, yeah. Flipping background tiles completely 'free'. It's defined at the nametable level.
The lack of hardware sprite flipping is what bothers me the most to be honest, but yeah, that one is pretty annoying too. I think I could settle for bursts of coarse vertical scrolling that don't pause the gameplay. I haven't played much SMB3 though, so I don't know if that'd be an acceptable solution everywhere. Cool, thanks for the example. I imagine that if we looked harder we'd find a few more. EDIT: Just noticed that Astérix and the Great Rescue has a parallax effect like that, but it's continuous as opposed to being tied to the scroll. That game looks fantastic BTW, it could almost pass for a 16-bit game IMO. Which's why I find the lack of sprite flipping so troublesome! You spend so much time redrawing sprites that there isn't much left for background animations. The end result is that even the most graphically impressive SMS games end up suffering from backgrounds that are way too static. That would only require the palette to be changed from one frame to the next, right? That's even easier. That number was a little off... the SMS has 16KB of VRAM, which would be enough for 512 tiles, but that memory is also used to hold the tile map (about 1792 bytes) and the sprite attribute table (192 bytes), so you actually have around 450 tiles available at any given time. EDIT: Flygon said 448... This varies a bit, since there are 2 possible heights for the tile map, and you may or may not use the unused portion of the sprite attribute table for 2 extra tiles. Flipping and recoloring are real-time transformations made on top of the original tiles, so no, they don't require any extra space. The same tile (32 bytes) can be displayed in 8 different ways: 4 combinations of H/V flipping * 2 possible palettes. I don't get it, wouldn't that be the other way around?
The Contra overlay that I found is a 32x32 repeating pattern with a couple 8x8 bits sticking out the side for edges. Since it originally came from an NES game, it's two shades of green and black. If the original Green Hill indent pattern was done with each flip/mirror being separate entries in memory, I would assume that the number of unique tiles used for such a pattern would be enough that it would be comparable to the number of unique tiles needed for my Contra pattern, making it a fairly safe bet that my plan would work. If the tiles used for the original Green Hill pattern involved flip/mirror tiles being a single entry, than the number of unique tiles that it needed would be much less than my Contra pattern, putting my plan at a bit of a risk of being too much for the system to have handled. Like I said, my pattern is two greens and a black, so if it shares the same shades of green as the grass-topped terrain, it wouldn't need any more of the palette than I would have needed otherwise. I can have it look like the ground is protruding from incredibly thick foliage, as an alternative to drawing a series of indents and protrusions to break things up visually. With the palette not being an issue at all, my only concern is the number of tiles that such a pattern would require. (Also, since existing Zones like Megapolis have proven that you can draw things in front of Sonic, I can use the foliage to hide secrets and hidden paths as well.) What I've been doing is using Paint to get the individual tiles done, then layering everything together in Paint.NET in 128x128 chunks like how things would have been put together in the Genesis games. This way, I don't have to redraw things like trees sticking out of the ground. Once I have everything put together properly, I can merge all of the layers together and feed the result into something like Graphics Gale. Have it break up the image into a tileset, removing all of the duplicates, and it should tell me how many tiles it's been reduced to. If it falls under 450-500 like you guys say, then everything should be in line with what the Master System could have done. Place my chunks into Game Maker as a 128x128 tileset, and I can assemble my level fairly quickly. What I'm also rather happy about is the parallax effects that you guys mentioned. It means that if I keep things within reason and not do too many layers, I can have a bit of a scrolling effect on the background without it looking too complex for the original system. Top that with a slight overlay in areas to simulate the mid-frame palette switching like you mentioned as well to implement a simplistic lighting effect, and I can probably get some really interesting graphics while staying somewhat faithful to what a Master System could have accomplished. This has been incredibly useful, thank you very much for clearing things up for me.
Oh, I get it now. About that... as you know, the SMS only has a single background layer, but each tile on the screen has a priority bit, indicating whether it's behind or in front of the sprites. This makes a few layering tricks possible, but note that the priority setting you choose is universal and affects ALL sprites: you can often see the HUD going behind these tiles in Sonic games, for example. Also, keep in mind that when tiles are drawn in front of the sprites, color 0 is considered transparent, if you plan on implementing background priorities faithfully. Hopefully you'll be able to share a few screens with us soon.
Fair chunks of the screen in quite a few stages are split into three separate planes. Even worse, all three tend to need to scroll smoothly vertically. While the HUD itself is fairly simplistic (Two colours used, to boot), and doesn't need to deal with sprites wandering in - Allowing 'easy enough' abuse of the whole SG-1000 modes trick? Unfortunately, the third pane tends to be integrated into the stage itself. Ceiling coming down to crush the player, water at the bottom of the screen bobbing in and out as a boat rides... Not friendly! There's a few ways I could see to try and work around it, in the context of the game, but... that's neither here nor there for the sake of this topic. :v:
By the way, I suggest you to visit smspower if you're interested into the Master System and the Game Gear.
Since you seem to be so interested in learning about those systems... I'd actually suggest making an actual SMS/GG game rather than a lookalike.
First off, I'm at college and I don't think I quite have the time to make a SMS/GG game from scratch. Second, I'm mainly wanting to do an 8-bit styled fangame because there aren't very many of those (I can only think of one, "Sonic Origins 2") and I thought it would be fun. And third, I have an idea for a game of my own that I want to do, and I need to figure out ball physics for it anyways, and making a Sonic fangame seemed like a fun way to do that. (No, it's not a character, but a primary weapon. Imagine a Mega Man X game where your strongest attack is a physics-driven ball that you can smash into enemies.) I just figured that if I'm going to make an 8-bit themed game, I might as well make sure it looks the part and I don't do anything overly complex while in the design stage. It should be easier to know what to avoid ahead of time instead of having to pare everything back after it's been made. EDIT: I went ahead and posted what I've got pieced together in the fangaming forum's General Project Screenshot thread. If you want to see what I've got done so far, it's over there.
IIRC Ys does this for the final battle with Dark Fact as well. There are a few other places where the MSX version of Ys did it as well, but those were turned into static scenes on the SMS (like the bridge on darm tower). But the final battle still has the same parallax trick, and assuming it's done the same way it's done on the MSX, then it's done with animated tiles.
