Re: [hatari-devel] Display problem in Paradox latest demo

[ Thread Index | Date Index | More Archives ]

On Sat, 28 Dec 2013, Nicolas Pomarède wrote:

I think it's to reduce color flickering with the 2 different dithering pictures ? A higher framerate can slightly limit it (I remember the old TEX's spectrum 512 slideshow was running in 60 Hz too).


The TEX slideshows were likely 60 Hz because Spec 512 itself was, 50 Hz display would have needed the displaycode to be modified and not ripped right off (speculating what happened here ;)

But yes for dual-field (as well as normal interlace) 60 Hz helps a fair bit.

A 60 Hz screen has only 263 hbl, but I see the demo is switching to med res on hbl 259, so the last 4 lines of the screen are displayed in med res, I don't see the point. Maybe something is displayed on a real STE that we don't see on Hatari ? But it's just seem to show some garbage lines.

I've run it on my STe (that's why I figured it was 60 Hz, as the screen appeared more stretched than usual). I did not see any garbage graphics at the bottom. Of all the monitors I've tried (including a PAL DV recorder), they only show 274 Atari PAL lines, not 276 that Hatari do.

Maybe the same problem in 60 Hz, Hatari show more lines than a real machine would so you get some graphics garbage at the bottom. Another thing is that perhaps Hatari window should somehow shrink or crop to the correct 263 HBL. On the other hand in programs switching a lot it might be total mayhem.

About medres. I can't be sure, but switching to medres then zeroing four palette registers is a faster way to blank the screen than to zero all 16 registers, it could be the reason.

For now, I added a 4 cycles tolerance to this case, so the demo should now run OK :)

Thanks :)

I suppose nobody is doing nightly builds for OS X? As usual I'm too lame to compile hatari.

"CMake Error: Parse error in cache file /Users/ae/Atari/Source/hatari/CMakeCache.txt. Offending entry: /SDKs/MacOSX10.9.sdk"

Anders Eriksson

Mail converted by MHonArc 2.6.19+