[Sik]

http://srb2town.sepwich.com/junk/fade_normal.bin
Normal fading method. It modifies all three components at the same time. Because the Mega Drive only has 3 bits per component in CRAM, it doesn't look very smooth as there are only 8 steps.

http://srb2town.sepwich.com/junk/fade_smooth.bin
Smooth fading method. It modifies only one component each step (in this case, first blue, then green, then red). This allows for 24 steps, 3 times as usual, giving a smoother fading.

Comments on this?

[Chilly Willy]

That's actually pretty good. The components stay close enough together that at the fade speed, it still seems gray the entire time.

[Sik]

:D

Another thing I'd like to remark is that the ROMs there are taking up 48 frames for the fading. I made this so the difference of smoothness between both methods becomes noticeable quickly. So the second ROM is taking two frames per step. This also means that the first ROM is taking six frames per step, or 1/10th of a second (assuming NTSC), which is too much of a gap :P

EDIT: I made another ROM. It does exactly the same as the second ROM above, but instead of changing the components in B-G-R order it does so in B-R-G order. Which one do you think achieves the effect better?

http://srb2town.sepwich.com/junk/fadein_smooth_brg.bin

This post has been edited by Sik: 02 August 2009 - 11:23 AM

[Overlord]

On my PC, I can make out the colour flashes on the 2 smoother ones. Though the other one is jerkier, it doesn't have any of these flashes. My only complaint =P

[Sik]

What do you mean by flashing o_O

[Overlord]

As in being able to make the colour shades out =P

[Sik]

I'm pretty sure that the effect is even worse with the non-smooth one.

Also I dare you to try this one:
http://srb2town.sepwich.com/junk/fade_fast.bin
24 frames instead of 48 >:P

[LocalH]

To be fair, the slight color fringing shouldn't really be a problem, it's done all the time on the C64 to overcome the lack of colors, and the MD is pretty limited with only 3 bits for each color component. The BGR version looked less objectionable to me, as the hue of the color never had red components increased before the blue or the green, and thus never had a red tint, only blue, cyan, and gray/white.

Here's another idea: Make a tile with every other pixel on and off alternating both across and down the tile (a single-pixel checkerboard), and then make another tile that is the binary inverse of that. Make a nametable large enough to hold two full screens, and then fill one half with the first tile and the second half with the second tile. Colorcycle the background as you're doing it now, and also rotate the same colors through the palette index used for the tiles but with a one or two frame advance on the background. Change the scroll to switch between the halves of the nametable on every frame to cause every single pixel to alternate back and forth as fast as possible.

This post has been edited by LocalH: 02 August 2009 - 08:52 PM

[Sik]

The BGR version looked less objectionable to me, as the hue of the color never had red components increased before the blue or the green, and thus never had a red tint, only blue, cyan, and gray/white.

Yeah, I know. The main problem however is this:

BGR: XXX XXX XXX
BRG: XXX XXX XXX

The difference of brightness between cyan and white is very small, and this is very noticeable actually. I don't like the red tinting, but at 24 frames (which is roughly half a second) there isn't much to notice when it comes to hue tinting either, so it's the brightness what matters more. Dunno, I should actually try it in an actual situation, but the deal is there :/

EDIT: coming to think on it, there isn't much brightness difference between blue and magenta either... Curse you, green

Here's another idea: Make a tile with every other pixel on and off alternating both across and down the tile (a single-pixel checkerboard), and then make another tile that is the binary inverse of that. Make a nametable large enough to hold two full screens, and then fill one half with the first tile and the second half with the second tile. Colorcycle the background as you're doing it now, and also rotate the same colors through the palette index used for the tiles but with a one or two frame advance on the background. Change the scroll to switch between the halves of the nametable on every frame to cause every single pixel to alternate back and forth as fast as possible.

Considering that it's a general fading function that should affect every single thing on the display (tilemaps, sprites, etc.), I doubt this is a feasible idea.

This post has been edited by Sik: 02 August 2009 - 09:01 PM

[Chilly Willy]

Well, I tried both smooth ones for a while, and I don't see either as superior or inferior to the other. Perhaps you should try this again, but with a real image. Load an image and then make it loop, fading in, then out. Just fading from black to white doesn't tell us much.

[Overlord]

I'm pretty sure that the effect is even worse with the non-smooth one.

Also I dare you to try this one:
http://srb2town.sepwich.com/junk/fade_fast.bin
24 frames instead of 48 >:P

Less noticible, but still there =P

I do wonder how much of it is due to the fact my PC is slow, though...

[Sik]

...aren't you running the ROM at full speed? o_O Try on real hardware? (though beware that since VRAM is uninitialized, you'll get lots of garbage - fading happens anyways)

[Overlord]

It's running at full speed, yes.


Just the graphics card isn't quite fast enough to always draw frames fluidly. =P If I reset and watch over and over, some runs look better than others.

[TmEE]

Set your monitor refresh to 60Hz or if you insist on 75Hz, use 50Hz in emulator... 75Hz seems to be default setting on most GFX cards.

[Overlord]

Putting aside the fact my refresh rate is already AT 60Hz, my monitor is a TFT. =P

I think you underestimate just how shitty my GeForce 4 MX 440 is....