Re: [Adonthell-devel] On source code structure and backends

[Alexandre Courbot]

> AFAIK, we'd only have a few #ifdefs for windows. The DLL tools are just
> the same, but named differently.

Actually, it looks like libtool provides everything we need for
compatibility over different platforms. I'll have to look at that.

Anyway - I have a short example working! It works very fine, modulo a
little drawback: all the class methods that are defined in the backend
must be declared as virtual in the interface file. Otherwise, when
linking the binary / loading the gfx library, the loader will look for
the methods symbols, which will only be made available later by our
dlopen(), and will of course fail to find them. After a quick search on
the web, all the tutorials I've found are made in this way.

Well, you all know my aversion towards virtual functions. Anyway, here
are a few points in their favour:
- Even if we could do without virtual methods, the calls we'd make to
functions in the backend would be calls to pointer to functions, which
would cause  pipeline break. I'm not even sure virtual functions cause a
pipeline break, since the value of the vtable is static - therefore the
processor can feed its parallel pipelines used when a jump if met.
- The virtual methods mechanism only uses a few assembler lines.
Compared to what the functions actually do (blitting images and so on),
it looks neglectable.
- The backends will only take place for rendering, audio and input. No
such things for the game itself - it'd only take place on the client
side.
- As long as the player doesn't miss a frame if we use virtual methods,
that's fine! The only thing is that we'd have to test.

Maybe I can ask some group where this topic isn't OT about it. Maybe
there's even a way to do without virtuals - although I can't think of
one right now.

I'm interested in what you may think!
Alex.
-- 
http://www.gnurou.org

ldtest.tar.gz
Description: GNU Zip compressed data