adonthell-devel
[Top][All Lists]
Advanced

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

[Adonthell-devel] Global framework redesign


From: Alexandre Courbot
Subject: [Adonthell-devel] Global framework redesign
Date: 17 Feb 2002 14:23:55 +0100

I think we might need to redesign a bit our global framework. It
currently has several disadvantages:
-You absolutely need a valid data directory (i.e wastesedge) to run
anything. This is absolutely bad. All the editors, and dlgedit in
particular, should be able to run with just the adonthell package
installed.
-The game class is a big mess. You usually call game::init(), to
initialise the game. If your application (editor once again) includes
the class, it has to include all the rest - but for my animation editor
I don't need at all to initialise the audio stuff, and I don't want it
included in my binary. So I initialise all the subsystems one by one -
and that's what should be done too in the main binary IMO.

There are others disadvantages, but globally it's heavy, it's dirty, and
it doesn't work as well as it should. So I propose we discuss it here to
write another framework from scratch.

What's the framework anyway? I see it at a glue that connects all the
different subsystems to each others. There is the gfx subsystem, the
dialog subsystem, the window subsystem, etc... which are independant.
You don't need all the dialog stuff to draw a window, for example. The
framework also handles the data and sets some global path so you know
where to get what.

The first thing is that one window theme and one font should come with
the adonthell package, and get installed with it. This theme and this
font would be automatically loaded by the theme & font manager at
initialisation time. That way, whatever you have, you KNOW that you have
at least one theme and one font in memory. The editors that rely on
Joel's GUI wouldn't need a data package to work anymore - I don't need
Waste's Edge if I just want to edit an animation, right?

The second thing is that characters/quests info files should be loadable
on request, for dlgedit to be able to run without a data package too.
You could edit dialogs without any character/quest in memory, but would
you need some available, just do file->load character file, select your
file and voila.

These are just random ideas, the only thing I'm certain about is that we
need to redo our framework. Currently everything is fixed at init time
and remains static. We must turn it into something more dynamic. I'll
try to come with more ideas later, but I let you know what I think so
you can give it a thought too ;)

Alex.
-- 
http://www.gnurou.org




reply via email to

[Prev in Thread] Current Thread [Next in Thread]