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

[Wouter V. <ver...@gm...>]

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

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.

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.

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)?

Wouter

On Sun, Feb 24, 2019 at 8:52 AM Maarten ter Huurne <ma...@tr...>
wrote:

> Hi all,
>
> We currently have two renderers that are only built when the source tree
> is not in "release mode": a flag we briefly set when tagging a release.
>
> The renderers are called SDLGL-FB16 and SDLGL-FB32. If I recall
> correctly, these:
> - render in MSX resolution in software (all our renderers do; doing this
> on the GPU turned out to be very inefficient)
> - scale in software (unlike SDLGL-PP)
> - upload to video memory via OpenGL calls
>
> I'm wondering how to translate this to the Meson build. Currently it
> works exactly like the non-Meson build, by looking at the release flag.
> But conceptually it feels like this should be a component instead: these
> renderers are an optional feature that can included or excluded from the
> build.
>
> In the non-Meson build, components are implicit: a component is enabled,
> unless:
> - a required dependency is not found
> - the component is disabled by the platform (via the LINK_MODE variable)
>
> So there is no way for the user to explicitly enable or disable
> components. That's something we inherited from the autoconf way of
> working, but over the years I've realized it's not a good approach: the
> user should be able to control whether a component is enabled or not and
> if the user explicitly enables it, it should be an error if the
> component cannot be built. This is different from autoconf's approach,
> which drops an optional component if a dependency is not available, even
> if the user explicitly asked for that component.
>
> Fortunately, Meson has a different way of dealing with this. You can
> define features and for each feature there is a flag that the user can
> set to "enabled", "disabled" or "auto". The "auto" value is the autoconf
> behavior: build the feature if possible, otherwise drop it. But if a
> user selects "enabled", it is an error if the feature has missing
> dependencies, such as a library that cannot be found.
>
> Since we have a better system for controlling features with Meson,
> converting these renderers to a component controlled by a feature makes
> sense. I think the feature should be specific to these renderers and no
> longer tied to release mode, which also controls things like showing the
> Git revision in the version number.
>
> What I would like to know:
> - are these renderers still useful for testing?
> - if so, do we want them enabled for developers only or also in daily
> builds?
>
> Related to this is the question of what we want to do with software
> scaling in general, but I'll compose a separate mail for that.
>
> Bye,
>                 Maarten
>
>
>
>
>
> _______________________________________________
> openMSX-devel mailing list
> ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openmsx-devel
>