Re: [hatari-devel] Feedback SDL2 support

[David Savinkoff <dsavnkff@xxxxxxxxx>]

----- Eero Tamminen wrote:
> Hi,
> 
> On torstai 14 toukokuu 2015, Thomas Huth wrote:
> > Am Thu, 14 May 2015 14:47:40 +0200
> > schrieb Nicolas Pomarède <npomarede@xxxxxxxxxxxx>:
> > [...]
> > 
> > > But maybe we could also remove 16 bit output too and keep only 24 bit
> > > full RGB ? I doubt many devices are not capale of 256 colors abd only
> > > capable of 65536 colors.
> > >
> > > And in all cases, shouldn't SDL handle the conversion itself if
> > > Hatari outputs a 24 bit RGB image and the display device is only 8 or
> > > 16 bit ?
> 
> Yes, SDL does conversions automatically (with little help
> from application itself).
> 
> 
> > > Might be a little less efficient, but that's not even sure if the
> > > video card driver has some accelerated function to do this.
> 
> Conversion is so simple that properly done (SIMD in SDL), it's memory 
> bandwidth bound, not CPU bound, so HW acceleration doesn't help with it.
> Only the Hatari part of the conversion (Atari planar -> SDL chunky)
> is CPU bound.
> 
> Overhead of that extra memory bandwidth usage [1] is *very* visible
> with ST emulation on devices that are barely fast enough to emulate ST
> (e.g. something like Rasberry PI).
> 
> [1] AFAIK 24-bit is typically handled as 32-bit (24-bit can be
>     slower than 32-bit due to alignment), so 2x more memory
>     bandwidth is needed.
> 
> 
> > I've still got an netbook computer (Toshiba AC100) which I use from
> > time to time while I'm travelling - and that one can only do 16-bit
> > color resolutions. It also has a rather poor CPU, so doing the
> > 32-bit to 16-bit convertion additionally would slow down Hatari too much
> > on that device. So as long as I've got that netbook, I'm still willing
> > to maintain the 16-bit convertion routines.
> 
> Btw. While 8-bit palettized resolutions are ugly, Hatari's VDI and
> monochrome modes have only 8-bit conversion routines.  Getting rid
> 8-bit host side code would mean that those would now always go
> through second conversion.
> 
> How your netbook performance would survive that?
> 
> 
> 	- Eero

Hi,

Hatari does video exceptionally well already. The video should
not be changed to accommodate new libraries or hardware
because the new stuff Must accommodate Hatari. If the new
stuff is incompatible with Hatari, the new stuff can use its high
powered CPU to churn the bits. Slow CPUs cannot afford this.

Hatari is a 16/32 bit optimized emulator for the 16/32 Atari ST.
New CPUs and video processors Must deal with this reality
because they can. The oldest reasonable CPU would be a
500 MHz pentium3 (The historic 16/32bit Hatari reference CPU).

I don't see any reason to stop supporting what Hatari already has.

Furthermore, Hatari should only conservatively adopt library
functions to avoid excessive intrinsic interconnected dependence
on the functions, and, negatively influence Hatari development.

Hatari does not need more old PC video modes support either.