Re: [Adonthell-devel] I'm back !!!

[Alexandre Courbot]

I'll try to give more infos as Jol and I are talking about this since
quite a long time! Especially about the input system, as the current one
is really a bull. If I were the boss, I would fire the guy who made it,
personnally ;)

> >> How, i'll use adonthell graphics class (image,
> >> drawing_area ... and other)
> >> What's news:
> >>        - I think(but i'm sure) an API like gtk.
> >>        - True type font. (it's more usefull for
> >> internationalization (unicode ...)
> > 
> > Coooool!
> > ...can it be anti-aliased too? :P
> 
> Yes true type fonts would be cool. There are a few things to keep in mind
> though:
> 
> * Making our own font would become much harder, so we possibly had to use
>   some freely available ones. (Not too much of a problem, I'd say)

No problem at all even. Think also about the advantages: scalable fonts,
etc... (more to come later)

> * We need colored fonts. So we have to be able to change the color of the
>   font we use. I am not sure how easy that will be with true type fonts.

As true type fonts doesn't have any color information, this should not
be a problem neither.

> * And last, we should keep Adonthell portable, so any true type library
>   we'd use should be portable as well.

You can't find more portable than freetype, the true type fonts handling
library, written in ANSI C ;) Moreover there already exists a SDL tt
fonts handling lib, SDL_ttf. Maybe we could use it, or at least get
inspired from it. 

And to answer James, yes, freetype does support AA! :)

> >>        - Full keyboard and mouse events.
> 
> Don't forget gamepads :).

Indeed! ;)

What I'm most concerned about for now (and so is Joel) is the input
system. First, I think we shouldn't work with "is this key pushed?" like
functions anymore. The only reason why I implemented it that way was to
control the map engine, and it was a serious design error. Instead, a
"listener" (that is, a class that listens to the input) should get
noticed when a key is pushed or released (this also applies to mouse and
joysticks, of course). There is some big design work once again.

The others drawbacks of the current input system are:
-Dependance on SDL for keys definitions. SWIG for example needs to
include the one of SDL's headers files that defines all the keys. We
have to define ourselves some contants for the keys we use instead.
-No abstraction layer for control customisation. Right now you just can
test the keyboard keys, but we should have some others functions that
return whether the RED key has been pushed (no matter whether it is
mapped to a keyboard key or a joystick button)
-

Jol still have a lot of work until April, so he won't be able to really
start coding before. So if nobody complains (especially you, Jol), I'll
take over the input system rewriting under Jol's direction, at least to
pose it's basics. That way, we will all have something usuable to work
on. Is it allright? If so, I'll start looking at how higher level,
object oriented libraries does handle the thing. Please also give your
requests and ideas, too! :)

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