| Re: [AD] Proposed changes for Allegro 5 (6?) |
[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
Hmm, I have a feeling this thread will explode as everyone is commenting on
everyone else's thoughts :)
Laurence Withers wrote:
Well:
- load_sample() and load_bitmap() both already exist,
Yes they do. I thikn they should be updated to be "smarter" - that is,
actually look at the header of the file (or meta data on the filesystem) to
determine its type instead of simply the filename. We could have a
registered function is_of_my_type(PACKFILE *), which would return true if
the file can be loaded by the registered format or not.
If we have this system, then it makes the other load* redundant.
- dropping things like zbuffer/p3d/blenders: why? As long as they are
in separate object files they won't be pulled in if necessary.
Yes, but how useful are they? They seem highly specialized (P3D), little
used, and much too slow (blenders, ZBuffer). My thought on the subject is
that polygon_3d would produce a list of spans to be rendered, and call a
hook function with this list. The hook (which can be user overridden) would
then eitehr z-buffer them, s-buffer them, c-buffer them, just render them,
or whatever else is the best-sorting-method-of-the-day. Those could of
course be packaged as add-ons. (zbuffer add-on for allegro, for example).
All of those were add-ons at some point.
- save_font(): can people not use the Allegro Fonts addon?
There's a Font add-on? Well, regarding Shawn's post, it should perhaps be
documented more clearly how to save or load fonts.
[snip]
- network: why not use something like libnet?
Because libnet is not being updated :)
Really, its only for completion of Allegro - it does abstracts everything
else needed to make a game, so why not networks?
- dynamic loading of modules: this would work fine on i386 (with
stonewheel), but not on anything else. So at best, we couldn't rely
on it being available.
Yes I know lots of people will disagree with me, but the fact is, if DOS
isn't dead now, it will be by the time Allegro 5/6/7 comes out, when Windows
YQ comes out.
If we drop DOS, we suddenly can have access to all these nice features like
multi-threading, networking, dynamic module loading, and probably a lot more
things that I can't think of right now.
Seriously though, who still uses a pure DOS system today? If you use
Windows, why not use Mingw and make Windows programs? (then port them to
Linux ;)
As to dropping DOS support, I do understand (really I do :-) ), but so
many people use the DJGPP/Allegro this could be a really big mistake.
They can use Allegro 4, which could serve as a migration path (tm) towards
other OSs. Kinda like: "look, it's so easy to code for
Windows/Linux/BeOS/Qnx/Mac/foobar now! Just like it was in DOS!"
However, there is no reason to write something like this in the docs:
LOCK_FUNCTION() and LOCK_VARIABLE() only need to be used if you ever
plan to port your program to DOS. If you don't, then all other
platforms that Allegro supports are reentrant, so this memory locking
isn't needed.
This way, the DOS port doesn't need to get in the way of the other
ports.
But then, the DOS port won't behave like the other ports, and we'll see lots
of those nasty #define tricks to get our games to run one way in DOS and
another (better?) way in other OSs.
--
- Robert J Ohannessian
"Microsoft code is probably O(n^20)" (my CS prof)
http://pages.infinit.net/voidstar/