| Re: [AD] Proposal for Allegro's future (namespaces, et al.) |
[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
Johan Henriksson wrote:
I personally think that Allegro 5.0 should have a new API (yes, it will be
incompatible with Allegro 4.0).
The incompability can be solved with an extra header.
Including the 63->255 palette entries? The BITMAP, RLE_SPRITE and
COMPILED_SPRITE merge? I don't think so.
Elias's idea of being able to download modules individually is good.
Perhaps
the web site could also generate a makefile that would compile everything?
This is a bad thing. It will only produce more work. You sound like there
will be only one Allegro game/computer. Not really, several games will
depend on the same SO/DLL's/.a's etc. It would just become harder
for the developer... :/
<sarcasm>Yeah, looked at what happened with the WIP, I'm sure everyonce is
likning against the same DLL...</sarcasm> :D
So check this: if you don't select "Everything", you can only static link
your code, where as if "Everything" was selected, you have the option of
dynamic linking. How's that?
Ok, that kind of defeats the purpose of it... ok so maybe it's a bad idea.
- have lots of new stuff (GUI skins, etc).
What about the GUI stuff on the GUI list? Could be interesting.
Why not drop the GUI thing completely? Any GUI is better than Allegro's.
I only know 3 apps that use it:
* Grabber
* The GUI example
* One mapeditor of mine (and I regret I used it...)
Some of the examples programs too! :)
Seriously though, the Allegro GUI is useful if you need to do a
quick-n-dirty GUI for your app/game/whatever and don't want to either cde
your own, or rely on MFC (pain in the ass), GTK (buggy), or Qt (C++ only).
> -Allegro specific IDE
Dev-C++ with a few enhancements? We could make a few templates for
linking,
and possibly add name completion of Allegro functions. Having a debugger
in
there would also be nice.
And the benefit of this would be...? Nothing. Just extra garbage to the
dist.
Who said anything about including it in the dist? AFAIK Dev-C++ comes with a
compiler. I don't hink addign 12 MB to the Allegro download is sane.
> -Allegro BASIC (go ahead and laugh) and scripting
I don't think it's a priority. Perhaps it could be started off as a
seperate
project, then later on merged?
More bloat???
See above about bloat.
I bet there are a 100 different scripting libraries, at least
10 good.
What would such a library gain by having it included in a 300k library that
doesn't help it a bit? You know, users know how to link multiple
libraries...
Perhaps. I don't think about that "100" number though, esp when it requires
being portable to every system Allegro can be ported to.
[snip]
I would like to add:
- Networking support (libnet merge-in?)
Anything about a "merge" is a bad idea
Bloat again? What about the module idea? We could have allegro.dll,
allegro-network.dll, allegro-scripting-language.dll, allegro-GUI.dll...
Where these libraries are really libnet, SeeR and DUI in disguise (for example).
--
- Robert J Ohannessian
"Microsoft code is probably O(n^20)" (my CS prof)
http://pages.infinit.net/voidstar/