Re: [openMSX-devel] SDLGL-FB16/32 renderers

[Maarten t. H. <ma...@tr...>]

On zondag 24 februari 2019 09:52:48 CET Wouter Vermaelen wrote:

> These renderers should not be included in daily builds. These are not
> useful for users (and can only confuse them).

OK, then setting the default for that feature to "disabled" would make 
sense.

> I don't remember the last time i used these renderers for development,
> but then I also haven't worked on rendering stuff for many year. If
> it's easy to make these into optional (disabled by default)
> components then that's fine. But I also wouldn't mind dropping them.
> Maybe that's even better? We can always get them back from git.

Getting things back from Git is not a good long-term strategy, since the 
longer the code hasn't been in the source tree, the more work it is 
going to be to get it working again if you need it. So I'd only be in 
favor of dropping them if we think we're never going to use them again.

> A few of our scaling algorithm exist in the software renderer (SDL)
> but not in openGL scalers (SDLGL-PP). The SDLGL-FBxx renderers could
> be a workaround for that. But OTOH nobody complained about the lack
> of these renderers.

I think the whole scaling system is not very easy to understand for 
users and having these renderers as an official workaround would only 
solidify that complexity. If we really need the workaround, it should be 
done automatically inside the SDLGL-PP renderer, in my opinion.

Which renderers have no GL counterpart, besides MLAA?

> An example of a software-only scaler is MLAA. But also in software
> that scaler is incomplete. Should we drop it? (Or is someone
> motivated to finish it)?

I am motivated, but also short on time.

Note that when finished, MLAA would be like the HQ scaler: we would 
compute slopes in MSX-resolution on the CPU, then upload that data into 
a texture and have it rendered at output resolution on the GPU. So it 
wouldn't remain a software-only scaler.

Bye,
		Maarten