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 - Noob questions about SMS/GG tiles...

Reply to topic
Author Message
  • Joined: 13 Apr 2005
  • Posts: 246
  • Location: Aracruz - ES, Brazil
Reply with quote
Noob questions about SMS/GG tiles...
Post Posted: Sat Feb 13, 2021 6:18 pm
Ok... I know there's some topics in this forum who already said something about some of my doubts, but I want to clarify myself about some informations and I don't want to dig in some 5 years old topic. So, let's create a new one...


1) There's one topic who talks about zommed sprites, and they are almost not being used because it results in a very blocky sprites, and they are buggy on SMS1. But what is always discussed is SMS/GG sprites can be zoomed to 2x (8x8 to 16x16, and 8x16 to 16x32), I saw at Sega Retro page the sprites can be zoomed up to 32x32. The question is: Is this information true? The SMS/GG hardware can zoom an 8x8 sprite not only into a 16x16 sprite, but up to 32x32 (4x), who also includes 24x24 (3x)?


2) I saw about the background tiles can be set to have high or low priority. Tiles with low priority will be overlayed by the sprite table, and tiles with high priority will overlay the sprite table. Good example is found at Sonic 1's Green Hill Zone Acts 1 and 2. Just to be sure, I must make the question: Can a background tile have "transparent colors"? When using a background tile with a "transparent color", is it possible to determine which color will be the drawing table? If yes, is it possible to change the drawing table's color on the fly? And, to finish, is it possible mix two background tiles, one with low and one with high priority, at the same "space"?


Thanks for your attention...
  View user's profile Send private message
  • Joined: 08 Sep 2018
  • Posts: 254
Reply with quote
Post Posted: Sat Feb 13, 2021 6:33 pm
These are rather hard questions to answer.
Starting with 1.
Here is a VDP register for the SMS/GG/MegaDrive(In SMS Mode)
Quote

Register $01 - Mode Control No. 2

D7 - No effect
D6 - (BLK) 1= Display visible, 0= display blanked.
D5 - (IE0) 1= Frame interrupt enable.
D4 - (M1) Selects 224-line screen for Mode 4 if M2=1, else has no effect.
D3 - (M3) Selects 240-line screen for Mode 4 if M2=1, else has no effect.
D2 - No effect
D1 - Sprites are 1=16x16,0=8x8 (TMS9918), Sprites are 1=8x16,0=8x8 (Mode 4)
D0 - Sprite pixels are doubled in size.


Note that you can set bit 0 and bit 1 to get a 16x16 tile sprite at double the size but this feature may be buggy or limited as the VDP I believe needs to be set to TMS9918 mode which is not desirable for the platform.

for question 2 you "Can" have "Transparent" tiles by quickly swapping the priority bit during vblank. If you manage your tiles color usage then you can using 2 colors only have one of the colors be your "Transparent" color... otherwise all 15 colors after the background/cutout mask color will give the "Transparent" look for tiles you are flipping the priority bit on.
You can change colors in a palette as you please but you need to be in vblank first.
Further more you cannot have a tile in the same space as another tile, this includes tiles with a high priority bit and a low priority bit. This is because the SMS/GG only has one tile layer.

Lastly, I do not understand this question.
Quote
is it possible to determine which color will be the drawing table?


You can research this yourself with either Charles MacDonald's documentation or poke around all the the documents available on SMS Power
https://www.smspower.org/uploads/Development/msvdp-20021112.txt
https://www.smspower.org/Development/Documents
  View user's profile Send private message
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 13627
  • Location: London
Reply with quote
Post Posted: Sat Feb 13, 2021 7:43 pm
The 32x32 sprite text references a page talking about MSX, which is not talking about sprite zooming at all. It’s nonsense.

For both tiles and sprites you can consider palette index 0 as transparent, but then the “background” of everything for the tile takes on colour 0. Alternatively you can say that for a tile with high priority, pixels with colour 0 retains low priority. The end result is the same. You can’t mix tiles in the same space - “foreground” tiles have to have a single colour “background”.
  View user's profile Send private message Visit poster's website
  • Joined: 13 Apr 2005
  • Posts: 246
  • Location: Aracruz - ES, Brazil
Reply with quote
Post Posted: Sat Feb 13, 2021 10:36 pm
Thanks for the info. I knew the 32x32 thing was a bulls**t, but I wanted to check it in the right place. I just don't know how this information was put as a SMS specification, specially when the source pointed to a MSX thread...

And the question about the background thing, I knew it could not be possible. Just a double check to see if I was missing something...

Anyway, thanks for the attention and the answers. It was very instrutive... :)
  View user's profile Send private message
  • Joined: 05 Sep 2013
  • Posts: 2905
Reply with quote
Post Posted: Sun Feb 14, 2021 3:30 pm
I seem to remember that the sprite zoom bit works on legacy (TMS9918) modes too, so I think a 16×16 monocolor sprite should turn into a zoomed 32×32 sprite. Also, I have no way to confirm this.

As for the priority BG tiles, the pixels with 0 values are the only ones that aren't drawn in front of the sprites. You can't change that 0 to anything else, and you can't have any additional values pixels to be drawn behind sprites. So you either use no priority, sprites are always in front, or priority, where everything that is NOT using color 0 is drawing in front of sprites.

Note that you can of course change the color associated with entry #0, just like any other color in the palette (precisely, in both of them).
  View user's profile Send private message Visit poster's website
  • Joined: 13 Apr 2005
  • Posts: 246
  • Location: Aracruz - ES, Brazil
Reply with quote
Post Posted: Mon Feb 15, 2021 4:49 pm
sverx wrote
I seem to remember that the sprite zoom bit works on legacy (TMS9918) modes too, so I think a 16×16 monocolor sprite should turn into a zoomed 32×32 sprite. Also, I have no way to confirm this.

Well... It's an interesting information. If a sprite can be zoomed into a 32x32 sprite, it can be used, even in monocolor mode, to do some tricks.

The question is it was said this information is specified to the MSX hardware. So, if someone want to dismitify this, a homebrew showing this technique must appear as a proofy of concept showing it's possible to the SMS hardware can zoom a sprite to 32x32. While such homebrew don't appear, the 16x16 / 16x32 is the max zooming possible.



sverx wrote
As for the priority BG tiles, the pixels with 0 values are the only ones that aren't drawn in front of the sprites. You can't change that 0 to anything else, and you can't have any additional values pixels to be drawn behind sprites. So you either use no priority, sprites are always in front, or priority, where everything that is NOT using color 0 is drawing in front of sprites.

Note that you can of course change the color associated with entry #0, just like any other color in the palette (precisely, in both of them).

More interesting info. Thank you... :)





Now, some more noob questions.

1) When a sprite is zoomed, is it possible to allign 8 zommed sprites in 16x16 in the same line, and it will not flicker, right? Or 8 zommed sprites will count as 16 no-zoomed sprites, and the flickering will be activated with more than just 4 zommed sprites in the same line?

2) Is it possible to mix zoomed and no-zoomed sprites to display both in the same screen / line?

3) When you allign more than 8 sprites in the same line, the flickering will be activated. Question: Is it possible to set sprites to have flickering priority to not flicker, or set the sprite to just "disapear", giving priority to other sprites to be shown when the max number of sprites per line exceed?
  View user's profile Send private message
  • Joined: 05 Sep 2013
  • Posts: 2905
Reply with quote
Post Posted: Mon Feb 15, 2021 5:02 pm
rouken wrote
If a sprite can be zoomed into a 32x32 sprite, it can be used, even in monocolor mode, to do some tricks.


This seems to confirm it. (MAG bit)

BTW keep in mind that in 'legacy' TMS9918 modes, you can't have more than 4 sprites appear on a scanline, and your can't have legacy mode sprites and mode 4 (SMS own mode) background at the same time.

Also, you can't mix zoomed and not zoomed sprites anyway, and you can't mix normal and tall sprites, split screen apart - and there's no such thing as 'flicker', the chip will simply draw the first sprites listed until there are 4 (or 8 in mode 4) and simply won't draw any more than those - this happens for each screen line.
  View user's profile Send private message Visit poster's website
  • Joined: 13 Apr 2005
  • Posts: 246
  • Location: Aracruz - ES, Brazil
Reply with quote
Post Posted: Thu Feb 18, 2021 1:21 am
sverx wrote
This seems to confirm it. (MAG bit)

BTW keep in mind that in 'legacy' TMS9918 modes, you can't have more than 4 sprites appear on a scanline, and your can't have legacy mode sprites and mode 4 (SMS own mode) background at the same time.

Also, you can't mix zoomed and not zoomed sprites anyway, and you can't mix normal and tall sprites, split screen apart - and there's no such thing as 'flicker', the chip will simply draw the first sprites listed until there are 4 (or 8 in mode 4) and simply won't draw any more than those - this happens for each screen line.

Information absorved... :)

With this, more questions comes in mind... Seeing how horizontal scrolling and horizontal parallax works on SMS, I would like to know if it's possible to aplly the same technique vertically to get vertical parallax.

I think it's not possible, because I tried to find some game used this idea, but I couldn't. But if this technique it possible to be aplyed, there's some game or homebrew uses this concept?



By the way, I found THIS HOMEBREW, and I liked it a lot. This homebrew was already posted in this site? Because I couldn't find it...
  View user's profile Send private message
  • Joined: 28 Sep 1999
  • Posts: 1169
Reply with quote
Post Posted: Thu Feb 18, 2021 5:51 am
Last edited by Charles MacDonald on Thu Feb 18, 2021 3:10 pm; edited 1 time in total
Quote
With this, more questions comes in mind... Seeing how horizontal scrolling and horizontal parallax works on SMS, I would like to know if it's possible to aplly the same technique vertically to get vertical parallax.


It can't be done on SMS as the vertical scroll register is latched once per frame, so if you modify it on each scanline you won't see any changes happening. It's pretty unfortunate IMO
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 13627
  • Location: London
Reply with quote
Post Posted: Thu Feb 18, 2021 8:59 am
To be fair, these techniques are getting pretty advanced for a “noob” developer. It’s probably a good idea to get a firm grasp of the VDP in “normal operation” before looking to heavy raster FX, let alone tricks never used on original commercial releases.
  View user's profile Send private message Visit poster's website
  • Joined: 28 Sep 1999
  • Posts: 1169
Reply with quote
Post Posted: Thu Feb 18, 2021 3:10 pm
Maxim wrote
To be fair, these techniques are getting pretty advanced for a “noob” developer. It’s probably a good idea to get a firm grasp of the VDP in “normal operation” before looking to heavy raster FX, let alone tricks never used on original commercial releases.


Good point! I've edited the post accordingly to be more on topic.
  View user's profile Send private message Visit poster's website
  • Joined: 08 Sep 2018
  • Posts: 254
Reply with quote
Post Posted: Thu Feb 18, 2021 5:11 pm
So Rouken, my question to you is why not attempt to program a few demos yourself to test your thoughts? There is definitely enough information here on SMS Power to get you going. Sometimes getting down and dirty in the code is the best and fastest way to find solid answers with visual proof to your questions.
  View user's profile Send private message
  • Joined: 13 Apr 2005
  • Posts: 246
  • Location: Aracruz - ES, Brazil
Reply with quote
Post Posted: Thu Feb 18, 2021 11:07 pm
IllusionOfMana wrote
So Rouken, my question to you is why not attempt to program a few demos yourself to test your thoughts? There is definitely enough information here on SMS Power to get you going. Sometimes getting down and dirty in the code is the best and fastest way to find solid answers with visual proof to your questions.


Well... Because I'm a "noob" at programing. In fact, I know nothing about programing (I would love to try, but my personal life is kind of "intense" nowdays... and I have little time for fun, and I have a lot of games to take care of... T_T ). But I think it's fun to to know what the SMS hardware can and what can't do, and try to make logical and possible suggestions in some homebrew projects at the forum's development section. Aside of having fun in the logical part in try to make suggestions who are possible to apply, it's amazing to know how games great works under the technical view.

Yes, I already visited the SMS Power! Development sections, and,when possible, in other SMS Development sections in other sites. Somethings are very easy for me to get, and other are too technical... @[email protected] That's why I'm making these questions: For... 1) Ask if some feature if possible or not, and 2) To receive a non-technical explanation (that's the "noob" part of the title's topic).



With that said, I just have one more question: It's possible to apply the "horizontal parallax" effect while the game is doing a vertical scrolling? If yes, there's some game who use this technique?



I was about to ask something about the SMS Colors Palette, but I got a clear answer HERE.
  View user's profile Send private message
  • Joined: 27 Nov 2011
  • Posts: 19
Reply with quote
Post Posted: Thu Feb 18, 2021 11:38 pm
rouken wrote
It's possible to apply the "horizontal parallax" effect while the game is doing a vertical scrolling?

Yup :-)

rouken wrote
If yes, there's some game who use this technique?

The background in Desert Speedtrap is a good example.
  View user's profile Send private message
  • Joined: 01 Feb 2014
  • Posts: 620
Reply with quote
Post Posted: Fri Feb 19, 2021 7:35 am
rouken wrote
With that said, I just have one more question: It's possible to apply the "horizontal parallax" effect while the game is doing a vertical scrolling? If yes, there's some game who use this technique?


Not technically a Master System game, but GG Aleste 3 does this quite a lot and to great effect. Look up videos of its stage 2.
  View user's profile Send private message
  • Joined: 13 Apr 2005
  • Posts: 246
  • Location: Aracruz - ES, Brazil
Reply with quote
Post Posted: Sat Mar 06, 2021 12:21 am
Ok... Back to the business again... This time, I put three more doubts...




1) Sample Playback

There's a good documentation about sample playback on SMS HERE. But I notice when a SMS game plays a sample, the game "freezes" while the sample is being played. You can name the game, like Alex Kidd: The Lost Stars, Street Fighter II, Sega Chess, Shadow Dancer, etc...

But my doubt is: SMS games freezes while playing samples is an unavoidable system limitation, or it's possible to the SMS play samples without freezing the game?




2) Color Palette

It's well explained the SMS have two layers: One for background, and one for sprites. Each layer can make use of a palette with 16 values each. But theres two things to note (from THIS SOURCE):
1) It's said, while the Sprites layer can only use the sprites palette, the Background layer can use both back background palette and sprites palette.
And...
2) Both palettes have a color marked as "zero". In the Background palette side, it makes the color be the only color who will be behind the sprite when the background tile is marked with "high priority" (high priority = background tiles overlays the sprites). And in the Sprites palette side, the color marked as "zero" determine that color is set to be transparent.

Ok... With everything said, there's my doubt: Once the Background layer can make use of the Sprites Color palette, what happens when a background tile uses a "transparent" color from that palette?

My bets: A) It will automatically use the "low priority color" from the background palette; or... B) It will use the color, ignoring the "transparent" value...




3) Embled Extra RAM

I was to "rise an old topic from its grave", but I decided to ask here... What exactly do this "Embled Extra RAM"? Is it something like an additional video memory to allow more tiles to be displayed at the same screen?





Kjell wrote
The background in Desert Speedtrap is a good example.

Nice one... It was very cool to see it in action... Technically speaking... :)






Kagesan wrote
Not technically a Master System game, but GG Aleste 3 does this quite a lot and to great effect. Look up videos of its stage 2.

You are right... I think it's uses something like updating background tiles, as explained in THIS VIDEO. I didn't checked yet, but I think it's the same method used to make that incledible cloud movement in Land of Illusion's Craggy Cliff stage. The first time I saw that stage, my mind blowed up... I must replay this game on emulator to check the technical part of the game (a good excuse to revisite an awesome game from my childhood S2).
  View user's profile Send private message
  • Joined: 08 Sep 2018
  • Posts: 254
Reply with quote
Post Posted: Sat Mar 06, 2021 1:06 am
Quote
1) It's said, while the Sprites layer can only use the sprites palette, the Background layer can use both back background palette and sprites palette.


I think there might be a register in the VDP that allows you to set the sprite palette to the first or second one but I dont think that is correct.

Quote

2) Both palettes have a color marked as "zero". In the Background palette side, it makes the color be the only color who will be behind the sprite when the background tile is marked with "high priority" (high priority = background tiles overlays the sprites). And in the Sprites palette side, the color marked as "zero" determine that color is set to be transparent


Yes color zero of a palette will be displayed behind a sprite no matter what when that tile is used in the tile map. Color zero is the only color that will render behind a sprite when the priority bit for that tile is set.

Quote

Ok... With everything said, there's my doubt: Once the Background layer can make use of the Sprites Color palette, what happens when a background tile uses a "transparent" color from that palette?


If you use the "sprite palette" for a tile used in the tilemap, the "transparent" color will become visible and will be used as the background color if the tile's priority bit is flipped.

I
Quote
was to "rise an old topic from its grave", but I decided to ask here... What exactly do this "Embled Extra RAM"? Is it something like an additional video memory to allow more tiles to be displayed at the same screen?


Odds are it just enables cart ram, this memory is only tied to the z80 bus and not the VDP bus... but can be used to cache tiles for some funky additional support.
  View user's profile Send private message
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 13627
  • Location: London
Reply with quote
Post Posted: Sat Mar 06, 2021 1:21 am
For samples, please use pcmenc to get the best quality. I ought to update that wiki page to mention it. It is CPU-based to time the samples, you can't really do anything while it is playing (except perhaps some extreme cases of small work with a lot of tricky code, or some glitchy sound). Some homebrew has audio played using the horizontal interrupt to time ~10kHz but I'm not sure how it works outside the visible area.

2B is correct.

The extra RAM in some games is to extend the 8KB system RAM. Generally it is used to hold uncompressed level data, also allowing that data to be modified/dynamic. For comparison, Sonic 1 uses 4KB of RAM for the level map and updates it each time a ring is collected. If they'd embedded 8KB RAM we could have had double size levels!

The cloud animation in Land of Illusion is animated tiles. See also the 3D effects in Aladdin and the parallax effect in Alien 3.
  View user's profile Send private message Visit poster's website
  • Joined: 29 Mar 2012
  • Posts: 669
  • Location: Spain
Reply with quote
Post Posted: Sat Mar 06, 2021 7:26 am
I did a small, silly C wrapper over Maxim code to play Samples, just in case:

https://github.com/kusfo/sms-fxsample
  View user's profile Send private message
  • Joined: 05 Sep 2013
  • Posts: 2905
Reply with quote
Post Posted: Mon Mar 08, 2021 6:05 pm
IllusionOfMana wrote
Quote
1) It's said, while the Sprites layer can only use the sprites palette, the Background layer can use both back background palette and sprites palette.


I think there might be a register in the VDP that allows you to set the sprite palette to the first or second one but I dont think that is correct.


no, you can't use anything else than the sprite palette (the second palette in CRAM) for the sprites, though the background tiles can use either with no difference, and it's not related to priority bit.

of course sprites will be drawn only using colors 1 to 15, so no pixel of color 0 is drawn, but the background instead draws each pixel, so colors 0 to 15 thus no 'transparent' color exist here (also because there's nothing 'behind' the background, you see...)
  View user's profile Send private message Visit poster's website
  • Joined: 13 Apr 2005
  • Posts: 246
  • Location: Aracruz - ES, Brazil
Reply with quote
Post Posted: Sun Mar 28, 2021 4:44 pm
Ok... Time to show the results of what I learned here.

As you all maybe can know, xfixium is kind of starting a port of TMNT Arcade Game to the SMS, but he is in a very early concept stage, just with some mock-ups.

In some point, I suggested it could be awesome to see the laser Konami logo from the 16bit generation ported to the SMS. But I thought "Is it really possible to do under the SMS limitations?".

I checked how the Konami logo works on the Sega Genesis, and, for my frustation, it works with two backgrounds layers. The back one have the Konami logo, and the front one is an all black layer with the laser line without the spark on top (the spark is a sprite), and after the laser fills the screen, the front background layer scrolls down and reveals the Konami logo. All the rest is just a change of color palette. Sega Genesis works with two background layers, and the Master System only with one. Yeah... It's not possible to use the same method of the 16bit machine on the 8bit machine. Everything must be done from the ground...

After that, I created an attack plan with all the information I absorved. But before I start, I must note the color of laser from the Konami logo is specific from system to system. The Super NES logo have a purple laser, the Genesis / Mega Drive have a green laser, and the PC Engine logo have a blue laser. I opted to make the Master System version of the logo with an orange laser.

With that said, let's go...






1) To start, I created this example using 244-Lines mode to make the resolution match with the same resolution of the SMD logo. If 224-Line is not possible to work with this logo, the screen can be ajusted to run at 192-Line mode by sacrificing some top and botton parts of the screen. But, for this example, I'll use 244-Line mode. Everything in this example is just a mock-up, by the way. Even the speed of the animation do not match with the SMD logo.

2) The spark will be formed by sprites. Where the spark pass through, the background tiles will update with the laser tiles. To prevent the tile update be displayed, I added a "tail" to the spark. This "tail" uses the same laser tiles of the background's laser, with the purpose to mask the tile update. I could use the background horizontal scrolling to scroll the lines of the laser, but it could means killing the leftmost column of tiles of the screen. So, I'm giving priority to the screen being fully used.

3) After the laser line be formed and the spark leaves the screen, the laser tiles are updated to make it thicker, just like in the original.

4) There's a short transition, where I put two lines of 8 zommed sprites. The zoomed sprites was builded to not look bad when zoomed, and to match with the background laser tiles. After that, the background tiles are replaced with a set of three tiles with 12 different color values in total (4 values for each tile), and this set is repeated in the whole line. In the end, the whole laser is composed with zommed sprites in the middle, and with background sprites in the sides. Zommed sprites are used to cover more tiles (8 tiles without zooming, against 16 tiles with zooming). The purpose will be said at step 6.

5) Time to make the laser scrolling down. The sprite portion of the laser can just be moved down. Now, the background portion of the laser is just a palette swap trick in the same way the spere of Sonic 3's Special Stage uses to gives the illusion of movement. Everytime a tile of this trio be all black, it will be moved from the top line to the botton line to keep the laser scrolling down. The only care here is to make both sprites and background portions of the laser be synced while the whole thing scrolls down.

6) The background tiles where the sprite portion of the laser will run over will be updated accordly to reveal the logo in a way the background tile update will occur behind the sprites. Even so, the logo is too big to the sprite portion of the laser to cover. I was to opt to reduce the logo to make it fit behind the sprites, but I came with the following idea: Then the tiles of the logo who will to be revealed at the background portion of the laser, these tiles will be updated with three different frames to match with the laser animation before to have the final tile displayed.

7) After the logo be completly revealed and the laser leaves the screen, the whole set of tiles will be updated with a new one. It's because the next step consist in work only with palette swaping, and the previous tiles don't have the right color values to do it. The color palette was set to make the tile update not be visible.

8) Now it's just the matter of swaping the color palette. I must point some notes in this part. A) Even with the colored logo screen having 17 colors in total, the whole screen uses all the SMS's 32 color slots to make the color changing work out. It's shows working with colors and working with values are two different things, because two or more values can be set to have the same color; And... B) The color transition of the background was difficult to port from the SMD to the SMS because of the SMS's limited color palette. From black to white, the SMS only have two tons of gray. To overcome this limitation, I used dithering by replacing the tile of the background with 1 black value to a tile with 2 black values in a full checkboard format during the "all-tile changing" momment. With this, altering the two black values with black, dark gray, light gray and white, I got a color variation from 2 to 5 between the all-black and all-white background. Even without the dithering thing, the result was much better than I expected.




Using this attack plan, I must calculate the number of tiles used in all this process to see if it's possible to keep everything into the VRAM. The number of total tiles used for the whole animation is bigger than what the VRAM can store, but the idea here is to make the tiles be loaded on the fly. The whole Konami logo after animated uses 190 (this number do not count repeated tiles), plus one tile to fill the background with black (Total = 191 Tiles). So, the logo before and after update requires 191 tiles each, and, with that said, 191 tiles must be reserved to store the graphics to the VRAM.

The rest of tiles used to make the laser animation part includes:
> 4 tiles for the spark, in a total of 16 tiles (4 tiles per frame);
> 2 tiles for laser, for a total of 6 tiles (it includes the tiles to make the "tail" of the spark);
> 3 tiles for the background laser being animated;
> 2 tiles for the zoomed sprite laser;
> Plus, 21 of the tiles of the logo is used to help the background laser animation, with 3 extra tiles each.

The total number of tiles must be reserved at the VRAM are 202, and most of them is dedicated to be updated on the fly.





But I remembered of one think very important I forgot to consider...

Maxim wrote
Zoomed sprites are rarely used because (1) they have bugs on SMS1s

The purpose of using the zoomed sprites is to hide the background tile changing, and to use less tiles to make the animation. But once we can have compatibility issues if this logo is being running on a Model 1, another way must be used instead.






In the animation above, I removed the zoomed sprites and made the whole laser formed by background tiles. But now it's needed to use more tiles to be updated to animate the logo. Before, only 21 tiles of the logo had to have extra tiles to help with animation of the laser building the logo, and now all the 190 tiles must have tiles to help with the laser scrolling animation, using the same method as listed in step 6. The cons is more memory must be used to store more tiles. The pros is zoomed sprites are not needed anymore, and the laser are not splited in two parts, and deal with sync.



In the end, it all was builded using what I learned in theory. It's not a certain it will work in practice, once there's a lot of other variations to consider, like processing power, processing circles, if the SMS can handle so much tiles being loaded/updated on the fly in so little time, the nature of how storing tiles on SMS's VRAM works, and other things...







Maxim wrote
For samples, please use pcmenc to get the best quality. I ought to update that wiki page to mention it. It is CPU-based to time the samples, you can't really do anything while it is playing (except perhaps some extreme cases of small work with a lot of tricky code, or some glitchy sound). Some homebrew has audio played using the horizontal interrupt to time ~10kHz but I'm not sure how it works outside the visible area.

2B is correct.

The extra RAM in some games is to extend the 8KB system RAM. Generally it is used to hold uncompressed level data, also allowing that data to be modified/dynamic. For comparison, Sonic 1 uses 4KB of RAM for the level map and updates it each time a ring is collected. If they'd embedded 8KB RAM we could have had double size levels!

The cloud animation in Land of Illusion is animated tiles. See also the 3D effects in Aladdin and the parallax effect in Alien 3.

Thanks for all the info.

About the sound part, I would love to see if the community can improve the SMS sound in other levels... Like in THIS TOPIC. But what I really wanted to see is the DEFLEMASK finally adding support for the YM2413 FM chip (and also offer support to create SMS musics by using both FM and PSG chips at the same time).

I would love to see how Sonic 1 maps with double of the size could looks like (or any other 8bit Sonic game)...

  View user's profile Send private message
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 13627
  • Location: London
Reply with quote
Post Posted: Sun Mar 28, 2021 5:46 pm
You should consider a name table swap to get a smooth line transition between the two parts. You can change the name table address in a line interrupt to give a wipe effect, and animating the laser tiles as you do there will give the effect you want with no sprites at all (for that part) and avoid the need for updating tiles on the fly.

It might be nice to then use sprites to give some sort of extra glow on the logo edges, but maybe that’s not wanted as it’s not part of the original effect...
  View user's profile Send private message Visit poster's website
  • Joined: 13 Apr 2005
  • Posts: 246
  • Location: Aracruz - ES, Brazil
Reply with quote
Post Posted: Mon Mar 29, 2021 8:20 pm
Maxim wrote
You should consider a name table swap to get a smooth line transition between the two parts. You can change the name table address in a line interrupt to give a wipe effect, and animating the laser tiles as you do there will give the effect you want with no sprites at all (for that part) and avoid the need for updating tiles on the fly.

Well... As I said before, I'm not into the programing thing... I'll leave the programing part for those who will make a good use of my "attack plan". It can be done by xfixium when his work takes some form, or for anyone who want to try to make test ROM...



Maxim wrote
It might be nice to then use sprites to give some sort of extra glow on the logo edges, but maybe that’s not wanted as it’s not part of the original effect...

About this, I though the same thing, but it do not work in this case because there's a lot of lines will exceed the max number of sprites without flicking. If that was not the case, my job could be easier, because I could set the background tiles of the laser with high priority, and hide the sprites behind the background layer.

Anyway... that was fun to speculate and create this mock-up with the SMS limitations as rules. I hope you all enjoyed it as I did.





Well... Not enough!! I did some extra work to create some extra logos with the following idea: "And if Sega ordered its 2nd and 3rd parties to add their studios logos in their works?". Imagine turn on the system and, before the game start, you behold the studio's logo. So, I did more logos...





First... Ancient, Yuzo "Chiptune God" Koshiro's studio, who did the 1st Sonic game for the 8bit. I took the logo from Beyond Oasys, and adjusted the color palette for the SMS palette...







Following the 8bit Sonic theme... Aspect, who produced most of the 8bit Sonic games, and other games for the Master System and Game Gear... The logo is the same the studio used. I took the logo from one of its NDS games (once the NDS resolution is the same from the SMS), removed the "Digital Entertaiment" text to make it looks like the logo they used on Gaia Breeder for Sega Saturn, and ajusted the colors.







Next, SIMS, who did original games like Putt & Putter, Master of Darkness, and Masters of Combat / Buster Fighter. Aside it, they ported games like Psychic World, created new games from existing characters, like Tails' Skypatrol, and many other works for many Sega systems, including many amazing works for the 8bit...

I created two logos: The old one, who could be used for the SMS / GG games, and the current one, who was used from 1997 / 2009 to present.







Next... Compile... Oh, Compile... How about start Aleste / Power Strike and be contemplated with the Compile logo and the Compile jingle...







Next... Taito... Who created amazing games who received ports for the Sega's 8bit systems, like Bubble Bobble and Sagaia.

I did two versions: One with black background after the logo used in NeoGeo games, and other with white background after the logo used in some SNES games.







I love Vic Tokai... So, why not show my love with a SMS Vic Tokai logo?



By the way... How ended the info searching about Psycho Fox from THIS TOPIC? Bock received some answer from his e-Mail? Someone got some interview with someone from the game's staff? Psycho Fox was done by Vic Tokai with 100% of certain?





To finish... The Capcom logo from the 16bit era. Capcom games was licenced to Sega or other Studios like U.S. Gold, but the Capcom logo appeared only at the TecToy's port of Street Fighter II. And, for my taste, it was not a nice choice of colors. I created a new one taking direcly from the SMD Capcom logo, and ajusted the palette to fit with the SMS palette. And I even put some color cycle to animate it, like as the 16bit version do.






Fun time is over... But this topic is still open to more discurssion... ^_^
SMS - Ancient.png (3.91 KB)
SMS - Ancient.png
SMS - Aspect.png (3.18 KB)
SMS - Aspect.png
SMS - Compile.png (2.14 KB)
SMS - Compile.png
SMS - SIMS 1.png (2.79 KB)
SMS - SIMS 1.png
SMS - SIMS 2.png (2.94 KB)
SMS - SIMS 2.png
SMS - Taito 1.png (2.85 KB)
SMS - Taito 1.png
SMS - Taito 2.png (3.05 KB)
SMS - Taito 2.png
SMS - Vic 1.png (2.66 KB)
SMS - Vic 1.png
SMS - Capcom.gif (4.2 KB)
SMS - Capcom.gif

  View user's profile Send private message
Reply to topic



Back to the top of this page

Back to SMS Power!