[hatari-devel] Hatari patches for bitplane conversion
Kåre Andersen
kareandersen at gmail.com
Wed Jul 22 11:50:33 CEST 2009
Some time ago:
>> >> PPS: the frameskip stuff in Video_Drawscreen() is still there and
>> >> bugging on OS X... "if (nVBLs % (nFrameSkips+1)) return;" -
>> >> seems to me like you are forcing frameskipping whenever things
>> >> get too hot, regardless of the user preference. I could be wrong
>> >> tho ;)
>> >
>> > nFrameSkips should be 0 when the user disabled frame skipping, so
>> > this line of could should be ignored.
>> > The recent problems with ST-High must be caused by something else,
>> > especially since it was working a week ago as far as I know
>> > I'll try to have a look at this problem at this weekend, too.
>
>> Thank you. However, something with nVBLs is definately going haywire -
>> and i don't see why you would want to do that modulo operation in the
>> first place. At least it deserves some documenting...
>Could you please check if this problem still persists for you after my
>latest commit (the frame cycles counter fix)?
It did...
On 7/22/09, Kåre Andersen <kareandersen at gmail.com> wrote:
> Nope. Except for the new Monochrome problem, which is still there.
> Like said, fullscreen SDL bypasses compositing. Or so i read
> somewhere...
And, the problem is gone! :)
nFrameSkips is somehow never initialised, add a =0 and everything is
fine... How can this be different on different platforms?
Mini-patch:
--- hatari-hg-072209/src/video.c 2009-07-22 10:17:27.000000000 +0200
+++ hatari/src/video.c 2009-07-22 11:47:56.000000000 +0200
@@ -293,7 +293,7 @@
int STRes = ST_LOW_RES; /* current ST resolution */
int TTRes; /* TT shifter
resolution mode */
-int nFrameSkips; /* speed up by
skipping video frames */
+int nFrameSkips=0; /* speed up by
skipping video frames */
bool bUseSTShifter; /* Falcon: whether to
use ST palette */
bool bUseHighRes; /* Use hi-res (ie
Mono monitor) */
/Kåre
More information about the hatari-devel
mailing list