[hatari-devel] Killing impact screen problem : I've found the problem
npomarede at corp.free.fr
npomarede at corp.free.fr
Wed Feb 3 22:27:48 CET 2010
On Wed, 3 Feb 2010, Eero Tamminen wrote:
>> I don't think that adding something like the following patch is a good
>> idea:
>>
>> if (hscrolloffset !=0)
>> fvram +=2;
>>
>> Perhaps "atariVideoRAM" is the problem too ?
>
> You can look into Video_CopyScreenLineColor() in video.c how it does STE HW
> scrolling. Maybe Videl code isn't taking into account everything doe in
> there?
>
> (I guess in the Videl case you can ignore the border handling code)
>
> Nicolas?
Hello,
I really don't have any clue on how the falcon memory is working. Sure
that in ST/STE mode, we can use the same routs are those for plain STE in
video.c/screen.c but for the problem reported by laurent, I think it's
falcon specific.
On STE low res, using hscroll requires 8 more bytes per line (due to
prefetching), but I don't know if similar adjustements are needed on
falcon.
>
>
>> Any idea of how to correct this correctly.
>
> I also wonder whether we really need always to use Videl drawing routines:
> /* Now draw the screen! */
> if (ConfigureParams.System.nMachineType == MACHINE_FALCON
> && !bUseVDIRes)
> {
> bScreenChanged = VIDEL_renderScreen();
> }
>
> Couldn't we on Falcon & TT use the ST/STE screen rendering when
> using ST/STE screen mode on them? Those drawing routines handle
> scrolling etc fine.
Yes, maybe some "shortcuts" could be used to call STE screen functions,
but does someone know how to determine when videl is in such mode ?
Nicolas
More information about the hatari-devel
mailing list