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 - 240 colors out of a palette of 343 on the SMS, color sprites

Reply to topic
Author Message
  • Joined: 05 Mar 2022
  • Posts: 98
  • Location: Seabrook, New Hampshire
Reply with quote
240 colors out of a palette of 343 on the SMS, color sprites
Post Posted: Tue Mar 08, 2022 6:11 am
Last edited by maxxoccupancy on Tue Mar 08, 2022 3:12 pm; edited 1 time in total
I know that it was asked elsewhere, but I've done a bit of investigating on the SMS's ability to put two different sets of background tiles up, interleaved, like on Zaxxon 3D and Missile Defense 3D. Some of us asked years ago if it would be possible to use this VDP trick to mix colors and get halftones.

This was done on the opening video of Sonic 3D for Genesis, but the SMS hardware is really designed to do this.

How many colors can be generated by mixing colors within one pixel? More important, how many of them are actually usable?

Each color on the SMS has an RGB value with two bits for each. From a base color, one can choose to mix it with any of nine colors: any combination of R, G, or B getting the same value, higher, or lower.

Using this mixing technique, R, G, or B could now have half values (2 mixed with 3, 0 mixed with 1, and so forth). To keep things simple I'll just say that, under color mixing, R, G, and B can each have any of 7 values, instead of just four.
4^^3 = 64 colors
7^^3 = 343 colors (using two background color mixing)

That's almost as good a picture as Genesis, able to display 64 out of 512.

"But wait," you say. "How many on screen at one time for the SMS? Surely we could get some advantage over our 16-bit cousin."

And you'd be right. Sprites on any given line can hold 15 colors plus one transparency. The background tiles can show either those or the 16 on its group. If we were to ignore the sprite colors, each background tile could mix its 16 colors in any way that works, giving us 16 base colors times 15 mixers, or 240 out of 343. If we really had to push the limits we could use color sprites, allowing us to synthesize the remaining 103, though this would only be useful for photos, and that would be a very memory intensive way to get those last few colors onscreen.

When memory space is at a premium, I think that the use of flashing (60fps) color sprites over the top of background tiles would be the most effective way to display 240 colors out of the palette of 343. By turning on half the color sprites one frame, then flipping them off and turning on the other half, we could get nice photos with half the screen benefitting from the richer color palette.

For smaller playing areas (like Street Fighter 2, Golden Axe Warrior, Monopoly, RISK, etc), flipping two different sets of slightly different background tiles a 60fps and the SMS2's 256x224 mode would allow much better Megadrive ports.

  View user's profile Send private message
  • Joined: 14 Aug 2000
  • Posts: 681
  • Location: Adelaide, Australia
Reply with quote
240 colors out of a palette of 343 on the SMS, color sprites
Post Posted: Tue Mar 08, 2022 7:32 am
Sounds like it may just result in a whole lot of flicker.

Have you thought about writing a simple colour demo to test your theory?
  View user's profile Send private message
  • Joined: 05 Sep 2013
  • Posts: 3145
Reply with quote
Post Posted: Tue Mar 08, 2022 7:50 am
I tried (a simpler version of) this years ago, by trying to obtain a color 'in between' two SMS colors. The result is lots of flicker, unless the colors are very very close in lightness. So I would say you might get a few more colors than those 64 but not that many.
  View user's profile Send private message Visit poster's website
  • Joined: 09 Jun 2014
  • Posts: 242
Reply with quote
Post Posted: Tue Mar 08, 2022 10:16 am
The gg2sms hack of Gunstar heroes does just that. There is some flickering indeed, but very interesting nonetheless
  View user's profile Send private message
  • Joined: 25 Feb 2006
  • Posts: 736
  • Location: Belo Horizonte, MG, Brazil
Reply with quote
Post Posted: Tue Mar 08, 2022 10:54 am
AFAIK, the human eye is less sensitive to changes in hue than changes in brightness. If you flicker between colors of similar levels of brightness, it should be less noticeable.

--edit--

Many Atari 2600 homebrews use flickering to get extra colors. Maybe the guys at Atariage could give some pointers on how to best do that?
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 14113
  • Location: London
Reply with quote
Post Posted: Tue Mar 08, 2022 12:33 pm
I guess someone should make a demo of all ~2000 possible colour pairs (64 colours each with 63 others to put with, half of which are the same pair of colours the other way around -> 64*63/2 pairs) to see which are acceptable? I imagine they will look worse in an emulator or on a modern LCD TV interpreting them as 480i than on an old CRT TV, and indeed the flickering will be more noticeable when the brightness is different.
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 3145
Reply with quote
Post Posted: Tue Mar 08, 2022 1:12 pm
I think somebody posted on the discord channel some image with the SMS colors ordered by hue (x) and luminance (y), but I can't find it.
I think that would be handy to see what colors could be easily mixed.
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 14113
  • Location: London
Reply with quote
Post Posted: Tue Mar 08, 2022 2:11 pm
That’s what so great about Discord, nothing can be found later…

  View user's profile Send private message Visit poster's website
  • Joined: 05 Dec 2019
  • Posts: 44
Reply with quote
Post Posted: Tue Mar 08, 2022 2:24 pm
sverx wrote
I think somebody posted on the discord channel some image with the SMS colors ordered by hue (x) and luminance (y), but I can't find it.

I posted that in the topic "SMS palette visualizations", though the vertical position interpreted as "luminance" is merely R+G+B.
  View user's profile Send private message
  • Joined: 09 Jun 2014
  • Posts: 242
Reply with quote
Post Posted: Tue Mar 08, 2022 2:28 pm
The picture of the palette this topic?
https://www.smspower.org/forums/18618-ColorPaletteWithProperIndices

  View user's profile Send private message
  • Joined: 05 Sep 2013
  • Posts: 3145
Reply with quote
Post Posted: Tue Mar 08, 2022 2:47 pm
it was more looking like the bottom part from this image

edit: another option is to fire the "DAWNBRINGER PALETTE ANALYSIS" on this palette
  View user's profile Send private message Visit poster's website
  • Joined: 05 Mar 2022
  • Posts: 98
  • Location: Seabrook, New Hampshire
Reply with quote
240 colors out of a palette of 343 on the SMS, color sprites
Post Posted: Tue Mar 08, 2022 3:39 pm
Both Toy Story and Sonic 3D for the Megadrive used similar tricks to exceed the color limits of the Genesis. The color mixing in Sonic's opening could generate 4,096 colors. The highlight-shadow mode from Toy Story gives you a palette of 1,375 to work with.


And Sonic 3D's full screen video (this shows the flickering effect when strongly contrasting colors are put next to each other):


For using halftones only to generate more colors, 343 is the limit, unfortunately. While, in theory, 64 * 64 should get you 4,096, most of those combinations are either duplicates or would get you bad flickering.

An obvious example of gray could be achieved with black #000 and white #333. That is certainly one of the 4,096. But that can be achieved without (or with much less) flicker than mixing light gray #222 and light gray #111. In fact, there are so many combinations to get to #1.5 1.5 1.5 for medium gray.
#123 could be mixed with #210
#230 could be mixed with #103
and so on...

Those are all duplicates, and there's just too much color difference between those two pixels. Take a look at the resulting image on the Missile Defense title screen above and look at the yellow moon. That half-yellow could be better created just mixing two yellows than with bright yellow and black.

The 343 color palette achieved with mixing assumes that we use two colors that are close together.

As you can see in this YouTube video, so long as the frame rate is kept at 60fps, the eye does not detect flickering. The retina refreshes at 23.6Hz, and that flashing effect only occurs when there's a slowdown in the game.

By sticking with colors that are close together, and flashing that does occur would be minimal and almost unnoticeable.

The Sega CD used the trick of mixing two images that had been compressed differently, resulting in each image having artifacts and obvious dithering. However, at full speed playback, similar colors seem to blend or mix together in the same pixel. Even if half of the color comibations have to be avoided to avoid flicker or flashing, a background using 16 colors could still find 6 or 7 usable mixing colors, giving you 200+ colors using this effect. On YouTube, I use Magic Actions and apply either Oil Painting or Soft Focus Lense to get rid of the flicker/flashing even on the starkly contrasting colors.
  View user's profile Send private message
  • Joined: 05 Mar 2022
  • Posts: 98
  • Location: Seabrook, New Hampshire
Reply with quote
100 colors out of 343
Post Posted: Tue Mar 08, 2022 4:37 pm
The browser crashed while reposting, but I'll summarize. A background tile can choose among 16 colors, but could mix with another tile. From the same group of earthy and midtones, we could get 240 combinations. Assuming that a random tile could only mix with one-third of those colors (5 or so), we get 80+ color combinations that can be made. Without using color sprites (as on photos), we get roughly 100 available just for backgrounds, not changing the 16 as the VDP displays to the screen.

However, consider a more common application: two digitized cloudy sky photos using various light shades of blue and light gray. By alternating between the two very similar, dithered images, we could get backgrounds that look much better than either image. Although this would eat up about 200 of the 448 available tiles, the backgrounds would still look very good.

Now that game cartridges can be 32 megabits in size on the SMS, those limitations are not a worry--just the 16KB of VRAM.

  View user's profile Send private message
  • Joined: 12 Dec 2021
  • Posts: 24
  • Location: Melbourne, Australia
Reply with quote
Post Posted: Wed Mar 09, 2022 10:40 am
If memory serves, the Lambo SMS demo by Genesis Project did a bit of a cheeky flicker between two images (of the sunglasses) to "fake" better colour.

For the Mega Drive, you could also look to Titan's Overdrive / Overdrive 2 for examples of "exceeding" what the MD is technically possible of doing with colours.
  View user's profile Send private message
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 14113
  • Location: London
Reply with quote
Post Posted: Wed Mar 09, 2022 5:14 pm
I always interpreted that flickering sunglasses colour as an effect (intended to look like flicker rather than a colour blend) but I guess maybe it’s less flickery on a CRT TV.
  View user's profile Send private message Visit poster's website
  • Joined: 05 Mar 2022
  • Posts: 98
  • Location: Seabrook, New Hampshire
Reply with quote
240 colors out of a palette of 343 on the SMS
Post Posted: Wed Mar 09, 2022 6:28 pm
The flicker/flashing effect only occurs when you have two starkly different colors in the same pixel. So a sky that mixes light gray with light blue and white is not likely to suffer from that problem.

However, some games flashed between yellow and black or yellow and red, and those odd combinations can get old after a while. Space Harrier 3D flashed red and yellow while also playing alternating backgrounds for the 3D glasses.
  View user's profile Send private message
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 14113
  • Location: London
Reply with quote
Post Posted: Wed Mar 09, 2022 6:44 pm
What 3D games do doesn’t really matter - we know they are a flickery mess without the shutters. The point is that flickering even close colours - let’s say adjacent colours in the 6 bit palette, differing by only one in a single channel - still look flickery when strobing.
  View user's profile Send private message Visit poster's website
  • Joined: 05 Mar 2022
  • Posts: 98
  • Location: Seabrook, New Hampshire
Reply with quote
Post Posted: Thu Mar 10, 2022 12:18 am
Maxim wrote
What 3D games do doesn’t really matter - we know they are a flickery mess without the shutters. The point is that flickering even close colours - let’s say adjacent colours in the 6 bit palette, differing by only one in a single channel - still look flickery when strobing.


I posted the Sonic video above which actually mixes the colors at 60fps. The flickering/flashing that you see only occurs when white and dark blue are mixed. No one complains when they see blue and dark blue mixed together.

The only way to prove that most of those 343 mixer combinations work is to generate actual photos using software techniques that I don't have.
  View user's profile Send private message
  • Joined: 05 Sep 2013
  • Posts: 3145
Reply with quote
Post Posted: Thu Mar 10, 2022 8:03 am
you should provide a POC instead

as I said before, I tried this a few years ago. you get a lot of flicker unless the two colors are very very close in luminance - so even mixing a blue with a dark blue will still result in no stable blue in between

SMS is RGB222, so primaries are 33.3% apart one from the other (0%, 33.3%, 66.6%, 100%) which is A LOT.
  View user's profile Send private message Visit poster's website
  • Joined: 25 Feb 2006
  • Posts: 736
  • Location: Belo Horizonte, MG, Brazil
Reply with quote
Post Posted: Thu Mar 10, 2022 11:17 pm
Maybe the Game Gear would provide better results, with its larger palette and blurry screen.
  View user's profile Send private message Visit poster's website
  • Joined: 05 Mar 2022
  • Posts: 98
  • Location: Seabrook, New Hampshire
Reply with quote
Post Posted: Thu Mar 10, 2022 11:24 pm
haroldoop wrote
Maybe the Game Gear would provide better results, with its larger palette and blurry screen.


It has, as someone posted on another thread. However, the GG already benefits from a palette of 4,096 colors.

Does anyone have a game template I can work with, ideally one that already does work like this with background tiles? My plan was just to take colorful test photos and do palette swapping every other cycle with the sprite palette.

My initial assumption is that #111's and #222's will likely work well together while producing many of those earthy, less colorful halftones that are great for backgrounds.
  View user's profile Send private message
  • Joined: 09 Jun 2014
  • Posts: 242
Reply with quote
Post Posted: Fri Mar 11, 2022 9:31 am
I made some animated images of Gunstar Heroes GG2SMS hack.

It works nicely for the Treasure logo because it is just a small part of the screen.
Also the select screen look ok, because the background colors are similar.
The sky works nicely in the level screen, but other parts don't.
In the Sega and title screens i would say the color differences are too big, and even at 60fps the flicker is distracting.

It also helps if the emulator output is exactly synced to the monitor hz (which was not the case with meka on my machine).
sega.png (1.25 KB)
sega.png
treasure.png (2.27 KB)
treasure.png
title.png (8.41 KB)
title.png
select.png (4.03 KB)
select.png
level.png (5.4 KB)
level.png

  View user's profile Send private message
  • Joined: 05 Mar 2022
  • Posts: 98
  • Location: Seabrook, New Hampshire
Reply with quote
240 colors out of a palette of 343 on the SMS, color sprites
Post Posted: Fri Mar 11, 2022 1:37 pm
So it's as almost everyone predicted, that bright and starkly contrasting colors would appear to flicker/flash distractingly while subdued and earthy tones would mix just fine.

The problem with the PNG's attached is that they're not occulting at anything like 60fps, and the greater the contrast between two colors, the higher the rate of occulting that you must have to make the flashing seem to disappear. Many of the dimming effects we see on screen and in our world are done by turning colors off and on at higher and higher rates.

As I've stated before, the only way to actually prove the concept is to actually build flipping background tiles using actual hardware or emulators that can maintain 60fps without dropping the frame rate.

To test out this approach, we would have to have actual images that have a realistic chance of looking better with color mixing with near colors occulting at 60pfs. For example, a single photo using two different dithering methods that draw from the same 32 out of 64 colors.

  View user's profile Send private message
  • Joined: 05 Sep 2013
  • Posts: 3145
Reply with quote
Post Posted: Fri Mar 11, 2022 3:06 pm
note that there's not enough room in VRAM for having a full screen image made of 32×24 (768) different tiles, so you either have to reuse tiles or not use the whole screen
  View user's profile Send private message Visit poster's website
  • Joined: 06 Apr 2015
  • Posts: 80
Reply with quote
Post Posted: Fri Mar 11, 2022 3:36 pm
I think you'd have better results with tiles that are striped or dithered rather than an entire tile cycling between two solid colors. In fact I think that's what my 6-bit per channel drawing tablet does to appear more like 8-bit per channel. Usually it's not noticeable but every once in a while my eyes detect some subtle dithering.
  View user's profile Send private message
  • Joined: 05 Mar 2022
  • Posts: 98
  • Location: Seabrook, New Hampshire
Reply with quote
Post Posted: Fri Mar 11, 2022 4:27 pm
Centrale wrote
I think you'd have better results with tiles that are striped or dithered rather than an entire tile cycling between two solid colors. In fact I think that's what my 6-bit per channel drawing tablet does to appear more like 8-bit per channel. Usually it's not noticeable but every once in a while my eyes detect some subtle dithering.


I'm not suggesting solid colors at all. That image is 448x256, compared with 256x192 for the SMS or 256x224 for the SMS (though few games ever used that).

Here's the same 448x256 limiting the image to just 256 similar tiles.

  View user's profile Send private message
  • Joined: 05 Mar 2022
  • Posts: 98
  • Location: Seabrook, New Hampshire
Reply with quote
porsche formula one 224x128
Post Posted: Fri Mar 11, 2022 4:58 pm
This is optimized for the SMS using all 448 tiles available in memory. We could also do 256x192 by sharing similar tiles, especially from the background image.

IMHO, this is about the best that we could get out of the SMS for large photos, and it's about the best I've seen. This is without color mixing, the use of which would be limited to about 10-15% of the screen using color sprites that turn on and off at 60fps. They would be barely noticeable since they would mostly be mixing dark grays at a few points.

  View user's profile Send private message
  • Joined: 05 Mar 2022
  • Posts: 98
  • Location: Seabrook, New Hampshire
Reply with quote
Post Posted: Tue Apr 05, 2022 5:51 am
It turns out that this color mixing trick was already done on the demo scene for the Commodore 64. The upside is that it proves that, for image stills, we can effectively mix colors, and that I was right all along. The downside is that I can't take credit for the idea, as people were doing this more than 30 years ago.

If you watch the video at this point, you see the need to mix close colors:


And the reason that the palette with color mixing is only 343 colors and not 4,096 is because of duplicates and the need to use two colors that are very close in RGB values to avoid that flickering effect. However, we may be able to reach 5-600 colors for certain exceptional cases at the dark and earthy end of the spectrum.

Background tiles can be flipped between two close variants of the same tile, though we're still limited to 448 tiles total. Without duplication, we could get Amiga quality photos of 128x96.
  View user's profile Send private message
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 14113
  • Location: London
Reply with quote
Post Posted: Tue Apr 05, 2022 8:03 am
Colour flicker is one of the easiest things you might try to make a static POC for. It's going to look flickery no matter what colours you pick, and will presumably look worse on emulators than on a CRT. On a CRT and expecting RF or composite connections, horizontal dithering is likely to work a lot better.
  View user's profile Send private message Visit poster's website
  • Joined: 14 Aug 2000
  • Posts: 681
  • Location: Adelaide, Australia
Reply with quote
240 colors out of a palette of 343 on the SMS, color sprites
Post Posted: Thu Apr 07, 2022 1:04 pm
I had a bit of spare time last night, so I wrote a quick and dirty demo to put this thread to bed once and for all.

This was literally a compiled-first-time-ran-first-time deal. It’s so quick and dirty, it has a bug in it...but it serves its purpose as a POC and shows why a POC is needed for new ideas.

The program changes the screen colour every 64 frames, cycling through red, green, blue, and white, going from zero brightness to full brightness for each colour in an attempted 7 levels, where every second level it alternates between 2 intensity levels each frame. If that makes sense.

I ran this on an emulator. To run on a physical console with BIOS it will need to be padded out and have a software header added. Which I can’t be stuffed doing.

Here is the source. The rom is attached below.

;===============================================================================================================================================================
;
; Colour Flicker - Proof Of Concept
;
;NOTES:
;
;
;===============================================================================================================================================================


;RAM USAGE
;===============================================================================================================================================================
RAMBaseAddress:         EQU   $C000
StartOfPgmRAM:         EQU   RAMBaseAddress + 16
frameCounter:         EQU   StartOfPgmRAM
colourIndex:         EQU   frameCounter + 1


;RST Vectors
;===============================================================================================================================================================

               ORG $0000                     
StartUp:
                  DI                        ;disable interrupts
                  IM 1                     ;set interrupt mode
                  LD SP,$DFF0                  ;set the stack pointer
                  JP Main                     ;jump to Main

               ;ORG $0008
                  ;RET                     ;overlapped by RST 00
                  
               ORG $0010
                  RET
                  
               ORG $0018
                  RET
                  
               ORG $0020
                  RET
                  
               ORG $0028
                  RET
                  
               ORG $0030
                  RET

               ORG $0038
                  JP INT_Handler


;NMI Routine
;===============================================================================================================================================================
;The Non-maskable Interrupt handler

               ORG $0066
NMI_Handler:         
                  RETN                     ;does nothing


;INT Routine
;===============================================================================================================================================================
;The Interrupt handler

INT_Handler:         
                  IN A,($BF)                  ;read the VDP Status register,
                  AND $80
                  JR Z,INT_Handler_Exit         ;break out if this is not a frame interrupt
                  
                  LD DE,$0010                  ;set the CRAM address to update the border colour
                  CALL SetCRAMAddress
                  
                  LD HL,COLOUR_TABLE            ;get the colour byte to write to CRAM from the COLOUR_TABLE using COLOUR_TABLE + lsb from frameCounter
                  LD A,(colourIndex)
                  LD E,A
                  LD A,(frameCounter)
                  AND $01
                  ADD A,E
                  LD E,A
                  LD D,$00
                  ADD HL,DE
                  LD A,(HL)                  ;get the colour byte
                  OUT ($BE),A                  ;write the colour byte to CRAM
                  
                  LD A,(frameCounter)            ;increment the frame counter and mod 64 so we change the border colour every 64 frames
                  INC A
                  AND $3F   
                  LD (frameCounter),A
                  
                  JR NZ,INT_Handler_Exit         ;if the frame counter is zero
                  
                  LD A,(colourIndex)            ;then also increment the colourIndex and mod it with 32 so we cycle through the COLOUR_TABLE continuously
                  INC A
                  AND $1F
                  LD (colourIndex),A               
INT_Handler_Exit:      
                  EI
                  RETI
                  
                  
;InitialiseVDP
;===============================================================================================================================================================
;Initialises the VDP by setting the VDP registers to initial values

InitialiseVDP:         
                  PUSH AF
                  PUSH BC
                  PUSH HL
                  LD HL,VDP_INIT_DATA
                  LD B,22
                  LD C,$BF
                  OTIR
                  POP HL
                  POP BC
                  POP AF
                  RET
                  
VDP_INIT_DATA:         db $36,$80                  ;Register 0 = $36   no scroll inhibits, left column blanked, line INT enabled, no sprite shift
                  db $A0,$81                  ;Register 1 = $A0   display blanked, frame INT enabled, normal sprite size
                  db $FF,$82                  ;Register 2 = $FF   screen map base address = $3800
                  db $FF,$83                  ;Register 3 = $FF   always set to $FF
                  db $FF,$84                  ;Register 4 = $FF   always set to $FF
                  db $FF,$85                  ;Register 5 = $FF   sprite attribute table = $3F00
                  db $FB,$86                  ;Register 6 = $FB   $FB = 1st 8k of VRAM for 256 patterns, $FF = 2nd 8k of VRAM for 192 patterns
                  db $00,$87                  ;Register 7 = $F0   take the border colour from the 2nd half colour palette
                  db $00,$88                  ;Register 8 = $00   no H scroll
                  db $00,$89                  ;Register 9 = $00   no V scroll
                  db $FF,$8A                  ;Register A = $FF   no line interrpt counter


;MutePSG
;================================================================================================================================================================
;Mutes the PSG

MutePSG:            
                  PUSH AF
                  PUSH BC
                  PUSH HL
                  LD HL,PSG_MUTE_DATA
                  LD B,4
                  LD C,$7F
                  OTIR
                  POP HL
                  POP BC
                  POP AF
                  RET
                  
PSG_MUTE_DATA:         db $9F,$BF,$DF,$FF

   
;SetCRAMAddress
;===============================================================================================================================================================
;Sets the VDP mode and address passed in via DE for writing data to CRAM

SetCRAMAddress:         
                  PUSH AF
                  LD A,E
                  AND $1F                     ;CRAM max size mask
                  OUT ($BF),A
                  LD A,$C0                  ;set bits 6 & 7 for CRAM write
                  OUT ($BF),A
                  POP AF
                  RET


;Main
;===============================================================================================================================================================

Main:               
                  CALL MutePSG               ;mute the PSG

                  LD A,0                     ;initialise all program variables to zero
                  LD (frameCounter),A
                  LD (colourIndex),A

                  CALL InitialiseVDP            ;initialise the VDP and blank the screen
                  
                  EI                        ;enable interrupts
InfiniteLoop:         
                  JR InfiniteLoop               ;loop forever

                  ;end Main

COLOUR_TABLE:         db   $00,$00,$01,$01,$02,$02,$03,$03
                  db   $00,$00,$04,$04,$08,$08,$0C,$0C
                  db   $00,$00,$10,$10,$20,$20,$30,$30
                  db   $00,$00,$15,$15,$2A,$2A,$3F,$3F


  View user's profile Send private message
  • Joined: 05 Sep 2013
  • Posts: 3145
Reply with quote
Post Posted: Thu Apr 07, 2022 4:58 pm
it's terrible, thank you! <3
  View user's profile Send private message Visit poster's website
  • Joined: 19 Feb 2022
  • Posts: 3
Reply with quote
Flickering
Post Posted: Fri Apr 08, 2022 12:24 pm
I would just like to point out that flickering is more an issue with emulators and "modern screens". If you're watching it on a small CRT (like most people used at the time, especially an SMS2 (Which only had RF output)), this problem becomes far less noticeable. While brightness difference can still be seen, developers back then DID keep this "blending" in mind when making sprites.

They used blending very often to create the illusion of more color. Good examples are Metroid and Super Mario Bros 3. Also, the colors in an emulator/perfect screen look different than on a CRT's RF signal.

Sorry, it's just something I feel strong about, as I believe the current retro/collector mania's aim to put everything "pixel perfect" on a screen is actually racing past the actual design decisions of many games. A game they claim is "ugly" very often looks really nice on the CRT it was designed to run on.
  View user's profile Send private message
  • Joined: 05 Sep 2013
  • Posts: 3145
Reply with quote
Post Posted: Fri Apr 08, 2022 1:08 pm
While I totally agree that the CRT makes blending easier and flicker way less noticeable, I had tried a very similar test on my SMSII -> RF -> CRT set up a few years ago. That's why for instance I decided to use dithering for shadows on MARKanoIIId instead of rapid palette changes. Even the darker blue and the black, which are the two colors with less luminance in the whole SMS palette, would result in a pretty annoying flicker, which I thought it wouldn't be acceptable. Yeah, of course it's my opinion, but I did color blending experiments before on different hardware with totally different outcome so it might be I'm pretty picky.
  View user's profile Send private message Visit poster's website
  • Joined: 19 Feb 2022
  • Posts: 3
Reply with quote
Post Posted: Fri Apr 08, 2022 9:14 pm
Oh I agree, but mostly mean that using colors close to each other to make an illusion of a third color was often used by developers when they designed backgrounds and sprites. They tested these on CRTs. There are dozens of pictures you can find online of Ni****do's dev teams where they are testing their games on some well known TV sets.

Another way to reduce flicker would be to invert what line does what color each frame I suppose. But I mean.. why even go about it when you can design the tiles with this in mind from the very start? (Like old devs also did).
  View user's profile Send private message
  • Joined: 14 Aug 2000
  • Posts: 681
  • Location: Adelaide, Australia
Reply with quote
240 colors out of a palette of 343 on the SMS, color sprites
Post Posted: Sat Apr 09, 2022 4:54 am
@dehnus someone can burn the rom to a dev cart or everdrive or something and find out for sure.

The source above is completely OPEN for anyone to take and modify as they please. Change the colours, add sprites, use it as a starting point and turn it into a game, anything anyone wants.
  View user's profile Send private message
  • Joined: 19 Feb 2022
  • Posts: 3
Reply with quote
Post Posted: Tue Apr 12, 2022 1:29 pm
asynchronous wrote
@dehnus someone can burn the rom to a dev cart or everdrive or something and find out for sure.

The source above is completely OPEN for anyone to take and modify as they please. Change the colours, add sprites, use it as a starting point and turn it into a game, anything anyone wants.


I just think it's a bit silly, as blending pixels can be done when designing sprites or tiles.

For instance if you wish to make a sunset? You can make a tile that has blended patterns and switch the colors per line. Then on an RF signal it should just blend the colors together due to the signal and nature of CRT.

I mean that is how most of the translucency tricks worked on a Megadrive.
  View user's profile Send private message
  • Joined: 05 Mar 2022
  • Posts: 98
  • Location: Seabrook, New Hampshire
Reply with quote
Post Posted: Sat Apr 16, 2022 4:18 am
asynchronous wrote
@dehnus someone can burn the rom to a dev cart or everdrive or something and find out for sure.

The source above is completely OPEN for anyone to take and modify as they please. Change the colours, add sprites, use it as a starting point and turn it into a game, anything anyone wants.


Thank you so much. I was only able to show this on my modern LED screen, and the color mixing never matched up. I then set Emulicious to "Sync to Audio," and the colors suddenly changed so smoothly, you'd think we had 200 colors on tap.

If I get some time, I may change your code to a tiled background of four cycles of 16 vertical tiles, alternating with 16 horizontal lines at 60fps. My original hypothesis was that this would work best with combinations of darker and earthier tones--both of which are in short supply on the SMS.

Even if 343 usable colors are impossible, but we are able to get 150 or so, that is worlds better than 31 out of 64 with only two gray shades.

Heck, it would be worth it to get 2-3 extra grays and nothing else, IMHO.
  View user's profile Send private message
  • Joined: 09 Jun 2014
  • Posts: 242
Reply with quote
Post Posted: Sat Apr 16, 2022 10:28 am
How about combining flicker and dither?
In some games it is used for fake transparency. I believe in the Street Fighter Alpha live bar for example (or was it Mortal Kombat?)

I used 3 different types of dither in my example. The top one seems to work really well. It requires double the number of tiles though.
greydither.png (385 B)
greydither.png

  View user's profile Send private message
  • Joined: 26 Feb 2021
  • Posts: 87
Reply with quote
Post Posted: Sat Apr 16, 2022 11:10 am
maxxoccupancy wrote
The upside is that it proves that, for image stills, we can effectively mix colors, and that I was right all along. The downside is that I can't take credit for the idea, as people were doing this more than 30 years ago.

Love your sense of humor, please keep entertaining us.
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 3145
Reply with quote
Post Posted: Sat Apr 16, 2022 7:38 pm
Let's try to turn this topic into an actually useful one.
I suspect if we try to mix two SMS colors that are very very close in brightness we might actually get a pretty stable mix.
The 'bri-hue' scatter here in the center-up-right

indeed shows that there are a few colors with same (or almost same) brightness and someone could pick a few pair and run a few tests on hardware (I currently have no way to do that)
EA5E03FD-B3A3-401A-A4AE-5AB9FBB0AB55.png (24.18 KB)
Attachment fairy
EA5E03FD-B3A3-401A-A4AE-5AB9FBB0AB55.png

  View user's profile Send private message Visit poster's website
  • Joined: 04 Jul 2010
  • Posts: 417
  • Location: Angers, France
Reply with quote
Post Posted: Sun Apr 17, 2022 8:11 am
With my long time friend Vingazole we've tried this kind of things years ago (specificaly greys), it was not very good on real crt. 60hz is to slow.
Funny to read this now, one more usefull topic by maxxx.

Ps. Epileptic people will thank you 🤣
  View user's profile Send private message
  • Joined: 05 Sep 2013
  • Posts: 3145
Reply with quote
Post Posted: Sun Apr 17, 2022 9:02 am
ichigobankai wrote
With my long time friend Vingazole we've tried this kind of things years ago (specificaly greys), it was not very good on real crt. 60hz is to slow.


yes, even two close grays are too far apart, it just flickers as hell
Maybe some other colors would work, hard to tell without being able to test on hardware...
  View user's profile Send private message Visit poster's website
  • Joined: 04 Jul 2010
  • Posts: 417
  • Location: Angers, France
Reply with quote
Post Posted: Sun Apr 17, 2022 9:28 am
Sure! But if the effect is only for close colors, its unfortunately far too limited / useless.

The console have already a great color choices but not for photographic things. Use it for cartoon style. Look at Astérix, WB3, Mickey, Donald... Which are also the best games of the support.

Or make something only for GG, with its 16bit color palette, it will be far better.
  View user's profile Send private message
  • Joined: 26 Feb 2021
  • Posts: 87
Reply with quote
Post Posted: Sun Apr 17, 2022 9:52 am
ichigobankai wrote
Sure! But if the effect is only for close colors, its unfortunately far too limited / useless.

The console have already a great color choices but not for photographic things. Use it for cartoon style. Look at Astérix, WB3, Mickey, Donald... Which are also the best games of the support.

Or make something only for GG, with its 16bit color palette, it will be far better.

Actually it's worth noting technical effects aren't what makes a good game, otherwise Tetris would have been forgotten pretty quickly.
The best games on the MS and GG (Castle of Illusion, Lucky Dime Caper, Tails Adventure, Sonic Triple Trouble) make little to no use of palette cycling, mid-frame palette swapping, parallax scrolling, etc.
  View user's profile Send private message Visit poster's website
  • Joined: 01 Feb 2014
  • Posts: 701
Reply with quote
Post Posted: Sun Apr 17, 2022 1:17 pm
Agreed. It's not the number of colours that's important, it’s what the artist does with them. I fail to see what could be achieved by flickering on the SMS that can’t be achieved better by dithering.
  View user's profile Send private message
  • Joined: 05 Mar 2022
  • Posts: 98
  • Location: Seabrook, New Hampshire
Reply with quote
Post Posted: Wed May 18, 2022 6:23 am
This would be an extra tool for game development, especially for backgrounds, cut scenes, and title images.

The theoretical maximum of any 64 colors mixed with any of the other 64 is 4,096 in total. Many of those are duplicates, and many are far enough apart in chroma and luma--so you'd get noticeable flicker. 343 colors is the limit if you're avoiding duplicates and only allowing two colors that are close in RGB values.

Remember that the Commodore 64 offered just 16 colors, yet made this same technique work for images, getting over 100 usable colors out of a theoretical 256 combinations (including duplicates). Here's an example of color blending (alternating between scanlines) using only close colors on the C64 without flicker. Note that they're only able to get 28 usable colors, but that's still significantly more than the C64's official 16 color palette.

Why not push the limits of the hardware?

  View user's profile Send private message
  • Joined: 01 Feb 2014
  • Posts: 701
Reply with quote
Post Posted: Wed May 18, 2022 10:39 am
Looking at it from an artist's perspective, I'm not quite convinced yet. More colours aren't an advantage per se unless you plan on using digitized photos or scanned-in paintings.

Even on systems that supported a lot of simultaneous colours, like the SNES or PCs with VGA cards, artists usually used only a fraction of them in a single piece of artwork (look at the first two Wing Commander games for example). On the other hand, good artists were able to achieve amazing things with either of the two horrible four-colour CGA palettes or the garish shades of the ZX Spectrum.

And again, I can't see how flicker is supposed to be better than dithering, at least if we’re talking about half-tone shades that mix two colours in equal measures. It would be another matter if there was a way of mixing them in different proportions to create smoother colour ramps, as dithering would produce rather spotty results there considering the SMS's chunky pixels. Unfortunately, the resulting flicker would be quite slow, and thus headache-inducingly visible.
  View user's profile Send private message
  • Joined: 23 Jan 2010
  • Posts: 160
Reply with quote
Post Posted: Thu May 19, 2022 6:26 pm
maxxoccupancy wrote
This would be an extra tool for game development, especially for backgrounds, cut scenes, and title images.

The theoretical maximum of any 64 colors mixed with any of the other 64 is 4,096 in total. Many of those are duplicates, and many are far enough apart in chroma and luma--so you'd get noticeable flicker. 343 colors is the limit if you're avoiding duplicates and only allowing two colors that are close in RGB values.

Remember that the Commodore 64 offered just 16 colors, yet made this same technique work for images, getting over 100 usable colors out of a theoretical 256 combinations (including duplicates). Here's an example of color blending (alternating between scanlines) using only close colors on the C64 without flicker. Note that they're only able to get 28 usable colors, but that's still significantly more than the C64's official 16 color palette.

Why not push the limits of the hardware?

Look at this video:

Now look this:

While you seek push the limits of sms ignoring the advices given for experienced devs here even claiming for explore only the SMS2 capacities, those japanese guy explore the truly capacities and keeping the compatibility.
  View user's profile Send private message
  • Joined: 25 Feb 2006
  • Posts: 736
  • Location: Belo Horizonte, MG, Brazil
Reply with quote
Post Posted: Thu May 19, 2022 7:36 pm
segarule wrote
maxxoccupancy wrote
This would be an extra tool for game development, especially for backgrounds, cut scenes, and title images.

The theoretical maximum of any 64 colors mixed with any of the other 64 is 4,096 in total. Many of those are duplicates, and many are far enough apart in chroma and luma--so you'd get noticeable flicker. 343 colors is the limit if you're avoiding duplicates and only allowing two colors that are close in RGB values.

Remember that the Commodore 64 offered just 16 colors, yet made this same technique work for images, getting over 100 usable colors out of a theoretical 256 combinations (including duplicates). Here's an example of color blending (alternating between scanlines) using only close colors on the C64 without flicker. Note that they're only able to get 28 usable colors, but that's still significantly more than the C64's official 16 color palette.

Why not push the limits of the hardware?

Look at this video:

Now look this:

While you seek push the limits of sms ignoring the advices given for experienced devs here even claiming for explore only the SMS2 capacities, those japanese guy explore the truly capacities and keeping the compatibility.


Very impressive homebrew. Most of the effects seem to be done via tile animation; notice the black borders around the pseudo foreground.
  View user's profile Send private message Visit poster's website
  • Joined: 01 Feb 2014
  • Posts: 701
Reply with quote
Post Posted: Fri May 20, 2022 7:41 am
haroldoop wrote
Very impressive homebrew. Most of the effects seem to be done via tile animation; notice the black borders around the pseudo foreground.


Yes, that's the only way to do vertical parallax effects on the SMS.

I think this is the guy who coded GG Aleste 3, so he clearly knows what to do with the hardware.
  View user's profile Send private message
Reply to topic



Back to the top of this page

Back to SMS Power!