Forums

Sega Master System / Mark III / Game Gear
SG-1000 / SC-3000 / SF-7000 / OMV
Home - Forums - Games - Scans - Maps - Cheats - Credits
Music - Videos - Development - Hacks - Translations - Homebrew

View topic - Master System Graphical Limitation Questions

Reply to topic
Author Message
  • Joined: 16 Oct 2022
  • Posts: 41
Reply with quote
Master System Graphical Limitation Questions
Post Posted: Sun Oct 16, 2022 12:27 pm
Last edited by Mondo on Sun Oct 16, 2022 12:50 pm; edited 1 time in total
Hi, I'm making a little game on PC that I want to ape the Master System's graphics, down to the tile limit if possible (but also taking into account tricks that were used). I'm a pixel artist first and a total layman on most other things, so I have a bunch of questions I'd like to ask the experts here if that's ok! I'll start with a few sentences of what I think I understand about the graphical hardware limitations, in case that's wrong, and then I'll put my questions after.

- 448 tiles in VRAM at once, up to 256 of them can be sprite tiles, and any amount of the 448 can be Background tiles.

- When drawing the background, any tile in VRAM can in fact be drawn despite its designation, but when drawing the sprites you only have access to the sprite tiles.

- Choosing colours from the master palette of 64 colours, there are two in-game 16-colour palettes. One of the palettes is available to sprites, whilst BG tiles can use either (I have a question about this below, number 1).

- BG tiles can be flipped horizontally or vertically to save space, sprite tiles cannot.

- When drawing backgrounds there is no limit on what 8x8 tile can be drawn where and with which palette, unlike say the NES which (until later, rare mappers) had the 16x16 regional divison of background palette usage.

My questions, if I may!

1. Can BG tiles actually just simply use either palette, or does this only refer to the SMS's ability to draw sprites as BG tiles?

1a. If BG tiles can just use either palette, can you take a BG tile that is designated to use one palette, and tell it to actually draw with the other on the fly (and it just looks up the same indices but in the other palette)?

1b. If it works like this, is it 'free', and could you have multiple instances of the same tile on-screen but drawn with each of the two different palettes?

2. Are the colours chosen to go in one of the 16-colour palette exclusive to any degree, or could both palettes even be the exact same selection of colours if you wanted?

3. When a BG tile is drawn, whichever of the two palettes being used, is the transparency colour now opaque by default and I can see all 16 colours?

3a. The SMS can draw BG tiles in front of sprites, if I've assumed correctly that the transparency colour is usually opaque when drawing BG tiles, can they turn their transparency colour actually transparent in that case, and is it optional?

4. Is drawing BG tiles in front of the sprites 'free'?

5. Is flipping BG tiles 'free'?

6. Is it possible to beat the VRAM limits by swapping out animation tiles from VRAM during gameplay, like some games do on NES? Large player animations being what I'm most concerned with, would it be possible to just have the current frame of the player sprite's current animation in memory at any given time, perhaps at the cost of permanently reserving the largest possible number of tiles in a single player frame in VRAM (7, so far!)?

7. Are there any other nifty hardware features or tricks I should know?

8. Lastly, but unrelated to just graphics, I'd like to make a platformer that is one big map, is that doable with a clever SMS programmer at the helm of a SMS game, hypothetically?

Thanks a ton!
  View user's profile Send private message
  • Joined: 23 Jan 2010
  • Posts: 417
Reply with quote
Post Posted: Sun Oct 16, 2022 12:39 pm
Quote
- BG tiles can be flipped horizontally or vertically to save space, sprite tiles cannot.

This. The others questions are for experts here.
Quote
5. Is flipping BG tiles 'free'?

I guess that you have a limit of 448 unique tiles that can be fliped.
  View user's profile Send private message
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 14690
  • Location: London
Reply with quote
Post Posted: Sun Oct 16, 2022 12:45 pm
I think all of your questions have “yes” as the answer. The only part needing clarification is that sprites draw with colour index 0 as transparent; background tiles always draw colour 0. However when setting the foreground priority bit on a tile, colour index 0 is drawn as “background” (behind sprites) and the rest are drawn in front of sprites. So it looks like transparency but in reality, the “background” of those tiles is solid colour index 0. This may or may not match the border colour.

Making a big world map with art swapping out would be possible but would practically require you to make “corridor” areas with a few tiles and colours that the player would take several seconds to travel through as the assets are loaded. The speed of loading is much slower when the screen is kept on.
  View user's profile Send private message Visit poster's website
  • Joined: 16 Oct 2022
  • Posts: 41
Reply with quote
Post Posted: Sun Oct 16, 2022 1:16 pm
Maxim wrote
So it looks like transparency but in reality, the “background” of those tiles is solid colour index 0. This may or may not match the border colour.


Very interesting, thanks!

Maxim wrote
Making a big world map with art swapping out would be possible but would practically require you to make “corridor” areas with a few tiles and colours that the player would take several seconds to travel through as the assets are loaded. The speed of loading is much slower when the screen is kept on.


I was actually intending to try and get all the art assets (assuming I can save space by rotating out the current player sprite) into one single batch of 448 tiles, would that help me avoid having such loading sections do you think?
  View user's profile Send private message
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 14690
  • Location: London
Reply with quote
Post Posted: Sun Oct 16, 2022 3:04 pm
448 tiles for an entire game sounds a bit limiting.
  View user's profile Send private message Visit poster's website
  • Joined: 24 Mar 2021
  • Posts: 120
Reply with quote
Post Posted: Sun Oct 16, 2022 6:36 pm
Mondo wrote
- 448 tiles in VRAM at once, up to 256 of them can be sprite tiles, and any amount of the 448 can be Background tiles.
Stupid rules-lawyering lets you exceed this a little bit.

You have 16 KiB of VRAM, and each tile takes 32 bytes. That's a library of 512 tiles, but some VRAM has to be used for other things.

For example, describing where sprites appear ("sprite attribute table") takes 192 bytes.
Describing which tiles are used where in the background takes another 1792 bytes.

Combining the two constraints leaves you with 450 tiles. (The discrepancy is the unused 64 bytes in the middle of the sprite attribute table.)

The background is normally 32x28 tiles, but only 32x24 are displayed. You can steal four rows of them for 8 more tiles if you don't scroll vertically.

On the other hand, maybe you want to reserve more memory to swap between multiple different backgrounds, or multiple different sprite attribute tables. That eats into the tile budget.

Quote
3. When a BG tile is drawn, whichever of the two palettes being used, is the transparency colour now opaque by default and I can see all 16 colours?
No, index 0 in each palette is always transparent, regardless of sprite or background or background palette specification.

This "backdrop" palette is the same way all the contemporary systems appear to work - SMS, NES, SMD, SNES.

Quote
6. Is it possible to beat the VRAM limits by swapping out animation tiles from VRAM during gameplay, like some games do on NES?
Very much so, and far more capably than the NES. The NES is very bandwidth-limited, but the SMS can upload an awful lot of data while the screen is redrawing. At the cost of spending all CPU time during redraw, you should be able to upload close to 1KB while the screen is drawing the current frame.

Quote
8. Lastly, but unrelated to just graphics, I'd like to make a platformer that is one big map, is that doable with a clever SMS programmer at the helm of a SMS game, hypothetically?
The VDP imposes no limits here – it's really just about dynamically streaming tiles in.
  View user's profile Send private message
  • Joined: 06 Mar 2022
  • Posts: 598
  • Location: London, UK
Reply with quote
Post Posted: Sun Oct 16, 2022 8:47 pm
Mondo wrote
7. Are there any other nifty hardware features or tricks I should know?

A fair few, but they are mostly fairly specific tricks. Generally it's possible to do things like change register values and palette entries mid frame which can, depending on the requirements, allow some pushing of the envelope as well as funky dynamic scrolling effects, “parallax" effects, etc.

There are also a few bit masks that can be applied, with interesting effects, for example setting bit 2 of register 0 effectively duplicates the top 12 rows of the display.

In terms of other exotic features there's sprite "zooming" settings which aren't as usable as one might hope, and technically all of the above discussion has been about "mode 4" graphics although there are hidden away in the VDP 3 other (broadly less capable) graphics modes including a raw text mode.

Two rather more mundane features to note are that you can turn the display "off" which actually fills with the backdrop colour, meaning you don't need to use tile map space for simply rendering backdrop; and also the two scroll inhibit flags, which can be used to render fixed displays at the top (16px) and / or right hand side (64px) of the screen.

I think some of the settings are also sensitive to the exact VDP model (I know for a fact the sprite zooming is but others I'm a bit more hazy on). Also, if it's of interest, the Game Gear has some slightly more advanced capabilities, most notably a deeper palette.

One other thing you might want to consider if you're trying to be completely faithful to the hardware is that there is a limit to how fast you can write to VRAM, which means that strictly speaking not everything you can concieve of is possible, at least not with maximum frame rates.

lidnariq wrote
No, index 0 in each palette is always transparent, regardless of sprite or background or background palette specification.

Perhaps it's just the way I'm reading this, and if so, apologies, but it doesn't sound quite right to me - I think Maxim's explanation was clearer and is the way I think about it: background tiles don't really have true transparency; only in the very limited sense that "foreground" background tiles give color index 0 priority to sprites which might be rendered to coincide with them.
  View user's profile Send private message Visit poster's website
  • Joined: 29 Mar 2012
  • Posts: 879
  • Location: Spain
Reply with quote
Post Posted: Mon Oct 17, 2022 8:36 am
I think Maxim is right, color 0 is not transparent on background tiles, even with priority flag enabled
  View user's profile Send private message
  • Joined: 05 Sep 2013
  • Posts: 3763
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Mon Oct 17, 2022 8:38 am
Last edited by sverx on Mon Oct 17, 2022 8:42 am; edited 1 time in total
lidnariq wrote
No, index 0 in each palette is always transparent, regardless of sprite or background or background palette specification.

This "backdrop" palette is the same way all the contemporary systems appear to work - SMS, NES, SMD, SNES.


No, this is wrong AFAIK. Colors (both) at index 0 are NOT transparency colors when used in background tiles. You can have backgrounds using 16+16 real colors.

edit - sorry for seemingly being an idiot for posting this when two other fellow forum users had stated that. I didn't read the whole thing - my bad :|
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 3763
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Mon Oct 17, 2022 8:40 am
willbritton wrote
There are also a few bit masks that can be applied, with interesting effects, for example setting bit 2 of register 0 effectively duplicates the top 12 rows of the display.


This doesn't work on the updated VDP (the one in the SMS II)
  View user's profile Send private message Visit poster's website
  • Joined: 06 Mar 2022
  • Posts: 598
  • Location: London, UK
Reply with quote
Post Posted: Mon Oct 17, 2022 9:25 am
sverx wrote
This doesn't work on the updated VDP (the one in the SMS II)

👍 thanks @sverx!

If anyone's interested, here's a snippet of SystemVerilog from my VDP implementation (which at least seems to work :D)

I'm sure there are similar snippets to be found in emulator codebases.


  always_comb begin
    if (border_mode)
      pixel_color = { 1'b1, border_color }; // Border color is from the top half of the palette
    else if (foreground_tile && bg_tile_color)
      pixel_color = { palette_upper, bg_tile_color };
    else if (sprite_color)
      pixel_color = { 1'b1, sprite_color }; // Sprite colors are always from the top half of the palette
    else if (!foreground_tile)
      pixel_color = { palette_upper, bg_tile_color };
    else // i.e. foreground tile with transparent pixel
      pixel_color = { palette_upper, bg_tile_color };
  end


You can see that in all five cases an actual colour is rendered, either one of `border_color`, `bg_tile_color` or `sprite_color`. Also the last two cases can technically be collapsed into one, illustrating that there's no difference in treatment of foreground or background (priority/non-priority) background tiles, save for the priority in relation to sprites, which is allowed for by case 2 being separate from cases 4/5. I left case 4 & 5 separate for clarity.
  View user's profile Send private message Visit poster's website
  • Joined: 16 Oct 2022
  • Posts: 41
Reply with quote
Post Posted: Mon Oct 17, 2022 2:51 pm
Thanks for all the replies and info guys! Amazing

lidnariq wrote

Combining the two constraints leaves you with 450 tiles. (The discrepancy is the unused 64 bytes in the middle of the sprite attribute table.)


I want both horizontal and vertical scrolling, but maybe I can grab those two extra tiles, every tile counts!

lidnariq wrote
At the cost of spending all CPU time during redraw, you should be able to upload close to 1KB while the screen is drawing the current frame.


So is that close to 32 tiles I could animate with VRAM swapping, at the potential expense of things like parallax I guess? That is very generous though, where I've got to so far I could animate the player and all the enemies with that and have ample CPU time to spare.

willbritton wrote

In terms of other exotic features there's sprite "zooming" settings which aren't as usable as one might hope]


Interesting, that does sound useful on the face of it, what are the issues?

willbritton wrote

Two rather more mundane features to note are that you can turn the display "off" which actually fills with the backdrop colour, meaning you don't need to use tile map space for simply rendering backdrop


That's great! Is the backdrop colour its own thing, set independently of the colour choices in the palettes?

willbritton wrote
One other thing you might want to consider if you're trying to be completely faithful to the hardware is that there is a limit to how fast you can write to VRAM, which means that strictly speaking not everything you can concieve of is possible, at least not with maximum frame rates.


Yeah I would love it to feel authentic as possible, I might look into adding artificial slow-down if I feel like I'm pushing it too far. I've already (messily) coded sprite flickering based on sprite limits.

----------------------------------------------------

Also can I double check I've understood correctly, the two 16 colour palettes can share colours, and could even be identical if you wanted?
  View user's profile Send private message
  • Joined: 29 Mar 2012
  • Posts: 879
  • Location: Spain
Reply with quote
Post Posted: Mon Oct 17, 2022 3:26 pm
Mondo wrote
Thanks for all the replies and info guys! Amazing



So is that close to 32 tiles I could animate with VRAM swapping, at the potential expense of things like parallax I guess?

Parallax probably could still be done if you deal carefully with the Hblank int.


Mondo wrote

Interesting, that does sound useful on the face of it, what are the issues?

It only zooms well the first 4 sprites in the scanline on VDP1, and it's not working at all on the Megadrive


Mondo wrote

That's great! Is the backdrop colour its own thing, set independently of the colour choices in the palettes?

It's one of the colours of the background palette, index selected in a register

Mondo wrote

Also can I double check I've understood correctly, the two 16 colour palettes can share colours, and could even be identical if you wanted?

Yes
  View user's profile Send private message
  • Joined: 06 Mar 2022
  • Posts: 598
  • Location: London, UK
Reply with quote
Post Posted: Mon Oct 17, 2022 3:36 pm
Mondo wrote
willbritton wrote

In terms of other exotic features there's sprite "zooming" settings which aren't as usable as one might hope]


Interesting, that does sound useful on the face of it, what are the issues?


I believe that only the first 4 sprites are zoomable on the SMS1 and I *think* they work properly on the SMS2, perhaps others can confirm. (EDIT: thanks @kusfo!)

Here's a related thread that may be of interest.

Mondo wrote
willbritton wrote

Two rather more mundane features to note are that you can turn the display "off" which actually fills with the backdrop colour, meaning you don't need to use tile map space for simply rendering backdrop


That's great! Is the backdrop colour its own thing, set independently of the colour choices in the palettes?


The backdrop colour is one of the 16 colours in the upper palette, and is chosen by setting a register in the VDP. In other words, one of your 32 colours (specifically one of the upper 16) MUST be the backdrop colour. This will display both around the screen borders, depending on the display hardware, and also across the entire screen for periods when you have the display turned off. So, if you want the screen to go completely black, or you want the borders to be black, you have to set black up as your backdrop colour - i.e. one of the upper 16 colours must be black.

You can turn the screen off mid-frame, which which will result in horizontal bands of backdrop colour.

Mondo wrote
Also can I double check I've understood correctly, the two 16 colour palettes can share colours, and could even be identical if you wanted?

Correct, you can set all 32 colours to be whatever 6-bit RGB value you want and they could certainly all be set to the same RGB value, resulting in the same colour visually. Sometimes you can use this to effect to cut down on the number of tile definitions. As a very crude example, you could set up a tile which uses the lower palette to render some pattern, and if you set up the upper palette all to the same colour, hey presto you can switch between the pattern and a completely solid tile just by rendering the same tile with different palettes selected.

Also worth pointing out that often you end up having to duplicate colours between the upper and lower palette since you have to choose between the two when rendering a background tile and you are forced to choose the upper palette for sprites (and backdrop colour). Deciding which colours best go where is a thing!
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 14690
  • Location: London
Reply with quote
Post Posted: Mon Oct 17, 2022 7:06 pm
It’s worth considering also what games tend to do as that is as much the aesthetic as the potential possibilities.

- it’s unusual to use both palettes for tiles, because usually your sprite palette is optimised for your sprite needs (player, enemies)
- it’s very common to stream animations for the player sprite, but also for those to not be very high frame rate because it costs a lot of ROM space
- for the same reason, it’s common to have the player animated tiles be 3bpp - using the lower 8 sprite colours - in order to stream a bit faster
- games will often also stream tiles for a little background animation or parallax effects
- much more common is to see a few colours from the tile palette spent on palette animations, three colours gives you a directional palette scroll and a single colour can be enough to make things flash
- however as we don’t have multiple sprite palettes, it’s rare to see colour swapped enemies on the screen together
- because the sprite tiles can’t be flipped, it’s “free” (as in, no more expensive in ROM space) to have the player sprites not be mirror images when facing the opposite direction, if you are streaming tiles. Not all games bothered though, and mirroring while streaming was technically possible to save ROM.
- the sprite limit tends to mean you don’t have more than two enemies visible at once
- we can’t do status bars when scrolling bidirectionally without serious trickery
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 3763
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Tue Oct 18, 2022 7:23 am
Mondo wrote
lidnariq wrote
At the cost of spending all CPU time during redraw, you should be able to upload close to 1KB while the screen is drawing the current frame.


So is that close to 32 tiles I could animate with VRAM swapping, at the potential expense of things like parallax I guess? That is very generous though, where I've got to so far I could animate the player and all the enemies with that and have ample CPU time to spare.


From my experience, given that you also have to update the SAT in VRAM during vblank, you can probably safely update quickly only approximately 24 tiles - of course you can update tiles even outside vblank, you just have to slow down.

But this value is for NTSC/60Hz, if you are aiming to PAL/50Hz compatibility only there's plenty more time, as vblank lasts 121 lines (instead of 70) in 50Hz mode.
  View user's profile Send private message Visit poster's website
  • Joined: 29 Mar 2012
  • Posts: 879
  • Location: Spain
Reply with quote
Post Posted: Tue Oct 18, 2022 7:53 am
As I think he's doing a PC game (With Master System limitations), I think he can assume 50hz Vblank time :-p
  View user's profile Send private message
  • Joined: 16 Oct 2022
  • Posts: 41
Reply with quote
Post Posted: Tue Oct 18, 2022 5:40 pm
kusfo wrote
Parallax probably could still be done if you deal carefully with the Hblank int.

Good to know! I wasn't planning on it, but with having the one single big level, open on the vertical as well as the horizontal axis, that might actually make using scanline parallax unworkable anyway right. It would be cool though, ideas are coming to me.. maybe I could look at animation parallax like Maxim mentioned, if the tile and tile manipulation budgets allow!

kusfo wrote
It only zooms well the first 4 sprites in the scanline on VDP1, and it's not working at all on the Megadrive

willbritton wrote
I believe that only the first 4 sprites are zoomable on the SMS1 and I *think* they work properly on the SMS2, perhaps others can confirm. (EDIT: thanks @kusfo!)
Here's a related thread that may be of interest.

Hmm yeah! The thread was an interesting read too. That's a tricky one isn't it. If I was making a real SMS game now, I'm pretty certain I wouldn't use it because I'd like it to work on everything. So maybe I should stick with that line of thinking. Are there any other features like that, that don't work on one of the SMS models or the Mega Drive?

kusfo wrote
It's one of the colours of the background palette, index selected in a register

willbritton wrote
The backdrop colour is one of the 16 colours in the upper palette, and is chosen by setting a register in the VDP. In other words, one of your 32 colours (specifically one of the upper 16) MUST be the backdrop colour. This will display both around the screen borders, depending on the display hardware, and also across the entire screen for periods when you have the display turned off. So, if you want the screen to go completely black, or you want the borders to be black, you have to set black up as your backdrop colour - i.e. one of the upper 16 colours must be black.
You can turn the screen off mid-frame, which which will result in horizontal bands of backdrop colour.

That sounds useful indeed, the game is set in an indoor location with a lot of black in the background, so I might be using that feature a lot if this were a real SMS game. It also could be used for different coloured screen flashes to sell explosions or impacts or something maybe! White, red and black are good ones, although i don't think I have red in the top palette yet.

kusfo wrote
Yes

willbritton wrote
Correct, you can set all 32 colours to be whatever 6-bit RGB value you want and they could certainly all be set to the same RGB value, resulting in the same colour visually. Sometimes you can use this to effect to cut down on the number of tile definitions. As a very crude example, you could set up a tile which uses the lower palette to render some pattern, and if you set up the upper palette all to the same colour, hey presto you can switch between the pattern and a completely solid tile just by rendering the same tile with different palettes selected.
Also worth pointing out that often you end up having to duplicate colours between the upper and lower palette since you have to choose between the two when rendering a background tile and you are forced to choose the upper palette for sprites (and backdrop colour). Deciding which colours best go where is a thing!

Thank goodness, I'd been doing lots of work just assuming I could put any colour in either palette, but then it dawned on me that other 8 bit systems probably wouldn't be nearly so nice! I've actually ended up with several colours that appear in both palettes so far, when you first hear about the SMS's capabilities you think that of course you'd try and go for 32 unique colours, but actually, the way two palettes with some shared colours can work together is incredibly powerful and can make the game's visuals really cohesive.

Maxim wrote
It’s worth considering also what games tend to do as that is as much the aesthetic as the potential possibilities.
- it’s unusual to use both palettes for tiles, because usually your sprite palette is optimised for your sprite needs (player, enemies)
- it’s very common to stream animations for the player sprite, but also for those to not be very high frame rate because it costs a lot of ROM space
- for the same reason, it’s common to have the player animated tiles be 3bpp - using the lower 8 sprite colours - in order to stream a bit faster
- games will often also stream tiles for a little background animation or parallax effects
- much more common is to see a few colours from the tile palette spent on palette animations, three colours gives you a directional palette scroll and a single colour can be enough to make things flash
- however as we don’t have multiple sprite palettes, it’s rare to see colour swapped enemies on the screen together
- because the sprite tiles can’t be flipped, it’s “free” (as in, no more expensive in ROM space) to have the player sprites not be mirror images when facing the opposite direction, if you are streaming tiles. Not all games bothered though, and mirroring while streaming was technically possible to save ROM.
- the sprite limit tends to mean you don’t have more than two enemies visible at once
- we can’t do status bars when scrolling bidirectionally without serious trickery

Wow some really great points and info there, thanks. You've got me thinking about animation parallax, that could be a lot of fun. About status bars/HUDs when scrolling bidirectionally, I did intend to have one, would it be possible but with some kind of drawback or limit perhaps? The preliminary one I made is at the bottom of the screen and four tiles in height.

---------------------------------------

A couple of other things that came to me, I'd like to have lots of animated collectibles floating in the air like rings in Sonic, that you collide with and they disappear. The sprite limit would probably be a problem, would it be a big deal to use background tiles for them? I was thinking maybe I could put them in areas where they're surrounded with black BG tiles (the predominate colour in the BG), and then just replace them with a black BG tile when you collect them.

The second thing, if I have one big level and the game has to remember a lot of information about what you've done, doors opened, collectibles picked up, maybe certain enemies defeated, could that be a problem?

Thanks again guys, this is invaluable.
  View user's profile Send private message
  • Joined: 06 Mar 2022
  • Posts: 598
  • Location: London, UK
Reply with quote
Post Posted: Tue Oct 18, 2022 5:56 pm
Mondo wrote
About status bars/HUDs when scrolling bidirectionally, I did intend to have one, would it be possible but with some kind of drawback or limit perhaps? The preliminary one I made is at the bottom of the screen and four tiles in height.

You won't be able to use scroll inhibit to implement a status bar at the bottom of the display. If you don't need it overlayed with transparency you can apportion some of your background tiles to the bar, but this will complicate scrolling. Alternatively use the sprite plane. That is what the SMS Sonic the Hedgehog does for it's status information (appears at the top of the screen) IIRC.

Mondo wrote
A couple of other things that came to me, I'd like to have lots of animated collectibles floating in the air like rings in Sonic, that you collide with and they disappear. The sprite limit would probably be a problem, would it be a big deal to use background tiles for them? I was thinking maybe I could put them in areas where they're surrounded with black BG tiles (the predominate colour in the BG), and then just replace them with a black BG tile when you collect them.

Yeah totally doable, again I believe the SMS version of Sonic does this for ring animations. I guess they are always over solid backgrounds to allow it.

Mondo wrote
The second thing, if I have one big level and the game has to remember a lot of information about what you've done, doors opened, collectibles picked up, maybe certain enemies defeated, could that be a problem?

I doubt you'll find lack of RAM an issue for simply storing user info. 8K is plenty. But technically carts could expand on the system RAM anyway so given you are emulating the system I feel like that should be an allowable trick to pull!
  View user's profile Send private message Visit poster's website
  • Joined: 17 Jun 2017
  • Posts: 19
Reply with quote
Post Posted: Tue Oct 18, 2022 8:38 pm
Quote
f I have one big level and the game has to remember a lot of information about what you've done, doors opened, collectibles picked up, maybe certain enemies defeated, could that be a problem?


Quote
I doubt you'll find lack of RAM an issue for simply storing user info. 8K is plenty.


yes, these examples are all true/false values so could be stored in 1-bit, meaning each byte could hold 8 object states. You'd have ~8000 of these bytes so there would plenty of space for state like this.

In a real game RAM does affect the size of individual levels and variety of their graphics. The level tilemaps take up a lot of space so will probably be stored in compressed form on the cartridge, but need to be decompressed to RAM on level load so they can be scrolled quickly. Games require a big chunk of RAM for this RAM buffer, but even 4KB (half the RAM) can only hold around 2000 tiles, meaning a level size of 44x44 tiles which is barely more than 1 screen each dimension. Instead, actual SMS games group individual background tiles together into 'metatiles', of say 2x2 tiles, and each byte in the tilemap will refer to one of 256 of these. 2x2 metatiles (16px by 16px) expand the max level size by 8x, and 4x4 tiles (32px by 32px) expand it by 16x. Metatiles therefore expand the total level size at the cost of graphical variety, as it effectively leaves you with only 256 possible (though larger) tiles. With corridor areas though you could always swap out these 256 metatiles with another set.

Even with these measures you might find the level sizes disappointing. 64x64 metatiles will take up 4KB of RAM. If they are 4x4 (32px by 32px) your map will be 2048x2048 pixels, which is only about 8 screens wide and 8 high. This is why large levels in actual SMS games are split up into smaller chunks, with a fade in and fade out transition between them. As this is a pretend SMS game you can perhaps take some creative license and say that you could probably overcome these limitations on the real system and make seamless transitions given enough time, but it's just something worth bearing in mind if you don't want to stray too far from the 8-bit aesthetic and feel :)
  View user's profile Send private message
  • Joined: 16 Oct 2022
  • Posts: 41
Reply with quote
Post Posted: Tue Oct 18, 2022 8:48 pm
willbritton wrote
You won't be able to use scroll inhibit to implement a status bar at the bottom of the display. If you don't need it overlayed with transparency you can apportion some of your background tiles to the bar, but this will complicate scrolling. Alternatively use the sprite plane. That is what the SMS Sonic the Hedgehog does for it's status information (appears at the top of the screen) IIRC.

Right! I don't need transparency and I'm a massive sucker for clean status bars and HUD design, so I'd love to use BG tiles to have graphics right across the bottom of the screen if possible. Would it affect the speed I could scroll at vertically or something?

willbritton wrote
Yeah totally doable, again I believe the SMS version of Sonic does this for ring animations. I guess they are always over solid backgrounds to allow it.

Great stuff.

willbritton wrote
I doubt you'll find lack of RAM an issue for simply storing user info. 8K is plenty. But technically carts could expand on the system RAM anyway so given you are emulating the system I feel like that should be an allowable trick to pull!

Music to my ears, thanks Will.
  View user's profile Send private message
  • Joined: 06 Mar 2022
  • Posts: 598
  • Location: London, UK
Reply with quote
Post Posted: Tue Oct 18, 2022 11:29 pm
Mondo wrote
Right! I don't need transparency and I'm a massive sucker for clean status bars and HUD design, so I'd love to use BG tiles to have graphics right across the bottom of the screen if possible. Would it affect the speed I could scroll at vertically or something?

If you were actually writing a native SMS game I'd say you'd be better off using sprites simply because cancelling out the scrolling becomes quite a problem with background tiles. If you're trying to scroll in both directions, you basically need to ensure there is always a solid bar at the bottom of the screen to act as the background to your status bar. I guess you could reset the scroll registers based on a scan line interrupt 4 tiles off the bottom of the screen and hold a blank 4 rows in the tile map somewhere convenient, then either use sprites to render the status information or store that in bg tiles too. In the latter case you'd need to fix the horizontal scrolling as well as the vertical.

willbritton wrote
willbritton wrote
I doubt you'll find lack of RAM an issue for simply storing user info. 8K is plenty. But technically carts could expand on the system RAM anyway so given you are emulating the system I feel like that should be an allowable trick to pull!

Music to my ears, thanks Will.

np, but @eljay makes a good point about RAM requirements for graphics. Not sure how much effort you want to spend figuring out how feasible your game would actually be to implement on the SMS but as eljay says you might take some creative license. I guess a similar argument applies to ROM size if your game is going to be enormous in terms of assets. Again here you could choose to play the card that if you were in a position to manufacturer your own cartridge today you could probably achieve practically unlimited use of ROM and RAM mapping, with the only hard constraint being you are limited to exposing a total of 64KB of memory to the CPU at any one time.

Perhaps if your game is really good someone here might be interested in porting it to the system one day :D
  View user's profile Send private message Visit poster's website
  • Joined: 16 Oct 2022
  • Posts: 41
Reply with quote
Post Posted: Wed Oct 19, 2022 3:01 pm
eljay wrote

yes, these examples are all true/false values so could be stored in 1-bit, meaning each byte could hold 8 object states. You'd have ~8000 of these bytes so there would plenty of space for state like this.
In a real game RAM does affect the size of individual levels and variety of their graphics. The level tilemaps take up a lot of space so will probably be stored in compressed form on the cartridge, but need to be decompressed to RAM on level load so they can be scrolled quickly. Games require a big chunk of RAM for this RAM buffer, but even 4KB (half the RAM) can only hold around 2000 tiles, meaning a level size of 44x44 tiles which is barely more than 1 screen each dimension. Instead, actual SMS games group individual background tiles together into 'metatiles', of say 2x2 tiles, and each byte in the tilemap will refer to one of 256 of these. 2x2 metatiles (16px by 16px) expand the max level size by 8x, and 4x4 tiles (32px by 32px) expand it by 16x. Metatiles therefore expand the total level size at the cost of graphical variety, as it effectively leaves you with only 256 possible (though larger) tiles. With corridor areas though you could always swap out these 256 metatiles with another set.
Even with these measures you might find the level sizes disappointing. 64x64 metatiles will take up 4KB of RAM. If they are 4x4 (32px by 32px) your map will be 2048x2048 pixels, which is only about 8 screens wide and 8 high. This is why large levels in actual SMS games are split up into smaller chunks, with a fade in and fade out transition between them. As this is a pretend SMS game you can perhaps take some creative license and say that you could probably overcome these limitations on the real system and make seamless transitions given enough time, but it's just something worth bearing in mind if you don't want to stray too far from the 8-bit aesthetic and feel :)

Thanks for all that detailed info! Yeah I'd love to keep the one big level, I may hide behind the fact it's possibly possible, by streaming the outer edges of the tile map into RAM from ROM as I go or something? Same with having a graphical HUD made of BG tiles at the bottom of the screen whilst bidirectionally scrolling, I'm in dodgy waters there too it seems. Let's just say I hired a programming genius haha

willbritton wrote
If you were actually writing a native SMS game I'd say you'd be better off using sprites simply because cancelling out the scrolling becomes quite a problem with background tiles. If you're trying to scroll in both directions, you basically need to ensure there is always a solid bar at the bottom of the screen to act as the background to your status bar. I guess you could reset the scroll registers based on a scan line interrupt 4 tiles off the bottom of the screen and hold a blank 4 rows in the tile map somewhere convenient, then either use sprites to render the status information or store that in bg tiles too. In the latter case you'd need to fix the horizontal scrolling as well as the vertical.

I might have to push my luck to breaking point with the HUD! You can tell I've got my heart set on one, right?

willbritton wrote
np, but @eljay makes a good point about RAM requirements for graphics. Not sure how much effort you want to spend figuring out how feasible your game would actually be to implement on the SMS but as eljay says you might take some creative license. I guess a similar argument applies to ROM size if your game is going to be enormous in terms of assets. Again here you could choose to play the card that if you were in a position to manufacturer your own cartridge today you could probably achieve practically unlimited use of ROM and RAM mapping, with the only hard constraint being you are limited to exposing a total of 64KB of memory to the CPU at any one time.

I do want this to be something that's authentic to the SMS in that it looks like it could have ran on the hardware, I'll be trying my absolute best to respect non-negotiable hard limits to achieve that. However i'd also like to push what the SMS could have potentially done if it means I can achieve the game that is in my mind, and in terms of art and general aesthetic, I'm just trying to make the game look as good as possible within my abilities and the amazing graphical power the SMS has.

willbritton wrote
Perhaps if your game is really good someone here might be interested in porting it to the system one day :D


That would be insane, a great motivator!! As long as they don't have to pore through my embarassing code :D

----------------------------------------------------------

Maybe when I've got something with all the components present and working, a vertical slice I think they call it in the modern game industry, I could post a video here and you can tell me if I've lost the plot.
  View user's profile Send private message
  • Joined: 14 Oct 2008
  • Posts: 508
Reply with quote
Post Posted: Wed Oct 19, 2022 4:06 pm
lidnariq wrote

Quote
6. Is it possible to beat the VRAM limits by swapping out animation tiles from VRAM during gameplay, like some games do on NES?
Very much so, and far more capably than the NES. The NES is very bandwidth-limited, but the SMS can upload an awful lot of data while the screen is redrawing. At the cost of spending all CPU time during redraw, you should be able to upload close to 1KB while the screen is drawing the current frame.

I suppose 1KB is enough to be better in practical terms. Though NES games that achieved background animation would often do it through bankswapping video ROM, making swapping a tileset as simple as writing to a bankswap register, giving potentially almost unlimited "bandwidth". There's pros and cons to each (RAM or ROM-based pattern memory), as so demonstrated by comparing the US and EU versions of Dragon's Lair.
  View user's profile Send private message
  • Joined: 23 Jan 2010
  • Posts: 417
Reply with quote
Post Posted: Wed Oct 19, 2022 5:14 pm
Quote
This is why large levels in actual SMS games are split up into smaller chunks, with a fade in and fade out transition between them

Ah! I love it. This explain now the things for me.
  View user's profile Send private message
  • Joined: 16 Oct 2022
  • Posts: 41
Reply with quote
Post Posted: Wed Nov 30, 2022 1:13 pm
I'm dividing my meta sprites into 8x8 sprites for the flicker system, and it made me think, is there any problem with having an entity's sprites in an unaligned pattern to save on tiles? I've looked at a few game's tilesets using Meka and an entity's 8x8 sprites have pretty much all seemed to be perfectly aligned so far, eg -

oo
oo
oo

Perhaps they were just drawn specifically to fit into a rectangle for simplicity, but I definitely have frames of animation for the player where it would save tiles to have the 8x8 sprites organised into a pyramid for example, but then maybe the next frame has a different unaligned arrangement also. eg -

..o................oo
.oo......>>......oo
ooo..............oo

Is this a problem at all?
  View user's profile Send private message
  • Joined: 29 Mar 2012
  • Posts: 879
  • Location: Spain
Reply with quote
Post Posted: Wed Nov 30, 2022 2:25 pm
There's no problem. I suppose most games used the fixed pattern just to simplify the information needed to render a metasprite
  View user's profile Send private message
  • Joined: 16 Oct 2022
  • Posts: 41
Reply with quote
Post Posted: Wed Nov 30, 2022 3:40 pm
kusfo wrote
There's no problem. I suppose most games used the fixed pattern just to simplify the information needed to render a metasprite


Thanks for that! I thought this would be the case but you never know, best to ask you guys!
  View user's profile Send private message
  • Joined: 09 Jun 2014
  • Posts: 365
Reply with quote
Post Posted: Thu Dec 01, 2022 9:10 am
i noticed that Castle of Illusion uses a couple of frames out of the 8x8 grid. The frame where Mickey gets hit, his hand is not on the grid.

The game uses 8x16 sprites though. Is there an advantage to 8x8 tiles?
  View user's profile Send private message Visit poster's website
  • Joined: 29 Mar 2012
  • Posts: 879
  • Location: Spain
Reply with quote
Post Posted: Thu Dec 01, 2022 9:48 am
You can have double sprite tiles on the screen at once (as you can have 64 8x16 sprites instead of 64 8x8). Obviously, this is useful if most of the sprites are taller than 8x8
  View user's profile Send private message
  • Joined: 16 Oct 2022
  • Posts: 41
Reply with quote
Post Posted: Thu Dec 01, 2022 11:20 am
Last edited by Mondo on Thu Dec 01, 2022 7:49 pm; edited 2 times in total
That's actually a really good point, thanks Slogra! Maybe I should've gone with 8x16. Please correct me guys if I'm wrong, but one of my main reasons to stick with 8x8 was because I thought I might run into funkiness with the sprites-per-scanline rule, I have plenty of 8 and 24 pixel tall metasprites y'see, so there'd be lots of 'empty' portions of sprites on-screen at times with 8x16 that I assume would be triggering that rule despite being transparent? My sprite flickering system is simple, chosen 8x8 sprites just aren't drawn at all when there are more than 8 on a scanline, to bring it down to no more than 8 on a scanline anywhere on-screen. But I think there was sprite flickering systems in some games that turned sprites on and off whilst drawing to the screen, and thus you just didn't see portions of 8x8 or 8x16 sprites rather than the whole thing, so perhaps that system would let me use 8x16 sprites with no drawbacks.. (except maybe CPU time whilst drawing being used up to some degree?)? I'd have to see if i could code it though :/ :D

edit: I didn't think, a slight drawback might be 8x16 sprites taking up more space in memory when what you're drawing doesn't need the extra height, like if I started to use 8x16 on this current project now. But if from the start you had drawn all the graphics specifically with it in mind, it'd probably not be much of an issue. I'd love to try that one day!
  View user's profile Send private message
  • Joined: 06 Mar 2022
  • Posts: 598
  • Location: London, UK
Reply with quote
Post Posted: Thu Dec 01, 2022 12:34 pm
Yes, the 8 sprites per line restriction applies regardless of whether or not the colour is opaque or transparent, and also applies to 8x16 sprites, since the limitation is presumably that for each scanline there are eight 8-bit shift registers which hold the sprite information for that line, and once they are used up that's it! The transparency handling happens "downstream" of those shift registers, so unfortunately transparent pixels still count at that stage.
  View user's profile Send private message Visit poster's website
  • Joined: 16 Oct 2022
  • Posts: 41
Reply with quote
Post Posted: Thu Dec 01, 2022 3:47 pm
willbritton wrote
Yes, the 8 sprites per line restriction applies regardless of whether or not the colour is opaque or transparent, and also applies to 8x16 sprites, since the limitation is presumably that for each scanline there are eight 8-bit shift registers which hold the sprite information for that line, and once they are used up that's it! The transparency handling happens "downstream" of those shift registers, so unfortunately transparent pixels still count at that stage.


Right, thanks Will! As an aside, has anyone ever tried revising the Master System hardware itself, improving it? Perhaps just in FPGA form, like that 15 sprite-per-line upgrade some NES cores add.
  View user's profile Send private message
  • Joined: 06 Mar 2022
  • Posts: 598
  • Location: London, UK
Reply with quote
Post Posted: Thu Dec 01, 2022 5:10 pm
Mondo wrote
Right, thanks Will! As an aside, has anyone ever tried revising the Master System hardware itself, improving it? Perhaps just in FPGA form, like that 15 sprite-per-line upgrade some NES cores add.

Yes! See this thread.

I actually just finished recording a teaser video for the crowdfunding campaign, which I can't share just yet to avoid premature shares, but here's a little snippet (inspired by a comment earlier in this thread as a matter of fact) you might find quite relevant!

https://drive.google.com/file/d/1CuzpKAXpfxb_SOMQtAENnfvcF-BdlPqp/view?usp=share_link

Note that I haven't actually tried any games with more than 8 sprites per line yet, but will definitely report back once I do.
  View user's profile Send private message Visit poster's website
  • Joined: 06 Mar 2022
  • Posts: 598
  • Location: London, UK
Reply with quote
Post Posted: Thu Dec 01, 2022 7:20 pm
Update:

Have made a quick experiment with Double Dragon and am not convinced I can see any difference. EDIT: I mean, maybe a slight improvement?? Definitely not sure...

Video with SPRITES_PER_LINE = 8

Video with SPRITES_PER_LINE = 16

Later on, I'll have a proper play with a test program and confirm that it's really allowing 16 sprites to appear on the same line.

I should note that the way I've written it, changing this constant will also affect the so-called "sprite overflow" status bit correspondingly, so we wouldn't expect that to be active until an attempt to render 17 sprites on a line, as opposed to 9. I might have expected that to upset some games which rely on that flag in some way.[/i]
  View user's profile Send private message Visit poster's website
  • Joined: 16 Oct 2022
  • Posts: 41
Reply with quote
Post Posted: Thu Dec 01, 2022 8:14 pm
Oh nice, I have read that thread before, but I must've missed that titbit! So not only is someone doing it, it's you! :D

It may break some games that rely on the limits in some way, I think that happens with the NES implementation, but it's an awesome feature. Breaking the 64 sprites onscreen at once rule would also be great, I saw you mention that too.

Yeah it looks like it's working to me in that second video! When the enemies and player are lined up and there are wider metasprites involved like attack frames or someone on the floor, there's flickering on the 8-sprite video and none on the 16 sprite video that I can see. There's sometimes extra flickering in DD though. The player and 3 enemies just walking around is a maximum of 8 sprites on a single scanline but they'll flicker when they overlap. Depth-fighting or something?
  View user's profile Send private message
  • Joined: 06 Mar 2022
  • Posts: 598
  • Location: London, UK
Reply with quote
Post Posted: Thu Dec 01, 2022 8:51 pm
Mondo wrote
Breaking the 64 sprites onscreen at once rule would also be great, I saw you mention that too.

Certainly possible, but raises a few challenges for backwards compatibility in that you'd need a different organisation for the Sprite Attribute Table. At the moment it's 256 bytes, of which 192 is used for sprite data and 64 is "spare". So to handle more than 64 sprites you'd need to take the 3 bytes per extra sprite from somewhere else in VRAM, most likely you'd sacrifice tilemap space, or alternatively add some more VRAM (my prototype can handle up to 128KB at the moment)

EDIT: I'd have to sit down and look at the HDL, but I think perhaps if I changed that 64 constant to, say, 128 right now, it might have the effect of using the first 128 bytes of the Sprite Attribute Table for vpos and then it would look for hpos and tile index all the way from byte 128 to 384 bytes from the start of the table, i.e. it would take the extra 128 bytes from the area of VRAM after the SAT. With the SAT in default position of $3f00 that would just push it past the 16KB mark, but with the SAT further down you could still fit within 16KB at the expense of some tile data.

The other consideration is timing - the Sprite Attribute Table needs to process in hblank, which effectively limits the maximum number of sprites it can contain. The retcon-av can probably handle a very large number because it processes very quickly, but again in terms of backward compatibility it might throw the timings off for older games.
  View user's profile Send private message Visit poster's website
  • Joined: 16 Oct 2022
  • Posts: 41
Reply with quote
Post Posted: Thu Dec 01, 2022 9:59 pm
You really know your onions! I'd love to see these features in the end product, even if they do end up a bit niche due to compatibility problems, but I'd understand if they weren't high-priority! Maybe down the line after the Retcon-AV is released, some homebrew developers might make good use of the features that don't play nicely with the original games.
  View user's profile Send private message
  • Joined: 06 Mar 2022
  • Posts: 598
  • Location: London, UK
Reply with quote
Post Posted: Fri Dec 02, 2022 10:03 am
Mondo wrote
You really know your onions! I'd love to see these features in the end product, even if they do end up a bit niche due to compatibility problems, but I'd understand if they weren't high-priority! Maybe down the line after the Retcon-AV is released, some homebrew developers might make good use of the features that don't play nicely with the original games.

Thanks for the kind words, although compared with many others on this forum I feel like mine are still baby onions x-D

The plan is to just open source the HDL so that anyone can install, or indeed write or modify, their own graphics implementation. I will supply a project intended for as "standard" SMS implementation as possible, with helpful switches for keen modders; and will likely start in on some other major similar chips (NES PPU, etc.) in the future, but otherwise will leave to people's imaginations.
  View user's profile Send private message Visit poster's website
Reply to topic



Back to the top of this page

Back to SMS Power!