|
ForumsSega Master System / Mark III / Game GearSG-1000 / SC-3000 / SF-7000 / OMV |
Home - Forums - Games - Scans - Maps - Cheats - Credits Music - Videos - Development - Hacks - Translations - Homebrew |
Author | Message |
---|---|
|
240 colors out of a palette of 343 on the SMS, color sprites
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. |
|
|
240 colors out of a palette of 343 on the SMS, color sprites
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? |
|
|
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. | |
|
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 | |
|
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? |
|
|
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. | |
|
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. |
|
|
Posted: Tue Mar 08, 2022 2:11 pm |
That’s what so great about Discord, nothing can be found later…
|
|
|
Posted: Tue Mar 08, 2022 2:24 pm |
I posted that in the topic "SMS palette visualizations", though the vertical position interpreted as "luminance" is merely R+G+B. |
|
|
Posted: Tue Mar 08, 2022 2:28 pm |
The picture of the palette this topic?
https://www.smspower.org/forums/18618-ColorPaletteWithProperIndices |
|
|
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 |
|
|
240 colors out of a palette of 343 on the SMS, color sprites
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. |
|
|
100 colors out of 343
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. |
|
|
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. |
|
|
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. | |
|
240 colors out of a palette of 343 on the SMS
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. |
|
|
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. | |
|
Posted: Thu Mar 10, 2022 12:18 am |
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. |
|
|
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. |
|
|
Posted: Thu Mar 10, 2022 11:17 pm |
Maybe the Game Gear would provide better results, with its larger palette and blurry screen. | |
|
Posted: Thu Mar 10, 2022 11:24 pm |
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. |
|
|
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). |
|
|
240 colors out of a palette of 343 on the SMS, color sprites
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. |
|
|
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 | |
|
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. | |
|
Posted: Fri Mar 11, 2022 4:27 pm |
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. |
|
|
porsche formula one 224x128
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. |
|
|
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. |
|
|
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. | |
|
240 colors out of a palette of 343 on the SMS, color sprites
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 |
|
|
Posted: Thu Apr 07, 2022 4:58 pm |
it's terrible, thank you! <3 | |
|
Flickering
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. |
|
|
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. | |
|
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). |
|
|
240 colors out of a palette of 343 on the SMS, color sprites
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. |
|
|
Posted: Tue Apr 12, 2022 1:29 pm |
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. |
|
|
Posted: Sat Apr 16, 2022 4:18 am |
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. |
|
|
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. |
|
|
Posted: Sat Apr 16, 2022 11:10 am |
Love your sense of humor, please keep entertaining us. |
|
|
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) |
|
|
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 🤣 |
|
|
Posted: Sun Apr 17, 2022 9:02 am |
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... |
|
|
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. |
|
|
Posted: Sun Apr 17, 2022 9:52 am |
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. |
|
|
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. | |
|
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? |
|
|
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. |
|
|
Posted: Thu May 19, 2022 6:26 pm |
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. |
|
|
Posted: Thu May 19, 2022 7:36 pm |
Very impressive homebrew. Most of the effects seem to be done via tile animation; notice the black borders around the pseudo foreground. |
|
|
Posted: Fri May 20, 2022 7:41 am |
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. |
|