[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

RE: Please review packaging of clanlib2



> Date: Wed, 21 Mar 2012 12:02:38 +0000
> From: smcv
>
> On 21/03/12 10:50, Mark Page wrote:
> > For the i386 platform the options are:
> > A) Disable SSE2 totally
> > Option A:
> > clanSWRender is not available.
> > There will not be any difference to games without sound running OpenGL.
> > With sound, the speed difference depends on the CPU speed.
>
> Is clanSWRender a separate shared library or what? How do ClanLib games
> select the software renderer?
>

All ClanLib components are separate libraries. (This is the same with the old packaged ClanLib 0.8 and ClanLib 1.0)

For example:
mark@mark-Inferno-Katana:/usr/lib$ ls libcl*.a
libclan23App.a        libclan23Display.a  libclan23MikMod.a   libclan23Sqlite.a
libclan23Core.a       libclan23GL1.a      libclan23Network.a  libclan23Vorbis.a
libclan23CSSLayout.a  libclan23GL.a       libclan23RegExp.a
libclan23Database.a   libclan23GUI.a      libclan23Sound.a   libclan23SWRender.a

An application selects which component it requires by calling the setup function and linking in the library
For example:
    #include <ClanLib/swrender.h>
   CL_SetupSWRender setup_swrender;

With clanGL, clanGL1 and clanSWRender, it plugs itself into the clanDisplay interface. So it's easy to change the render target by using a option in the application command line or otherwise.

As far as I know, no games use clanSWRender as the default renderer. It usually is clanGL1 (OpenGL 1.3)

A game "configure" script can/should detect the presence of clanSWRender, and not use it.

> > B) Create 2 versions of the library ( something like /usr/lib and
> > /usr/lib/sse2 - http://wiki.debian.org/Multiarch/LibraryPathOverview )
> > Option B:
> > This adds extra complexity for little gain
> > Application developers have to be aware that SSE2 may or may not be available
>
> Why would game developers have to be aware of it? Are the only reasons
> "the software renderer might not be available, and things might not be
> fast enough" or are there others?

The only reason is that the software renderer might not be available.

Not a real problem though, since the application would only need to catch the "not available" exception on the stub version.

>
> It's already the case that the software renderer might not be available
> (all non-x86 platforms), so game developers have to be aware of that
> anyway; it's already the case that things might not be fast enough (slow
> CPUs), so users have to be aware of that anyway (don't run it if it's
> unplayably slow).
>
> This solution is only suitable if the versions built with/without SSE2
> have the same ABI.
>

Yes, I agree

> > A non-SSE2 clanSWRender would have to be implemented that throws a "not available" exception
>
> What do ClanLib games currently do on non-x86 platforms like powerpc,
> where SSE2 doesn't exist?

They run using OpenGL instead.

> > In the future ClanLib 2.4 may contains inline SSE2 intrinsic in the API.
>
> How does this work on non-x86 platforms like powerpc, where SSE2 doesn't
> exist?
>

That is my mistake. It should not matter.

  #ifdef SSE2
    void func() { ...SSE2_Code... }
  #else
    void func() { ... Code ... }
  #endif



Reply to: