Atari++ & TIP?

[Heaven/TQA]

Hello guys,

 

first I thought it is my code but is it just me or does Atari++ emulator not support TIP? I mean HIP is presented correct but what about TIP?

 

look at the screenshot of Numen, TQA logo appears correct at the beginning but not the TIP?

[pps]

Here this picture looks more bw than coloured. Only the eye and the numen is blue.

 

seems to be a problem of atari++ since atari800win+ has not this problem.

Edited December 27, 2008 by pps

[Tezz]

Heaven both Atari++ and Atari800WinPLus are not acurate (or correct) yet in respect of Antic + GTIA emulation it seems. On the whole they cope with the standard stuff as you'd expect but doing a lot of stuff outside of the norm, it falls down. It's so convenient using emulation when working on stuff but I've had to use the real hardware a lot more recently. This past few weeks I've been trying out some stuff with GTIA and the emulators are giving nothing like the correct output, Atari++ and Atari800WinPLus produce different incorrect results too.

Edited December 27, 2008 by Tezz

[thorfdbg]

Hello guys,

 

first I thought it is my code but is it just me or does Atari++ emulator not support TIP? I mean HIP is presented correct but what about TIP?

 

look at the screenshot of Numen, TQA logo appears correct at the beginning but not the TIP?

What should it look like? Did you enable the de-flicker option in the GTIA emulation?

 

Thanks,

Thomas

[Rybags]

Maybe the emulator has some sort of desaturation going on? Kinda like the real thing, except taking it a bit too far.

[frogstar_robot]

Maybe the emulator has some sort of desaturation going on? Kinda like the real thing, except taking it a bit too far.

 

That is very evident in the TIP animations that have been so popular recently. Atari800 displays them in a highly colorful way that seems fairly accurate. Many either look b&w or almost b&w on Atari++.

[thorfdbg]

Maybe the emulator has some sort of desaturation going on? Kinda like the real thing, except taking it a bit too far.

 

That is very evident in the TIP animations that have been so popular recently. Atari800 displays them in a highly colorful way that seems fairly accurate. Many either look b&w or almost b&w on Atari++.

That is due to the way they are generated. I'm rather unsure whether they *are* colorful - look, what happens here is that the colors are mixed at the screen by flickering, and all the emulator does is to average the two frames, which seems fairly reasonable, but which also implies that the colors will be desaturated by 50%. If you do not enable the de-flickering, the flicker will be close to the original flicker, and thus the color appearance will be close to the original. If you enable the de-flickering mode, colors will be mixed in the emulator, taking the average of the two frames. Whether that's close to what happens in reality depends on your monitor (and your eyes). Unless you can provide good evidence that taking averages is *not* a good model (for example by taking a photo from a "real" image), I'd say I stick to what I have. Otherwise, I would guess that Atari800 shows the colors too colorful to be real. Showing a mid-level red and a bright grey does not give you a bright red. It gives you a 50% desaturated bright red.

 

So long,

Thomas

[frogstar_robot]

If you do not enable the de-flickering, the flicker will be close to the original flicker, and thus the color appearance will be close to the original. If you enable the de-flickering mode, colors will be mixed in the emulator, taking the average of the two frames.

 

Antiflicker is not enabled. I just tried enabling it and the only difference it makes is to steady the actually flickery TIP frames. Someone with real hardware driving an NTSC or PAL set would have to tell if washed out color in those modes is what actually occurs.

 

I'll tell you an interesting thing that happens though. If I use a screenshot application to take a snap of a TIP frame then the color returns. If I had to guess, I'd say my LCD monitor interacts in an unfortunate way with how Atari++ deals with TIP pictures.

Edited December 29, 2008 by frogstar_robot

[thorfdbg]

If you do not enable the de-flickering, the flicker will be close to the original flicker, and thus the color appearance will be close to the original. If you enable the de-flickering mode, colors will be mixed in the emulator, taking the average of the two frames.

 

Antiflicker is not enabled. I just tried enabling it and the only difference it makes is to steady the actually flickery TIP frames. Someone with real hardware driving an NTSC or PAL set would have to tell if washed out color in those modes is what actually occurs.

 

I'll tell you an interesting thing that happens though. If I use a screenshot application to take a snap of a TIP frame then the color returns. If I had to guess, I'd say my LCD monitor interacts in an unfortunate way with how Atari++ deals with TIP pictures.

If you make a screen shot, you only save one of the two frames (IIRC), so you have half of the lines in grey-scale, and the other half in color. What can happen is that you get an additional smoothing effect from the LCD, indeed, since it might be too slow to follow the flicker. Depending on the technology, the LCD panel colors then come out too dark or too bright - the crystals can't follow the oscillation (too dark for my screen, actually).

 

However, the de-flicker option would remove all that, and would average frames so you do get a steady picture. However, I would need to compare that with the impression you get from a TV to really design a more sophisticated color mixing model.

 

So long,

Thomas

[Rybags]

Maybe the emulator only decides to do colour mixing if it detects interleaved scanlines of Mode 11 and 9.

 

TIP shouldn't have flickering - the GTIA colour mode (11) lines are static and the interleaved lines just alternate between luma and paletted mode (9 and 10).

 

Also, PAL colour mixing occurs regardless of what graphics mode you use.

 

 

GTIA colour (Gr. 11) interleaved with Antic Mode 4 using VScrol = 7 to show single line of that mode, with underlayed PMGs.

[thorfdbg]

Maybe the emulator only decides to do colour mixing if it detects interleaved scanlines of Mode 11 and 9.

 

Nope. Color mixing is completely orthogonal to the graphics mode.

 

TIP shouldn't have flickering - the GTIA colour mode (11) lines are static and the interleaved lines just alternate between luma and paletted mode (9 and 10).

 

Then the NUMEN entry picture is not following the TIP convention. It *does* perform flickering.

 

Also, PAL colour mixing occurs regardless of what graphics mode you use.

 

 

GTIA colour (Gr. 11) interleaved with Antic Mode 4 using VScrol = 7 to show single line of that mode, with underlayed PMGs.

 

Of course it does, the TV doesn't know the graphics mode in first place. (-: Mixing applies whenever two colors of the same brightness are displayed next to each other, i.e. either above or below each other. If the brightness is different, no mixing applies. At least this is what my TV does about it.

 

So long,

Thomas

[Rybags]

What I meant was - the emulator mightn't necessarily decide to do the colour blending.

 

On the real machine on the default Gr. 0 display, the first scanline of the text should have a slightly different background to the rest. The emulator doesn't seem to do it, but it's easy to identify using my capture card and magnifying a small area.

[thorfdbg]

What I meant was - the emulator mightn't necessarily decide to do the colour blending.

 

On the real machine on the default Gr. 0 display, the first scanline of the text should have a slightly different background to the rest. The emulator doesn't seem to do it, but it's easy to identify using my capture card and magnifying a small area.

No, no color blending takes place there simply because the luminance of the background is different from the luminance of the blue background. I do not see any color blending artifacts on my TV.

 

Try that: Open a Gr.15 screen, draw horizontal lines with altering colors, color 1 followed by color 2. Then use "setcolor" to change the color registers. On my PAL TV, the two colors blend into each other if and only if they have the same luminance.

 

If that's different from your experience, please report.

 

Thanks,

Thomas