[hatari-devel] OS X frameskip issue
Kåre Andersen
kareandersen at gmail.com
Fri Jul 24 02:59:18 CEST 2009
On Thu, Jul 23, 2009 at 11:53 PM, Kåre Andersen<kareandersen at gmail.com> wrote:
> On Thu, Jul 23, 2009 at 7:44 PM, Eero Tamminen<eerot at users.berlios.de> wrote:
>> Hi,
>>
>> (I changed the subject as this isn't anymore about the convertors)
>>
>> On Thursday 23 July 2009, Kåre Andersen wrote:
>>> >> > -int nFrameSkips; /* speed up by skipping video frames */
>>> >> > +int nFrameSkips=0; /* speed up by skipping video frames */
>>> >>
>>> >> It's possible that because you explicitly set the variable, it goes
>>> >> to a different section in the binary (.data instead of .bss)[1], but
>>> >> that should not have any effect on it's value as globals are
>>> >> automatically zeroed. (Apple documentation I referred in my earlier
>>> >> mail already stated that .bss should be zeroed.)
>>> >
>>> > I agree with Eero here. I hardly can believe that the .bss is not
>>> > initialized to zero on Mac OS X (it's a BSD/Unix based OS, and all such
>>> > systems clear the BSS as far as I know).
>>>
>>> Ok, talking to my guru gives the same answer: The C standard defines
>>> that bss should be cleared. And Eero found the info that i could not
>>> find, so I back down from this... Sorry for jumping the gun - again -
>>> bad habit. I guess the fix was just too simple to be correct....
>>>
>>> > So the real problem (a wrong memory access) might still persist, it's
>>> > just not visible anymore since the variable has been moved to another
>>> > location in memory.
>>>
>>> I will try to track this down as best as I can tomorrow daytime.
>>> Better get as much done as possible before holidays end....
>>
>> Could you remove zeroing of the nFrameSkips and do following change:
>> --------------------
>> --- a/src/video.c Tue Jul 21 23:37:35 2009 +0300
>> +++ b/src/video.c Thu Jul 23 20:40:53 2009 +0300
>> @@ -2483,6 +2483,14 @@
>> static void Video_DrawScreen(void)
>> {
>> bool bScreenChanged;
>> +
>> + static int OldFrameSkips = 0;
>> +
>> + if (nFrameSkips != OldFrameSkips) {
>> + fprintf(stderr, "DEBUG: nFrameSkips, old: %d, new: %d\n",
>> + OldFrameSkips, nFrameSkips);
>> + OldFrameSkips = nFrameSkips;
>> + }
>>
>> /* Skip frame if need to */
>> if (nVBLs % (nFrameSkips+1))
>> --------------------
>>
>> Then run Hatari in a way that earlier produced the issue and mail
>> us what it outputs.
>>
>> I want to know what the problematic value is and whether it changes.
>>
>> If it's because of overwrite from some other variable, the bogus frameskip
>> value(s) could tell what does the overwriting.
>>
>>
>> - Eero
>>
>
> Indeed, but I can do you one better... :)
>
> Gotcha!
>
> The problem is with the ShifterLines array in the SHIFTER_FRAME
> struct. Either there is an off-by-one error someplace or the number of
> scanlines per frame should be 502 for high res.
>
> So, temporary solution is increase the value of
> MAX_SCANLINES_PER_FRAME in video.h to 502 - and all is peachy. Does
> this turn any light bulbs on for you, or should i dig deeper into the
> scanline code?
>
> I am your humble servant :)
>
> /Kåre
>
So much for sleeping normal hours, I just had to figure this one out :)
Seems Hatari was preparing an extra HBL at the end of the screen,
which was fine in Low and Med rez, since there are enough ShifterLines
reserved for High anyway...
Or something else entirely ;) Seems to work perfectly tho!
/Kåre
Minipatch:
--- ../../hatari-hg-072209/src/video.c 2009-07-22 10:17:27.000000000 +0200
+++ video.c 2009-07-24 02:54:50.000000000 +0200
@@ -1442,6 +1442,9 @@
nHBL++; /* Increase HBL count */
+ if(nHBL >= nScanlinesPerFrame)
+ return;
+
/* Update start cycle for next HBL */
ShifterFrame.ShifterLines[ nHBL ].StartCycle = FrameCycles -
PendingCyclesOver;
LOG_TRACE ( TRACE_VIDEO_HBL , "HBL %d start=%d %x\n" , nHBL ,
ShifterFrame.ShifterLines[ nHBL ].StartCycle ,
ShifterFrame.ShifterLines[ nHBL ].StartCycle );
More information about the hatari-devel
mailing list