| Re: [AD] Proposed changes for Allegro 5 (6?) |
[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
Shawn Hargreaves wrote:
Bob writes:
>> - network: why not use something like libnet?
>
> Because libnet is not being updated :)
I think there is a flaw in your logic here :-)
- X amount of people want to have networking code
- Y amouht of people want to spend time writing networking code
- Z amount of people want to spend time working on Allegro
- Networking code exists, but is not being updated
Except in this case, Y = Z :)
Yes I know, putting libnet in Allegro isn't a solution to libnet not being
worked on very much. I was just running out of arguments on why there should
be basic network functionality in Allegro :P
> 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.
Good timing! As it happens, a guy called Martin Slater, who
works with me here at Climax and is currently the lead
programmer on a team porting one of our PS2 titles across
to Gamecube, just came up to talk to me about Allegro about
5 mins before this email arrived. Someone just gave him
a crappy old laptop (386, 4 meg, 40 meg HD), which he is
planning on using as a debug monitor (dump data to it over
the serial link, graph this on a 640x480x256 display).
The reason he came to talk to me about this is that he's
using DOS Allegro for it...
He can still use Allegro 4 :)
AFAIK bug fixes will still be applied to Allegro 4, whether or not Allegro
5/6/7 still supports DOS or not.
There is only so much you can do with a 386 with 4 MB of RAM, and I don't
think any of the new stuff that gets added to Allegro 5 (6?) will be 'vital'.
Yes, this is a minority use, and he could do it fine with
an older version of Allegro. But there still are lots of
people who are doing serious work with crap hardware,
especially in the scientific research community, who
(perhaps surprisingly) are often years behind hobbyist
game coders in terms of computing power.
Ten years behind? Sorry I'm asking, but I'd really like to know.
I've personally
spoken to dozens of people who are doing medical imaging,
data collection, experiments into reaction times, etc,
using Allegro on what struck me as ridiculously obsolete
machines.
It can't be anything less than a 386 with 2 MB though (I don't think DJGPP
even runs on that!) So how would they benefit from the new stuff in Allegro 5/6?
If the DOS port was causing problems, I could see an
argument for dropping it. But, what problems are these?
The port already exists, is very stable, and in fact
is at least as cleaner and elegant code than any of
the other platforms!
That's because of Allegro's DOS-ism :)
Yes I know it's stable and clean and works right most of the time. There's
no argument to remove it from Allegro 4 or stop updating it at all. I'd just
hate to see DOS as being the deadwieght that much be carried by Allegro.
[snip]
You mention things like multithreading, dynamic loading,
etc, as benefits of losing the DOS port. I think it is
a really terrible idea to depend on that sort of feature,
because:
- These things can already be used by platform-specific
drivers, just not as part of the API. I see no need
for them to be used anywhere else (remember Allegro
is supposed to be a low-level lib - don't bloat it
by adding complexity where the simple approach is
perfectly good enough).
That funny, cause those strike me as low-level things. Perhaps it's because
I only started using computers with a 386, but this kind of functionality
seems very 'basic' IMHO.
- These features are all major portability hassles. Using
them in drivers is no problem, but depending on them
will make the lib far harder to port to new platforms.
- They are all features which are lacking from embedded
systems, consoles, stripped-down Linux kernels as
used in many settop boxes, etc. These environments are
all very similar to DOS in terms of features provided
by the OS (ie. basically the OS does nothing :-)
If you make Allegro use any features that make the
DOS port hard to continue, you also pretty much rule
out it ever being run on any of these small platforms.
I beleive that a similar idea was discussed a while back about a GBA port of
Allegro or somesuch. Perhaps it would be better to port an Allegro-like API
and structure, than the full Allegro. I can't imagine porting the keyboard
routines to a console, for example. In that case, the programmer will have
to take some extra care if they want their Allegro code to compile for
console X.
Embedded systems are, to me, a very interesting thing for
Allegro to support (actually far more interesting than
desktop computers, as these days if I was doing a game for
a PC, I'd just use GL or D3D).
See above. Maybe we can define (in text) a mini-Allegro API, which is a set
of really basic routines which should be ported/portable to any number of
embedded platforms/minimal OS.
Incidentally, embedded systems are also the main place
where Allegro has been used commercially, eg. for the
overlay graphics in pinball machines, for half a dozen
different products by Caldera (who funded the initial
work on the Linux port as a direct result of this), and
by several other fairly large companies that I forget
right now).
Really? I wasn't aware of any of this. Interesting to say the least.
Besides, I can't force you or the other Allegro devs to drop/not drop DOS
support. I just thought I'd bring it up for discussion.
--
- Robert J Ohannessian
"Microsoft code is probably O(n^20)" (my CS prof)
http://pages.infinit.net/voidstar/