adonthell-devel
[Top][All Lists]
Advanced

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

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


From: Kai Sterker
Subject: Re: [Adonthell-devel] I'm back !!!
Date: Mon, 18 Feb 2002 12:56:40 +0100 (CET)

On 18 Feb 2002 12:36:28 +0100 Alexandre Courbot wrote
> 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 ;)

Even better: force him to do it properly this time! ... oh, he already
volunteered for that - too bad ;).


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

Yeah, I came to the same conclusion after writing that.


>> * 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. 

That's settled then.


> 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.

Yes, that would be a lot cleaner. So you would basically register a
callback if you want to get notified of keypresses and all that.

As we only care for a dozend buttons or so, you might even have individual
callbacks for each key (or groups of keys). Like one callback for movement
keys, another one for action keys, etc.

Just a random idea; not sure if it's feasible or useful. 

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

Completely right. In the main programm we should just use the keys we
defined ourselves. And the input system would just map physical keys and
buttons and whatnot to those logical keys.

As for the callback mechanism, I guess you could do it similar to Java.
I think input stuff is handled pretty good there, despite my feelings for
Java as such ;).

Kai





reply via email to

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