; Thu, 29 Nov 2001 11:00:14 -0000
Message-ID: <28A7C352840AD511AC9400508BE70AC24FFDB7@FRUITMACHINE>
From: Shawn Hargreaves <[email]>
To: 'Bob' <[email]>, [email]
Subject: RE: [AD] Proposed changes for Allegro 5 (6?)
Date: Thu, 29 Nov 2001 11:00:12 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
boundary="----_=_NextPart_001_01C178C5.04BE5F00"
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
------_=_NextPart_001_01C178C5.04BE5F00
Content-Type: text/plain;
charset="iso-8859-1"
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
>From that, I would conclude that the Y-type people are not
currently sufficient to meet the needs of group X.
Moving code from one place to another is unlikely to change
any of the numbers X, Y, or Z (or if it does, that is just
because more people become aware of the code, in which case
the same effect could be obtained by advertising it better).
The only way that it could be better maintained after a move
is if some of the type-Z people started maintaining it, as
they would then see this as a part of their job of keeping
Allegro up to scratch. But this is hardly fair to these
developers, as it is adding more code to their pile of things
that have to be maintained and documented and ported and
supported. If they wanted to spend time on network stuff,
they could already do that without needing to move the code
into Allegro, so really, I think this solution is just taking
advantage of their dedication to making Allegro good, by
piling on more work to an already huge pile of stuff that
they are taking care of.
IMHO a fairer solution, if there aren't enough people in Y,
would be for a few of the X's to move themselves into
group Y. But moving the code into Allegro has nothing to
do with X or Y, and just shifts the problem onto the Z's,
who I think have more important things to keep themselves
occupied with...
> 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...
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. 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.
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! Why remove something that is useful
to some people, and costs so little maintenance effort?
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).
- 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.
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). It would be very feasible
(actually I think quite easy) to get Allegro running on
PalmOS, and only a matter of time before you could put
it on a mobile phone too! (one of my colleagues already
has a phone that can run a Java Worms game in a JVM:
I reckon 2 years until all of Allegro can fit on there).
Please don't ruin that possibility just because you want
to add a few non-essential features to the Windows and
Linux versions!
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).
--
Shawn
------_=_NextPart_001_01C178C5.04BE5F00
Content-Type: text/html;
charset="iso-8859-1"
RE: [AD] Proposed changes for Allegro 5 (6?)
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
From that, I would conclude that the Y-type people are not
currently sufficient to meet the needs of group X.
Moving code from one place to another is unlikely to change
any of the numbers X, Y, or Z (or if it does, that is just
because more people become aware of the code, in which case
the same effect could be obtained by advertising it better).
The only way that it could be better maintained after a move
is if some of the type-Z people started maintaining it, as
they would then see this as a part of their job of keeping
Allegro up to scratch. But this is hardly fair to these
developers, as it is adding more code to their pile of things
that have to be maintained and documented and ported and
supported. If they wanted to spend time on network stuff,
they could already do that without needing to move the code
into Allegro, so really, I think this solution is just taking
advantage of their dedication to making Allegro good, by
piling on more work to an already huge pile of stuff that
they are taking care of.
IMHO a fairer solution, if there aren't enough people in Y,
would be for a few of the X's to move themselves into
group Y. But moving the code into Allegro has nothing to
do with X or Y, and just shifts the problem onto the Z's,
who I think have more important things to keep themselves
occupied with...
> 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...
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. 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.
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! Why remove something that is useful
to some people, and costs so little maintenance effort?
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).
- 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.
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). It would be very feasible
(actually I think quite easy) to get Allegro running on
PalmOS, and only a matter of time before you could put
it on a mobile phone too! (one of my colleagues already
has a phone that can run a Java Worms game in a JVM:
I reckon 2 years until all of Allegro can fit on there).
Please don't ruin that possibility just because you want
to add a few non-essential features to the Windows and
Linux versions!
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).
--
Shawn
------_=_NextPart_001_01C178C5.04BE5F00--
From - Thu Nov 29 09:25:52 2001
X-UIDL: 17595-968516558
X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Return-Path:
Received: from VL-MS-MR002.sc1.videotron.ca ([10.23.32.72]) by
VL-MS-MS002.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNK6N903.XWL for <[email]>; Thu,
29 Nov 2001 06:01:57 -0500
Received: from canvaslink.com ([216.47.35.50]) by
VL-MS-MR002.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNK6N801.0L7 for <[email]>; Thu,
29 Nov 2001 06:01:56 -0500
Received: from fruitmachine.brighton.climax.co.uk [212.74.3.86] by canvaslink.com with ESMTP
(SMTPD32-6.00) id A6135B46032E; Thu, 29 Nov 2001 06:03:47 -0500
Received: by FRUITMACHINE with Internet Mail Service (5.5.2653.19)
id ; Thu, 29 Nov 2001 11:00:14 -0000
Message-ID: <28A7C352840AD511AC9400508BE70AC24FFDB7@FRUITMACHINE>
From: Shawn Hargreaves <[email]>
To: 'Bob' <[email]>, [email]
Date: Thu, 29 Nov 2001 11:00:12 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
boundary="----_=_NextPart_001_01C178C5.04BE5F00"
Subject: RE: [AD] Proposed changes for Allegro 5 (6?)
Precedence: bulk
Sender: conductors-[email]
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
------_=_NextPart_001_01C178C5.04BE5F00
Content-Type: text/plain;
charset="iso-8859-1"
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
>From that, I would conclude that the Y-type people are not
currently sufficient to meet the needs of group X.
Moving code from one place to another is unlikely to change
any of the numbers X, Y, or Z (or if it does, that is just
because more people become aware of the code, in which case
the same effect could be obtained by advertising it better).
The only way that it could be better maintained after a move
is if some of the type-Z people started maintaining it, as
they would then see this as a part of their job of keeping
Allegro up to scratch. But this is hardly fair to these
developers, as it is adding more code to their pile of things
that have to be maintained and documented and ported and
supported. If they wanted to spend time on network stuff,
they could already do that without needing to move the code
into Allegro, so really, I think this solution is just taking
advantage of their dedication to making Allegro good, by
piling on more work to an already huge pile of stuff that
they are taking care of.
IMHO a fairer solution, if there aren't enough people in Y,
would be for a few of the X's to move themselves into
group Y. But moving the code into Allegro has nothing to
do with X or Y, and just shifts the problem onto the Z's,
who I think have more important things to keep themselves
occupied with...
> 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...
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. 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.
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! Why remove something that is useful
to some people, and costs so little maintenance effort?
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).
- 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.
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). It would be very feasible
(actually I think quite easy) to get Allegro running on
PalmOS, and only a matter of time before you could put
it on a mobile phone too! (one of my colleagues already
has a phone that can run a Java Worms game in a JVM:
I reckon 2 years until all of Allegro can fit on there).
Please don't ruin that possibility just because you want
to add a few non-essential features to the Windows and
Linux versions!
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).
--
Shawn
------_=_NextPart_001_01C178C5.04BE5F00
Content-Type: text/html;
charset="iso-8859-1"
RE: [AD] Proposed changes for Allegro 5 (6?)
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
From that, I would conclude that the Y-type people are not
currently sufficient to meet the needs of group X.
Moving code from one place to another is unlikely to change
any of the numbers X, Y, or Z (or if it does, that is just
because more people become aware of the code, in which case
the same effect could be obtained by advertising it better).
The only way that it could be better maintained after a move
is if some of the type-Z people started maintaining it, as
they would then see this as a part of their job of keeping
Allegro up to scratch. But this is hardly fair to these
developers, as it is adding more code to their pile of things
that have to be maintained and documented and ported and
supported. If they wanted to spend time on network stuff,
they could already do that without needing to move the code
into Allegro, so really, I think this solution is just taking
advantage of their dedication to making Allegro good, by
piling on more work to an already huge pile of stuff that
they are taking care of.
IMHO a fairer solution, if there aren't enough people in Y,
would be for a few of the X's to move themselves into
group Y. But moving the code into Allegro has nothing to
do with X or Y, and just shifts the problem onto the Z's,
who I think have more important things to keep themselves
occupied with...
> 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...
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. 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.
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! Why remove something that is useful
to some people, and costs so little maintenance effort?
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).
- 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.
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). It would be very feasible
(actually I think quite easy) to get Allegro running on
PalmOS, and only a matter of time before you could put
it on a mobile phone too! (one of my colleagues already
has a phone that can run a Java Worms game in a JVM:
I reckon 2 years until all of Allegro can fit on there).
Please don't ruin that possibility just because you want
to add a few non-essential features to the Windows and
Linux versions!
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).
--
Shawn
------_=_NextPart_001_01C178C5.04BE5F00--
From - Thu Nov 29 09:25:54 2001
X-UIDL: 17602-968516558
X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Return-Path:
Received: from VL-MS-MR001.sc1.videotron.ca ([10.23.32.71]) by
VL-MS-MS002.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNK93G00.8L4 for <[email]>; Thu,
29 Nov 2001 06:54:52 -0500
Received: from canvaslink.com ([216.47.35.50]) by
VL-MS-MR001.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNK93F04.3H2 for <[email]>; Thu,
29 Nov 2001 06:54:51 -0500
Received: from smtp2.libero.it [193.70.192.52] by canvaslink.com with ESMTP
(SMTPD32-6.00) id A2855C690356; Thu, 29 Nov 2001 06:56:53 -0500
Received: from lano (151.28.39.195) by smtp2.libero.it (6.0.032)
id 3BEFF161005FCB6F; Thu, 29 Nov 2001 12:53:23 +0100
Date: Thu, 29 Nov 2001 12:48:29 +0100
From: Lo'oRiS il Kabukimono <[email]>
To: Shawn Hargreaves <[email]>
Cc: [email]
Message-Id: <[email]>
In-Reply-To: <28A7C352840AD511AC9400508BE70AC24FFDB7@FRUITMACHINE>
References: <28A7C352840AD511AC9400508BE70AC24FFDB7@FRUITMACHINE>
X-Mailer: Sylpheed version 0.6.5 (GTK+ 1.2.9; i586-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Subject: Re: [AD] Proposed changes for Allegro 5 (6?)
Precedence: bulk
Sender: conductors-[email]
> 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). It would be very feasible
nice.
and moreover think that it will ease very much porting a game
from a console to a pc: if the console game is made using Allegro,
u can simply recompile it and it works on the pc. it is very nice
since often the pc ports of a, for example, psx game add *lots*
of bugs (one relevant example is FF7: the pc version had a little
nicer graphic but often when it had a complex animation to display,
like a big boss, freezed without any possibility of saving the game)
"Chocobos ignore humans who don't look like they'll give them greens"
Final Fantasy 7
_.-:/°^^°\:-._.-:/°^^°\:-._ __. ____
- Lo'oRiS il Kabukimono - / /| /^___ \
Real Name: Lorenzo Petrone / / / / /L_/ /
e-mail: [email] / / / / ___-°/
irc.azzurra.org #lano / /_/__ / /|__-°
digilander.iol.it/lano666 /______/| /__/ /
^°\:-.__.-:/°^°\:-.__.-:/°^ |______|/ |__L/
From - Thu Nov 29 17:17:07 2001
X-UIDL: 17609-968516558
X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Return-Path:
Received: from VL-MS-MR001.sc1.videotron.ca ([10.23.32.71]) by
VL-MS-MS002.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNKIYU01.6SI for <[email]>; Thu,
29 Nov 2001 10:28:06 -0500
Received: from canvaslink.com ([216.47.35.50]) by
VL-MS-MR001.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNKIYT01.8JV for <[email]>; Thu,
29 Nov 2001 10:28:05 -0500
Received: from uria.its.uu.se [130.238.7.14] by canvaslink.com with ESMTP
(SMTPD32-6.00) id A450108E0348; Thu, 29 Nov 2001 10:29:20 -0500
Received: from regulus2.student.uu.se ([130.238.5.5]:49740 "EHLO student.uu.se")
by uria.its.uu.se with ESMTP id ;
Thu, 29 Nov 2001 16:25:41 +0100
Message-ID: <[email]>
Date: Thu, 29 Nov 2001 16:25:28 +0100
From: Sven Sandberg <[email]>
X-Mailer: Mozilla 4.77 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Allegro Developer <[email]>
References: <28A7C352840AD511AC9400508BE70AC24FFDB6@FRUITMACHINE>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: Re: [AD] Proposed changes for Allegro 5 (6?)
Precedence: bulk
Sender: conductors-[email]
Shawn Hargreaves wrote:
> If the address is not a pointer type, this makes it far more
> obvious that it must be accessed in a special way, so people
> are more likely to produce correct and portable code.
But it is not portable to assume that you can store a pointer in a long:
they can even have different sizeof()'s. Can't we do something like:
typedef void *al_video_memory_pointer;
This will not be dereferencable without a cast, and will also have a
more descriptive name.
--
Sven Sandberg [email] home.student.uu.se/svsa1977
From - Thu Nov 29 17:17:08 2001
X-UIDL: 17610-968516558
X-Mozilla-Status: 0013
X-Mozilla-Status2: 00000000
Return-Path:
Received: from VL-MS-MR002.sc1.videotron.ca ([10.23.32.72]) by
VL-MS-MS002.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNKJHV03.JRO for <[email]>; Thu,
29 Nov 2001 10:39:31 -0500
Received: from canvaslink.com ([216.47.35.50]) by
VL-MS-MR002.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNKJHV02.4VU for <[email]>; Thu,
29 Nov 2001 10:39:31 -0500
Received: from uria.its.uu.se [130.238.7.14] by canvaslink.com with ESMTP
(SMTPD32-6.00) id A70311DB0348; Thu, 29 Nov 2001 10:40:51 -0500
Received: from regulus2.student.uu.se ([130.238.5.5]:35698 "EHLO student.uu.se")
by uria.its.uu.se with ESMTP id ;
Thu, 29 Nov 2001 16:37:08 +0100
Message-ID: <[email]>
Date: Thu, 29 Nov 2001 16:36:57 +0100
From: Sven Sandberg <[email]>
X-Mailer: Mozilla 4.77 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Allegro Developer <[email]>
References:
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: Re: [AD] Proposed changes for Allegro 5 (6?)
Precedence: bulk
Sender: conductors-[email]
Stepan Roh wrote:
> But in-source documentation is good thing.
There are some problems with it too:
- Is it possible to make sections be structured another way than the
source files? It would be confusing if there was one section for the
functions in gfx.c and another for the functions in graphics.c, or if
load_bmp(), load_pcx() etc were in different sections.
- Some functions are defined in different files depending on which
platform they are on, so there's no unique natural place to put the
documentation on.
- allegro._tx contains several generic sections that discuss
programming principles (e.g. "Bitmap objects"), or non-api stuff (e.g.
"Makefile targets"), that would not fit in naturally in any source file.
- allegro._tx is not the only file generated by makedoc: there are
totally 8 files mathching allegro/docs/src/*._tx. So we need something
to compile help that does not come from a source file anyway.
--
Sven Sandberg [email] home.student.uu.se/svsa1977
From - Thu Nov 29 17:17:08 2001
X-UIDL: 17611-968516558
X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Return-Path:
Received: from VL-MS-MR002.sc1.videotron.ca ([10.23.32.72]) by
VL-MS-MS002.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNKJOW00.JYU for <[email]>; Thu,
29 Nov 2001 10:43:44 -0500
Received: from canvaslink.com ([216.47.35.50]) by
VL-MS-MR002.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNKJOW02.5US for <[email]>; Thu,
29 Nov 2001 10:43:44 -0500
Received: from relay4.ftech.net [212.32.16.76] by canvaslink.com with ESMTP
(SMTPD32-6.00) id A822120E0348; Thu, 29 Nov 2001 10:45:38 -0500
Received: from ibm9.ftech.net ([212.32.16.79] helo=mailgate)
by relay4.ftech.net with esmtp (Exim 3.22-ftech-p6.1 #9)
id 169TKB-0005te-00
for [email]; Thu, 29 Nov 2001 15:42:07 +0000
Received: from [89.0.0.95] by (MailGate 3.5.165) with ESMTP; Thu, 29 Nov 2001 15:42:23 +0000
Received: by warhol with Internet Mail Service (5.5.2448.0)
id ; Thu, 29 Nov 2001 15:40:30 -0000
Message-ID:
From: Vincent Penquerc'h <[email]>
To: Allegro Developer <[email]>
Date: Thu, 29 Nov 2001 15:40:29 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/alternative;
boundary="----_=_NextPart_001_01C178EC.2CCEB930"
Subject: RE: [AD] Proposed changes for Allegro 5 (6?)
Precedence: bulk
Sender: conductors-[email]
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
------_=_NextPart_001_01C178EC.2CCEB930
Content-Type: text/plain;
charset="windows-1252"
> they can even have different sizeof()'s. Can't we do something like:
>
> typedef void *al_video_memory_pointer;
I support this.
In addition, this makes me think that, eg, in BITMAP, dat and lines are of
different types if I recall well, and both are character types. They also
could do with retyping, as they can point to 8 bit, but also 16, 24, 32 bit
data, so a character type begs for mistakenly being dereferenced. Though it
wouldn't lead to a crash in this case.
--
Vincent Penquerc'h
------_=_NextPart_001_01C178EC.2CCEB930
Content-Type: text/html;
charset="windows-1252"
RE: [AD] Proposed changes for Allegro 5 (6?)
> they can even have different sizeof()'s. Can't we do something like:
>
> typedef void *al_video_memory_pointer;
I support this.
In addition, this makes me think that, eg, in BITMAP, dat and lines are of
different types if I recall well, and both are character types. They also
could do with retyping, as they can point to 8 bit, but also 16, 24, 32 bit
data, so a character type begs for mistakenly being dereferenced. Though it
wouldn't lead to a crash in this case.
--
Vincent Penquerc'h
------_=_NextPart_001_01C178EC.2CCEB930--
From - Thu Nov 29 17:17:08 2001
X-UIDL: 17612-968516558
X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Return-Path:
Received: from VL-MS-MR002.sc1.videotron.ca ([10.23.32.72]) by
VL-MS-MS002.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNKL1I02.G3R for <[email]>; Thu,
29 Nov 2001 11:12:54 -0500
Received: from canvaslink.com ([216.47.35.50]) by
VL-MS-MR002.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNKL1H00.QYQ for <[email]>; Thu,
29 Nov 2001 11:12:53 -0500
Received: from alfa.srnet.cz [62.24.72.242] by canvaslink.com with ESMTP
(SMTPD32-6.00) id AECC16A403A8; Thu, 29 Nov 2001 11:14:04 -0500
Received: from localhost (stepan@localhost)
by alfa.srnet.cz (8.10.2/8.10.2) with ESMTP id fATGAZc02556
for <[email]>; Thu, 29 Nov 2001 17:10:35 +0100
Date: Thu, 29 Nov 2001 17:10:35 +0100 (CET)
From: Stepan Roh <[email]>
X-Sender: <[email]>
To: Allegro Developers List <[email]>
In-Reply-To: <[email]>
Message-ID:
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: Re: [AD] Proposed changes for Allegro 5 (6?)
Precedence: bulk
Sender: conductors-[email]
On Thu, 29 Nov 2001, Sven Sandberg wrote:
> Stepan Roh wrote:
> > But in-source documentation is good thing.
I was talking as Java programmer where packages and interfaces solve most
of your problems.
> There are some problems with it too:
> - Is it possible to make sections be structured another way than the
> source files? It would be confusing if there was one section for the
> functions in gfx.c and another for the functions in graphics.c, or if
> load_bmp(), load_pcx() etc were in different sections.
> - Some functions are defined in different files depending on which
> platform they are on, so there's no unique natural place to put the
> documentation on.
> - allegro._tx contains several generic sections that discuss
> programming principles (e.g. "Bitmap objects"), or non-api stuff (e.g.
> "Makefile targets"), that would not fit in naturally in any source file.
> - allegro._tx is not the only file generated by makedoc: there are
> totally 8 files mathching allegro/docs/src/*._tx. So we need something
> to compile help that does not come from a source file anyway.
In-source documentation could be add-on only. Maybe hack makedoc to be
able to parse sources and found function descriptions? Like :
@source_parse src/dir/source.c:function_name
But that is too complicated to do.
Have a nice day.
Stepan Roh
From - Thu Nov 29 17:17:09 2001
X-UIDL: 17614-968516558
X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Return-Path:
Received: from VL-MS-MR003.sc1.videotron.ca ([10.23.32.73]) by
VL-MS-MS002.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNKOY202.Z76 for <[email]>; Thu,
29 Nov 2001 12:37:14 -0500
Received: from canvaslink.com ([216.47.35.50]) by
VL-MS-MR003.sc1.videotron.ca (Netscape Messaging Server 4.15
MR003 Jul 24 2001 16:23:26) with ESMTP id GNKOY101.BQ7 for
<[email]>; Thu, 29 Nov 2001 12:37:13 -0500
Received: from finch-post-12.mail.demon.net [194.217.242.41] by canvaslink.com with ESMTP
(SMTPD32-6.00) id A28F148D0348; Thu, 29 Nov 2001 12:38:23 -0500
Received: from lwithers.demon.co.uk ([194.222.80.1])
by finch-post-12.mail.demon.net with esmtp (Exim 2.12 #1)
id 169V5F-0002Lh-0C
for [email]; Thu, 29 Nov 2001 17:34:50 +0000
Message-ID:
Date: Thu, 29 Nov 2001 16:50:44 +0000
To: [email]
From: Laurence Withers <[email]>
References: <[email]> <[email]>
<[email]> <[email]>
<[email]>
In-Reply-To: <[email]>
MIME-Version: 1.0
Content-Type: multipart/signed;boundary="=_Turnpike_sRQW2FAZdmB8U+qZ=";
protocol="application/pgp-signature";micalg=pgp-sha1
X-Mailer: Turnpike Integrated Version 5.01 S
Subject: Re: [AD] Proposed changes for Allegro 5 (6?)
Precedence: bulk
Sender: conductors-[email]
This is a PGP signed message sent according to RFC2015 [PGP/MIME]
--=_Turnpike_sRQW2FAZdmB8U+qZ=
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
In reply to Javier Gonz=E1lez <[email]>:
>Totally agree, btw, methinks allegro 5 should include code to play
>cd audiotracks
>(sorry, there are just so many things i wonder when i think of a new alleg=
ro
>version =3D)
Use libcda (see Peter's website).
Bye for now,
--=20
Laurence Withers, [email]
http://www.lwithers.demon.co.uk/
--=_Turnpike_sRQW2FAZdmB8U+qZ=
Content-Type: application/pgp-signature
Content-Disposition: attachment; filename=signature.asc
-----BEGIN PGP SIGNATURE-----
Version: PGPsdk version 1.7.1
iQA/AwUBPAZnZGbrT6QxxsGNEQJBQACfSI0azDH2ppXlUC1ofzDWZ31LmAEAoLOq
EkkKj1tpJbu0zfBpmgsxzRAP
=CLu7
-----END PGP SIGNATURE-----
--=_Turnpike_sRQW2FAZdmB8U+qZ=--
From - Thu Nov 29 17:17:10 2001
X-UIDL: 17617-968516558
X-Mozilla-Status: 0013
X-Mozilla-Status2: 00000000
Return-Path:
Received: from VL-MS-MR003.sc1.videotron.ca ([10.23.32.73]) by
VL-MS-MS002.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNKT0M03.J1O for <[email]>; Thu,
29 Nov 2001 14:05:10 -0500
Received: from canvaslink.com ([216.47.35.50]) by
VL-MS-MR003.sc1.videotron.ca (Netscape Messaging Server 4.15
MR003 Jul 24 2001 16:23:26) with ESMTP id GNKT0M01.N2L for
<[email]>; Thu, 29 Nov 2001 14:05:10 -0500
Received: from pedos.es [212.170.193.45] by canvaslink.com with ESMTP
(SMTPD32-6.00) id A70A6199032E; Thu, 29 Nov 2001 14:05:46 -0500
Received: from gregorio by pedos.es with local (Exim 3.12 #5 (Mega-Debian))
id 169R0g-0000KM-00
for <[email]>; Thu, 29 Nov 2001 14:13:50 +0100
Date: Thu, 29 Nov 2001 14:13:50 +0100
From: Grzegorz Adam Hankiewicz <[email]>
To: [email]
Message-ID: <[email]>
Mail-Followup-To: [email]
References: <[email]> <[email]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <[email]>; from [email] on Wed, Nov 28, 2001 at 06:33:04PM -0500
Subject: Re: [AD] Proposed changes for Allegro 5 (6?)
Precedence: bulk
Sender: conductors-[email]
On Wed, Nov 28, 2001 at 06:33:04PM -0500, Bob wrote:
> > - network: why not use something like libnet?
>
> Because libnet is not being updated :)
Surely George can say something about that :)
> Really, its only for completion of Allegro - it does abstracts everything
> else needed to make a game, so why not networks?
Because network is something which really really really is not needed in
lots of games, just take a look at allegro.cc. I understand however that
today the trend is to move towards multiplayer(only) games, but since
networking is really hard to do properly as well, I think it deserves
it's own library with proper documentation, examples, etc.
Also, if you wanted to only use networking in the future, you would be
'forced' to include Allegro as well, no matter how modular the interface
would be, and if it's modular, why melt both libs?
--
Grzegorz Adam Hankiewicz [email] http://gradha.infierno.org/
From - Thu Nov 29 17:17:11 2001
X-UIDL: 17619-968516558
X-Mozilla-Status: 0013
X-Mozilla-Status2: 00000000
Return-Path:
Received: from VL-MS-MR004.sc1.videotron.ca ([10.23.32.74]) by
VL-MS-MS002.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNKUKQ05.58K for <[email]>; Thu,
29 Nov 2001 14:38:50 -0500
Received: from canvaslink.com ([216.47.35.50]) by
VL-MS-MR004.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNKUKQ02.GUW for <[email]>; Thu,
29 Nov 2001 14:38:50 -0500
Received: from pedos.es [212.170.193.45] by canvaslink.com with ESMTP
(SMTPD32-6.00) id A70E619A032E; Thu, 29 Nov 2001 14:05:50 -0500
Received: from gregorio by pedos.es with local (Exim 3.12 #5 (Mega-Debian))
id 169RhR-0000L5-00
for <[email]>; Thu, 29 Nov 2001 14:58:01 +0100
Date: Thu, 29 Nov 2001 14:58:00 +0100
From: Grzegorz Adam Hankiewicz <[email]>
To: Allegro Conductors <[email]>
Message-ID: <[email]>
Mail-Followup-To: Allegro Conductors <[email]>
References: <[email]> <[email]> <[email]>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
User-Agent: Mutt/1.2.5i
In-Reply-To: <[email]>; from [email] on Thu, Nov 29, 2001 at 01:15:30AM +0100
Subject: Re: [AD] Proposed changes for Allegro 5 (6?)
Precedence: bulk
Sender: conductors-[email]
On Thu, Nov 29, 2001 at 01:15:30AM +0100, Javier González wrote:
> > 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 ;)
Dropping support for a specific OS should not be taken as a democratic vote, where
the majority wins, or we would have only a windows version of Allegro due to the
monopoly of Mr Gates.
> I must agree with this... either if we want or not DOS will be totally dead
> in say from 6 months to 1 year max
People have been saying that since windows 95. Why don't we do the
following: instead of trying to foresee the future, let's agree that
DOS will be dropped whenever djgpp is not longer maintained. We can talk
again about this subject whenever that happens.
> Btw, about the name, packfiles... could we name it something like
> AllegroFiles or AllegroBuffers?...
Allegro should not fall to the devil side (ahack explains this).
--
Grzegorz Adam Hankiewicz [email] http://gradha.infierno.org/
From - Thu Nov 29 17:51:31 2001
X-UIDL: 17624-968516558
X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Return-Path:
Received: from VL-MS-MR004.sc1.videotron.ca ([10.23.32.74]) by
VL-MS-MS002.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNL3HX02.7B6 for <[email]>; Thu,
29 Nov 2001 17:51:33 -0500
Received: from canvaslink.com ([216.47.35.50]) by
VL-MS-MR004.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNL3HW02.T64 for <[email]>; Thu,
29 Nov 2001 17:51:32 -0500
Received: from VL-MS-MR001.sc1.videotron.ca [24.201.245.36] by canvaslink.com with ESMTP
(SMTPD32-6.00) id AB412F4B031C; Thu, 29 Nov 2001 17:48:33 -0500
Received: from videotron.ca ([24.202.201.127]) by
VL-MS-MR001.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNL37404.I5N for <[email]>; Thu,
29 Nov 2001 17:45:04 -0500
Message-ID: <[email]>
Date: Thu, 29 Nov 2001 17:45:01 -0500
From: Bob <[email]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.6) Gecko/20011120
X-Accept-Language: en-us
MIME-Version: 1.0
To: [email]
References: <[email]> <[email]> <[email]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [AD] Proposed changes for Allegro 5 (6?)
Precedence: bulk
Sender: conductors-[email]
Grzegorz Adam Hankiewicz wrote:
[snip]
>>Really, its only for completion of Allegro - it does abstracts everything
>>else needed to make a game, so why not networks?
>>
>
> Because network is something which really really really is not needed in
> lots of games, just take a look at allegro.cc. I understand however that
> today the trend is to move towards multiplayer(only) games, but since
> networking is really hard to do properly as well, I think it deserves
> it's own library with proper documentation, examples, etc.
Perhaps Allegro can only have basic operations, like open communication
port, send bytes, receive bytes, close port. Anything more fancy can be
implemented in add-ons.
--
- Robert J Ohannessian
"Microsoft code is probably O(n^20)" (my CS prof)
http://pages.infinit.net/voidstar/
From - Thu Nov 29 17:57:18 2001
X-UIDL: 17625-968516558
X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Return-Path:
Received: from VL-MS-MR001.sc1.videotron.ca ([10.23.32.71]) by
VL-MS-MS002.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNL3MP02.HP7 for <[email]>; Thu,
29 Nov 2001 17:54:25 -0500
Received: from canvaslink.com ([216.47.35.50]) by
VL-MS-MR001.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNL3MO02.ZDC for <[email]>; Thu,
29 Nov 2001 17:54:24 -0500
Received: from VL-MS-MR002.sc1.videotron.ca [24.201.245.36] by canvaslink.com with ESMTP
(SMTPD32-6.00) id AC1C2F79031C; Thu, 29 Nov 2001 17:52:12 -0500
Received: from videotron.ca ([24.202.201.127]) by
VL-MS-MR002.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNL3D701.KLN for <[email]>; Thu,
29 Nov 2001 17:48:43 -0500
Message-ID: <[email]>
Date: Thu, 29 Nov 2001 17:48:40 -0500
From: Bob <[email]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.6) Gecko/20011120
X-Accept-Language: en-us
MIME-Version: 1.0
To: [email]
References: <[email]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [AD] Proposed changes for Allegro 5 (6?)
Precedence: bulk
Sender: conductors-[email]
Sven Sandberg wrote:
> Stepan Roh wrote:
>
>>But in-source documentation is good thing.
>>
>
> There are some problems with it too:
> - Is it possible to make sections be structured another way than the
> source files?
Yes. Use \insection (not portable to JavaDoc).
> - Some functions are defined in different files depending on which
> platform they are on, so there's no unique natural place to put the
> documentation on.
You can document it in some include file. As long as there's a prototype to
it, then Doxygen will find it. Or even better, have al_doxygen.h file, which
has all the docs to those functions, but only gets included #ifdef DOXYGEN
(defined by Doxygen parser).
> - allegro._tx contains several generic sections that discuss
> programming principles (e.g. "Bitmap objects"), or non-api stuff (e.g.
> "Makefile targets"), that would not fit in naturally in any source file.
You can include other files. For example, AllegroGL includes 'mainfile.foo'
(or something like that), which documents installation procedure and some
other basic stuff. The .txt files can be generated from there, or inversely,
this file can be generated by makedoc.
> - allegro._tx is not the only file generated by makedoc: there are
> totally 8 files mathching allegro/docs/src/*._tx. So we need something
> to compile help that does not come from a source file anyway.
See above.
--
- Robert J Ohannessian
"Microsoft code is probably O(n^20)" (my CS prof)
http://pages.infinit.net/voidstar/
From - Thu Nov 29 17:57:18 2001
X-UIDL: 17626-968516558
X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Return-Path:
Received: from VL-MS-MR001.sc1.videotron.ca ([10.23.32.71]) by
VL-MS-MS002.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNL3OI05.CSR for <[email]>; Thu,
29 Nov 2001 17:55:30 -0500
Received: from canvaslink.com ([216.47.35.50]) by
VL-MS-MR001.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNL3OI00.09G for <[email]>; Thu,
29 Nov 2001 17:55:30 -0500
Received: from VL-MS-MR004.sc1.videotron.ca [24.201.245.36] by canvaslink.com with ESMTP
(SMTPD32-6.00) id AADA2F39031C; Thu, 29 Nov 2001 17:46:50 -0500
Received: from videotron.ca ([24.202.201.127]) by
VL-MS-MR004.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNL34A01.M5P for <[email]>; Thu,
29 Nov 2001 17:43:22 -0500
Message-ID: <[email]>
Date: Thu, 29 Nov 2001 17:43:16 -0500
From: Bob <[email]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.6) Gecko/20011120
X-Accept-Language: en-us
MIME-Version: 1.0
To: [email]
References: <[email]> <[email]> <[email]> <[email]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [AD] Proposed changes for Allegro 5 (6?)
Precedence: bulk
Sender: conductors-[email]
Grzegorz Adam Hankiewicz wrote:
> On Thu, Nov 29, 2001 at 01:15:30AM +0100, Javier González wrote:
>
>>>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 ;)
>>>
>
> Dropping support for a specific OS should not be taken as a democratic vote, where
> the majority wins, or we would have only a windows version of Allegro due to the
> monopoly of Mr Gates.
And I agree. However, I'd hate to see DOS being the large boulder attached
to Allegro. If all the neat stuff can be done from DOS, then you have my
vote to keep it. Otherwise, it can stay with Allegro 4.
>>I must agree with this... either if we want or not DOS will be totally dead
>>in say from 6 months to 1 year max
>>
>
> People have been saying that since windows 95.
Yes, and with win2k/xp, it's becoming even more of a pain to run DOS
programs. I'm keeping my win95 partition alive soulely for FenixBlade :)
> Why don't we do the
> following: instead of trying to foresee the future, let's agree that
> DOS will be dropped whenever djgpp is not longer maintained. We can talk
> again about this subject whenever that happens.
If we do'nt drop DOS, then, if ever some feature pops up that Allegro cannot
(easily) emulate in DOS, could we have a non-portable-to-DOS program? That
is, we use feature X of modern operating system Y, which can't be done in
DOS without writting our own OS, then can we still include it in Allegro,
but make programs built on it not portable to DOS?
--
- Robert J Ohannessian
"Microsoft code is probably O(n^20)" (my CS prof)
http://pages.infinit.net/voidstar/
From - Thu Nov 29 18:02:18 2001
X-UIDL: 17627-968516558
X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Return-Path:
Received: from VL-MS-MR001.sc1.videotron.ca ([10.23.32.71]) by
VL-MS-MS002.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNL3Z104.5JB for <[email]>; Thu,
29 Nov 2001 18:01:49 -0500
Received: from canvaslink.com ([216.47.35.50]) by
VL-MS-MR001.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNL3Z000.T93 for <[email]>; Thu,
29 Nov 2001 18:01:48 -0500
Received: from VL-MS-MR001.sc1.videotron.ca [24.201.245.36] by canvaslink.com with ESMTP
(SMTPD32-6.00) id ADE42E2C03EE; Thu, 29 Nov 2001 17:59:48 -0500
Received: from videotron.ca ([24.202.201.127]) by
VL-MS-MR001.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNL3PV02.0BO for <[email]>; Thu,
29 Nov 2001 17:56:19 -0500
Message-ID: <[email]>
Date: Thu, 29 Nov 2001 17:56:16 -0500
From: Bob <[email]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.6) Gecko/20011120
X-Accept-Language: en-us
MIME-Version: 1.0
To: [email]
References: <[email]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [AD] Proposed changes for Allegro 5 (6?)
Precedence: bulk
Sender: conductors-[email]
Doug Eleveld wrote:
>>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.
>>
>
> Just a thought that if you combine all these load* functions into one, that code to read in all the possible types gets included in your executable, even if it can never been used. A good example of this is jpeg reading. Jpeg decoding is quite a bit of code and including it in load_bitmap will make load_bitmap a very big function.
>
> Please still give access to the load* functions, then the user can decide whether they want the bloat or not. Forcing them to use a load_bitmap function does not give them any choice but to include code in their executable that cannot be run.
>
> I think that this is actually a hard problem to make very transparent to the user. The only thing I see working well is some kind of registering function or macros. The users have to explicitly choose what decoding functions they want in the executable, but at least they are not forced to include useless code.
>
> Allegro executables are big enough. Lets try not to make them any bigger.
Firstly, if you already use load_bitmap(), you won't notice any change in
your executable size - all the bitmap loaders get included anyway. Secondly,
we could make the option of you deciding which of the default format to
include, kind like selecting which of the video drivers you want to be
compiled in.
Allegro also doesn't nativaly support jpeg. If you were to use a jpeg add-on
(let's say), then the add-on can register its format with load_bitmap so
that calls to load_bitmap can also load *.jpg on top of every other format.
--
- Robert J Ohannessian
"Microsoft code is probably O(n^20)" (my CS prof)
http://pages.infinit.net/voidstar/
From - Thu Nov 29 18:02:18 2001
X-UIDL: 17628-968516558
X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Return-Path:
Received: from VL-MS-MR002.sc1.videotron.ca ([10.23.32.72]) by
VL-MS-MS002.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNL3ZE03.LFX for <[email]>; Thu,
29 Nov 2001 18:02:02 -0500
Received: from canvaslink.com ([216.47.35.50]) by
VL-MS-MR002.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNL3ZE00.7NE for <[email]>; Thu,
29 Nov 2001 18:02:02 -0500
Received: from oxmail.ox.ac.uk [163.1.2.33] by canvaslink.com with ESMTP
(SMTPD32-6.00) id ADF12E2D03EE; Thu, 29 Nov 2001 18:00:01 -0500
Received: from athens.robots.ox.ac.uk ([163.1.8.248])
by oxmail.ox.ac.uk with esmtp (Exim 3.12 #1)
id 169a6a-0005Mw-04
for [email]; Thu, 29 Nov 2001 22:56:32 +0000
Received: from arragon.robots.ox.ac.uk (arragon [163.1.6.216])
by athens.robots.ox.ac.uk (8.8.8+Sun/8.8.8) with ESMTP id WAA01691
for <[email]>; Thu, 29 Nov 2001 22:56:32 GMT
Received: by arragon.robots.ox.ac.uk
id WAA03543; Thu, 29 Nov 2001 22:56:32 GMT
Date: Thu, 29 Nov 2001 22:56:32 +0000
From: Neil Townsend <[email]>
To: [email]
Message-ID: <[email]>
Mail-Followup-To: Neil Townsend , [email]
References: <[email]> <[email]> <[email]> <[email]> <[email]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <[email]>; from [email] on Thu, Nov 29, 2001 at 05:43:16PM -0500
Subject: Re: [AD] Proposed changes for Allegro 5 (6?)
Precedence: bulk
Sender: conductors-[email]
>>>>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 someone who does use a pure DOS system I think I'd better put
my hand up and explain why.
Whilst DOS may be old, cranky and messy it is also very predictable
and offers you complete control of the CPU. I suspect that there are
many DOS based systems out there for which a transition to windows
would be a great waste of time.
>From my point of view, removing DOS from allegro would be a disaster,
I suspect that I'm not the only one who thinks so.
Neil
From - Thu Nov 29 20:19:20 2001
X-UIDL: 17629-968516558
X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Return-Path:
Received: from VL-MS-MR003.sc1.videotron.ca ([10.23.32.73]) by
VL-MS-MS002.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNL50305.GYK for <[email]>; Thu,
29 Nov 2001 18:24:03 -0500
Received: from canvaslink.com ([216.47.35.50]) by
VL-MS-MR003.sc1.videotron.ca (Netscape Messaging Server 4.15
MR003 Jul 24 2001 16:23:26) with ESMTP id GNL50203.2E5 for
<[email]>; Thu, 29 Nov 2001 18:24:02 -0500
Received: from VL-MS-MR003.sc1.videotron.ca [24.201.245.36] by canvaslink.com with ESMTP
(SMTPD32-6.00) id A2EDEF2032A; Thu, 29 Nov 2001 18:21:17 -0500
Received: from videotron.ca ([24.202.201.127]) by
VL-MS-MR003.sc1.videotron.ca (Netscape Messaging Server 4.15
MR003 Jul 24 2001 16:23:26) with ESMTP id GNL4NZ02.VM7 for
<[email]>; Thu, 29 Nov 2001 18:16:47 -0500
Message-ID: <[email]>
Date: Thu, 29 Nov 2001 18:16:44 -0500
From: Bob <[email]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.6) Gecko/20011120
X-Accept-Language: en-us
MIME-Version: 1.0
To: [email]
References: <28A7C352840AD511AC9400508BE70AC24FFDB7@FRUITMACHINE>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [AD] Proposed changes for Allegro 5 (6?)
Precedence: bulk
Sender: conductors-[email]
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/
From - Thu Nov 29 20:19:21 2001
X-UIDL: 17631-968516558
X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Return-Path:
Received: from VL-MS-MR002.sc1.videotron.ca ([10.23.32.72]) by
VL-MS-MS002.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNL5PP00.ELQ for <[email]>; Thu,
29 Nov 2001 18:39:25 -0500
Received: from canvaslink.com ([216.47.35.50]) by
VL-MS-MR002.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNL5PP01.9IL for <[email]>; Thu,
29 Nov 2001 18:39:25 -0500
Received: from VL-MS-MR001.sc1.videotron.ca [24.201.245.36] by canvaslink.com with ESMTP
(SMTPD32-6.00) id AE9AD30032A; Thu, 29 Nov 2001 18:02:50 -0500
Received: from videotron.ca ([24.202.201.127]) by
VL-MS-MR001.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNL3UX00.RBG for <[email]>; Thu,
29 Nov 2001 17:59:21 -0500
Message-ID: <[email]>
Date: Thu, 29 Nov 2001 17:59:18 -0500
From: Bob <[email]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.6) Gecko/20011120
X-Accept-Language: en-us
MIME-Version: 1.0
To: [email]
References: <28A7C352840AD511AC9400508BE70AC24FFDB6@FRUITMACHINE>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [AD] Proposed changes for Allegro 5 (6?)
Precedence: bulk
Sender: conductors-[email]
Shawn Hargreaves wrote:
> Bob writes:
> >>> - `bmp_read8()' & co currently use longs instead of pointers.
> >>
> >> The thinking behind using longs is that this makes the pointers
> >> opaque, ie. can't be dereferenced directly by the user
> >
> > Those functions are of the fairly advanced level, so I don't
> > see users who haven't understood pointers use them :)
>
> The problem is not so much programmer ignorance, as portability.
[snip - explication]
Ah, I see now what you meant.
I like the 'typedef void* bitmap_ptr' idea though, and it seems to 'fix'
what was wrong with having a regular point. If this ok with you?
Of course, users can still cast back to chart/short/int, just like they can
cast the int to a pointer and read/write from there.
Examples of how to make proper use of the functions should be in the
documentation, instead of the example programs :)
--
- Robert J Ohannessian
"Microsoft code is probably O(n^20)" (my CS prof)
http://pages.infinit.net/voidstar/
From - Thu Nov 29 20:19:22 2001
X-UIDL: 17632-968516558
X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Return-Path:
Received: from VL-MS-MR004.sc1.videotron.ca ([10.23.32.74]) by
VL-MS-MS002.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNL6DN04.4OP for <[email]>; Thu,
29 Nov 2001 18:53:47 -0500
Received: from canvaslink.com ([216.47.35.50]) by
VL-MS-MR004.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNL6DM04.66D for <[email]>; Thu,
29 Nov 2001 18:53:46 -0500
Received: from pedos.es [193.152.161.130] by canvaslink.com with ESMTP
(SMTPD32-6.00) id AA243E8602BE; Thu, 29 Nov 2001 18:52:04 -0500
Received: from gregorio by pedos.es with local (Exim 3.12 #5 (Mega-Debian))
id 169aty-0000VO-00
for <[email]>; Fri, 30 Nov 2001 00:47:34 +0100
Date: Fri, 30 Nov 2001 00:47:34 +0100
From: Grzegorz Adam Hankiewicz <[email]>
To: [email]
Message-ID: <[email]>
Mail-Followup-To: [email]
References: <[email]> <[email]> <[email]> <[email]> <[email]> <[email]> <[email]> <[email]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <[email]>; from [email] on Thu, Nov 29, 2001 at 05:43:16PM -0500
Subject: Re: [AD] Proposed changes for Allegro 5 (6?)
Precedence: bulk
Sender: conductors-[email]
On Thu, Nov 29, 2001 at 05:43:16PM -0500, Bob wrote:
> And I agree. However, I'd hate to see DOS being the large boulder attached
> to Allegro. If all the neat stuff can be done from DOS, then you have my
> vote to keep it. Otherwise, it can stay with Allegro 4.
Always take a look from the other side: would you drop hardware scrolling
or high precision timing just because Windows can't do "the neat stuff"?
> If we do'nt drop DOS, then, if ever some feature pops up that Allegro cannot
> (easily) emulate in DOS, could we have a non-portable-to-DOS program?
With the above you already have nonportable programs to non-DOS systems...
Anyway, what I was meaning is that most of the proposed things didn't
look to me imposible to do for DOS, except for the 3d acceleration stuff.
> > Because network is something which really really really is not needed...
>
> Perhaps Allegro can only have basic operations, like open communication
> port, send bytes, receive bytes, close port. Anything more fancy can be
> implemented in add-ons.
That would end up being like the basic 3d allegro versus
allegrogl. Packfile routines are cool, but most users go directly for
high-level datafiles.
--
Grzegorz Adam Hankiewicz [email] http://gradha.infierno.org/
From - Thu Nov 29 20:19:23 2001
X-UIDL: 17635-968516558
X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Return-Path:
Received: from VL-MS-MR003.sc1.videotron.ca ([10.23.32.73]) by
VL-MS-MS002.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNL8PT05.5MK for <[email]>; Thu,
29 Nov 2001 19:44:17 -0500
Received: from canvaslink.com ([216.47.35.50]) by
VL-MS-MR003.sc1.videotron.ca (Netscape Messaging Server 4.15
MR003 Jul 24 2001 16:23:26) with ESMTP id GNL8PS02.TT3 for
<[email]>; Thu, 29 Nov 2001 19:44:16 -0500
Received: from mbox.wins.uva.nl [146.50.16.20] by canvaslink.com with ESMTP
(SMTPD32-6.00) id ACBE806035A; Thu, 29 Nov 2001 19:03:10 -0500
Received: from stol-117-137.uva.studentennet.nl [145.98.117.137]
by mbox.wins.uva.nl with SMTP (sendmail 8.10.2/config 11.20).
id fATNwT320744; Fri, 30 Nov 2001 00:58:30 +0100 (MET)
X-Organisation: Faculty of Science, University of Amsterdam, The Netherlands
X-URL: http://www.science.uva.nl/
Date: Fri, 30 Nov 2001 00:22:38 +0100
From: Evert Glebbeek <[email]>
To: Allegro Developers list <[email]>
Message-Id: <[email]>
In-Reply-To: <[email]>
References: <[email]>
<[email]>
<[email]>
<[email]>
<[email]>
<[email]>
Organization: University of Amsterdam
X-Mailer: Sylpheed version 0.6.5 (GTK+ 1.2.10; i686-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Subject: Re: [AD] Proposed changes for Allegro 5 (6?)
Precedence: bulk
Sender: conductors-[email]
On Thu, 29 Nov 2001 22:56:32 +0000 Neil Townsend <[email]> wrote:
>>>>>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 someone who does use a pure DOS system I think I'd better put
>my hand up and explain why.
>
>Whilst DOS may be old, cranky and messy it is also very predictable
>and offers you complete control of the CPU. I suspect that there are
>many DOS based systems out there for which a transition to windows
>would be a great waste of time.
>
>From my point of view, removing DOS from allegro would be a disaster,
>I suspect that I'm not the only one who thinks so.
I sometimes use DOS for a smilar reason: it's fast.
I once ran a series of Monte-Carlo simulations for something or other, and under
windows, the DJGPP version ran about 10% slower than under pure DOS, and with
MinGW it was even slower.
While I doubt games require the processor power that program did, Allegro is
also used for other things besides game programming.
From - Thu Nov 29 22:44:27 2001
X-UIDL: 17642-968516558
X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Return-Path:
Received: from VL-MS-MR002.sc1.videotron.ca ([10.23.32.72]) by
VL-MS-MS002.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNLEPB03.H39 for <[email]>; Thu,
29 Nov 2001 21:53:35 -0500
Received: from canvaslink.com ([216.47.35.50]) by
VL-MS-MR002.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNLEPA04.RUJ for <[email]>; Thu,
29 Nov 2001 21:53:34 -0500
Received: from pd4mo2so.prod.shaw.ca [24.71.223.10] by canvaslink.com with ESMTP
(SMTPD32-6.00) id A5416219032E; Thu, 29 Nov 2001 21:56:01 -0500
Received: from pd5mr1so.prod.shaw.ca
(pd5mr1so-qfe3.prod.shaw.ca [10.0.141.232]) by l-daemon
(iPlanet Messaging Server 5.0 Patch 2 (built Dec 14 2000))
with ESMTP id <0GNL00MD5ELWQX@l-daemon> for [email]; Thu,
29 Nov 2001 19:51:32 -0700 (MST)
Received: from pn2ml5so (pn2ml5so-qfe0.prod.shaw.ca [10.0.121.149])
by l-daemon (iPlanet Messaging Server 5.1 (built May 7 2001))
with ESMTP id <0GNL006OPELW0K@l-daemon> for [email]; Thu,
29 Nov 2001 19:51:32 -0700 (MST)
Received: from there ([24.65.100.169])
by l-daemon (iPlanet Messaging Server 5.0 Patch 2 (built Dec 14 2000))
with SMTP id <0GNL00HP7ELW6T@l-daemon> for [email]; Thu,
29 Nov 2001 19:51:32 -0700 (MST)
Date: Thu, 29 Nov 2001 19:51:26 -0700
From: Thomas Fjellstrom <[email]>
In-reply-to: <28A7C352840AD511AC9400508BE70AC24FFDB7@FRUITMACHINE>
To: [email]
Reply-to: [email]
Message-id: <0GNL00HP8ELW6T@l-daemon>
MIME-version: 1.0
X-Mailer: KMail [version 1.3.2]
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT
References: <28A7C352840AD511AC9400508BE70AC24FFDB7@FRUITMACHINE>
Subject: Re: [AD] Proposed changes for Allegro 5 (6?)
Precedence: bulk
Sender: conductors-[email]
On November 29, 2001 04:00 am, Shawn Hargreaves wrote:
[snip]
First I have to say I agree totally with Shawn.
> It would be very feasible
> (actually I think quite easy) to get Allegro running on
> PalmOS
Second, I was playing with Palm a while ago and this would be a seriously fun
project, Its too bad that all I have is an old US Robotics Palm Pilot
Personal. I doubt it has enough memory for the lib alone.
So, if anyone gets the hint ;) Id be more than willing to try and port
allegro to PalmOS durring my month off. (starting Dec. 7)
[snip]
--
Thomas Fjellstrom
[email]
http://strangesoft.net
From - Thu Nov 29 22:44:27 2001
X-UIDL: 17643-968516558
X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Return-Path: <[email]>
Received: from VL-MS-MR003.sc1.videotron.ca ([10.23.32.73]) by
VL-MS-MS002.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNLFUS05.20N for <[email]>; Thu,
29 Nov 2001 22:18:29 -0500
Received: from mail19.bigmailbox.com ([209.132.220.50]) by
VL-MS-MR003.sc1.videotron.ca (Netscape Messaging Server 4.15
MR003 Jul 24 2001 16:23:26) with ESMTP id GNLFUR02.6UU for
<[email]>; Thu, 29 Nov 2001 22:18:27 -0500
Received: (from www@localhost)
by mail19.bigmailbox.com (8.10.0/8.10.0) id fAU3IP530219;
Thu, 29 Nov 2001 19:18:25 -0800
Date: Thu, 29 Nov 2001 19:18:25 -0800
Message-Id: <[email]>
Content-Type: text/plain
Content-Disposition: inline
Content-Transfer-Encoding: binary
X-Mailer: MIME-tools 4.104 (Entity 4.116)
Mime-Version: 1.0
X-Originating-Ip: [213.51.194.171]
From: "Doug Eleveld" <[email]>
To: [email]
Cc: [email]
Subject: RE: Re: [AD] Proposed changes for Allegro 5 (6?)
>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.
Just my 2 cents in the discussion. If Allegro drops DOS, I will drop Allegro. I use it for some model fitting and optimization programs and I still prefer to work in DOS. I also use it for some controller software that must run on old laptops, i.e. 386/486 machines. Simply because it's fast, simple, portable (under DOS or Windows), easy to use and works on old hardware. Shouldn't Allegro 5/6 also be these things? I guess it's up to other people to decide.
Doug Eleveld
btw, I'm drunk. I hope that I not too obvious. I guess I'll see tomorrow when I re-read this post...
------------------------------------------------------------
--== Sent via Deja.com ==--
http://www.deja.com/
From - Thu Nov 29 22:44:28 2001
X-UIDL: 17644-968516558
X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Return-Path:
Received: from VL-MS-MR004.sc1.videotron.ca ([10.23.32.74]) by
VL-MS-MS002.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNLFZM02.OYW for <[email]>; Thu,
29 Nov 2001 22:21:22 -0500
Received: from canvaslink.com ([216.47.35.50]) by
VL-MS-MR004.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNLFZJ04.7MW for <[email]>; Thu,
29 Nov 2001 22:21:19 -0500
Received: from mail19.bigmailbox.com [209.132.220.50] by canvaslink.com with ESMTP
(SMTPD32-6.00) id AB916383032E; Thu, 29 Nov 2001 22:22:57 -0500
Received: (from www@localhost)
by mail19.bigmailbox.com (8.10.0/8.10.0) id fAU3IP530219;
Thu, 29 Nov 2001 19:18:25 -0800
Date: Thu, 29 Nov 2001 19:18:25 -0800
Message-Id: <[email]>
Content-Type: text/plain
Content-Disposition: inline
Content-Transfer-Encoding: binary
X-Mailer: MIME-tools 4.104 (Entity 4.116)
Mime-Version: 1.0
X-Originating-Ip: [213.51.194.171]
From: "Doug Eleveld" <[email]>
To: [email]
Cc: [email]
Subject: RE: Re: [AD] Proposed changes for Allegro 5 (6?)
Precedence: bulk
Sender: conductors-[email]
>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.
Just my 2 cents in the discussion. If Allegro drops DOS, I will drop Allegro. I use it for some model fitting and optimization programs and I still prefer to work in DOS. I also use it for some controller software that must run on old laptops, i.e. 386/486 machines. Simply because it's fast, simple, portable (under DOS or Windows), easy to use and works on old hardware. Shouldn't Allegro 5/6 also be these things? I guess it's up to other people to decide.
Doug Eleveld
btw, I'm drunk. I hope that I not too obvious. I guess I'll see tomorrow when I re-read this post...
------------------------------------------------------------
--== Sent via Deja.com ==--
http://www.deja.com/
From - Thu Nov 29 22:44:28 2001
X-UIDL: 17645-968516558
X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Return-Path: <[email]>
Received: from VL-MS-MR003.sc1.videotron.ca ([10.23.32.73]) by
VL-MS-MS002.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNLGBE02.PUA for <[email]>; Thu,
29 Nov 2001 22:28:26 -0500
Received: from mail19.bigmailbox.com ([209.132.220.50]) by
VL-MS-MR003.sc1.videotron.ca (Netscape Messaging Server 4.15
MR003 Jul 24 2001 16:23:26) with ESMTP id GNLGBE03.I1L for
<[email]>; Thu, 29 Nov 2001 22:28:26 -0500
Received: (from www@localhost)
by mail19.bigmailbox.com (8.10.0/8.10.0) id fAU3SNq31085;
Thu, 29 Nov 2001 19:28:23 -0800
Date: Thu, 29 Nov 2001 19:28:23 -0800
Message-Id: <[email]>
Content-Type: text/plain
Content-Disposition: inline
Content-Transfer-Encoding: binary
X-Mailer: MIME-tools 4.104 (Entity 4.116)
Mime-Version: 1.0
X-Originating-Ip: [213.51.194.171]
From: "Doug Eleveld" <[email]>
To: [email]
Cc: [email]
Subject: RE: Re: [AD] Proposed changes for Allegro 5 (6?)
>Allegro also doesn't nativaly support jpeg. If you were to use a >jpeg add-on (let's say), then the add-on can register its format >with load_bitmap so that calls to load_bitmap can also load *.jpg on >top of every other format.
So then what makes jpeg different than BMP or PCX or TGA or whatever?
I personally would prefer all bitmap format loading functions to be handled in the same consistant way. Allegro 4 has some legacy code issues that can't be helped. Allegro 5/6 shouldn't make the same mistake. I just think it's a shame that code gets included without the consent or thought of the programmer. Allegro 5/6 executables could be *smaller* than Allegro 4 executables, with some good API design. I think that would be real progress.
Doug
------------------------------------------------------------
--== Sent via Deja.com ==--
http://www.deja.com/
From - Thu Nov 29 22:44:28 2001
X-UIDL: 17646-968516558
X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Return-Path:
Received: from VL-MS-MR003.sc1.videotron.ca ([10.23.32.73]) by
VL-MS-MS002.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNLGGV03.JMA for <[email]>; Thu,
29 Nov 2001 22:31:43 -0500
Received: from canvaslink.com ([216.47.35.50]) by
VL-MS-MR003.sc1.videotron.ca (Netscape Messaging Server 4.15
MR003 Jul 24 2001 16:23:26) with ESMTP id GNLGGU02.X05 for
<[email]>; Thu, 29 Nov 2001 22:31:42 -0500
Received: from mail19.bigmailbox.com [209.132.220.50] by canvaslink.com with ESMTP
(SMTPD32-6.00) id ADE76432032E; Thu, 29 Nov 2001 22:32:55 -0500
Received: (from www@localhost)
by mail19.bigmailbox.com (8.10.0/8.10.0) id fAU3SNq31085;
Thu, 29 Nov 2001 19:28:23 -0800
Date: Thu, 29 Nov 2001 19:28:23 -0800
Message-Id: <[email]>
Content-Type: text/plain
Content-Disposition: inline
Content-Transfer-Encoding: binary
X-Mailer: MIME-tools 4.104 (Entity 4.116)
Mime-Version: 1.0
X-Originating-Ip: [213.51.194.171]
From: "Doug Eleveld" <[email]>
To: [email]
Cc: [email]
Subject: RE: Re: [AD] Proposed changes for Allegro 5 (6?)
Precedence: bulk
Sender: conductors-[email]
>Allegro also doesn't nativaly support jpeg. If you were to use a >jpeg add-on (let's say), then the add-on can register its format >with load_bitmap so that calls to load_bitmap can also load *.jpg on >top of every other format.
So then what makes jpeg different than BMP or PCX or TGA or whatever?
I personally would prefer all bitmap format loading functions to be handled in the same consistant way. Allegro 4 has some legacy code issues that can't be helped. Allegro 5/6 shouldn't make the same mistake. I just think it's a shame that code gets included without the consent or thought of the programmer. Allegro 5/6 executables could be *smaller* than Allegro 4 executables, with some good API design. I think that would be real progress.
Doug
------------------------------------------------------------
--== Sent via Deja.com ==--
http://www.deja.com/
From - Fri Nov 30 09:31:30 2001
X-UIDL: 17663-968516558
X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Return-Path:
Received: from VL-MS-MR002.sc1.videotron.ca ([10.23.32.72]) by
VL-MS-MS002.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNM8L403.4D8 for <[email]>; Fri,
30 Nov 2001 08:39:04 -0500
Received: from canvaslink.com ([216.47.35.50]) by
VL-MS-MR002.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNM8L401.5CB for <[email]>; Fri,
30 Nov 2001 08:39:04 -0500
Received: from tele-post-20.mail.demon.net [194.217.242.20] by canvaslink.com with ESMTP
(SMTPD32-6.00) id AC81F34037A; Fri, 30 Nov 2001 08:41:21 -0500
Received: from lwithers.demon.co.uk ([194.222.80.1])
by tele-post-20.mail.demon.net with esmtp (Exim 2.12 #2)
id 169nqV-0004n2-0K
for [email]; Fri, 30 Nov 2001 13:36:52 +0000
Message-ID: <[email]>
Date: Fri, 30 Nov 2001 13:36:25 +0000
To: [email]
From: Laurence Withers <[email]>
References: <[email]>
<[email]>
<[email]> <[email]>
<[email]>
In-Reply-To: <[email]>
MIME-Version: 1.0
Content-Type: multipart/signed;boundary="=_Turnpike_c$T6NFAWt4B84zbw=";
protocol="application/pgp-signature";micalg=pgp-sha1
X-Mailer: Turnpike Integrated Version 5.01 S
Subject: Re: [AD] Proposed changes for Allegro 5 (6?)
Precedence: bulk
Sender: conductors-[email]
This is a PGP signed message sent according to RFC2015 [PGP/MIME]
--=_Turnpike_c$T6NFAWt4B84zbw=
Content-Type: text/plain;charset=us-ascii
Content-Transfer-Encoding: quoted-printable
In reply to Bob <[email]>:
>And I agree. However, I'd hate to see DOS being the large boulder attached=
=20
>to Allegro. If all the neat stuff can be done from DOS, then you have my=20
>vote to keep it. Otherwise, it can stay with Allegro 4.
But so what if neat stuff can't be done from DOS? Allegro isn't an
operating system, so it doesn't need to provide services which are non-
trivial to implement if the OS doesn't have them. For instance, as Shawn
said, embedded devices are where Allegro has been used commercially. But
they may not support color graphics, mouse, keyboard, sound, etc. That
doesn't mean we should just drop such platforms; simply programs which
*require* something that is not available won't work.
>If we do'nt drop DOS, then, if ever some feature pops up that Allegro cann=
ot=20
>(easily) emulate in DOS, could we have a non-portable-to-DOS program?=20
Yes, why not? Who cares if DOS can't (for instance) create a new
process; programs which require this can't be run on DOS. Get a better
OS... ;-)
Bye for now,
--=20
Laurence Withers, [email]
http://www.lwithers.demon.co.uk/
--=_Turnpike_c$T6NFAWt4B84zbw=
Content-Type: application/pgp-signature
Content-Disposition: attachment; filename=signature.asc
-----BEGIN PGP SIGNATURE-----
Version: PGPsdk version 1.7.1
iQA/AwUBPAeLWWbrT6QxxsGNEQLsoACeO1ClEHGNwwOuUkGr31I6gZqFH3cAoLwt
FY6JYLdMGAHJadRTtmEiZYyV
=P5hT
-----END PGP SIGNATURE-----
--=_Turnpike_c$T6NFAWt4B84zbw=--
From - Tue Nov 27 23:22:21 2001
X-UIDL: 17505-968516558
X-Mozilla-Status: 0001
X-Mozilla-Status2: 00000000
Return-Path:
Received: from VL-MS-MR003.sc1.videotron.ca ([10.23.32.73]) by
VL-MS-MS002.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNHTB101.03B for <[email]>; Tue,
27 Nov 2001 23:18:37 -0500
Received: from canvaslink.com ([216.47.35.50]) by
VL-MS-MR003.sc1.videotron.ca (Netscape Messaging Server 4.15
MR003 Jul 24 2001 16:23:26) with ESMTP id GNHTB101.DIL for
<[email]>; Tue, 27 Nov 2001 23:18:37 -0500
Received: from VL-MS-MR004.sc1.videotron.ca [24.201.245.36] by canvaslink.com with ESMTP
(SMTPD32-6.00) id A61530440316; Tue, 27 Nov 2001 23:20:37 -0500
Received: from videotron.ca ([24.202.201.127]) by
VL-MS-MR004.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNHT8J04.XO1 for <[email]>; Tue,
27 Nov 2001 23:17:07 -0500
Message-ID: <[email]>
Date: Tue, 27 Nov 2001 23:17:02 -0500
From: Bob <[email]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.6) Gecko/20011120
X-Accept-Language: en-us
MIME-Version: 1.0
To: [email]
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [AD] Proposed changes for Allegro 5 (6?)
Precedence: bulk
Sender: conductors-[email]
Heya,
I've composed a small list of things that we can discuss when moving the new
API for Allegro 5 or 6. The list is NOT complete (I'd like to hear your
opinion), and is NOT final - some entries even contradict others.
http://pages.infinit.net/voidstar/newalleg.txt
With Eric's blessing, I can create a new module on CVS (allegro5 ?), where
this list can be placed, along with perhaps some sample programs that would
use the new API (just to show how it would be used). It would be kinda like
ahack.txt but split out over several files.
--
- Robert J Ohannessian
"Microsoft code is probably O(n^20)" (my CS prof)
http://pages.infinit.net/voidstar/
From - Wed Nov 28 08:00:26 2001
X-UIDL: 17508-968516558
X-Mozilla-Status: 0013
X-Mozilla-Status2: 00000000
Return-Path:
Received: from VL-MS-MR001.sc1.videotron.ca ([10.23.32.71]) by
VL-MS-MS002.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNHWTY02.R5Q for <[email]>; Wed,
28 Nov 2001 00:34:46 -0500
Received: from canvaslink.com ([216.47.35.50]) by
VL-MS-MR001.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNHWTY00.9SS for <[email]>; Wed,
28 Nov 2001 00:34:46 -0500
Received: from finch-post-11.mail.demon.net [194.217.242.39] by canvaslink.com with ESMTP
(SMTPD32-6.00) id A7EE4B0F02CC; Wed, 28 Nov 2001 00:36:46 -0500
Received: from lwithers.demon.co.uk ([194.222.80.1])
by finch-post-11.mail.demon.net with esmtp (Exim 2.12 #1)
id 168xLP-000HBu-0B
for [email]; Wed, 28 Nov 2001 05:33:16 +0000
Message-ID:
Date: Wed, 28 Nov 2001 05:33:13 +0000
To: [email]
From: Laurence Withers <[email]>
References: <[email]>
In-Reply-To: <[email]>
MIME-Version: 1.0
Content-Type: multipart/signed;boundary="=_Turnpike_pwAH+VAZcHB8cxHB=";
protocol="application/pgp-signature";micalg=pgp-sha1
X-Mailer: Turnpike Integrated Version 5.01 S
Subject: Re: [AD] Proposed changes for Allegro 5 (6?)
Precedence: bulk
Sender: conductors-[email]
This is a PGP signed message sent according to RFC2015 [PGP/MIME]
--=_Turnpike_pwAH+VAZcHB8cxHB=
Content-Type: text/plain;charset=us-ascii
Content-Transfer-Encoding: quoted-printable
In reply to Bob <[email]>:
>http://pages.infinit.net/voidstar/newalleg.txt
Well:
- load_sample() and load_bitmap() both already exist,
- dropping things like zbuffer/p3d/blenders: why? As long as they are
in separate object files they won't be pulled in if necessary.
- save_font(): can people not use the Allegro Fonts addon?
- packfiles: I agree with removing encryption, and with moving=20
compression to be separate to the actual packfile routines, but we
should provide the current compression scheme because it is quite=20
fast and loads of people use it.
- network: why not use something like libnet?
- dynamic loading of modules: this would work fine on i386 (with=20
stonewheel), but not on anything else. So at best, we couldn't rely=20
on it being available.
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.
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=20
plan to port your program to DOS. If you don't, then all other=20
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.
Bye for now,
--=20
Laurence Withers, [email]
http://www.lwithers.demon.co.uk/
--=_Turnpike_pwAH+VAZcHB8cxHB=
Content-Type: application/pgp-signature
Content-Disposition: attachment; filename=signature.asc
-----BEGIN PGP SIGNATURE-----
Version: PGPsdk version 1.7.1
iQA/AwUBPAR3GWbrT6QxxsGNEQIyngCePPOQZ1qKHM6mE3bpBStd0mLcc3IAn1jJ
YFbkkkv7S7qyZEdoEY/BPEY+
=Jfr6
-----END PGP SIGNATURE-----
--=_Turnpike_pwAH+VAZcHB8cxHB=--
From - Wed Nov 28 08:00:27 2001
X-UIDL: 17511-968516558
X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Return-Path:
Received: from VL-MS-MR004.sc1.videotron.ca ([10.23.32.74]) by
VL-MS-MS002.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNI70800.U5C for <[email]>; Wed,
28 Nov 2001 04:14:32 -0500
Received: from canvaslink.com ([216.47.35.50]) by
VL-MS-MR004.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNI70802.ST0 for <[email]>; Wed,
28 Nov 2001 04:14:32 -0500
Received: from alfa.srnet.cz [62.24.72.242] by canvaslink.com with ESMTP
(SMTPD32-6.00) id AB761A6A03B4; Wed, 28 Nov 2001 04:16:38 -0500
Received: from penguin.src (penguin.src [10.0.0.2])
by alfa.srnet.cz (8.10.2/8.10.2) with ESMTP id fAS9D5f17599
for <[email]>; Wed, 28 Nov 2001 10:13:05 +0100
Date: Wed, 28 Nov 2001 10:13:05 +0100 (CET)
From: Stepan Roh <[email]>
To: Allegro Developers List <[email]>
In-Reply-To: <[email]>
Message-ID:
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: Re: [AD] Proposed changes for Allegro 5 (6?)
Precedence: bulk
Sender: conductors-[email]
On Tue, 27 Nov 2001, Bob wrote:
> http://pages.infinit.net/voidstar/newalleg.txt
Splitting packfiles handling to compression/encryption layers is good, but
removing default implementation is bad, bad, bad :-) Why?
Adding networking is not good thing, I think. Too much new code without
any connection to current Allegro.
Allegro 5 should have cleaner and consistent API with better decomposition
to modules (unicode handling, gfx, sound, input, packfiles, etc.). This
should be the main goal. And, of course, cleaning up the sources a bit.
Generated API docs is very good idea, but forget Javadoc. It's too
Java-centric and too slow.
Have a nice day.
Stepan Roh
From - Wed Nov 28 08:00:27 2001
X-UIDL: 17512-968516558
X-Mozilla-Status: 0013
X-Mozilla-Status2: 00000000
Return-Path:
Received: from VL-MS-MR001.sc1.videotron.ca ([10.23.32.71]) by
VL-MS-MS002.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNICAK04.Y97 for <[email]>; Wed,
28 Nov 2001 06:08:44 -0500
Received: from canvaslink.com ([216.47.35.50]) by
VL-MS-MR001.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNICAJ01.SUY for <[email]>; Wed,
28 Nov 2001 06:08:43 -0500
Received: from uria.its.uu.se [130.238.7.14] by canvaslink.com with ESMTP
(SMTPD32-6.00) id A4F45A92032E; Wed, 28 Nov 2001 06:05:24 -0500
Received: from regulus2.student.uu.se ([130.238.5.5]:40187 "EHLO student.uu.se")
by uria.its.uu.se with ESMTP id ;
Wed, 28 Nov 2001 12:00:58 +0100
Message-ID: <[email]>
Date: Wed, 28 Nov 2001 12:00:49 +0100
From: Sven Sandberg <[email]>
X-Mailer: Mozilla 4.77 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Allegro Developer <[email]>
References: <[email]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: Re: [AD] Proposed changes for Allegro 5 (6?)
Precedence: bulk
Sender: conductors-[email]
Bob wrote:
> I've composed a small list of things that we can discuss when moving
> the new API for Allegro 5 or 6.
A good idea!
Here are my opinions about what I know something about. You can insert
`IMHO' before each sentence if you like, so I don't need to instantiate
humbleness everywhere :-).
I may seem a bit conservative, but I think it is important to keep
backwards compatibility on all places that aren't totally broken. It
will be hard enough anyway to port old programs to Allegro 5.
First, I'd like to add a point that has irritated me for a long time
now:
- `bmp_read8()' & co currently use longs instead of pointers. I think
this is an old djgpp-ism, because `_farnspokew()' take longs as
arguments. If someone knows a good reason why it must be this way,
please say it. Otherwise, can we please replace `unsigned long' by
`unsigned char *', `unsigned short *', and `unsigned long *'? It scares
me a bit because there's no reason to think that
sizeof(long)==sizeof(void*) on all platforms, plus there's apparently no
reason to store a pointer in a long.
We also discussed replacing `text_mode()' by an extra parameter to
`textout()'; this might be worth adding to the list.
> Graphics:
> - 8 bit palette components
Absolutely!
> - Possible merge of AllegroGL (as an OpenGL driver only, to keep it
Why can't it be in AllegroGL?
> - merge blit and sprite API
What do you mean? This sounds like "remove `draw_sprite()' and add an
extra parameter to `blit()' indicating whether transparent pixels should
be masked out", but we earlier discussed "make the order of source/dest
parameters to `draw_sprite()' be the same as the order of source/dest
parameters to `blit()'".
> - is_*_bitmap collapsed to a single function - get_bitmap_type()
Why? I think the bit field that such a function would have to return
would be a bit complicated, and some of those functions are very
different from each other.
> - What to do with floodfill (can't be accelerated via GL or D3D)
Why should we want to do anything with it? Just let it be the way it is.
> - Dump draw_character
Why? It needs to be in the library because we need to draw text, so it
doesn't hurt to have it in the API, right?
> - Unified rotate_flip_pivot_stretch routine
There is already one: `_pivot_scaled_sprite_flip()' in aintern.h
> - hsv_to_rgb and rgb_to_hsv in a separate lib
> - Remove not-so-useful blenders (dissolve, dodge, hue, invert,
> luminance, multiply, saturation, screen)
Why? They are all small and can't hurt much?
> - Fix this whole 32bpp == int, 16bpp == short thing. Use int16_t and
> int32_t instead?
Why? I think this would break too much code, both in Allegro and in
user's code. Btw, 32bpp == long, not int.
> - true color fade in/out (Nathan)
Yes, this is probably such a frequent faq that it is worth implementing.
> Text Drawing:
> - textout should not use -1 for colored fonts.
Why? What else?
> Packfiles:
> - Allow registering of new compression and encryption libs.
Good idea, but nothing we need to wait for if nobody writes it.
> - save_datafile() and save_datafile_object() (Nathan Smith)
I think these already exist in libaldat.a.
> Network:
> - Can we get one? Please? :)
Why can't it stay in libnet?
> Core:
> - prefixing of the API
Absolutely!
> - Move as much as possible to VTables
Any specific ideas on which functions this should include?
> - Drop DOS.
No, please! There are so many people who use djgpp, and there are no
problems with that port. There was a reason to drop rsx because it
didn't work, nobody used it, and the platform is dead, but nothing of
this applies to djgpp.
> Documentation:
> - Generated from source via Doxygen or Javadoc
Why? _tx files work perfectly, can generate more file formats than
anything else, and are self-contained, i.e. no need for user to download
another package with the help compiler. And some add-ons actually use
makedoc.
> Stuff to remove (can be placed in add-ons)
[snip]
> - Software 3D code
> - 3D Math
I think these are too widely used to be removed.
> - Fixed point math
Many people, including Allegro itself, uses it everywhere, so I strongly
disagree.
> - Compiled sprites and RLE
Maybe compiled sprites, but please not RLE, they are useful to save
memory.
You didn't mention the gui, which I think is good. IMHO it is
fundamentally broken by design (because it wasn't meant for anything
else than internal purposes), and should remain so because a proper gui
can grow unboundedly and is better done as an add-on. And also because
redesigning it would break tons of user code.
Sven
From - Wed Nov 28 08:00:27 2001
X-UIDL: 17514-968516558
X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Return-Path:
Received: from VL-MS-MR003.sc1.videotron.ca ([10.23.32.73]) by
VL-MS-MS002.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNICT201.L80 for <[email]>; Wed,
28 Nov 2001 06:19:50 -0500
Received: from canvaslink.com ([216.47.35.50]) by
VL-MS-MR003.sc1.videotron.ca (Netscape Messaging Server 4.15
MR003 Jul 24 2001 16:23:26) with ESMTP id GNICT102.QZ5 for
<[email]>; Wed, 28 Nov 2001 06:19:49 -0500
Received: from mail.libertysurf.net [213.36.80.91] by canvaslink.com with ESMTP
(SMTPD32-6.00) id A8BC9680348; Wed, 28 Nov 2001 06:21:32 -0500
Received: from zephyr (213.36.44.234) by mail.libertysurf.net (5.1.053)
id 3C03EA540001CA39 for [email]; Wed, 28 Nov 2001 12:18:02 +0100
Message-ID: <00e901c177fe$87eae000$ea2c24d5@zephyr>
From: "Eric Botcazou" <[email]>
To: "Allegro conductors" <[email]>
References: <[email]>
Date: Wed, 28 Nov 2001 12:18:33 +0100
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2014.211
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211
Subject: Re: [AD] Proposed changes for Allegro 5 (6?)
Precedence: bulk
Sender: conductors-[email]
> With Eric's blessing, I can create a new module on CVS (allegro5 ?), where
> this list can be placed, along with perhaps some sample programs that
> would use the new API (just to show how it would be used).
Huh... you have it of course, but it is actually not very useful since the
right guys to convince are rather P*** W*** from Australia or G*** F*** from
England (or M*** B*** from ... ????).
--
Eric Botcazou
[email]
From - Wed Nov 28 08:00:28 2001
X-UIDL: 17516-968516558
X-Mozilla-Status: 0013
X-Mozilla-Status2: 00000000
Return-Path:
Received: from VL-MS-MR004.sc1.videotron.ca ([10.23.32.74]) by
VL-MS-MS002.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNIDKU04.HJB for <[email]>; Wed,
28 Nov 2001 06:36:30 -0500
Received: from canvaslink.com ([216.47.35.50]) by
VL-MS-MR004.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNIDKS00.SR4 for <[email]>; Wed,
28 Nov 2001 06:36:28 -0500
Received: from fruitmachine.brighton.climax.co.uk [212.74.3.86] by canvaslink.com with ESMTP
(SMTPD32-6.00) id AC47201303EE; Wed, 28 Nov 2001 06:36:39 -0500
Received: by FRUITMACHINE with Internet Mail Service (5.5.2653.19)
id ; Wed, 28 Nov 2001 11:33:05 -0000
Message-ID: <28A7C352840AD511AC9400508BE70AC24FFDA3@FRUITMACHINE>
From: Shawn Hargreaves <[email]>
To: 'Sven Sandberg' <[email]>, Allegro Developer
<[email]>
Date: Wed, 28 Nov 2001 11:33:03 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
boundary="----_=_NextPart_001_01C17800.70C8B760"
Subject: RE: [AD] Proposed changes for Allegro 5 (6?)
Precedence: bulk
Sender: conductors-[email]
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
------_=_NextPart_001_01C17800.70C8B760
Content-Type: text/plain;
charset="iso-8859-1"
Sven Sandberg writes:
> - `bmp_read8()' & co currently use longs instead of pointers. I think
> this is an old djgpp-ism, because `_farnspokew()' take longs as
> arguments. If someone knows a good reason why it must be this way,
> please say it. Otherwise, can we please replace `unsigned long' by
> `unsigned char *', `unsigned short *', and `unsigned long *'?
The thinking behind using longs is that this makes the pointers
opaque, ie. can't be dereferenced directly by the user, so
people are forced to always access them with the bmp_read*()
macros. If they were pointers, it would be easy to accidentally
write *ptr, which would work on some platforms but fail on
others.
Ideally these should be a "vidmemptr" type, but given the lack
of such a thing in C (cue suggestions to do it in C++ :-) an
integer type does a reasonable job of supporting copy, comparison,
addition, etc, but not dereferencing.
> > - save_datafile() and save_datafile_object() (Nathan Smith)
>
> I think these already exist in libaldat.a.
They do, but not in a very useful form as they call grabber plugin
functions to do the work of actually saving out the various chunk
types. I think it would be a shame to lose that plugin architecture
just so those functions could be included in core Allegro, but if
anyone wanted this, maybe they could do some work to make the
datafile lib a bit more generic and easily linkable into other
programs? (although even at present, it is pretty easy to use
as long as you don't mind reading headers/source to figure out the
API).
> > Stuff to remove (can be placed in add-ons)
> [snip]
> > - Software 3D code
> > - 3D Math
>
> I think these are too widely used to be removed.
Probably true. It is a shame because vector/matrix math is one
area where C++ classes can make life so much nicer than a C API,
so I'd hate to be stuck ever actually writing real code with
something like the Allegro routines, but they certainly are used
a lot, and Allegro is probably the wrong place to put a nice C++
math package in any case (plus, such things don't need to be that
tightly integrated so there are unlikely to be problems using
whatever C++ math package alongside other graphics libs).
Shawn.
------_=_NextPart_001_01C17800.70C8B760
Content-Type: text/html;
charset="iso-8859-1"
RE: [AD] Proposed changes for Allegro 5 (6?)
Sven Sandberg writes:
> - `bmp_read8()' & co currently use longs instead of pointers. I think
> this is an old djgpp-ism, because `_farnspokew()' take longs as
> arguments. If someone knows a good reason why it must be this way,
> please say it. Otherwise, can we please replace `unsigned long' by
> `unsigned char *', `unsigned short *', and `unsigned long *'?
The thinking behind using longs is that this makes the pointers
opaque, ie. can't be dereferenced directly by the user, so
people are forced to always access them with the bmp_read*()
macros. If they were pointers, it would be easy to accidentally
write *ptr, which would work on some platforms but fail on
others.
Ideally these should be a "vidmemptr" type, but given the lack
of such a thing in C (cue suggestions to do it in C++ :-) an
integer type does a reasonable job of supporting copy, comparison,
addition, etc, but not dereferencing.
> > - save_datafile() and save_datafile_object() (Nathan Smith)
>
> I think these already exist in libaldat.a.
They do, but not in a very useful form as they call grabber plugin
functions to do the work of actually saving out the various chunk
types. I think it would be a shame to lose that plugin architecture
just so those functions could be included in core Allegro, but if
anyone wanted this, maybe they could do some work to make the
datafile lib a bit more generic and easily linkable into other
programs? (although even at present, it is pretty easy to use
as long as you don't mind reading headers/source to figure out the
API).
> > Stuff to remove (can be placed in add-ons)
> [snip]
> > - Software 3D code
> > - 3D Math
>
> I think these are too widely used to be removed.
Probably true. It is a shame because vector/matrix math is one
area where C++ classes can make life so much nicer than a C API,
so I'd hate to be stuck ever actually writing real code with
something like the Allegro routines, but they certainly are used
a lot, and Allegro is probably the wrong place to put a nice C++
math package in any case (plus, such things don't need to be that
tightly integrated so there are unlikely to be problems using
whatever C++ math package alongside other graphics libs).
Shawn.
------_=_NextPart_001_01C17800.70C8B760--
From - Wed Nov 28 08:00:29 2001
X-UIDL: 17522-968516558
X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Return-Path:
Received: from VL-MS-MR002.sc1.videotron.ca ([10.23.32.72]) by
VL-MS-MS002.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNIF1C03.2PT for <[email]>; Wed,
28 Nov 2001 07:08:00 -0500
Received: from canvaslink.com ([216.47.35.50]) by
VL-MS-MR002.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNIF1B00.X4T for <[email]>; Wed,
28 Nov 2001 07:07:59 -0500
Received: from smtp1.libero.it [193.70.192.51] by canvaslink.com with ESMTP
(SMTPD32-6.00) id A09A213C0396; Wed, 28 Nov 2001 06:55:06 -0500
Received: from lano (151.28.46.178) by smtp1.libero.it (6.0.032)
id 3BF1798A0048B448 for [email]; Wed, 28 Nov 2001 12:51:37 +0100
Date: Wed, 28 Nov 2001 12:41:41 +0100
From: Lo'oRiS il Kabukimono <[email]>
To: [email]
Message-Id: <[email]>
In-Reply-To: <[email]>
References: <[email]>
<[email]>
X-Mailer: Sylpheed version 0.6.5 (GTK+ 1.2.9; i586-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Subject: Re: [AD] Proposed changes for Allegro 5 (6?)
Precedence: bulk
Sender: conductors-[email]
> user's code. Btw, 32bpp == long, not int.
not true.
it depends on the platform.
for me sizeof(int)==sizeof(long)==32
about AllegroGL i think it should be nice to have, directly in Allegro,
something like a GFX_OPENGL driver, without adding anything else to
the program. (if it is possible, i don't know so much about this...)
about other issues i agree with Laurence, Stepan and Sven, and i want
to repeat that DOS port can't be dropped (though is nice to do what
Laurence suggested)
"Keep mouthing off like that, little girl, and you're going to get burned."
"I got insurance"
Yuffie, Final Fantasy 7
_.-:/°^^°\:-._.-:/°^^°\:-._ __. ____
- Lo'oRiS il Kabukimono - / /| /^___ \
Real Name: Lorenzo Petrone / / / / /L_/ /
e-mail: [email] / / / / ___-°/
irc.azzurra.org #lano / /_/__ / /|__-°
digilander.iol.it/lano666 /______/| /__/ /
^°\:-.__.-:/°^°\:-.__.-:/°^ |______|/ |__L/
From - Wed Nov 28 08:00:29 2001
X-UIDL: 17523-968516558
X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Return-Path:
Received: from VL-MS-MR004.sc1.videotron.ca ([10.23.32.74]) by
VL-MS-MS002.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNIG5F04.HKJ for <[email]>; Wed,
28 Nov 2001 07:32:03 -0500
Received: from canvaslink.com ([216.47.35.50]) by
VL-MS-MR004.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNIG5E02.3WE for <[email]>; Wed,
28 Nov 2001 07:32:02 -0500
Received: from uria.its.uu.se [130.238.7.14] by canvaslink.com with ESMTP
(SMTPD32-6.00) id A98F56B102CC; Wed, 28 Nov 2001 07:33:19 -0500
Received: from regulus2.student.uu.se ([130.238.5.5]:38014 "EHLO student.uu.se")
by uria.its.uu.se with ESMTP id ;
Wed, 28 Nov 2001 13:29:38 +0100
Message-ID: <[email]>
Date: Wed, 28 Nov 2001 13:29:29 +0100
From: Sven Sandberg <[email]>
X-Mailer: Mozilla 4.77 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Allegro Developer <[email]>
References: <[email]>
<[email]> <[email]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: Re: [AD] Proposed changes for Allegro 5 (6?)
Precedence: bulk
Sender: conductors-[email]
Lo'oRiS il Kabukimono wrote:
> > user's code. Btw, 32bpp == long, not int.
>
> not true.
> it depends on the platform.
> for me sizeof(int)==sizeof(long)==32
No, sorry, 32bpp pixels are stored as long on all platforms. It might be
true that int also works on some platforms, but not generally. This can
be seen from the definition of BYTES_PER_PIXEL() (around line 300 of
ainline.h), and BYTES_PER_PIXEL() is what create_bitmap() uses to
determine the size (line 848 of graphics.c).
--
Sven Sandberg [email] home.student.uu.se/svsa1977
From - Wed Nov 28 08:00:29 2001
X-UIDL: 17524-968516558
X-Mozilla-Status: 0013
X-Mozilla-Status2: 00000000
Return-Path:
Received: from VL-MS-MR003.sc1.videotron.ca ([10.23.32.73]) by
VL-MS-MS002.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNIGVX03.7NU for <[email]>; Wed,
28 Nov 2001 07:47:57 -0500
Received: from canvaslink.com ([216.47.35.50]) by
VL-MS-MR003.sc1.videotron.ca (Netscape Messaging Server 4.15
MR003 Jul 24 2001 16:23:26) with ESMTP id GNIGVX03.F68 for
<[email]>; Wed, 28 Nov 2001 07:47:57 -0500
Received: from relay4.ftech.net [212.32.16.76] by canvaslink.com with ESMTP
(SMTPD32-6.00) id AD371A7003E2; Wed, 28 Nov 2001 07:48:55 -0500
Received: from ibm9.ftech.net ([212.32.16.79] helo=mailgate)
by relay4.ftech.net with esmtp (Exim 3.22-ftech-p6.1 #9)
id 16945b-0004JD-00
for [email]; Wed, 28 Nov 2001 12:45:23 +0000
Received: from [89.0.0.95] by (MailGate 3.5.165) with ESMTP; Wed, 28 Nov 2001 12:45:38 +0000
Received: by warhol with Internet Mail Service (5.5.2448.0)
id ; Wed, 28 Nov 2001 12:43:44 -0000
Message-ID:
From: Vincent Penquerc'h <[email]>
To: [email]
Date: Wed, 28 Nov 2001 12:43:43 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/alternative;
boundary="----_=_NextPart_001_01C1780A.50A1B220"
Subject: RE: [AD] Proposed changes for Allegro 5 (6?)
Precedence: bulk
Sender: conductors-[email]
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
------_=_NextPart_001_01C1780A.50A1B220
Content-Type: text/plain;
charset="windows-1252"
Hi,
my humble opinion about these:
> merge blit and sprite API
Could you be more specific about what to change ? without losing speed.
> is_*_bitmap collapsed to a single function - get_bitmap_type()
You could have a subbitmap of a video bitmap (I think), so a bitmap
could have more than one type
> What to do with floodfill (can't be accelerated via GL or D3D)
And then ? That is not a reason to remove it I think :)
> Collapse load_* into one function load_bitmap(), smart enough to read
> the file header to determine the format.
There is no such thing: TGA has no header, PCX has a riducully small one,
making it very awkward to detect. However, if we *know* the user can't
ask to load a non TGA-or-PCX-or-LBM-or-BMP file, then it becomes easier,
but I don't think it's feasible (eg user selecting an image file in a
directory pick dialog)
> Speed ups in the asm code
I remember Shawn saying that the lit and trans routines were faster in
C than in asm :)
> Message based (see SDL) (about input)
In addition to the current API, right ?
> Can we get one? Please? :) (about network)
Well, I'd agree with that, even with the argument that libnet exists.
> Configuration via an OpenGL-like al_set(variable, value) system
I'm not too hapy about that. That's... well, odd. You lose type safety.
And the code is a big switch. Not appealing.
> Some of the little used variables converted to strings
Making them more difficult to use ?
> Drop DOS
No comment :)
Ah yes, one: why remove it while it's working fine ????
It could be possible to not implement stuff that it doesn't support
though, like switch in/out callbacks setters (they nop on DOS).
This allows other stuff to be added while keeping DOS compatibility.
> Have a Windows installer built from a script (PIMP?)
Huh ????? :)
> Stuff to remove:
> Fixed point math
That's being used in quite a few of Allegro's routines themselves
(hmm, almost all are variations on rotation, though).
> Compiled sprites and RLE
Heh ????? If you remove RLE sprites, I'll get angry :)
That's one of the features that actually make Allegro useful. Moving it
away in an add-on is pointless, as they're quite core, I think.
On a general way, I'd like to point out the obvious: moving stuff into
addons means that they're far more likely to rot. So moving stuff into
addons should be weighed carefully.
What could be done is to split Allegro into parts which would be like
addons, but still part of Allegro. A new release would not have to
included updated parts of all parts, meaning that, say, packfile
comrpession work needs not delay a release, but Allegro can still
count on packfiles being part of Allegro (and thus use them in the
lib). This would need fairly extensive work to get rid of many
dependencies though.
Anyway, that's a nice list, thanks for taking the time of doing it :)
--
Vincent Penquerc'h
------_=_NextPart_001_01C1780A.50A1B220
Content-Type: text/html;
charset="windows-1252"
RE: [AD] Proposed changes for Allegro 5 (6?)
Hi,
my humble opinion about these:
> merge blit and sprite API
Could you be more specific about what to change ? without losing speed.
> is_*_bitmap collapsed to a single function - get_bitmap_type()
You could have a subbitmap of a video bitmap (I think), so a bitmap
could have more than one type
> What to do with floodfill (can't be accelerated via GL or D3D)
And then ? That is not a reason to remove it I think :)
> Collapse load_* into one function load_bitmap(), smart enough to read
> the file header to determine the format.
There is no such thing: TGA has no header, PCX has a riducully small one,
making it very awkward to detect. However, if we *know* the user can't
ask to load a non TGA-or-PCX-or-LBM-or-BMP file, then it becomes easier,
but I don't think it's feasible (eg user selecting an image file in a
directory pick dialog)
> Speed ups in the asm code
I remember Shawn saying that the lit and trans routines were faster in
C than in asm :)
> Message based (see SDL) (about input)
In addition to the current API, right ?
> Can we get one? Please? :) (about network)
Well, I'd agree with that, even with the argument that libnet exists.
> Configuration via an OpenGL-like al_set(variable, value) system
I'm not too hapy about that. That's... well, odd. You lose type safety.
And the code is a big switch. Not appealing.
> Some of the little used variables converted to strings
Making them more difficult to use ?
> Drop DOS
No comment :)
Ah yes, one: why remove it while it's working fine ????
It could be possible to not implement stuff that it doesn't support
though, like switch in/out callbacks setters (they nop on DOS).
This allows other stuff to be added while keeping DOS compatibility.
> Have a Windows installer built from a script (PIMP?)
Huh ????? :)
> Stuff to remove:
> Fixed point math
That's being used in quite a few of Allegro's routines themselves
(hmm, almost all are variations on rotation, though).
> Compiled sprites and RLE
Heh ????? If you remove RLE sprites, I'll get angry :)
That's one of the features that actually make Allegro useful. Moving it
away in an add-on is pointless, as they're quite core, I think.
On a general way, I'd like to point out the obvious: moving stuff into
addons means that they're far more likely to rot. So moving stuff into
addons should be weighed carefully.
What could be done is to split Allegro into parts which would be like
addons, but still part of Allegro. A new release would not have to
included updated parts of all parts, meaning that, say, packfile
comrpession work needs not delay a release, but Allegro can still
count on packfiles being part of Allegro (and thus use them in the
lib). This would need fairly extensive work to get rid of many
dependencies though.
Anyway, that's a nice list, thanks for taking the time of doing it :)
--
Vincent Penquerc'h
------_=_NextPart_001_01C1780A.50A1B220--
From - Wed Nov 28 08:49:40 2001
X-UIDL: 17527-968516558
X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Return-Path:
Received: from VL-MS-MR003.sc1.videotron.ca ([10.23.32.73]) by
VL-MS-MS002.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNIJ3S02.6RP for <[email]>; Wed,
28 Nov 2001 08:35:52 -0500
Received: from canvaslink.com ([216.47.35.50]) by
VL-MS-MR003.sc1.videotron.ca (Netscape Messaging Server 4.15
MR003 Jul 24 2001 16:23:26) with ESMTP id GNIJ3S00.L4L for
<[email]>; Wed, 28 Nov 2001 08:35:52 -0500
Received: from smtp2.libero.it [193.70.192.52] by canvaslink.com with ESMTP
(SMTPD32-6.00) id A89C35FC02CE; Wed, 28 Nov 2001 08:37:32 -0500
Received: from lano (151.28.42.122) by smtp2.libero.it (6.0.032)
id 3BEFF1610057709D for [email]; Wed, 28 Nov 2001 14:34:02 +0100
Date: Wed, 28 Nov 2001 14:24:04 +0100
From: Lo'oRiS il Kabukimono <[email]>
To: [email]
Message-Id: <[email]>
In-Reply-To: <[email]>
References: <[email]>
<[email]>
<[email]>
<[email]>
X-Mailer: Sylpheed version 0.6.5 (GTK+ 1.2.9; i586-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Subject: Re: [AD] sizeofs
Precedence: bulk
Sender: conductors-[email]
> > > user's code. Btw, 32bpp == long, not int.
> >
> > not true.
> > it depends on the platform.
> > for me sizeof(int)==sizeof(long)==32
>
> No, sorry, 32bpp pixels are stored as long on all platforms. It might be
ok i trust u but i was saying a little different thing,
i meant that it is not true that int!=32 and also that is not true
that int!=long
this does not exclude that long can always be 32.
"When the world is in darkness, four warriors will come..."
Final Fantasy I
_.-:/°^^°\:-._.-:/°^^°\:-._ __. ____
- Lo'oRiS il Kabukimono - / /| /^___ \
Real Name: Lorenzo Petrone / / / / /L_/ /
e-mail: [email] / / / / ___-°/
irc.azzurra.org #lano / /_/__ / /|__-°
digilander.iol.it/lano666 /______/| /__/ /
^°\:-.__.-:/°^°\:-.__.-:/°^ |______|/ |__L/
From - Wed Nov 28 08:49:41 2001
X-UIDL: 17529-968516558
X-Mozilla-Status: 0013
X-Mozilla-Status2: 00000000
Return-Path:
Received: from VL-MS-MR003.sc1.videotron.ca ([10.23.32.73]) by
VL-MS-MS002.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNIJGX05.HIR for <[email]>; Wed,
28 Nov 2001 08:43:45 -0500
Received: from canvaslink.com ([216.47.35.50]) by
VL-MS-MR003.sc1.videotron.ca (Netscape Messaging Server 4.15
MR003 Jul 24 2001 16:23:26) with ESMTP id GNIJGX01.T3C for
<[email]>; Wed, 28 Nov 2001 08:43:45 -0500
Received: from mail.libertysurf.net [213.36.80.91] by canvaslink.com with ESMTP
(SMTPD32-6.00) id A901361602CE; Wed, 28 Nov 2001 08:39:13 -0500
Received: from zephyr (213.36.128.168) by mail.libertysurf.net (5.1.053)
id 3BFECE80000AB710 for [email]; Wed, 28 Nov 2001 14:36:00 +0100
Message-ID: <01cd01c17811$c45a1660$ea2c24d5@zephyr>
From: "Eric Botcazou" <[email]>
To: <[email]>
References:
Date: Wed, 28 Nov 2001 14:33:44 +0100
MIME-Version: 1.0
Content-Type: text/plain;
charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2014.211
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211
Subject: Re: [AD] Proposed changes for Allegro 5 (6?)
Precedence: bulk
Sender: conductors-[email]
> > Message based (see SDL) (about input)
> In addition to the current API, right ?
And you need to poll ?
Gosh ! ;-) All the complexity in the Windows port comes precisely from
hiding the message-driven nature of the OS. I think we'd better use a
slot/callback design.
--
Eric Botcazou
[email]
From - Wed Nov 28 08:54:36 2001
X-UIDL: 17530-968516558
X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Return-Path:
Received: from VL-MS-MR003.sc1.videotron.ca ([10.23.32.73]) by
VL-MS-MS002.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNIJYX02.AG6 for <[email]>; Wed,
28 Nov 2001 08:54:33 -0500
Received: from canvaslink.com ([216.47.35.50]) by
VL-MS-MR003.sc1.videotron.ca (Netscape Messaging Server 4.15
MR003 Jul 24 2001 16:23:26) with ESMTP id GNIJYX01.K4R for
<[email]>; Wed, 28 Nov 2001 08:54:33 -0500
Received: from relay5.ftech.net [212.32.16.118] by canvaslink.com with ESMTP
(SMTPD32-6.00) id AD011BAA0388; Wed, 28 Nov 2001 08:56:17 -0500
Received: from ibm9.ftech.net ([212.32.16.79] helo=mailgate)
by relay5.ftech.net with esmtp (Exim 3.22-ftech-p6.1 #14)
id 16958o-0005bd-00
for [email]; Wed, 28 Nov 2001 13:52:46 +0000
Received: from [89.0.0.95] by (MailGate 3.5.165) with ESMTP; Wed, 28 Nov 2001 13:53:02 +0000
Received: by warhol with Internet Mail Service (5.5.2448.0)
id ; Wed, 28 Nov 2001 13:51:07 -0000
Message-ID:
From: Vincent Penquerc'h <[email]>
To: [email]
Date: Wed, 28 Nov 2001 13:51:07 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/alternative;
boundary="----_=_NextPart_001_01C17813.BAD04AE0"
Subject: RE: [AD] Proposed changes for Allegro 5 (6?)
Precedence: bulk
Sender: conductors-[email]
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
------_=_NextPart_001_01C17813.BAD04AE0
Content-Type: text/plain;
charset="windows-1252"
> > > Message based (see SDL) (about input)
> > In addition to the current API, right ?
>
> And you need to poll ?
> Gosh ! ;-) All the complexity in the Windows port comes precisely from
> hiding the message-driven nature of the OS. I think we'd better use a
> slot/callback design.
I was saying that almost *every* existing Allegro program must be using
the current input API, so removing it will be very painful for everyone.
I'll have to update my SDL docs, the ones I have are quite dated now :)
--
Vincent Penquerc'h
------_=_NextPart_001_01C17813.BAD04AE0
Content-Type: text/html;
charset="windows-1252"
RE: [AD] Proposed changes for Allegro 5 (6?)
> > > Message based (see SDL) (about input)
> > In addition to the current API, right ?
>
> And you need to poll ?
> Gosh ! ;-) All the complexity in the Windows port comes precisely from
> hiding the message-driven nature of the OS. I think we'd better use a
> slot/callback design.
I was saying that almost *every* existing Allegro program must be using
the current input API, so removing it will be very painful for everyone.
I'll have to update my SDL docs, the ones I have are quite dated now :)
--
Vincent Penquerc'h
------_=_NextPart_001_01C17813.BAD04AE0--
From - Wed Nov 28 10:24:36 2001
X-UIDL: 17533-968516558
X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Return-Path:
Received: from VL-MS-MR001.sc1.videotron.ca ([10.23.32.71]) by
VL-MS-MS002.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNIO3T00.0QJ for <[email]>; Wed,
28 Nov 2001 10:23:53 -0500
Received: from canvaslink.com ([216.47.35.50]) by
VL-MS-MR001.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNIO3S02.X2B for <[email]>; Wed,
28 Nov 2001 10:23:52 -0500
Received: from anchor-post-32.mail.demon.net [194.217.242.90] by canvaslink.com with ESMTP
(SMTPD32-6.00) id A1BB5A9902CC; Wed, 28 Nov 2001 10:24:43 -0500
Received: from lwithers.demon.co.uk ([194.222.80.1])
by anchor-post-32.mail.demon.net with esmtp (Exim 2.12 #1)
id 1696WB-0000Yp-0W
for [email]; Wed, 28 Nov 2001 15:21:06 +0000
Message-ID: <[email]>
Date: Wed, 28 Nov 2001 15:20:03 +0000
To: [email]
From: Laurence Withers <[email]>
References: <[email]> <[email]>
In-Reply-To: <[email]>
MIME-Version: 1.0
Content-Type: multipart/signed;boundary="=_Turnpike_3HuwTWAjCQB8k$Ik=";
protocol="application/pgp-signature";micalg=pgp-sha1
X-Mailer: Turnpike Integrated Version 5.01 S
Subject: Re: [AD] Proposed changes for Allegro 5 (6?)
Precedence: bulk
Sender: conductors-[email]
This is a PGP signed message sent according to RFC2015 [PGP/MIME]
--=_Turnpike_3HuwTWAjCQB8k$Ik=
Content-Type: text/plain;charset=us-ascii
Content-Transfer-Encoding: quoted-printable
In reply to Sven Sandberg <[email]>:
>You didn't mention the gui, which I think is good. IMHO it is
>fundamentally broken by design (because it wasn't meant for anything
>else than internal purposes), and should remain so because a proper gui
>can grow unboundedly and is better done as an add-on. And also because
>redesigning it would break tons of user code.
We could try and make the GUI code smaller (ie. less features, more
sensible code, etc.) rather than replace it. It needs to stay in,
though, because we need it for tests/examples/tools (especially the
grabber, which is a fundamental part of Allegro).
Bye for now,
--=20
Laurence Withers, [email]
http://www.lwithers.demon.co.uk/
--=_Turnpike_3HuwTWAjCQB8k$Ik=
Content-Type: application/pgp-signature
Content-Disposition: attachment; filename=signature.asc
-----BEGIN PGP SIGNATURE-----
Version: PGPsdk version 1.7.1
iQA/AwUBPAUAo2brT6QxxsGNEQJtrQCcD343SIOLrKwkhNiwEeFeNfbbcWYAn1rb
SaBZJo/PfZ+sP1o31u4kLpei
=1OuB
-----END PGP SIGNATURE-----
--=_Turnpike_3HuwTWAjCQB8k$Ik=--
From - Wed Nov 28 11:14:46 2001
X-UIDL: 17536-968516558
X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Return-Path:
Received: from VL-MS-MR003.sc1.videotron.ca ([10.23.32.73]) by
VL-MS-MS002.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNIQA003.9XK for <[email]>; Wed,
28 Nov 2001 11:10:48 -0500
Received: from canvaslink.com ([216.47.35.50]) by
VL-MS-MR003.sc1.videotron.ca (Netscape Messaging Server 4.15
MR003 Jul 24 2001 16:23:26) with ESMTP id GNIQ9Z00.TIB for
<[email]>; Wed, 28 Nov 2001 11:10:47 -0500
Received: from mout02.kundenserver.de [195.20.224.133] by canvaslink.com with ESMTP
(SMTPD32-6.00) id AC525C6702CC; Wed, 28 Nov 2001 11:09:54 -0500
Received: from [195.20.224.204] (helo=mrvdom00.schlund.de)
by mout02.kundenserver.de with esmtp (Exim 2.12 #2)
id 1697E0-0003jA-00
for [email]; Wed, 28 Nov 2001 17:06:16 +0100
Received: from m425-mp1-cvx2a.ren.ntl.com ([62.252.145.169] helo=rudge)
by mrvdom00.schlund.de with smtp (Exim 2.12 #2)
id 16979E-00057S-00
for [email]; Wed, 28 Nov 2001 17:01:21 +0100
Message-ID: <009401c17825$e7de1960$a991fc3e@rudge>
Reply-To: "Owen Rudge" <[email]>
From: "Owen Rudge" <[email]>
To: <[email]>
References: <[email]>
Date: Wed, 28 Nov 2001 16:01:12 -0000
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Subject: Re: [AD] Proposed changes for Allegro 5 (6?)
Precedence: bulk
Sender: conductors-[email]
> - Drop DOS.
Please no. As Laurence said, many people still use this, such as me. :-)
> - Remove compression/encryption. This can be spun off to a new lib.
> Basic endian-safe pack functions can still be present.
I find the packfile routines very useful. Also, what would happen to
compressed datafiles? Or would there just be a little bit of code internally
for these?
Owen Rudge
http://www.owenrudge.co.uk/
MSN Messenger: [email]
ICQ: 125455765
From - Wed Nov 28 13:59:46 2001
X-UIDL: 17541-968516558
X-Mozilla-Status: 0003
X-Mozilla-Status2: 00000000
Return-Path:
Received: from VL-MS-MR003.sc1.videotron.ca ([10.23.32.73]) by
VL-MS-MS002.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNIXZ602.RTS for <[email]>; Wed,
28 Nov 2001 13:57:06 -0500
Received: from canvaslink.com ([216.47.35.50]) by
VL-MS-MR003.sc1.videotron.ca (Netscape Messaging Server 4.15
MR003 Jul 24 2001 16:23:26) with ESMTP id GNIXZ601.7Q7 for
<[email]>; Wed, 28 Nov 2001 13:57:06 -0500
Received: from smtp3.libero.it [193.70.192.53] by canvaslink.com with ESMTP
(SMTPD32-6.00) id A3B3271F03EE; Wed, 28 Nov 2001 13:57:55 -0500
Received: from eulero (151.38.220.151) by smtp3.libero.it (6.0.032)
id 3BD43E2500BB37AB for [email]; Wed, 28 Nov 2001 19:54:24 +0100
From: "Angelo Mottola" <[email]>
To: "Allegro conductors" <[email]>
Date: Wed, 28 Nov 2001 19:54:44 +0100
Message-ID: <003001c1783e$27b540a0$0201a8c0@eulero>
MIME-Version: 1.0
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-Reply-To: <[email]>
Importance: Normal
Subject: R: [AD] Proposed changes for Allegro 5 (6?)
Precedence: bulk
Sender: conductors-[email]
Ok, I've been out to my university all day and when I've returned, I
found 33 AD messages most of which about this subject, so even if a lot
has already been said, let me tell you my thoughts.
> - Switch to completely disable the Allegro mixer, and send
audiobuffers to the sound card directly. (TRAC)
Hum, I'm not a sound programming expert, but removing our software mixer
wouldn't mean to loose a lot of functionalities?
> - remove those unused sound functions (vibratto, etc)
Agreed. I guess those have been there (empty) since something like
3.0...
> - Possible merge of AllegroGL (as an OpenGL driver only, to keep it
light)
I'm all for it! By "as an OpenGL driver only" do you mean to implement
only the current AGL "direct" mode? If so I agree again as I don't see
any reasons on including the others.
> - merge blit and sprite API
I agree, but how to recognize when to draw a transparent bitmap (sprite)
or a solid one? What about using al_set(AL_BLIT, AL_BLIT_TRANS) or
al_set(AL_BLIT, AL_BLIT_SOLID)?
> - window resizing support
Is this really needed? I think it'd require so much overhead it isn't
worth it at all. Who really needs window resizing in games? Ok, Allegro
is also for general multimedia apps, but again I'm not convinced on
adding support for this...
> - is_*_bitmap collapsed to a single function - get_bitmap_type()
Sounds reasonable as it avoids making confusion with all those similar
functions. And makes the API cleaner.
> - What to do with floodfill (can't be accelerated via GL or D3D)
Some programs may need it, so I don't think removing it is a good idea.
GL and D3D could just have a slow unrecommended implementation (stated
in the docs) or not have it at all (but this would mean making floodfill
part of the gfx vtable, which isn't a bad idea at all)
> - Hooks in the polygon routines to add our own span-based sorter.
> This means that ZBuffer, SBuffer, and P3D can spun out to other
libs.
Ok about the hooks, but leave the other things as people may complain
about them if they're missing from the default lib. IMHO P3D can be
moved away as it's the most recent one and hardly anyone has used it so
far (AFAIK).
> - Make blenders work with spans (see FBlend)
Agreed =)
- Fix this whole 32bpp == int, 16bpp == short thing. Use int16_t and
int32_t instead?
In Allegro tradition all types and structures should be uppercase, so I
propose INT16, INT32 and such. Just thought someone had to say this ;)
> - textout should not use -1 for colored fonts.
Again al_set(AL_FONT, AL_FONT_MONO) and al_set(AL_FONT, AL_FONT_COLORED)
come to my mind... Or simply the textout function could recognize the
colored font and use the proper drawing function, discarding the color
value passed to textout.
> Input:
> - Message based (see SDL)
The callbacks suggested by Eric sound also interesting. Could you
elaborate more?
> - Remove compression/encryption. This can be spun off to a new lib.
> Basic endian-safe pack functions can still be present.
> - Allow registering of new compression and encryption libs.
I'm against removing the compression support, as I find it nice and
useful. But having hooks to define new compression routines seems a
great idea - zlib comes to mind
> Network:
> - Can we get one? Please? :)
It would be really nice to have libnet integrated into Allegro. But I
can understand many of you will disagree for a lot of good reasons.
Nonetheless I like the idea. And what about adding a generalized
framework of network functions, that could be used to hook on other
packages? Libnet could be just one of the possibilities (and here I'm
talking about the nth vtable to Allegro)
> - Configuration via an OpenGL-like al_set(variable, value) system
> - prefixing of the API
Agreed on both. Al_set() could be a really powerful tool, and it would
also give a nice side-effect: in some cases adding new features will
just mean adding more variables/values, without overbloating (tm) the
API with more dedicated functions.
> - Move as much as possible to Vtables
This seems inevitable to me.
> - Drop DOS.
Psss! A hint: don't propose this once again, or someday you'll find
hordes of angry people knocking at your door!
> Documentation:
> - Generated from source via Doxygen or Javadoc (see AllegroGL for
example)
Here I agree on what Sven said: the _tx format should be kept.
> Stuff to remove (can be placed in add-ons)
> - FLI playback code
> - Software 3D code
> - 3D Math
> - Fixed point math
> - Compiled sprites and RLE
Ok for FLI and compiled sprites, but keep the rest. Dunno about the 3d
math, but if kept it should be possibly modified to be compatible with
OpenGL (see matrices).
--
Angelo Mottola
[email]
http://www.ecplusplus.com
From - Wed Nov 28 14:29:46 2001
X-UIDL: 17542-968516558
X-Mozilla-Status: 0013
X-Mozilla-Status2: 00000000
Return-Path:
Received: from VL-MS-MR002.sc1.videotron.ca ([10.23.32.72]) by
VL-MS-MS002.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNIZHL01.T0U for <[email]>; Wed,
28 Nov 2001 14:29:45 -0500
Received: from canvaslink.com ([216.47.35.50]) by
VL-MS-MR002.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNIZHK01.APL for <[email]>; Wed,
28 Nov 2001 14:29:44 -0500
Received: from fruitmachine.brighton.climax.co.uk [212.74.3.86] by canvaslink.com with ESMTP
(SMTPD32-6.00) id AAA0285003EE; Wed, 28 Nov 2001 14:27:28 -0500
Received: by FRUITMACHINE with Internet Mail Service (5.5.2653.19)
id ; Wed, 28 Nov 2001 19:23:54 -0000
Message-ID: <28A7C352840AD511AC9400508BE70AC24FFDB3@FRUITMACHINE>
From: Shawn Hargreaves <[email]>
To: 'Angelo Mottola' <[email]>, Allegro conductors
<[email]>
Date: Wed, 28 Nov 2001 19:23:53 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
boundary="----_=_NextPart_001_01C17842.37734380"
Subject: RE: [AD] Proposed changes for Allegro 5 (6?)
Precedence: bulk
Sender: conductors-[email]
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
------_=_NextPart_001_01C17842.37734380
Content-Type: text/plain;
charset="iso-8859-1"
Angelo Mottola writes:
> > - Switch to completely disable the Allegro mixer, and send
> audiobuffers to the sound card directly. (TRAC)
>
> Hum, I'm not a sound programming expert, but removing our
> software mixer wouldn't mean to loose a lot of functionalities?
It would make it much harder to write drivers for devices that
can't do good mixing themselves (eg. most of the DOS and Unix
sound drivers). The mixer isn't a requirement, just a set of
helper functions that drivers can use if it makes their job
easier. Allegro never talks straight to the mixer code: the
framework tells the driver what to do, and then some drivers
can choose to pass some of those requests onto the software
mixer. What's the problem with that? And if you lose the mixer,
how do you write drivers for devices that can't do mixing
themselves?
> > - merge blit and sprite API
>
> I agree, but how to recognize when to draw a transparent
> bitmap (sprite) or a solid one? What about using al_set(AL_BLIT,
> AL_BLIT_TRANS) or al_set(AL_BLIT, AL_BLIT_SOLID)?
My general advice is to avoid putting this kind of persistent
state into the API. Or if you are going to do it, do it totally
(like OpenGL) so that every single operation is split up into
many very small single-parameter function calls. Allegro isn't
really built like that, though, so I think it is better to avoid
having state at all. Pass parameters to functions to tell them
what to do, or if it is such a commonly used routine that this
will be a pain, split it into a family of related functions.
My experience has been that every time I did put in something
with persistent state (the text_mode() function being a prime
example), it caused problems and confusion down the road, and
I ended up wishing I hadn't done that (eg. it would be better
if the background color was always passed to text drawing
routines along with the foreground).
Persistent state causes particular problems for addon packages,
but also when other parts of the lib may need to change it
(eg. calling alert() alters some settings that the programmer
may not expect to have changed - it is loads of hassle and
housekeeping if alert() needs to track that and put the values
back when it is done!)
> > - Configuration via an OpenGL-like al_set(variable, value) system
> > - prefixing of the API
>
> Agreed on both. Al_set() could be a really powerful tool, and it would
> also give a nice side-effect: in some cases adding new features will
> just mean adding more variables/values, without overbloating (tm) the
> API with more dedicated functions.
The config routines can already do this, and were intended to support
exactly this kind of runtime setup. They could do with a nicer API
for setting multiple values on the fly, though, and maybe better docs
explaining how you can use them for such things (a _lot_ of the drivers
have settings that can be tweaked at runtime by programs using the
config override routines).
> Ok for FLI and compiled sprites, but keep the rest. Dunno about the 3d
> math, but if kept it should be possibly modified to be compatible with
> OpenGL (see matrices).
That's a tough one because whichever way around you put it, it will
be wrong for one of D3D or OpenGL. I don't think this is much of
a problem, though, as it is trivial to write a "set my X format matrix
to API that uses Y format" wrapper, and this doesn't happen often
enough for flipping the row/axis order to be a measurable performance
hit.
--
Shawn
------_=_NextPart_001_01C17842.37734380
Content-Type: text/html;
charset="iso-8859-1"
RE: [AD] Proposed changes for Allegro 5 (6?)
Angelo Mottola writes:
> > - Switch to completely disable the Allegro mixer, and send
> audiobuffers to the sound card directly. (TRAC)
>
> Hum, I'm not a sound programming expert, but removing our
> software mixer wouldn't mean to loose a lot of functionalities?
It would make it much harder to write drivers for devices that
can't do good mixing themselves (eg. most of the DOS and Unix
sound drivers). The mixer isn't a requirement, just a set of
helper functions that drivers can use if it makes their job
easier. Allegro never talks straight to the mixer code: the
framework tells the driver what to do, and then some drivers
can choose to pass some of those requests onto the software
mixer. What's the problem with that? And if you lose the mixer,
how do you write drivers for devices that can't do mixing
themselves?
> > - merge blit and sprite API
>
> I agree, but how to recognize when to draw a transparent
> bitmap (sprite) or a solid one? What about using al_set(AL_BLIT,
> AL_BLIT_TRANS) or al_set(AL_BLIT, AL_BLIT_SOLID)?
My general advice is to avoid putting this kind of persistent
state into the API. Or if you are going to do it, do it totally
(like OpenGL) so that every single operation is split up into
many very small single-parameter function calls. Allegro isn't
really built like that, though, so I think it is better to avoid
having state at all. Pass parameters to functions to tell them
what to do, or if it is such a commonly used routine that this
will be a pain, split it into a family of related functions.
My experience has been that every time I did put in something
with persistent state (the text_mode() function being a prime
example), it caused problems and confusion down the road, and
I ended up wishing I hadn't done that (eg. it would be better
if the background color was always passed to text drawing
routines along with the foreground).
Persistent state causes particular problems for addon packages,
but also when other parts of the lib may need to change it
(eg. calling alert() alters some settings that the programmer
may not expect to have changed - it is loads of hassle and
housekeeping if alert() needs to track that and put the values
back when it is done!)
> > - Configuration via an OpenGL-like al_set(variable, value) system
> > - prefixing of the API
>
> Agreed on both. Al_set() could be a really powerful tool, and it would
> also give a nice side-effect: in some cases adding new features will
> just mean adding more variables/values, without overbloating (tm) the
> API with more dedicated functions.
The config routines can already do this, and were intended to support
exactly this kind of runtime setup. They could do with a nicer API
for setting multiple values on the fly, though, and maybe better docs
explaining how you can use them for such things (a _lot_ of the drivers
have settings that can be tweaked at runtime by programs using the
config override routines).
> Ok for FLI and compiled sprites, but keep the rest. Dunno about the 3d
> math, but if kept it should be possibly modified to be compatible with
> OpenGL (see matrices).
That's a tough one because whichever way around you put it, it will
be wrong for one of D3D or OpenGL. I don't think this is much of
a problem, though, as it is trivial to write a "set my X format matrix
to API that uses Y format" wrapper, and this doesn't happen often
enough for flipping the row/axis order to be a measurable performance
hit.
--
Shawn
------_=_NextPart_001_01C17842.37734380--
From - Wed Nov 28 16:14:47 2001
X-UIDL: 17545-968516558
X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Return-Path:
Received: from VL-MS-MR003.sc1.videotron.ca ([10.23.32.73]) by
VL-MS-MS002.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNJ48Q00.JZA for <[email]>; Wed,
28 Nov 2001 16:12:26 -0500
Received: from canvaslink.com ([216.47.35.50]) by
VL-MS-MR003.sc1.videotron.ca (Netscape Messaging Server 4.15
MR003 Jul 24 2001 16:23:26) with ESMTP id GNJ48P01.E3P for
<[email]>; Wed, 28 Nov 2001 16:12:25 -0500
Received: from mail.libertysurf.net [213.36.80.91] by canvaslink.com with ESMTP
(SMTPD32-6.00) id A35C4AB5035E; Wed, 28 Nov 2001 16:13:00 -0500
Received: from zephyr (213.36.120.43) by mail.libertysurf.net (5.1.053)
id 3C05241E000096BA for [email]; Wed, 28 Nov 2001 22:09:31 +0100
Message-ID: <00a601c17851$28e27b60$747824d5@zephyr>
From: "Eric Botcazou" <[email]>
To: "Allegro conductors" <[email]>
References: <003001c1783e$27b540a0$0201a8c0@eulero>
Date: Wed, 28 Nov 2001 22:08:44 +0100
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2014.211
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211
Subject: Re: [AD] Proposed changes for Allegro 5 (6?)
Precedence: bulk
Sender: conductors-[email]
> > - window resizing support
>
> Is this really needed? I think it'd require so much overhead it isn't
> worth it at all. Who really needs window resizing in games? Ok, Allegro
> is also for general multimedia apps, but again I'm not convinced on
> adding support for this...
And I'm already scared by simply thinking of resizing a DirectDraw overlay
surface with two backbuffers attached to it !
> > - Message based (see SDL)
>
> The callbacks suggested by Eric sound also interesting. Could you
> elaborate more?
I don't know if the 'you' is for Bob or me or both. Either way, I'm
elaborating: part of the elegance of Allegro is that you don't have to
bother writing a message loop in order to make the most tiny program work
and appropriately respond to the flood of messages the OS sends.
A dedicated background framework is in place to do that (threads on most
platforms) and does the hard work for you. Then, when you want to get some
input, you either simply read some shared variables the threads have cooked
for you (mouse_x, mouse_y, key[]) or you use a communication channel like
readkey().
Within this framework, the most straightforward way to implement
asynchronous events is the slot/callback mechanism: you register a callback
function for each event you want to be informed of.
Allegro already sort of implements this mechanism via:
extern int (*keyboard_callback)(int key);
extern void (*keyboard_lowlevel_callback)(int scancode);
extern void (*mouse_callback)(int flags);
int set_display_switch_callback(int dir, void (*cb)());
We could devise an unified slot/callback API: providing a list of events
with one or more slots attached to each, in order to let the programmer
register its callback functions. Of course this would require the
synchronization API we have been talking about for months.
--
Eric Botcazou
[email]
From - Wed Nov 28 18:39:46 2001
X-UIDL: 17556-968516558
X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Return-Path:
Received: from VL-MS-MR001.sc1.videotron.ca ([10.23.32.71]) by
VL-MS-MS002.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNJAXV00.Y8O for <[email]>; Wed,
28 Nov 2001 18:37:07 -0500
Received: from canvaslink.com ([216.47.35.50]) by
VL-MS-MR001.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNJAXQ04.0QB for <[email]>; Wed,
28 Nov 2001 18:37:02 -0500
Received: from VL-MS-MR004.sc1.videotron.ca [24.201.245.36] by canvaslink.com with ESMTP
(SMTPD32-6.00) id A51B67B302CC; Wed, 28 Nov 2001 18:36:59 -0500
Received: from videotron.ca ([24.202.201.127]) by
VL-MS-MR004.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNJAR804.DMS for <[email]>; Wed,
28 Nov 2001 18:33:08 -0500
Message-ID: <[email]>
Date: Wed, 28 Nov 2001 18:33:04 -0500
From: Bob <[email]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.6) Gecko/20011120
X-Accept-Language: en-us
MIME-Version: 1.0
To: [email]
References: <[email]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [AD] Proposed changes for Allegro 5 (6?)
Precedence: bulk
Sender: conductors-[email]
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/
From - Wed Nov 28 18:44:46 2001
X-UIDL: 17557-968516558
X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Return-Path:
Received: from VL-MS-MR004.sc1.videotron.ca ([10.23.32.74]) by
VL-MS-MS002.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNJB3B02.QXC for <[email]>; Wed,
28 Nov 2001 18:40:23 -0500
Received: from canvaslink.com ([216.47.35.50]) by
VL-MS-MR004.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNJB3701.YP1 for <[email]>; Wed,
28 Nov 2001 18:40:19 -0500
Received: from VL-MS-MR002.sc1.videotron.ca [24.201.245.36] by canvaslink.com with ESMTP
(SMTPD32-6.00) id A638686B02CC; Wed, 28 Nov 2001 18:41:44 -0500
Received: from videotron.ca ([24.202.201.127]) by
VL-MS-MR002.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNJAZQ04.I3L for <[email]>; Wed,
28 Nov 2001 18:38:14 -0500
Message-ID: <[email]>
Date: Wed, 28 Nov 2001 18:38:10 -0500
From: Bob <[email]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.6) Gecko/20011120
X-Accept-Language: en-us
MIME-Version: 1.0
To: [email]
References:
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [AD] Proposed changes for Allegro 5 (6?)
Precedence: bulk
Sender: conductors-[email]
Stepan Roh wrote:
>
> On Tue, 27 Nov 2001, Bob wrote:
>
>
>>http://pages.infinit.net/voidstar/newalleg.txt
>>
>
> Splitting packfiles handling to compression/encryption layers is good, but
> removing default implementation is bad, bad, bad :-) Why?
I just thought about lightening the lib. There's no reason really, and I'm
not advocating it. I just thought I'd bring it up incase someone else would
argument for it :)
> Adding networking is not good thing, I think. Too much new code without
> any connection to current Allegro.
The current Allegro has nearly no connection to Allegro 3.0 appart from most
of the external API. Why is networking any different?
> Allegro 5 should have cleaner and consistent API with better decomposition
> to modules (unicode handling, gfx, sound, input, packfiles, etc.). This
> should be the main goal. And, of course, cleaning up the sources a bit.
Agreed.
>
> Generated API docs is very good idea, but forget Javadoc. It's too
> Java-centric and too slow.
Doxygen? They use the same syntax (AFAIK), so we could just document the
code like this:
/** Draws a bitmap. (insert blit() docs)
*
* \param source The source bitmap
* \param dest The destination bitmap
* (and so on)
*
* \sa draw_sprite masked_blit stretch_blit
*/
void blit(...) {
}
Then docs are in the sources, get updates with the sources, and get generated from the sources.
Docs get generated in html, latex, rich text, and some other formats I can't remember.
--
- Robert J Ohannessian
"Microsoft code is probably O(n^20)" (my CS prof)
http://pages.infinit.net/voidstar/
From - Wed Nov 28 18:59:46 2001
X-UIDL: 17558-968516558
X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Return-Path:
Received: from VL-MS-MR002.sc1.videotron.ca ([10.23.32.72]) by
VL-MS-MS002.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNJBTJ02.B7H for <[email]>; Wed,
28 Nov 2001 18:56:07 -0500
Received: from canvaslink.com ([216.47.35.50]) by
VL-MS-MR002.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNJBTH02.L1H for <[email]>; Wed,
28 Nov 2001 18:56:05 -0500
Received: from smtp2.libero.it [193.70.192.52] by canvaslink.com with ESMTP
(SMTPD32-6.00) id A9EC697A02CC; Wed, 28 Nov 2001 18:57:32 -0500
Received: from lano (151.28.34.162) by smtp2.libero.it (6.0.032)
id 3BEFF161005D342E for [email]; Thu, 29 Nov 2001 00:53:58 +0100
Date: Thu, 29 Nov 2001 00:41:52 +0100
From: Lo'oRiS il Kabukimono <[email]>
To: [email]
Message-Id: <[email]>
In-Reply-To: <[email]>
References: <[email]>
<[email]>
X-Mailer: Sylpheed version 0.6.5 (GTK+ 1.2.9; i586-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Subject: Re: [AD] Proposed changes for Allegro 5 (6?)
Precedence: bulk
Sender: conductors-[email]
> > - 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?
IMVHO i think that this is a *very* good point of view.
^^ ^^ ^^ :)
"Americans need the telephone, but we don't. We have enough mailmen."
Sir William Preece, head engeneer of the British Mail, 1876
_.-:/°^^°\:-._.-:/°^^°\:-._ __. ____
- Lo'oRiS il Kabukimono - / /| /^___ \
Real Name: Lorenzo Petrone / / / / /L_/ /
e-mail: [email] / / / / ___-°/
irc.azzurra.org #lano / /_/__ / /|__-°
digilander.iol.it/lano666 /______/| /__/ /
^°\:-.__.-:/°^°\:-.__.-:/°^ |______|/ |__L/
From - Wed Nov 28 19:09:46 2001
X-UIDL: 17559-968516558
X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Return-Path:
Received: from VL-MS-MR004.sc1.videotron.ca ([10.23.32.74]) by
VL-MS-MS002.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNJC8Z05.I89 for <[email]>; Wed,
28 Nov 2001 19:05:23 -0500
Received: from canvaslink.com ([216.47.35.50]) by
VL-MS-MR004.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNJC8V01.CPX for <[email]>; Wed,
28 Nov 2001 19:05:19 -0500
Received: from VL-MS-MR002.sc1.videotron.ca [24.201.245.36] by canvaslink.com with ESMTP
(SMTPD32-6.00) id ABAC69D502CC; Wed, 28 Nov 2001 19:05:00 -0500
Received: from videotron.ca ([24.202.201.127]) by
VL-MS-MR002.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNJC2A02.JZC for <[email]>; Wed,
28 Nov 2001 19:01:22 -0500
Message-ID: <[email]>
Date: Wed, 28 Nov 2001 19:01:18 -0500
From: Bob <[email]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.6) Gecko/20011120
X-Accept-Language: en-us
MIME-Version: 1.0
To: [email]
References: <[email]> <[email]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [AD] Proposed changes for Allegro 5 (6?)
Precedence: bulk
Sender: conductors-[email]
Sven Sandberg wrote:
[snip]
> - `bmp_read8()' & co currently use longs instead of pointers. I think
> this is an old djgpp-ism, because `_farnspokew()' take longs as
> arguments. If someone knows a good reason why it must be this way,
> please say it. Otherwise, can we please replace `unsigned long' by
> `unsigned char *', `unsigned short *', and `unsigned long *'? It scares
> me a bit because there's no reason to think that
> sizeof(long)==sizeof(void*) on all platforms, plus there's apparently no
> reason to store a pointer in a long.
Good idea. I'll add it to the list.
[snip]
>> - Possible merge of AllegroGL (as an OpenGL driver only, to keep it
>>
>
> Why can't it be in AllegroGL?
Well for one thing, it makes porting Allegro a lot easier. Many more
platforms have OpenGL support than they have SVGAlib support (for one
thing). So if I wanted to port Allegro to (let's say) the Playstation, I
almost don't have to worry about the graphics. GL is also accelerated on
just about every platform, so it's an added bonus.
>> - merge blit and sprite API
>>
>
> What do you mean? This sounds like "remove `draw_sprite()' and add an
> extra parameter to `blit()' indicating whether transparent pixels should
> be masked out",
You mean like masked_blit()? :DD
I mean that draw_sprite is equivalent to masked_blit already, but it less
flexible. I *think* they both use the same code (minus the extra clipping),
so I don't see why it wouldn't be done.
[snip]
>
>
>> - is_*_bitmap collapsed to a single function - get_bitmap_type()
>>
>
> Why? I think the bit field that such a function would have to return
> would be a bit complicated, and some of those functions are very
> different from each other.
Yes, but it makes it nicer for the assembly code to figure out if a bitmap
is a memory linear bitmap so that it can do some things which may not be
permitted on other bitmap types. Hahving it return a testable constant is
nice. We'd also get rid of the function entry points to is_*_bitmap. There
are 7 of them, and I don't see any users using them appart for some add-ons
which do specific things on those bitmaps.
>> - Dump draw_character
>>
>
> Why? It needs to be in the library because we need to draw text, so it
> doesn't hurt to have it in the API, right?
Oh I see. I wasn't aware of it being used by the text code. It just didn't
seem that useful when reading back the description of the function :)
>
>
>> - Unified rotate_flip_pivot_stretch routine
>>
>
> There is already one: `_pivot_scaled_sprite_flip()' in aintern.h
Yep, so make this one public, then remove some of the other ones.
pivot_sprite and rotate_sprite could be kept as shortcuts to the
pivot_scaled_flip_sprite, but the others just bloat the API IMO.
>> - hsv_to_rgb and rgb_to_hsv in a separate lib
>> - Remove not-so-useful blenders (dissolve, dodge, hue, invert,
>>luminance, multiply, saturation, screen)
>>
>
> Why? They are all small and can't hurt much?
There are a lot of small things which can't hurt much which will make
Allegro be crushed under its own weight :)
hsv_to_rgb is somewhat useful, but I really don't see the others ever being
used at all.
>
>
>> - Fix this whole 32bpp == int, 16bpp == short thing. Use int16_t and
>>int32_t instead?
>>
>
> Why? I think this would break too much code, both in Allegro and in
> user's code. Btw, 32bpp == long, not int.
So on 64 bit machines, 32bpp bitmaps waste twice the memory and memory
bandwidth - just great :)
I'd rather have them as type INT32, where INT32 can be defined as whatever
fits 32 bits in the current machine.
>
>
>> - true color fade in/out (Nathan)
>>
>
> Yes, this is probably such a frequent faq that it is worth implementing.
I was planning on adding those to FBlend, so the code can be merged in at
some later point :)
>
>
>>Text Drawing:
>> - textout should not use -1 for colored fonts.
>>
>
> Why? What else?
AllegroGL - makeacol(255, 255, 255, 255) is a perfectly valid color for a
font (which with no alpha blending), but gets interpreted by Allegro as
"Draw colored fonts". I'd rather have text_out split into two functions, or
at lesat have something like text_mode() but for enabling/disabling colored
fonts.
>
>
>>Packfiles:
>> - Allow registering of new compression and encryption libs.
>>
>
> Good idea, but nothing we need to wait for if nobody writes it.
I thought Peter Wang had already written it, but it was left as a patch on
Allegro.
>
>
>> - save_datafile() and save_datafile_object() (Nathan Smith)
>>
>
> I think these already exist in libaldat.a.
Yes, but it would be nice to have those in the main library, or at least
documented as being in aldat.
[snip]
>> - Move as much as possible to VTables
>>
>
> Any specific ideas on which functions this should include?
I did say everything :) polygon2d/3d (and family), and perhaps the Allegro
mixer.
>> - Drop DOS.
>>
>
> No, please! There are so many people who use djgpp, and there are no
> problems with that port.
Then they can use Allegro 4.0 :)
Or switch to Mingw (see previous post).
[snip]
>>Documentation:
>> - Generated from source via Doxygen or Javadoc
>>
>
> Why? _tx files work perfectly, can generate more file formats than
> anything else, and are self-contained, i.e. no need for user to download
> another package with the help compiler. And some add-ons actually use
> makedoc.
Documentation can be generated by one of the devs when making releases.
Also, it will help keep the docs in sync with the code.
[snip]
>> - Software 3D code
>> - 3D Math
>>
>
> I think these are too widely used to be removed.
Appart from some of the *Hack entries, I really don't see them being used at
all. Really. The 3d math one would most probably do better as a separate
package, and gain extra functionality. The software 3d is too slow to be of
any real use, and is still more complicated to use than OpenGL (IMHO).
[snip]
--
- Robert J Ohannessian
"Microsoft code is probably O(n^20)" (my CS prof)
http://pages.infinit.net/voidstar/
From - Wed Nov 28 19:09:46 2001
X-UIDL: 17560-968516558
X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Return-Path:
Received: from VL-MS-MR001.sc1.videotron.ca ([10.23.32.71]) by
VL-MS-MS002.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNJCDO02.J97 for <[email]>; Wed,
28 Nov 2001 19:08:12 -0500
Received: from canvaslink.com ([216.47.35.50]) by
VL-MS-MR001.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNJCDM00.1UJ for <[email]>; Wed,
28 Nov 2001 19:08:10 -0500
Received: from VL-MS-MR004.sc1.videotron.ca [24.201.245.36] by canvaslink.com with ESMTP
(SMTPD32-6.00) id AC9122B00396; Wed, 28 Nov 2001 19:08:49 -0500
Received: from videotron.ca ([24.202.201.127]) by
VL-MS-MR004.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNJC8T00.PQS for <[email]>; Wed,
28 Nov 2001 19:05:17 -0500
Message-ID: <[email]>
Date: Wed, 28 Nov 2001 19:05:13 -0500
From: Bob <[email]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.6) Gecko/20011120
X-Accept-Language: en-us
MIME-Version: 1.0
To: [email]
References: <28A7C352840AD511AC9400508BE70AC24FFDA3@FRUITMACHINE>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [AD] Proposed changes for Allegro 5 (6?)
Precedence: bulk
Sender: conductors-[email]
Shawn Hargreaves wrote:
> Sven Sandberg writes:
> > - `bmp_read8()' & co currently use longs instead of pointers. I think
> > this is an old djgpp-ism, because `_farnspokew()' take longs as
> > arguments. If someone knows a good reason why it must be this way,
> > please say it. Otherwise, can we please replace `unsigned long' by
> > `unsigned char *', `unsigned short *', and `unsigned long *'?
>
> The thinking behind using longs is that this makes the pointers
> opaque, ie. can't be dereferenced directly by the user, so
> people are forced to always access them with the bmp_read*()
> macros. If they were pointers, it would be easy to accidentally
> write *ptr, which would work on some platforms but fail on
> others.
Those functions are of the fairly advanced level, so I don't see users who
haven't understood pointers use them :)
If they write *ptr instead of ptr, then it's a bug in the user's program,
not Allegro.
It's also bad for portability. I32P64 x86 chips are due out very soon, and
Allegro will be broken at that point. Better to fix it now, then having
Allegro not run on half the world's computers in a few years :)
[snip]
--
- Robert J Ohannessian
"Microsoft code is probably O(n^20)" (my CS prof)
http://pages.infinit.net/voidstar/
From - Wed Nov 28 19:14:46 2001
X-UIDL: 17561-968516558
X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Return-Path:
Received: from VL-MS-MR003.sc1.videotron.ca ([10.23.32.73]) by
VL-MS-MS002.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNJCO301.K5P for <[email]>; Wed,
28 Nov 2001 19:14:27 -0500
Received: from canvaslink.com ([216.47.35.50]) by
VL-MS-MR003.sc1.videotron.ca (Netscape Messaging Server 4.15
MR003 Jul 24 2001 16:23:26) with ESMTP id GNJCO001.UEV for
<[email]>; Wed, 28 Nov 2001 19:14:24 -0500
Received: from hotmail.com [64.4.14.206] by canvaslink.com with ESMTP
(SMTPD32-6.00) id AE3B23670396; Wed, 28 Nov 2001 19:15:55 -0500
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
Wed, 28 Nov 2001 16:12:26 -0800
X-Originating-IP: [62.83.96.14]
From: =?iso-8859-1?Q?Javier_Gonz=E1lez?= <[email]>
To: "Allegro Conductors" <[email]>
References: <[email]> <[email]>
Date: Thu, 29 Nov 2001 01:15:30 +0100
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Message-ID: <[email]>
X-OriginalArrivalTime: 29 Nov 2001 00:12:26.0419 (UTC) FILETIME=[86A94030:01C1786A]
Subject: Re: [AD] Proposed changes for Allegro 5 (6?)
Precedence: bulk
Sender: conductors-[email]
> There's a Font add-on? Well, regarding Shawn's post, it should perhaps be
> documented more clearly how to save or load fonts.
At least I made one, AllegroFont =)
http://sunsite.dk/allegro/files/alfont.zip
> 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 ;)
I must agree with this... either if we want or not DOS will be totally dead
in say from 6 months to 1 year max
BTW, why dont we change our mode of work with files?
Right now, load_bitmap, load_sample etc etc *only* work with files and data
files, wich is a shame, because if we could load them from memory (say
somebody
makes his own datafile propietary format (not everybody likes to use allegro
datafiles =) but wants to be able to load them from its own datafiles (from
memory)
we could make somthing like making packfiles able to read from a memory
buffer (a la c++ stringstream)
Btw, about the name, packfiles... could we name it something like
AllegroFiles
or AllegroBuffers?...
Well, there is my proposal
Also I see event based system a lot better than callbacks system, because
say you change from the main menu to the game itself
you would have to uncallback everything from the menu part and callback the
game part... which is just easier to change to another event processing
function
My 2 cents, if you like them feel able to add them to the list (and hope
somebody adds all those ideas before they get lost) =)
It would be wonderful to make Allegro 5.0 the API we all would like without
caring about old compatibility, wouldnt it? =)
Oh yes, in Allegro 5.0 we *need* 3D
3D is *now*, so we need to support OpenGL at least (or at least behave
nicely, which if we use an event based system i bet would be a lot easier
todo)
Also, IMHO, we should forget DirectX3... it has been a while... ;)
From - Wed Nov 28 19:19:50 2001
X-UIDL: 17562-968516558
X-Mozilla-Status: 0013
X-Mozilla-Status2: 00000000
Return-Path: <[email]>
Received: from VL-MS-MR004.sc1.videotron.ca ([10.23.32.74]) by
VL-MS-MS002.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNJCOQ03.Y5M for <[email]>; Wed,
28 Nov 2001 19:14:50 -0500
Received: from mail12.bigmailbox.com ([209.132.220.43]) by
VL-MS-MR004.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNJCOP00.5SQ for <[email]>; Wed,
28 Nov 2001 19:14:49 -0500
Received: (from www@localhost)
by mail12.bigmailbox.com (8.10.0/8.10.0) id fAT0Ekp13748;
Wed, 28 Nov 2001 16:14:46 -0800
Date: Wed, 28 Nov 2001 16:14:46 -0800
Message-Id: <[email]>
Content-Type: text/plain
Content-Disposition: inline
Content-Transfer-Encoding: binary
X-Mailer: MIME-tools 4.104 (Entity 4.116)
Mime-Version: 1.0
X-Originating-Ip: [213.51.194.171]
From: "Doug Eleveld" <[email]>
To: [email]
Cc: [email]
Subject: RE: Re: [AD] Proposed changes for Allegro 5 (6?)
>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.
Just a thought that if you combine all these load* functions into one, that code to read in all the possible types gets included in your executable, even if it can never been used. A good example of this is jpeg reading. Jpeg decoding is quite a bit of code and including it in load_bitmap will make load_bitmap a very big function.
Please still give access to the load* functions, then the user can decide whether they want the bloat or not. Forcing them to use a load_bitmap function does not give them any choice but to include code in their executable that cannot be run.
I think that this is actually a hard problem to make very transparent to the user. The only thing I see working well is some kind of registering function or macros. The users have to explicitly choose what decoding functions they want in the executable, but at least they are not forced to include useless code.
Allegro executables are big enough. Lets try not to make them any bigger.
Doug
------------------------------------------------------------
--== Sent via Deja.com ==--
http://www.deja.com/
From - Wed Nov 28 19:29:46 2001
X-UIDL: 17566-968516558
X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Return-Path:
Received: from VL-MS-MR002.sc1.videotron.ca ([10.23.32.72]) by
VL-MS-MS002.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNJD7L00.6EW for <[email]>; Wed,
28 Nov 2001 19:26:09 -0500
Received: from canvaslink.com ([216.47.35.50]) by
VL-MS-MR002.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNJD7K04.Y3A for <[email]>; Wed,
28 Nov 2001 19:26:08 -0500
Received: from VL-MS-MR001.sc1.videotron.ca [24.201.245.36] by canvaslink.com with ESMTP
(SMTPD32-6.00) id A0C94C2F035E; Wed, 28 Nov 2001 19:26:49 -0500
Received: from videotron.ca ([24.202.201.127]) by
VL-MS-MR001.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNJD2S04.VV8 for <[email]>; Wed,
28 Nov 2001 19:23:16 -0500
Message-ID: <[email]>
Date: Wed, 28 Nov 2001 19:23:12 -0500
From: Bob <[email]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.6) Gecko/20011120
X-Accept-Language: en-us
MIME-Version: 1.0
To: [email]
References:
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [AD] Proposed changes for Allegro 5 (6?)
Precedence: bulk
Sender: conductors-[email]
Vincent Penquerc'h wrote:
> Hi,
>
> my humble opinion about these:
>
> > merge blit and sprite API
> Could you be more specific about what to change ? without losing speed.
AFAIK both draw_sprite and masked_blit use the same backend code.
masked_blit just does some extra clipping, so unless you blit loads of 4x4
images, they should be of the same speed.
I was also thinking of merding draw_rle_sprite into masked_blit() for
example, so that users can switch formats at run time depending on platform,
etc. It also means that if they want to try out RLE bitmaps in their
programs, they can just insert a convert_to_rle call somewhere, and have
everything else work automagically.
> > is_*_bitmap collapsed to a single function - get_bitmap_type()
> You could have a subbitmap of a video bitmap (I think), so a bitmap
> could have more than one type
Subbitmaps and planar bitmaps are probably the only type of bitmaps that can
have mixed types. Bit flags anyone?
>
> > What to do with floodfill (can't be accelerated via GL or D3D)
> And then ? That is not a reason to remove it I think :)
I guess not. As someone else said, it could be documetned as "horribly slow
when using OpenGL or D3D drivers" or something like that.
>
> > Collapse load_* into one function load_bitmap(), smart enough to read
> > the file header to determine the format.
> There is no such thing: TGA has no header, PCX has a riducully small one,
so TGA is a raw format? doubtful.
A quick search on wotsit revealed that TGAs have their headers at the *end*
of the file. An analysis of the beginning of the file for consistency) can
also help in determining the file type. The same type of consistency check
can be done on PCX files.
[snip]>
> > Speed ups in the asm code
> I remember Shawn saying that the lit and trans routines were faster in
> C than in asm :)
FBlend is here to remedy that :D
>
> > Message based (see SDL) (about input)
> In addition to the current API, right ?
Haven't formed an opinion on that yet.
[snip]
> > Configuration via an OpenGL-like al_set(variable, value) system
> I'm not too hapy about that. That's... well, odd. You lose type safety.
> And the code is a big switch. Not appealing.
But most types in Allegro are ints anyway :)
It'll also allow us to add many more attributes without having to break the
API every time, or resort to adding new functions (like text_mode).
> > Some of the little used variables converted to string
> Making them more difficult to use ?
They aren't used anyway :)
At least we can make them more flexible, like cpu_*.
> > Drop DOS
> No comment :)
> Ah yes, one: why remove it while it's working fine ????
> It could be possible to not implement stuff that it doesn't support
> though, like switch in/out callbacks setters (they nop on DOS).
> This allows other stuff to be added while keeping DOS compatibility.
See other posts - we gain extra functionality without having to drag a
deadweight around. Also, DOS people can still use Allegro 4. They could also
migrate to Mingw (or Linux) without too much trouble.
>
> > Have a Windows installer built from a script (PIMP?)
> Huh ????? :)
The Winamp people have made a nice scriptable install program maker thingie
availble for free. You write a script, and feed it to Pimp (like makefiles),
and Pimp builds an executable installer for Windows out of it. If you drop
by IRC some day, and log a day's conversation, you'll find at least two or
three people having difficulty installing the Windows version of Allegro.
Either due to a problem in the binary package, or a compiler
misconfiguration, or just Windows being a b!tch.
[snip]
> On a general way, I'd like to point out the obvious: moving stuff into
> addons means that they're far more likely to rot. So moving stuff into
> addons should be weighed carefully.
They could be made "official addons" or something, and directly linked from
alleg.sf.net. Also, since a lot of those things that should be spinned off
don't use platform specific code, it would make fixing them trivial really.
[snip]
> Anyway, that's a nice list, thanks for taking the time of doing it :)
Hey, no problem :)
--
- Robert J Ohannessian
"Microsoft code is probably O(n^20)" (my CS prof)
http://pages.infinit.net/voidstar/
From - Wed Nov 28 19:29:46 2001
X-UIDL: 17567-968516558
X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Return-Path:
Received: from VL-MS-MR001.sc1.videotron.ca ([10.23.32.71]) by
VL-MS-MS002.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNJDBV00.XBD for <[email]>; Wed,
28 Nov 2001 19:28:43 -0500
Received: from canvaslink.com ([216.47.35.50]) by
VL-MS-MR001.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNJDBS04.2Q1 for <[email]>; Wed,
28 Nov 2001 19:28:40 -0500
Received: from hotmail.com [64.4.14.193] by canvaslink.com with ESMTP
(SMTPD32-6.00) id A17C246C0396; Wed, 28 Nov 2001 19:29:48 -0500
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
Wed, 28 Nov 2001 16:26:19 -0800
X-Originating-IP: [62.83.96.14]
Wrom: TTZRCLBDXRQBGJSNBOHMKHJYFMYXOEAIJJPHSCRTNHGSWZIDREXCAXZOWCO
To: "Allegro Conductors" <[email]>
References: <[email]> <[email]> <[email]>
Date: Thu, 29 Nov 2001 01:29:29 +0100
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
From: [email]
Message-ID: <[email]>
X-OriginalArrivalTime: 29 Nov 2001 00:26:19.0212 (UTC) FILETIME=[770B60C0:01C1786C]
Subject: Re: [AD] Proposed changes for Allegro 5 (6?)
Precedence: bulk
Sender: conductors-[email]
Oh yeah, one thing I forgot to say
No global variables if possible, I see it "nicer"
to have something like
al_get_boolean(AL_CAPABILITIES_CPU_MMX);
Hmm, I think college has affected me too much...
All their "side effects" and globals =)
From - Wed Nov 28 19:39:46 2001
X-UIDL: 17568-968516558
X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Return-Path:
Received: from VL-MS-MR002.sc1.videotron.ca ([10.23.32.72]) by
VL-MS-MS002.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNJDNZ00.17T for <[email]>; Wed,
28 Nov 2001 19:35:59 -0500
Received: from canvaslink.com ([216.47.35.50]) by
VL-MS-MR002.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNJDNY04.WZO for <[email]>; Wed,
28 Nov 2001 19:35:58 -0500
Received: from VL-MS-MR003.sc1.videotron.ca [24.201.245.36] by canvaslink.com with ESMTP
(SMTPD32-6.00) id A30A590B0356; Wed, 28 Nov 2001 19:36:26 -0500
Received: from videotron.ca ([24.202.201.127]) by
VL-MS-MR003.sc1.videotron.ca (Netscape Messaging Server 4.15
MR003 Jul 24 2001 16:23:26) with ESMTP id GNJDIW02.MI8 for
<[email]>; Wed, 28 Nov 2001 19:32:56 -0500
Message-ID: <[email]>
Date: Wed, 28 Nov 2001 19:32:52 -0500
From: Bob <[email]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.6) Gecko/20011120
X-Accept-Language: en-us
MIME-Version: 1.0
To: [email]
References: <003001c1783e$27b540a0$0201a8c0@eulero>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: R: [AD] Proposed changes for Allegro 5 (6?)
Precedence: bulk
Sender: conductors-[email]
Angelo Mottola wrote:
> Ok, I've been out to my university all day and when I've returned, I
> found 33 AD messages most of which about this subject, so even if a lot
> has already been said, let me tell you my thoughts.
I have a feeling there will be a lot more comming :)
>
>
>>- Switch to completely disable the Allegro mixer, and send
>>
> audiobuffers to the sound card directly. (TRAC)
>
> Hum, I'm not a sound programming expert, but removing our software mixer
> wouldn't mean to loose a lot of functionalities?
I'm not talking about removing them, I'm talking about providing an option
for the user to disable them. They use computational resources, and aren't
even good at what they do. If the user can do it better, then why not let him?
[snip]
>>- Possible merge of AllegroGL (as an OpenGL driver only, to keep it
>>
> light)
>
> I'm all for it! By "as an OpenGL driver only" do you mean to implement
> only the current AGL "direct" mode? If so I agree again as I don't see
> any reasons on including the others.
Yes. But we'll be cutting out some of the functions, like AGLF and possibly
the texture uploading code.
>
>
>>- merge blit and sprite API
>>
>
> I agree, but how to recognize when to draw a transparent bitmap (sprite)
> or a solid one? What about using al_set(AL_BLIT, AL_BLIT_TRANS) or
> al_set(AL_BLIT, AL_BLIT_SOLID)?
Or make a trans_blit() function?
>
>
>>- window resizing support
>>
>
> Is this really needed? I think it'd require so much overhead it isn't
> worth it at all. Who really needs window resizing in games? Ok, Allegro
> is also for general multimedia apps, but again I'm not convinced on
> adding support for this...
Yes, I was thinking more for application. If it's too hard to implement in
DDraw, then perhaps it can put in the backburner for a while. Having that
option platforms/drivers which support it (like OpenGL) would be really nice
though.
[snip]
>>- What to do with floodfill (can't be accelerated via GL or D3D)
>>
>
> Some programs may need it, so I don't think removing it is a good idea.
> GL and D3D could just have a slow unrecommended implementation (stated
> in the docs) or not have it at all (but this would mean making floodfill
> part of the gfx vtable, which isn't a bad idea at all)
Agreed.
>>- Drop DOS.
>>
>
> Psss! A hint: don't propose this once again, or someday you'll find
> hordes of angry people knocking at your door!
Too late :)
They can upgrade to a better OS (like Linux!) :)
--
- Robert J Ohannessian
"Microsoft code is probably O(n^20)" (my CS prof)
http://pages.infinit.net/voidstar/
From - Wed Nov 28 22:05:19 2001
X-UIDL: 17569-968516558
X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Return-Path:
Received: from VL-MS-MR004.sc1.videotron.ca ([10.23.32.74]) by
VL-MS-MS002.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNJDWO03.NIU for <[email]>; Wed,
28 Nov 2001 19:41:12 -0500
Received: from canvaslink.com ([216.47.35.50]) by
VL-MS-MR004.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNJDWN02.4S4 for <[email]>; Wed,
28 Nov 2001 19:41:11 -0500
Received: from VL-MS-MR004.sc1.videotron.ca [24.201.245.36] by canvaslink.com with ESMTP
(SMTPD32-6.00) id A4636AE302CC; Wed, 28 Nov 2001 19:42:11 -0500
Received: from videotron.ca ([24.202.201.127]) by
VL-MS-MR004.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNJDSH00.VRI for <[email]>; Wed,
28 Nov 2001 19:38:41 -0500
Message-ID: <[email]>
Date: Wed, 28 Nov 2001 19:38:28 -0500
From: Bob <[email]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.6) Gecko/20011120
X-Accept-Language: en-us
MIME-Version: 1.0
To: [email]
References: <28A7C352840AD511AC9400508BE70AC24FFDB3@FRUITMACHINE>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [AD] Proposed changes for Allegro 5 (6?)
Precedence: bulk
Sender: conductors-[email]
Shawn Hargreaves wrote:
> Angelo Mottola writes:
> > > - Switch to completely disable the Allegro mixer, and send
> > audiobuffers to the sound card directly. (TRAC)
> >
> > Hum, I'm not a sound programming expert, but removing our
> > software mixer wouldn't mean to loose a lot of functionalities?
>
> It would make it much harder to write drivers for devices that
> can't do good mixing themselves (eg. most of the DOS and Unix
> sound drivers). The mixer isn't a requirement, just a set of
> helper functions that drivers can use if it makes their job
> easier. Allegro never talks straight to the mixer code: the
> framework tells the driver what to do, and then some drivers
> can choose to pass some of those requests onto the software
> mixer. What's the problem with that? And if you lose the mixer,
> how do you write drivers for devices that can't do mixing
> themselves?
I'm against removig the mixer. I am for some option somewhere to disable it
though. Some programs (emulators, DUMB) already do their own mixing, and can
support just about every sound card configuration you throw at them. Adding
the Allegro mixer over that is a waste of CPU cycles. It would also open the
way for mixer add-ons.
[snip]
> My general advice is to avoid putting this kind of persistent
> state into the API. Or if you are going to do it, do it totally
> (like OpenGL) so that every single operation is split up into
> many very small single-parameter function calls. Allegro isn't
> really built like that, though, so I think it is better to avoid
> having state at all. Pass parameters to functions to tell them
> what to do, or if it is such a commonly used routine that this
> will be a pain, split it into a family of related functions.
>
> My experience has been that every time I did put in something
> with persistent state (the text_mode() function being a prime
> example), it caused problems and confusion down the road, and
> I ended up wishing I hadn't done that (eg. it would be better
> if the background color was always passed to text drawing
> routines along with the foreground).
Then every time we need to add a new capability, we need to either change
existing functions (not nice), or add new ones (bloat). Just MHO though. I
like Allegro how it is, but I hate to see the kludges put in place (like
text_mode() you mentioned, or having vertain numbers have special meaning in
certain circumstances).
>
> Persistent state causes particular problems for addon packages,
> but also when other parts of the lib may need to change it
> (eg. calling alert() alters some settings that the programmer
> may not expect to have changed - it is loads of hassle and
> housekeeping if alert() needs to track that and put the values
> back when it is done!)
Why can't Alert use the user settings? Or am I missing something?
[snip]
--
- Robert J Ohannessian
"Microsoft code is probably O(n^20)" (my CS prof)
http://pages.infinit.net/voidstar/
From - Wed Nov 28 22:05:20 2001
X-UIDL: 17570-968516558
X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Return-Path:
Received: from VL-MS-MR002.sc1.videotron.ca ([10.23.32.72]) by
VL-MS-MS002.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNJEHC02.2LE for <[email]>; Wed,
28 Nov 2001 19:53:36 -0500
Received: from canvaslink.com ([216.47.35.50]) by
VL-MS-MR002.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNJEHB02.42U for <[email]>; Wed,
28 Nov 2001 19:53:35 -0500
Received: from VL-MS-MR004.sc1.videotron.ca [24.201.245.36] by canvaslink.com with ESMTP
(SMTPD32-6.00) id A1CC246F0396; Wed, 28 Nov 2001 19:31:08 -0500
Received: from videotron.ca ([24.202.201.127]) by
VL-MS-MR004.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNJDA200.PRS for <[email]>; Wed,
28 Nov 2001 19:27:38 -0500
Message-ID: <[email]>
Date: Wed, 28 Nov 2001 19:27:34 -0500
From: Bob <[email]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.6) Gecko/20011120
X-Accept-Language: en-us
MIME-Version: 1.0
To: [email]
References: <01cd01c17811$c45a1660$ea2c24d5@zephyr>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [AD] Proposed changes for Allegro 5 (6?)
Precedence: bulk
Sender: conductors-[email]
Eric Botcazou wrote:
>>>Message based (see SDL) (about input)
>>>
>>In addition to the current API, right ?
>>
>
> And you need to poll ?
> Gosh ! ;-) All the complexity in the Windows port comes precisely from
> hiding the message-driven nature of the OS. I think we'd better use a
> slot/callback design.
Can we also get timestamps on events? We implemented such a scheme in SUUTB,
so that the input module would catch as many events as possible, without
losing keys, ignoring user input, or making the game too slow to run.
Also, you have to poll the joystick anyway :)
--
- Robert J Ohannessian
"Microsoft code is probably O(n^20)" (my CS prof)
http://pages.infinit.net/voidstar/
From - Wed Nov 28 22:05:20 2001
X-UIDL: 17572-968516558
X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Return-Path:
Received: from VL-MS-MR002.sc1.videotron.ca ([10.23.32.72]) by
VL-MS-MS002.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNJEXS02.35U for <[email]>; Wed,
28 Nov 2001 20:03:28 -0500
Received: from canvaslink.com ([216.47.35.50]) by
VL-MS-MR002.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNJEXO00.E3U for <[email]>; Wed,
28 Nov 2001 20:03:24 -0500
Received: from mail3.alphalink.com.au [202.161.124.59] by canvaslink.com with ESMTP
(SMTPD32-6.00) id A9A41E460388; Wed, 28 Nov 2001 20:04:36 -0500
Received: from alphalink.com.au (d35-ds9-mel.alphalink.com.au [202.161.101.163])
by mail3.alphalink.com.au (8.11.4/8.9.3) with ESMTP id fAT114e20490
for <[email]>; Thu, 29 Nov 2001 12:01:04 +1100
Received: (from tjaden@localhost)
by alphalink.com.au (8.11.0/8.11.0) id fAT13nr05734
for [email]; Thu, 29 Nov 2001 12:03:49 +1100
Date: Thu, 29 Nov 2001 12:03:49 +1100
From: Peter Wang <[email]>
To: [email]
Message-ID: <[email]>
Mail-Followup-To: [email]
References: <[email]> <[email]> <[email]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <[email]>; from [email] on Wed, Nov 28, 2001 at 07:01:18PM -0500
Subject: Re: [AD] Proposed changes for Allegro 5 (6?)
Precedence: bulk
Sender: conductors-[email]
On 2001-11-28, Bob <[email]> wrote:
> >>Packfiles:
> >> - Allow registering of new compression and encryption libs.
> >>
> >
> > Good idea, but nothing we need to wait for if nobody writes it.
>
>
> I thought Peter Wang had already written it, but it was left as a patch on
> Allegro.
Yep. If I had known 4.0 was going to take this long, I would have
tested it more and pushed for its inclusion. But it's too late now...
I wish you guys had left this discussion till later.
Must.. resist.. temptation to.. reply...
... ok, just one response: I agree with Shawn about persistent state
in libraries. To a certain degree it's unavoidable, but on the whole,
it sucks. Ideally, every function call should be complete unto itself.
From - Wed Nov 28 22:05:21 2001
X-UIDL: 17574-968516558
X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Return-Path:
Received: from VL-MS-MR002.sc1.videotron.ca ([10.23.32.72]) by
VL-MS-MS002.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNJFW803.O7I for <[email]>; Wed,
28 Nov 2001 20:24:08 -0500
Received: from canvaslink.com ([216.47.35.50]) by
VL-MS-MR002.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNJFW703.M6W for <[email]>; Wed,
28 Nov 2001 20:24:07 -0500
Received: from hotmail.com [64.4.14.118] by canvaslink.com with ESMTP
(SMTPD32-6.00) id AE7725950396; Wed, 28 Nov 2001 20:25:11 -0500
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
Wed, 28 Nov 2001 17:21:41 -0800
X-Originating-IP: [62.83.96.14]
From: =?iso-8859-1?Q?Javier_Gonz=E1lez?= <[email]>
To: "Allegro Conductors" <[email]>
References: <[email]> <[email]> <[email]> <[email]>
Date: Thu, 29 Nov 2001 02:24:50 +0100
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Message-ID: <[email]>
X-OriginalArrivalTime: 29 Nov 2001 01:21:41.0845 (UTC) FILETIME=[337CF050:01C17874]
Subject: Re: [AD] Proposed changes for Allegro 5 (6?)
Precedence: bulk
Sender: conductors-[email]
> ... ok, just one response: I agree with Shawn about persistent state
> in libraries. To a certain degree it's unavoidable, but on the whole,
> it sucks. Ideally, every function call should be complete unto itself.
Totally agree, btw, methinks allegro 5 should include code to play
cd audiotracks
(sorry, there are just so many things i wonder when i think of a new allegro
version =)
From - Wed Nov 28 23:29:30 2001
X-UIDL: 17578-968516558
X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Return-Path:
Received: from VL-MS-MR003.sc1.videotron.ca ([10.23.32.73]) by
VL-MS-MS002.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNJLU100.LH9 for <[email]>; Wed,
28 Nov 2001 22:32:25 -0500
Received: from canvaslink.com ([216.47.35.50]) by
VL-MS-MR003.sc1.videotron.ca (Netscape Messaging Server 4.15
MR003 Jul 24 2001 16:23:26) with ESMTP id GNJLU001.HOG for
<[email]>; Wed, 28 Nov 2001 22:32:24 -0500
Received: from tele-post-20.mail.demon.net [194.217.242.20] by canvaslink.com with ESMTP
(SMTPD32-6.00) id AB882B1C03EE; Wed, 28 Nov 2001 22:29:12 -0500
Received: from lwithers.demon.co.uk ([194.222.80.1])
by tele-post-20.mail.demon.net with esmtp (Exim 2.12 #2)
id 169HpW-0004Rk-0K
for [email]; Thu, 29 Nov 2001 03:25:43 +0000
Message-ID: <[email]>
Date: Thu, 29 Nov 2001 03:25:29 +0000
To: [email]
From: Laurence Withers <[email]>
References: <[email]>
<[email]>
In-Reply-To: <[email]>
MIME-Version: 1.0
Content-Type: multipart/signed;boundary="=_Turnpike_bdvbFGAmqaB802FX=";
protocol="application/pgp-signature";micalg=pgp-sha1
X-Mailer: Turnpike Integrated Version 5.01 S
Subject: Re: [AD] Proposed changes for Allegro 5 (6?)
Precedence: bulk
Sender: conductors-[email]
This is a PGP signed message sent according to RFC2015 [PGP/MIME]
--=_Turnpike_bdvbFGAmqaB802FX=
Content-Type: text/plain;charset=us-ascii
Content-Transfer-Encoding: quoted-printable
In reply to Bob <[email]>:
>Hmm, I have a feeling this thread will explode as everyone is commenting o=
n=20
>everyone else's thoughts :)
Yay! Combinatorial explosion...
>> - network: why not use something like libnet?
>
>Because libnet is not being updated :)
>Really, its only for completion of Allegro - it does abstracts everything=
=20
>else needed to make a game, so why not networks?
Then let's update libnet ourselves. The license is open enough that we
can either make our own branch or just submit updates to the authors.
Although I suppose it wouldn't do any harm to merge libnet sources in
later on.
>> - dynamic loading of modules: this would work fine on i386 (with=20
>> stonewheel), but not on anything else. So at best, we couldn't rely=20
>> on it being available.
>
>Yes I know lots of people will disagree with me, but the fact is, if DOS=20
>isn't dead now, it will be by the time Allegro 5/6/7 comes out, when Windo=
ws=20
>YQ comes out.
>If we drop DOS, we suddenly can have access to all these nice features lik=
e=20
>multi-threading, networking, dynamic module loading, and probably a lot mo=
re=20
>things that I can't think of right now.
>Seriously though, who still uses a pure DOS system today? If you use=20
>Windows, why not use Mingw and make Windows programs? (then port them to=20
>Linux ;)
Erm... I didn't mention DOS. Dynamic loading does work fine on DOS if
you use stonewheel. And DOS does support multi-threading (you can get
POSIX threads for DJGPP), networking (via libnet), etc.
[snip]
>But then, the DOS port won't behave like the other ports, and we'll see lo=
ts=20
>of those nasty #define tricks to get our games to run one way in DOS and=20
>another (better?) way in other OSs.
No, Allegro will be the same; if people want their games to run on DOS
(ie. presumably if they are developing on DOS), then they will have to
include some extra macros, which would be #defined to nothing on other
platforms.
Bye for now,
--=20
Laurence Withers, [email]
http://www.lwithers.demon.co.uk/
--=_Turnpike_bdvbFGAmqaB802FX=
Content-Type: application/pgp-signature
Content-Disposition: attachment; filename=signature.asc
-----BEGIN PGP SIGNATURE-----
Version: PGPsdk version 1.7.1
iQA/AwUBPAWqqWbrT6QxxsGNEQJ3tgCfRYVnht5WjCvUCq2wqJXYBimww9wAn10W
h2BfXmGFSFCcsdo/lXN8gi2b
=wQ5l
-----END PGP SIGNATURE-----
--=_Turnpike_bdvbFGAmqaB802FX=--
From - Thu Nov 29 09:25:49 2001
X-UIDL: 17584-968516558
X-Mozilla-Status: 0013
X-Mozilla-Status2: 00000000
Return-Path:
Received: from VL-MS-MR002.sc1.videotron.ca ([10.23.32.72]) by
VL-MS-MS002.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNK0Y403.2Z5 for <[email]>; Thu,
29 Nov 2001 03:58:52 -0500
Received: from canvaslink.com ([216.47.35.50]) by
VL-MS-MR002.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNK0Y303.8IK for <[email]>; Thu,
29 Nov 2001 03:58:51 -0500
Received: from alfa.srnet.cz [62.24.72.242] by canvaslink.com with ESMTP
(SMTPD32-6.00) id A92C2FB702BA; Thu, 29 Nov 2001 04:00:28 -0500
Received: from penguin.src (penguin.src [10.0.0.2])
by alfa.srnet.cz (8.10.2/8.10.2) with ESMTP id fAT8uxf01155
for <[email]>; Thu, 29 Nov 2001 09:56:59 +0100
Date: Thu, 29 Nov 2001 09:56:58 +0100 (CET)
From: Stepan Roh <[email]>
To: Allegro Developers List <[email]>
In-Reply-To: <[email]>
Message-ID:
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: Re: [AD] Proposed changes for Allegro 5 (6?)
Precedence: bulk
Sender: conductors-[email]
On Wed, 28 Nov 2001, Bob wrote:
> Stepan Roh wrote:
>
> >
> > On Tue, 27 Nov 2001, Bob wrote:
> >
> >
> >>http://pages.infinit.net/voidstar/newalleg.txt
> >>
> >
> > Splitting packfiles handling to compression/encryption layers is good, but
> > removing default implementation is bad, bad, bad :-) Why?
>
>
> I just thought about lightening the lib. There's no reason really, and I'm
> not advocating it. I just thought I'd bring it up incase someone else would
> argument for it :)
Sorry, noone here :-)
> > Adding networking is not good thing, I think. Too much new code without
> > any connection to current Allegro.
>
>
> The current Allegro has nearly no connection to Allegro 3.0 appart from most
> of the external API. Why is networking any different?
Input, graphics and sound are core of Allegro. Unicode functions are there
as a support for text output. GUI is there for utilities and grabber.
Datafiles are there for simplify data loading. Unaccelerated 3D is there
for unknown reason :-) Network should be there for what? You want to drop
small blenders and want to include huge networking layer.
> > Generated API docs is very good idea, but forget Javadoc. It's too
> > Java-centric and too slow.
>
>
> Doxygen? They use the same syntax (AFAIK), so we could just document the
> code like this:
>
> /** Draws a bitmap. (insert blit() docs)
> *
> * \param source The source bitmap
> * \param dest The destination bitmap
> * (and so on)
> *
> * \sa draw_sprite masked_blit stretch_blit
> */
> void blit(...) {
> }
If this is Doxygen's syntax (I don't know it), then it's not Javadoc :-)
But in-source documentation is good thing.
Have a nice day.
Stepan Roh
From - Thu Nov 29 09:25:49 2001
X-UIDL: 17585-968516558
X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Return-Path:
Received: from VL-MS-MR001.sc1.videotron.ca ([10.23.32.71]) by
VL-MS-MS002.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNK17001.AO0 for <[email]>; Thu,
29 Nov 2001 04:04:12 -0500
Received: from canvaslink.com ([216.47.35.50]) by
VL-MS-MR001.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNK17003.C8G for <[email]>; Thu,
29 Nov 2001 04:04:12 -0500
Received: from alfa.srnet.cz [62.24.72.242] by canvaslink.com with ESMTP
(SMTPD32-6.00) id AA782DB703EE; Thu, 29 Nov 2001 04:06:00 -0500
Received: from penguin.src (penguin.src [10.0.0.2])
by alfa.srnet.cz (8.10.2/8.10.2) with ESMTP id fAT92Wf01194
for <[email]>; Thu, 29 Nov 2001 10:02:32 +0100
Date: Thu, 29 Nov 2001 10:02:30 +0100 (CET)
From: Stepan Roh <[email]>
To: Allegro Developers List <[email]>
In-Reply-To: <[email]>
Message-ID:
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: Re: [AD] Proposed changes for Allegro 5 (6?)
Precedence: bulk
Sender: conductors-[email]
On Wed, 28 Nov 2001, Bob wrote:
> >> - Fix this whole 32bpp == int, 16bpp == short thing. Use int16_t and
> >>int32_t instead?
> >>
> >
> > Why? I think this would break too much code, both in Allegro and in
> > user's code. Btw, 32bpp == long, not int.
>
>
> So on 64 bit machines, 32bpp bitmaps waste twice the memory and memory
> bandwidth - just great :)
That's not true. For example on IRIX64, int and long are the same as on
32-bit platforms. Same applies to SunOS. Changing it would break too much
code (including system libraries), so it was left as is.
> I'd rather have them as type INT32, where INT32 can be defined as whatever
> fits 32 bits in the current machine.
I proposed that once, but had no success.
Have a nice day.
Stepan Roh
From - Thu Nov 29 09:25:51 2001
X-UIDL: 17589-968516558
X-Mozilla-Status: 0013
X-Mozilla-Status2: 00000000
Return-Path: <[email]>
Received: from VL-MS-MR001.sc1.videotron.ca ([10.23.32.71]) by
VL-MS-MS002.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNK4V503.ESM for <[email]>; Thu,
29 Nov 2001 05:23:29 -0500
Received: from fruitmachine.brighton.climax.co.uk
([212.74.3.86]) by VL-MS-MR001.sc1.videotron.ca (Netscape
Messaging Server 4.15) with ESMTP id GNK4V504.LDV for
<[email]>; Thu, 29 Nov 2001 05:23:29 -0500
Received: by FRUITMACHINE with Internet Mail Service (5.5.2653.19)
id ; Thu, 29 Nov 2001 10:23:24 -0000
Message-ID: <28A7C352840AD511AC9400508BE70AC24FFDB6@FRUITMACHINE>
From: Shawn Hargreaves <[email]>
To: 'Bob' <[email]>, [email]
Subject: RE: [AD] Proposed changes for Allegro 5 (6?)
Date: Thu, 29 Nov 2001 10:23:23 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
boundary="----_=_NextPart_001_01C178BF.E007D1A0"
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
------_=_NextPart_001_01C178BF.E007D1A0
Content-Type: text/plain;
charset="iso-8859-1"
Bob writes:
>>> - `bmp_read8()' & co currently use longs instead of pointers.
>>
>> The thinking behind using longs is that this makes the pointers
>> opaque, ie. can't be dereferenced directly by the user
>
> Those functions are of the fairly advanced level, so I don't
> see users who haven't understood pointers use them :)
The problem is not so much programmer ignorance, as portability.
On Windows or Unix, it would work fine if I was to write:
unsigned char *address = (unsigned char *)bmp_write_line(bmp, y);
bmp_select(bmp);
address[x] = color;
bmp_unwrite_line(bmp);
But this code will fail miserably on any platform where the
bitmap memory is not part of your standard address space.
Currently I think DOS is the only such platform supported
by Allegro, but this is also true for many embedded systems,
consoles, etc, so it would be a shame to lose the portability
of always accessing vram using the read/write macros.
Even a very experienced programmer, when presented with a
char * that references video memory, is likely to use *ptr
as a way to access this memory, and when this works for them,
will assume that this access method is correct. They will
then be unpleasantly surprised when this code fails to work
on other platforms.
If the address is not a pointer type, this makes it far more
obvious that it must be accessed in a special way, so people
are more likely to produce correct and portable code.
--
Shawn
------_=_NextPart_001_01C178BF.E007D1A0
Content-Type: text/html;
charset="iso-8859-1"
RE: [AD] Proposed changes for Allegro 5 (6?)
Bob writes:
>>> - `bmp_read8()' & co currently use longs instead of pointers.
>>
>> The thinking behind using longs is that this makes the pointers
>> opaque, ie. can't be dereferenced directly by the user
>
> Those functions are of the fairly advanced level, so I don't
> see users who haven't understood pointers use them :)
The problem is not so much programmer ignorance, as portability.
On Windows or Unix, it would work fine if I was to write:
unsigned char *address = (unsigned char *)bmp_write_line(bmp, y);
bmp_select(bmp);
address[x] = color;
bmp_unwrite_line(bmp);
But this code will fail miserably on any platform where the
bitmap memory is not part of your standard address space.
Currently I think DOS is the only such platform supported
by Allegro, but this is also true for many embedded systems,
consoles, etc, so it would be a shame to lose the portability
of always accessing vram using the read/write macros.
Even a very experienced programmer, when presented with a
char * that references video memory, is likely to use *ptr
as a way to access this memory, and when this works for them,
will assume that this access method is correct. They will
then be unpleasantly surprised when this code fails to work
on other platforms.
If the address is not a pointer type, this makes it far more
obvious that it must be accessed in a special way, so people
are more likely to produce correct and portable code.
--
Shawn
------_=_NextPart_001_01C178BF.E007D1A0--
From - Thu Nov 29 09:25:51 2001
X-UIDL: 17590-968516558
X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Return-Path:
Received: from VL-MS-MR004.sc1.videotron.ca ([10.23.32.74]) by
VL-MS-MS002.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNK4YE03.ZNQ for <[email]>; Thu,
29 Nov 2001 05:25:26 -0500
Received: from canvaslink.com ([216.47.35.50]) by
VL-MS-MR004.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNK4YE02.M8C for <[email]>; Thu,
29 Nov 2001 05:25:26 -0500
Received: from fruitmachine.brighton.climax.co.uk [212.74.3.86] by canvaslink.com with ESMTP
(SMTPD32-6.00) id AD71142A03A8; Thu, 29 Nov 2001 05:26:57 -0500
Received: by FRUITMACHINE with Internet Mail Service (5.5.2653.19)
id ; Thu, 29 Nov 2001 10:23:24 -0000
Message-ID: <28A7C352840AD511AC9400508BE70AC24FFDB6@FRUITMACHINE>
From: Shawn Hargreaves <[email]>
To: 'Bob' <[email]>, [email]
Date: Thu, 29 Nov 2001 10:23:23 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
boundary="----_=_NextPart_001_01C178BF.E007D1A0"
Subject: RE: [AD] Proposed changes for Allegro 5 (6?)
Precedence: bulk
Sender: conductors-[email]
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
------_=_NextPart_001_01C178BF.E007D1A0
Content-Type: text/plain;
charset="iso-8859-1"
Bob writes:
>>> - `bmp_read8()' & co currently use longs instead of pointers.
>>
>> The thinking behind using longs is that this makes the pointers
>> opaque, ie. can't be dereferenced directly by the user
>
> Those functions are of the fairly advanced level, so I don't
> see users who haven't understood pointers use them :)
The problem is not so much programmer ignorance, as portability.
On Windows or Unix, it would work fine if I was to write:
unsigned char *address = (unsigned char *)bmp_write_line(bmp, y);
bmp_select(bmp);
address[x] = color;
bmp_unwrite_line(bmp);
But this code will fail miserably on any platform where the
bitmap memory is not part of your standard address space.
Currently I think DOS is the only such platform supported
by Allegro, but this is also true for many embedded systems,
consoles, etc, so it would be a shame to lose the portability
of always accessing vram using the read/write macros.
Even a very experienced programmer, when presented with a
char * that references video memory, is likely to use *ptr
as a way to access this memory, and when this works for them,
will assume that this access method is correct. They will
then be unpleasantly surprised when this code fails to work
on other platforms.
If the address is not a pointer type, this makes it far more
obvious that it must be accessed in a special way, so people
are more likely to produce correct and portable code.
--
Shawn
------_=_NextPart_001_01C178BF.E007D1A0
Content-Type: text/html;
charset="iso-8859-1"
RE: [AD] Proposed changes for Allegro 5 (6?)
Bob writes:
>>> - `bmp_read8()' & co currently use longs instead of pointers.
>>
>> The thinking behind using longs is that this makes the pointers
>> opaque, ie. can't be dereferenced directly by the user
>
> Those functions are of the fairly advanced level, so I don't
> see users who haven't understood pointers use them :)
The problem is not so much programmer ignorance, as portability.
On Windows or Unix, it would work fine if I was to write:
unsigned char *address = (unsigned char *)bmp_write_line(bmp, y);
bmp_select(bmp);
address[x] = color;
bmp_unwrite_line(bmp);
But this code will fail miserably on any platform where the
bitmap memory is not part of your standard address space.
Currently I think DOS is the only such platform supported
by Allegro, but this is also true for many embedded systems,
consoles, etc, so it would be a shame to lose the portability
of always accessing vram using the read/write macros.
Even a very experienced programmer, when presented with a
char * that references video memory, is likely to use *ptr
as a way to access this memory, and when this works for them,
will assume that this access method is correct. They will
then be unpleasantly surprised when this code fails to work
on other platforms.
If the address is not a pointer type, this makes it far more
obvious that it must be accessed in a special way, so people
are more likely to produce correct and portable code.
--
Shawn
------_=_NextPart_001_01C178BF.E007D1A0--
From - Thu Nov 29 09:25:51 2001
X-UIDL: 17591-968516558
X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Return-Path:
Received: from VL-MS-MR003.sc1.videotron.ca ([10.23.32.73]) by
VL-MS-MS002.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNK5JV02.QF0 for <[email]>; Thu,
29 Nov 2001 05:38:19 -0500
Received: from canvaslink.com ([216.47.35.50]) by
VL-MS-MR003.sc1.videotron.ca (Netscape Messaging Server 4.15
MR003 Jul 24 2001 16:23:26) with ESMTP id GNK5JV01.56A for
<[email]>; Thu, 29 Nov 2001 05:38:19 -0500
Received: from relay4.ftech.net [212.32.16.76] by canvaslink.com with ESMTP
(SMTPD32-6.00) id A08B3C0202BE; Thu, 29 Nov 2001 05:40:11 -0500
Received: from ibm9.ftech.net ([212.32.16.79] helo=mailgate)
by relay4.ftech.net with esmtp (Exim 3.22-ftech-p6.1 #9)
id 169OYa-0006lg-00
for [email]; Thu, 29 Nov 2001 10:36:40 +0000
Received: from [89.0.0.95] by (MailGate 3.5.165) with ESMTP; Thu, 29 Nov 2001 10:36:56 +0000
Received: by warhol with Internet Mail Service (5.5.2448.0)
id ; Thu, 29 Nov 2001 10:35:03 -0000
Message-ID:
From: Vincent Penquerc'h <[email]>
To: [email]
Date: Thu, 29 Nov 2001 10:35:01 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/alternative;
boundary="----_=_NextPart_001_01C178C1.805BB0E0"
Subject: RE: [AD] Proposed changes for Allegro 5 (6?)
Precedence: bulk
Sender: conductors-[email]
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
------_=_NextPart_001_01C178C1.805BB0E0
Content-Type: text/plain;
charset="windows-1252"
> Subbitmaps and planar bitmaps are probably the only type of
> bitmaps that can
> have mixed types. Bit flags anyone?
Makes sense. And stuff RLE sprites in it too, with a bit for RLE format ?
Though blitting on RLEs is not possible at the moment, so it might be
problematic ... It would go towards your idea of unifying both types though.
> so TGA is a raw format? doubtful.
> A quick search on wotsit revealed that TGAs have their
> headers at the *end*
> of the file. An analysis of the beginning of the file for
> consistency) can
> also help in determining the file type. The same type of
> consistency check
> can be done on PCX files.
Oh, I didn't know that for TGAs. I just looked at /etc/magic :)
PCX though, has a single non-changing byte in its header, and another one
than can take two or three values. The rest have "probable" values, like
resolution, or inches size, but that hardly can be used as detection, as
it is too likely to get rejection for valid PCX files with odd sizes or
the like. You'd be enforcing a certain type of "Allegro compliant" sub
format. Which is not very nice.
For the record, neither TGA nor PCX are recognized in my /etc/magic, PCX
is there but commented out becauses it is not reliable enough.
> But most types in Allegro are ints anyway :)
> It'll also allow us to add many more attributes without
> having to break the
> API every time, or resort to adding new functions (like text_mode).
Well, maybe there are advantages to this way of specifying parameters,
but I didn't spot them. You want to set something, do it, do not ask for
someone to do it in an odd way. Maybe it decreases the number of API calls
but it certainly won't decrease the complexity of the code.
I don't like bloat in the sense of duplicated or useless code, but this
kind of bloat (splitting unrelated things into more functions) strikes me
as "good bloat" :) But it's more gut feeling that real arguments I have.
--
Vincent Penquerc'h
------_=_NextPart_001_01C178C1.805BB0E0
Content-Type: text/html;
charset="windows-1252"
RE: [AD] Proposed changes for Allegro 5 (6?)
> Subbitmaps and planar bitmaps are probably the only type of
> bitmaps that can
> have mixed types. Bit flags anyone?
Makes sense. And stuff RLE sprites in it too, with a bit for RLE format ?
Though blitting on RLEs is not possible at the moment, so it might be
problematic ... It would go towards your idea of unifying both types though.
> so TGA is a raw format? doubtful.
> A quick search on wotsit revealed that TGAs have their
> headers at the *end*
> of the file. An analysis of the beginning of the file for
> consistency) can
> also help in determining the file type. The same type of
> consistency check
> can be done on PCX files.
Oh, I didn't know that for TGAs. I just looked at /etc/magic :)
PCX though, has a single non-changing byte in its header, and another one
than can take two or three values. The rest have "probable" values, like
resolution, or inches size, but that hardly can be used as detection, as
it is too likely to get rejection for valid PCX files with odd sizes or
the like. You'd be enforcing a certain type of "Allegro compliant" sub
format. Which is not very nice.
For the record, neither TGA nor PCX are recognized in my /etc/magic, PCX
is there but commented out becauses it is not reliable enough.
> But most types in Allegro are ints anyway :)
> It'll also allow us to add many more attributes without
> having to break the
> API every time, or resort to adding new functions (like text_mode).
Well, maybe there are advantages to this way of specifying parameters,
but I didn't spot them. You want to set something, do it, do not ask for
someone to do it in an odd way. Maybe it decreases the number of API calls
but it certainly won't decrease the complexity of the code.
I don't like bloat in the sense of duplicated or useless code, but this
kind of bloat (splitting unrelated things into more functions) strikes me
as "good bloat" :) But it's more gut feeling that real arguments I have.
--
Vincent Penquerc'h
------_=_NextPart_001_01C178C1.805BB0E0--
From - Thu Nov 29 09:25:52 2001
X-UIDL: 17594-968516558
X-Mozilla-Status: 0013
X-Mozilla-Status2: 00000000
Return-Path: <[email]>
Received: from VL-MS-MR004.sc1.videotron.ca ([10.23.32.74]) by
VL-MS-MS002.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNK6KJ05.31X for <[email]>; Thu,
29 Nov 2001 06:00:19 -0500
Received: from fruitmachine.brighton.climax.co.uk
([212.74.3.86]) by VL-MS-MR004.sc1.videotron.ca (Netscape
Messaging Server 4.15) with ESMTP id GNK6KJ03.K83 for
<[email]>; Thu, 29 Nov 2001 06:00:19 -0500
Received: by FRUITMACHINE with Internet Mail Service (5.5.2653.19)
id ; Thu, 29 Nov 2001 11:00:14 -0000
Message-ID: <28A7C352840AD511AC9400508BE70AC24FFDB7@FRUITMACHINE>
From: Shawn Hargreaves <[email]>
To: 'Bob' <[email]>, [email]
Subject: RE: [AD] Proposed changes for Allegro 5 (6?)
Date: Thu, 29 Nov 2001 11:00:12 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
boundary="----_=_NextPart_001_01C178C5.04BE5F00"
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
------_=_NextPart_001_01C178C5.04BE5F00
Content-Type: text/plain;
charset="iso-8859-1"
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
>From that, I would conclude that the Y-type people are not
currently sufficient to meet the needs of group X.
Moving code from one place to another is unlikely to change
any of the numbers X, Y, or Z (or if it does, that is just
because more people become aware of the code, in which case
the same effect could be obtained by advertising it better).
The only way that it could be better maintained after a move
is if some of the type-Z people started maintaining it, as
they would then see this as a part of their job of keeping
Allegro up to scratch. But this is hardly fair to these
developers, as it is adding more code to their pile of things
that have to be maintained and documented and ported and
supported. If they wanted to spend time on network stuff,
they could already do that without needing to move the code
into Allegro, so really, I think this solution is just taking
advantage of their dedication to making Allegro good, by
piling on more work to an already huge pile of stuff that
they are taking care of.
IMHO a fairer solution, if there aren't enough people in Y,
would be for a few of the X's to move themselves into
group Y. But moving the code into Allegro has nothing to
do with X or Y, and just shifts the problem onto the Z's,
who I think have more important things to keep themselves
occupied with...
> 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...
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. 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.
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! Why remove something that is useful
to some people, and costs so little maintenance effort?
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).
- 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.
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). It would be very feasible
(actually I think quite easy) to get Allegro running on
PalmOS, and only a matter of time before you could put
it on a mobile phone too! (one of my colleagues already
has a phone that can run a Java Worms game in a JVM:
I reckon 2 years until all of Allegro can fit on there).
Please don't ruin that possibility just because you want
to add a few non-essential features to the Windows and
Linux versions!
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).
--
Shawn
------_=_NextPart_001_01C178C5.04BE5F00
Content-Type: text/html;
charset="iso-8859-1"
RE: [AD] Proposed changes for Allegro 5 (6?)
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
From that, I would conclude that the Y-type people are not
currently sufficient to meet the needs of group X.
Moving code from one place to another is unlikely to change
any of the numbers X, Y, or Z (or if it does, that is just
because more people become aware of the code, in which case
the same effect could be obtained by advertising it better).
The only way that it could be better maintained after a move
is if some of the type-Z people started maintaining it, as
they would then see this as a part of their job of keeping
Allegro up to scratch. But this is hardly fair to these
developers, as it is adding more code to their pile of things
that have to be maintained and documented and ported and
supported. If they wanted to spend time on network stuff,
they could already do that without needing to move the code
into Allegro, so really, I think this solution is just taking
advantage of their dedication to making Allegro good, by
piling on more work to an already huge pile of stuff that
they are taking care of.
IMHO a fairer solution, if there aren't enough people in Y,
would be for a few of the X's to move themselves into
group Y. But moving the code into Allegro has nothing to
do with X or Y, and just shifts the problem onto the Z's,
who I think have more important things to keep themselves
occupied with...
> 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...
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. 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.
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! Why remove something that is useful
to some people, and costs so little maintenance effort?
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).
- 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.
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). It would be very feasible
(actually I think quite easy) to get Allegro running on
PalmOS, and only a matter of time before you could put
it on a mobile phone too! (one of my colleagues already
has a phone that can run a Java Worms game in a JVM:
I reckon 2 years until all of Allegro can fit on there).
Please don't ruin that possibility just because you want
to add a few non-essential features to the Windows and
Linux versions!
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).
--
Shawn
------_=_NextPart_001_01C178C5.04BE5F00--
From - Thu Nov 29 09:25:52 2001
X-UIDL: 17595-968516558
X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Return-Path:
Received: from VL-MS-MR002.sc1.videotron.ca ([10.23.32.72]) by
VL-MS-MS002.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNK6N903.XWL for <[email]>; Thu,
29 Nov 2001 06:01:57 -0500
Received: from canvaslink.com ([216.47.35.50]) by
VL-MS-MR002.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNK6N801.0L7 for <[email]>; Thu,
29 Nov 2001 06:01:56 -0500
Received: from fruitmachine.brighton.climax.co.uk [212.74.3.86] by canvaslink.com with ESMTP
(SMTPD32-6.00) id A6135B46032E; Thu, 29 Nov 2001 06:03:47 -0500
Received: by FRUITMACHINE with Internet Mail Service (5.5.2653.19)
id ; Thu, 29 Nov 2001 11:00:14 -0000
Message-ID: <28A7C352840AD511AC9400508BE70AC24FFDB7@FRUITMACHINE>
From: Shawn Hargreaves <[email]>
To: 'Bob' <[email]>, [email]
Date: Thu, 29 Nov 2001 11:00:12 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
boundary="----_=_NextPart_001_01C178C5.04BE5F00"
Subject: RE: [AD] Proposed changes for Allegro 5 (6?)
Precedence: bulk
Sender: conductors-[email]
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
------_=_NextPart_001_01C178C5.04BE5F00
Content-Type: text/plain;
charset="iso-8859-1"
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
>From that, I would conclude that the Y-type people are not
currently sufficient to meet the needs of group X.
Moving code from one place to another is unlikely to change
any of the numbers X, Y, or Z (or if it does, that is just
because more people become aware of the code, in which case
the same effect could be obtained by advertising it better).
The only way that it could be better maintained after a move
is if some of the type-Z people started maintaining it, as
they would then see this as a part of their job of keeping
Allegro up to scratch. But this is hardly fair to these
developers, as it is adding more code to their pile of things
that have to be maintained and documented and ported and
supported. If they wanted to spend time on network stuff,
they could already do that without needing to move the code
into Allegro, so really, I think this solution is just taking
advantage of their dedication to making Allegro good, by
piling on more work to an already huge pile of stuff that
they are taking care of.
IMHO a fairer solution, if there aren't enough people in Y,
would be for a few of the X's to move themselves into
group Y. But moving the code into Allegro has nothing to
do with X or Y, and just shifts the problem onto the Z's,
who I think have more important things to keep themselves
occupied with...
> 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...
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. 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.
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! Why remove something that is useful
to some people, and costs so little maintenance effort?
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).
- 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.
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). It would be very feasible
(actually I think quite easy) to get Allegro running on
PalmOS, and only a matter of time before you could put
it on a mobile phone too! (one of my colleagues already
has a phone that can run a Java Worms game in a JVM:
I reckon 2 years until all of Allegro can fit on there).
Please don't ruin that possibility just because you want
to add a few non-essential features to the Windows and
Linux versions!
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).
--
Shawn
------_=_NextPart_001_01C178C5.04BE5F00
Content-Type: text/html;
charset="iso-8859-1"
RE: [AD] Proposed changes for Allegro 5 (6?)
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
From that, I would conclude that the Y-type people are not
currently sufficient to meet the needs of group X.
Moving code from one place to another is unlikely to change
any of the numbers X, Y, or Z (or if it does, that is just
because more people become aware of the code, in which case
the same effect could be obtained by advertising it better).
The only way that it could be better maintained after a move
is if some of the type-Z people started maintaining it, as
they would then see this as a part of their job of keeping
Allegro up to scratch. But this is hardly fair to these
developers, as it is adding more code to their pile of things
that have to be maintained and documented and ported and
supported. If they wanted to spend time on network stuff,
they could already do that without needing to move the code
into Allegro, so really, I think this solution is just taking
advantage of their dedication to making Allegro good, by
piling on more work to an already huge pile of stuff that
they are taking care of.
IMHO a fairer solution, if there aren't enough people in Y,
would be for a few of the X's to move themselves into
group Y. But moving the code into Allegro has nothing to
do with X or Y, and just shifts the problem onto the Z's,
who I think have more important things to keep themselves
occupied with...
> 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...
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. 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.
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! Why remove something that is useful
to some people, and costs so little maintenance effort?
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).
- 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.
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). It would be very feasible
(actually I think quite easy) to get Allegro running on
PalmOS, and only a matter of time before you could put
it on a mobile phone too! (one of my colleagues already
has a phone that can run a Java Worms game in a JVM:
I reckon 2 years until all of Allegro can fit on there).
Please don't ruin that possibility just because you want
to add a few non-essential features to the Windows and
Linux versions!
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).
--
Shawn
------_=_NextPart_001_01C178C5.04BE5F00--
From - Thu Nov 29 09:25:54 2001
X-UIDL: 17602-968516558
X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Return-Path:
Received: from VL-MS-MR001.sc1.videotron.ca ([10.23.32.71]) by
VL-MS-MS002.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNK93G00.8L4 for <[email]>; Thu,
29 Nov 2001 06:54:52 -0500
Received: from canvaslink.com ([216.47.35.50]) by
VL-MS-MR001.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNK93F04.3H2 for <[email]>; Thu,
29 Nov 2001 06:54:51 -0500
Received: from smtp2.libero.it [193.70.192.52] by canvaslink.com with ESMTP
(SMTPD32-6.00) id A2855C690356; Thu, 29 Nov 2001 06:56:53 -0500
Received: from lano (151.28.39.195) by smtp2.libero.it (6.0.032)
id 3BEFF161005FCB6F; Thu, 29 Nov 2001 12:53:23 +0100
Date: Thu, 29 Nov 2001 12:48:29 +0100
From: Lo'oRiS il Kabukimono <[email]>
To: Shawn Hargreaves <[email]>
Cc: [email]
Message-Id: <[email]>
In-Reply-To: <28A7C352840AD511AC9400508BE70AC24FFDB7@FRUITMACHINE>
References: <28A7C352840AD511AC9400508BE70AC24FFDB7@FRUITMACHINE>
X-Mailer: Sylpheed version 0.6.5 (GTK+ 1.2.9; i586-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Subject: Re: [AD] Proposed changes for Allegro 5 (6?)
Precedence: bulk
Sender: conductors-[email]
> 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). It would be very feasible
nice.
and moreover think that it will ease very much porting a game
from a console to a pc: if the console game is made using Allegro,
u can simply recompile it and it works on the pc. it is very nice
since often the pc ports of a, for example, psx game add *lots*
of bugs (one relevant example is FF7: the pc version had a little
nicer graphic but often when it had a complex animation to display,
like a big boss, freezed without any possibility of saving the game)
"Chocobos ignore humans who don't look like they'll give them greens"
Final Fantasy 7
_.-:/°^^°\:-._.-:/°^^°\:-._ __. ____
- Lo'oRiS il Kabukimono - / /| /^___ \
Real Name: Lorenzo Petrone / / / / /L_/ /
e-mail: [email] / / / / ___-°/
irc.azzurra.org #lano / /_/__ / /|__-°
digilander.iol.it/lano666 /______/| /__/ /
^°\:-.__.-:/°^°\:-.__.-:/°^ |______|/ |__L/
From - Thu Nov 29 17:17:07 2001
X-UIDL: 17609-968516558
X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Return-Path:
Received: from VL-MS-MR001.sc1.videotron.ca ([10.23.32.71]) by
VL-MS-MS002.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNKIYU01.6SI for <[email]>; Thu,
29 Nov 2001 10:28:06 -0500
Received: from canvaslink.com ([216.47.35.50]) by
VL-MS-MR001.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNKIYT01.8JV for <[email]>; Thu,
29 Nov 2001 10:28:05 -0500
Received: from uria.its.uu.se [130.238.7.14] by canvaslink.com with ESMTP
(SMTPD32-6.00) id A450108E0348; Thu, 29 Nov 2001 10:29:20 -0500
Received: from regulus2.student.uu.se ([130.238.5.5]:49740 "EHLO student.uu.se")
by uria.its.uu.se with ESMTP id ;
Thu, 29 Nov 2001 16:25:41 +0100
Message-ID: <[email]>
Date: Thu, 29 Nov 2001 16:25:28 +0100
From: Sven Sandberg <[email]>
X-Mailer: Mozilla 4.77 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Allegro Developer <[email]>
References: <28A7C352840AD511AC9400508BE70AC24FFDB6@FRUITMACHINE>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: Re: [AD] Proposed changes for Allegro 5 (6?)
Precedence: bulk
Sender: conductors-[email]
Shawn Hargreaves wrote:
> If the address is not a pointer type, this makes it far more
> obvious that it must be accessed in a special way, so people
> are more likely to produce correct and portable code.
But it is not portable to assume that you can store a pointer in a long:
they can even have different sizeof()'s. Can't we do something like:
typedef void *al_video_memory_pointer;
This will not be dereferencable without a cast, and will also have a
more descriptive name.
--
Sven Sandberg [email] home.student.uu.se/svsa1977
From - Thu Nov 29 17:17:08 2001
X-UIDL: 17610-968516558
X-Mozilla-Status: 0013
X-Mozilla-Status2: 00000000
Return-Path:
Received: from VL-MS-MR002.sc1.videotron.ca ([10.23.32.72]) by
VL-MS-MS002.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNKJHV03.JRO for <[email]>; Thu,
29 Nov 2001 10:39:31 -0500
Received: from canvaslink.com ([216.47.35.50]) by
VL-MS-MR002.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNKJHV02.4VU for <[email]>; Thu,
29 Nov 2001 10:39:31 -0500
Received: from uria.its.uu.se [130.238.7.14] by canvaslink.com with ESMTP
(SMTPD32-6.00) id A70311DB0348; Thu, 29 Nov 2001 10:40:51 -0500
Received: from regulus2.student.uu.se ([130.238.5.5]:35698 "EHLO student.uu.se")
by uria.its.uu.se with ESMTP id ;
Thu, 29 Nov 2001 16:37:08 +0100
Message-ID: <[email]>
Date: Thu, 29 Nov 2001 16:36:57 +0100
From: Sven Sandberg <[email]>
X-Mailer: Mozilla 4.77 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Allegro Developer <[email]>
References:
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: Re: [AD] Proposed changes for Allegro 5 (6?)
Precedence: bulk
Sender: conductors-[email]
Stepan Roh wrote:
> But in-source documentation is good thing.
There are some problems with it too:
- Is it possible to make sections be structured another way than the
source files? It would be confusing if there was one section for the
functions in gfx.c and another for the functions in graphics.c, or if
load_bmp(), load_pcx() etc were in different sections.
- Some functions are defined in different files depending on which
platform they are on, so there's no unique natural place to put the
documentation on.
- allegro._tx contains several generic sections that discuss
programming principles (e.g. "Bitmap objects"), or non-api stuff (e.g.
"Makefile targets"), that would not fit in naturally in any source file.
- allegro._tx is not the only file generated by makedoc: there are
totally 8 files mathching allegro/docs/src/*._tx. So we need something
to compile help that does not come from a source file anyway.
--
Sven Sandberg [email] home.student.uu.se/svsa1977
From - Thu Nov 29 17:17:08 2001
X-UIDL: 17611-968516558
X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Return-Path:
Received: from VL-MS-MR002.sc1.videotron.ca ([10.23.32.72]) by
VL-MS-MS002.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNKJOW00.JYU for <[email]>; Thu,
29 Nov 2001 10:43:44 -0500
Received: from canvaslink.com ([216.47.35.50]) by
VL-MS-MR002.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNKJOW02.5US for <[email]>; Thu,
29 Nov 2001 10:43:44 -0500
Received: from relay4.ftech.net [212.32.16.76] by canvaslink.com with ESMTP
(SMTPD32-6.00) id A822120E0348; Thu, 29 Nov 2001 10:45:38 -0500
Received: from ibm9.ftech.net ([212.32.16.79] helo=mailgate)
by relay4.ftech.net with esmtp (Exim 3.22-ftech-p6.1 #9)
id 169TKB-0005te-00
for [email]; Thu, 29 Nov 2001 15:42:07 +0000
Received: from [89.0.0.95] by (MailGate 3.5.165) with ESMTP; Thu, 29 Nov 2001 15:42:23 +0000
Received: by warhol with Internet Mail Service (5.5.2448.0)
id ; Thu, 29 Nov 2001 15:40:30 -0000
Message-ID:
From: Vincent Penquerc'h <[email]>
To: Allegro Developer <[email]>
Date: Thu, 29 Nov 2001 15:40:29 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/alternative;
boundary="----_=_NextPart_001_01C178EC.2CCEB930"
Subject: RE: [AD] Proposed changes for Allegro 5 (6?)
Precedence: bulk
Sender: conductors-[email]
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
------_=_NextPart_001_01C178EC.2CCEB930
Content-Type: text/plain;
charset="windows-1252"
> they can even have different sizeof()'s. Can't we do something like:
>
> typedef void *al_video_memory_pointer;
I support this.
In addition, this makes me think that, eg, in BITMAP, dat and lines are of
different types if I recall well, and both are character types. They also
could do with retyping, as they can point to 8 bit, but also 16, 24, 32 bit
data, so a character type begs for mistakenly being dereferenced. Though it
wouldn't lead to a crash in this case.
--
Vincent Penquerc'h
------_=_NextPart_001_01C178EC.2CCEB930
Content-Type: text/html;
charset="windows-1252"
RE: [AD] Proposed changes for Allegro 5 (6?)
> they can even have different sizeof()'s. Can't we do something like:
>
> typedef void *al_video_memory_pointer;
I support this.
In addition, this makes me think that, eg, in BITMAP, dat and lines are of
different types if I recall well, and both are character types. They also
could do with retyping, as they can point to 8 bit, but also 16, 24, 32 bit
data, so a character type begs for mistakenly being dereferenced. Though it
wouldn't lead to a crash in this case.
--
Vincent Penquerc'h
------_=_NextPart_001_01C178EC.2CCEB930--
From - Thu Nov 29 17:17:08 2001
X-UIDL: 17612-968516558
X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Return-Path:
Received: from VL-MS-MR002.sc1.videotron.ca ([10.23.32.72]) by
VL-MS-MS002.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNKL1I02.G3R for <[email]>; Thu,
29 Nov 2001 11:12:54 -0500
Received: from canvaslink.com ([216.47.35.50]) by
VL-MS-MR002.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNKL1H00.QYQ for <[email]>; Thu,
29 Nov 2001 11:12:53 -0500
Received: from alfa.srnet.cz [62.24.72.242] by canvaslink.com with ESMTP
(SMTPD32-6.00) id AECC16A403A8; Thu, 29 Nov 2001 11:14:04 -0500
Received: from localhost (stepan@localhost)
by alfa.srnet.cz (8.10.2/8.10.2) with ESMTP id fATGAZc02556
for <[email]>; Thu, 29 Nov 2001 17:10:35 +0100
Date: Thu, 29 Nov 2001 17:10:35 +0100 (CET)
From: Stepan Roh <[email]>
X-Sender: <[email]>
To: Allegro Developers List <[email]>
In-Reply-To: <[email]>
Message-ID:
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: Re: [AD] Proposed changes for Allegro 5 (6?)
Precedence: bulk
Sender: conductors-[email]
On Thu, 29 Nov 2001, Sven Sandberg wrote:
> Stepan Roh wrote:
> > But in-source documentation is good thing.
I was talking as Java programmer where packages and interfaces solve most
of your problems.
> There are some problems with it too:
> - Is it possible to make sections be structured another way than the
> source files? It would be confusing if there was one section for the
> functions in gfx.c and another for the functions in graphics.c, or if
> load_bmp(), load_pcx() etc were in different sections.
> - Some functions are defined in different files depending on which
> platform they are on, so there's no unique natural place to put the
> documentation on.
> - allegro._tx contains several generic sections that discuss
> programming principles (e.g. "Bitmap objects"), or non-api stuff (e.g.
> "Makefile targets"), that would not fit in naturally in any source file.
> - allegro._tx is not the only file generated by makedoc: there are
> totally 8 files mathching allegro/docs/src/*._tx. So we need something
> to compile help that does not come from a source file anyway.
In-source documentation could be add-on only. Maybe hack makedoc to be
able to parse sources and found function descriptions? Like :
@source_parse src/dir/source.c:function_name
But that is too complicated to do.
Have a nice day.
Stepan Roh
From - Thu Nov 29 17:17:09 2001
X-UIDL: 17614-968516558
X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Return-Path:
Received: from VL-MS-MR003.sc1.videotron.ca ([10.23.32.73]) by
VL-MS-MS002.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNKOY202.Z76 for <[email]>; Thu,
29 Nov 2001 12:37:14 -0500
Received: from canvaslink.com ([216.47.35.50]) by
VL-MS-MR003.sc1.videotron.ca (Netscape Messaging Server 4.15
MR003 Jul 24 2001 16:23:26) with ESMTP id GNKOY101.BQ7 for
<[email]>; Thu, 29 Nov 2001 12:37:13 -0500
Received: from finch-post-12.mail.demon.net [194.217.242.41] by canvaslink.com with ESMTP
(SMTPD32-6.00) id A28F148D0348; Thu, 29 Nov 2001 12:38:23 -0500
Received: from lwithers.demon.co.uk ([194.222.80.1])
by finch-post-12.mail.demon.net with esmtp (Exim 2.12 #1)
id 169V5F-0002Lh-0C
for [email]; Thu, 29 Nov 2001 17:34:50 +0000
Message-ID:
Date: Thu, 29 Nov 2001 16:50:44 +0000
To: [email]
From: Laurence Withers <[email]>
References: <[email]> <[email]>
<[email]> <[email]>
<[email]>
In-Reply-To: <[email]>
MIME-Version: 1.0
Content-Type: multipart/signed;boundary="=_Turnpike_sRQW2FAZdmB8U+qZ=";
protocol="application/pgp-signature";micalg=pgp-sha1
X-Mailer: Turnpike Integrated Version 5.01 S
Subject: Re: [AD] Proposed changes for Allegro 5 (6?)
Precedence: bulk
Sender: conductors-[email]
This is a PGP signed message sent according to RFC2015 [PGP/MIME]
--=_Turnpike_sRQW2FAZdmB8U+qZ=
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
In reply to Javier Gonz=E1lez <[email]>:
>Totally agree, btw, methinks allegro 5 should include code to play
>cd audiotracks
>(sorry, there are just so many things i wonder when i think of a new alleg=
ro
>version =3D)
Use libcda (see Peter's website).
Bye for now,
--=20
Laurence Withers, [email]
http://www.lwithers.demon.co.uk/
--=_Turnpike_sRQW2FAZdmB8U+qZ=
Content-Type: application/pgp-signature
Content-Disposition: attachment; filename=signature.asc
-----BEGIN PGP SIGNATURE-----
Version: PGPsdk version 1.7.1
iQA/AwUBPAZnZGbrT6QxxsGNEQJBQACfSI0azDH2ppXlUC1ofzDWZ31LmAEAoLOq
EkkKj1tpJbu0zfBpmgsxzRAP
=CLu7
-----END PGP SIGNATURE-----
--=_Turnpike_sRQW2FAZdmB8U+qZ=--
From - Thu Nov 29 17:17:10 2001
X-UIDL: 17617-968516558
X-Mozilla-Status: 0013
X-Mozilla-Status2: 00000000
Return-Path:
Received: from VL-MS-MR003.sc1.videotron.ca ([10.23.32.73]) by
VL-MS-MS002.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNKT0M03.J1O for <[email]>; Thu,
29 Nov 2001 14:05:10 -0500
Received: from canvaslink.com ([216.47.35.50]) by
VL-MS-MR003.sc1.videotron.ca (Netscape Messaging Server 4.15
MR003 Jul 24 2001 16:23:26) with ESMTP id GNKT0M01.N2L for
<[email]>; Thu, 29 Nov 2001 14:05:10 -0500
Received: from pedos.es [212.170.193.45] by canvaslink.com with ESMTP
(SMTPD32-6.00) id A70A6199032E; Thu, 29 Nov 2001 14:05:46 -0500
Received: from gregorio by pedos.es with local (Exim 3.12 #5 (Mega-Debian))
id 169R0g-0000KM-00
for <[email]>; Thu, 29 Nov 2001 14:13:50 +0100
Date: Thu, 29 Nov 2001 14:13:50 +0100
From: Grzegorz Adam Hankiewicz <[email]>
To: [email]
Message-ID: <[email]>
Mail-Followup-To: [email]
References: <[email]> <[email]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <[email]>; from [email] on Wed, Nov 28, 2001 at 06:33:04PM -0500
Subject: Re: [AD] Proposed changes for Allegro 5 (6?)
Precedence: bulk
Sender: conductors-[email]
On Wed, Nov 28, 2001 at 06:33:04PM -0500, Bob wrote:
> > - network: why not use something like libnet?
>
> Because libnet is not being updated :)
Surely George can say something about that :)
> Really, its only for completion of Allegro - it does abstracts everything
> else needed to make a game, so why not networks?
Because network is something which really really really is not needed in
lots of games, just take a look at allegro.cc. I understand however that
today the trend is to move towards multiplayer(only) games, but since
networking is really hard to do properly as well, I think it deserves
it's own library with proper documentation, examples, etc.
Also, if you wanted to only use networking in the future, you would be
'forced' to include Allegro as well, no matter how modular the interface
would be, and if it's modular, why melt both libs?
--
Grzegorz Adam Hankiewicz [email] http://gradha.infierno.org/
From - Thu Nov 29 17:17:11 2001
X-UIDL: 17619-968516558
X-Mozilla-Status: 0013
X-Mozilla-Status2: 00000000
Return-Path:
Received: from VL-MS-MR004.sc1.videotron.ca ([10.23.32.74]) by
VL-MS-MS002.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNKUKQ05.58K for <[email]>; Thu,
29 Nov 2001 14:38:50 -0500
Received: from canvaslink.com ([216.47.35.50]) by
VL-MS-MR004.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNKUKQ02.GUW for <[email]>; Thu,
29 Nov 2001 14:38:50 -0500
Received: from pedos.es [212.170.193.45] by canvaslink.com with ESMTP
(SMTPD32-6.00) id A70E619A032E; Thu, 29 Nov 2001 14:05:50 -0500
Received: from gregorio by pedos.es with local (Exim 3.12 #5 (Mega-Debian))
id 169RhR-0000L5-00
for <[email]>; Thu, 29 Nov 2001 14:58:01 +0100
Date: Thu, 29 Nov 2001 14:58:00 +0100
From: Grzegorz Adam Hankiewicz <[email]>
To: Allegro Conductors <[email]>
Message-ID: <[email]>
Mail-Followup-To: Allegro Conductors <[email]>
References: <[email]> <[email]> <[email]>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
User-Agent: Mutt/1.2.5i
In-Reply-To: <[email]>; from [email] on Thu, Nov 29, 2001 at 01:15:30AM +0100
Subject: Re: [AD] Proposed changes for Allegro 5 (6?)
Precedence: bulk
Sender: conductors-[email]
On Thu, Nov 29, 2001 at 01:15:30AM +0100, Javier González wrote:
> > 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 ;)
Dropping support for a specific OS should not be taken as a democratic vote, where
the majority wins, or we would have only a windows version of Allegro due to the
monopoly of Mr Gates.
> I must agree with this... either if we want or not DOS will be totally dead
> in say from 6 months to 1 year max
People have been saying that since windows 95. Why don't we do the
following: instead of trying to foresee the future, let's agree that
DOS will be dropped whenever djgpp is not longer maintained. We can talk
again about this subject whenever that happens.
> Btw, about the name, packfiles... could we name it something like
> AllegroFiles or AllegroBuffers?...
Allegro should not fall to the devil side (ahack explains this).
--
Grzegorz Adam Hankiewicz [email] http://gradha.infierno.org/
From - Thu Nov 29 17:51:31 2001
X-UIDL: 17624-968516558
X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Return-Path:
Received: from VL-MS-MR004.sc1.videotron.ca ([10.23.32.74]) by
VL-MS-MS002.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNL3HX02.7B6 for <[email]>; Thu,
29 Nov 2001 17:51:33 -0500
Received: from canvaslink.com ([216.47.35.50]) by
VL-MS-MR004.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNL3HW02.T64 for <[email]>; Thu,
29 Nov 2001 17:51:32 -0500
Received: from VL-MS-MR001.sc1.videotron.ca [24.201.245.36] by canvaslink.com with ESMTP
(SMTPD32-6.00) id AB412F4B031C; Thu, 29 Nov 2001 17:48:33 -0500
Received: from videotron.ca ([24.202.201.127]) by
VL-MS-MR001.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNL37404.I5N for <[email]>; Thu,
29 Nov 2001 17:45:04 -0500
Message-ID: <[email]>
Date: Thu, 29 Nov 2001 17:45:01 -0500
From: Bob <[email]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.6) Gecko/20011120
X-Accept-Language: en-us
MIME-Version: 1.0
To: [email]
References: <[email]> <[email]> <[email]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [AD] Proposed changes for Allegro 5 (6?)
Precedence: bulk
Sender: conductors-[email]
Grzegorz Adam Hankiewicz wrote:
[snip]
>>Really, its only for completion of Allegro - it does abstracts everything
>>else needed to make a game, so why not networks?
>>
>
> Because network is something which really really really is not needed in
> lots of games, just take a look at allegro.cc. I understand however that
> today the trend is to move towards multiplayer(only) games, but since
> networking is really hard to do properly as well, I think it deserves
> it's own library with proper documentation, examples, etc.
Perhaps Allegro can only have basic operations, like open communication
port, send bytes, receive bytes, close port. Anything more fancy can be
implemented in add-ons.
--
- Robert J Ohannessian
"Microsoft code is probably O(n^20)" (my CS prof)
http://pages.infinit.net/voidstar/
From - Thu Nov 29 17:57:18 2001
X-UIDL: 17625-968516558
X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Return-Path:
Received: from VL-MS-MR001.sc1.videotron.ca ([10.23.32.71]) by
VL-MS-MS002.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNL3MP02.HP7 for <[email]>; Thu,
29 Nov 2001 17:54:25 -0500
Received: from canvaslink.com ([216.47.35.50]) by
VL-MS-MR001.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNL3MO02.ZDC for <[email]>; Thu,
29 Nov 2001 17:54:24 -0500
Received: from VL-MS-MR002.sc1.videotron.ca [24.201.245.36] by canvaslink.com with ESMTP
(SMTPD32-6.00) id AC1C2F79031C; Thu, 29 Nov 2001 17:52:12 -0500
Received: from videotron.ca ([24.202.201.127]) by
VL-MS-MR002.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNL3D701.KLN for <[email]>; Thu,
29 Nov 2001 17:48:43 -0500
Message-ID: <[email]>
Date: Thu, 29 Nov 2001 17:48:40 -0500
From: Bob <[email]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.6) Gecko/20011120
X-Accept-Language: en-us
MIME-Version: 1.0
To: [email]
References: <[email]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [AD] Proposed changes for Allegro 5 (6?)
Precedence: bulk
Sender: conductors-[email]
Sven Sandberg wrote:
> Stepan Roh wrote:
>
>>But in-source documentation is good thing.
>>
>
> There are some problems with it too:
> - Is it possible to make sections be structured another way than the
> source files?
Yes. Use \insection (not portable to JavaDoc).
> - Some functions are defined in different files depending on which
> platform they are on, so there's no unique natural place to put the
> documentation on.
You can document it in some include file. As long as there's a prototype to
it, then Doxygen will find it. Or even better, have al_doxygen.h file, which
has all the docs to those functions, but only gets included #ifdef DOXYGEN
(defined by Doxygen parser).
> - allegro._tx contains several generic sections that discuss
> programming principles (e.g. "Bitmap objects"), or non-api stuff (e.g.
> "Makefile targets"), that would not fit in naturally in any source file.
You can include other files. For example, AllegroGL includes 'mainfile.foo'
(or something like that), which documents installation procedure and some
other basic stuff. The .txt files can be generated from there, or inversely,
this file can be generated by makedoc.
> - allegro._tx is not the only file generated by makedoc: there are
> totally 8 files mathching allegro/docs/src/*._tx. So we need something
> to compile help that does not come from a source file anyway.
See above.
--
- Robert J Ohannessian
"Microsoft code is probably O(n^20)" (my CS prof)
http://pages.infinit.net/voidstar/
From - Thu Nov 29 17:57:18 2001
X-UIDL: 17626-968516558
X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Return-Path:
Received: from VL-MS-MR001.sc1.videotron.ca ([10.23.32.71]) by
VL-MS-MS002.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNL3OI05.CSR for <[email]>; Thu,
29 Nov 2001 17:55:30 -0500
Received: from canvaslink.com ([216.47.35.50]) by
VL-MS-MR001.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNL3OI00.09G for <[email]>; Thu,
29 Nov 2001 17:55:30 -0500
Received: from VL-MS-MR004.sc1.videotron.ca [24.201.245.36] by canvaslink.com with ESMTP
(SMTPD32-6.00) id AADA2F39031C; Thu, 29 Nov 2001 17:46:50 -0500
Received: from videotron.ca ([24.202.201.127]) by
VL-MS-MR004.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNL34A01.M5P for <[email]>; Thu,
29 Nov 2001 17:43:22 -0500
Message-ID: <[email]>
Date: Thu, 29 Nov 2001 17:43:16 -0500
From: Bob <[email]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.6) Gecko/20011120
X-Accept-Language: en-us
MIME-Version: 1.0
To: [email]
References: <[email]> <[email]> <[email]> <[email]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [AD] Proposed changes for Allegro 5 (6?)
Precedence: bulk
Sender: conductors-[email]
Grzegorz Adam Hankiewicz wrote:
> On Thu, Nov 29, 2001 at 01:15:30AM +0100, Javier González wrote:
>
>>>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 ;)
>>>
>
> Dropping support for a specific OS should not be taken as a democratic vote, where
> the majority wins, or we would have only a windows version of Allegro due to the
> monopoly of Mr Gates.
And I agree. However, I'd hate to see DOS being the large boulder attached
to Allegro. If all the neat stuff can be done from DOS, then you have my
vote to keep it. Otherwise, it can stay with Allegro 4.
>>I must agree with this... either if we want or not DOS will be totally dead
>>in say from 6 months to 1 year max
>>
>
> People have been saying that since windows 95.
Yes, and with win2k/xp, it's becoming even more of a pain to run DOS
programs. I'm keeping my win95 partition alive soulely for FenixBlade :)
> Why don't we do the
> following: instead of trying to foresee the future, let's agree that
> DOS will be dropped whenever djgpp is not longer maintained. We can talk
> again about this subject whenever that happens.
If we do'nt drop DOS, then, if ever some feature pops up that Allegro cannot
(easily) emulate in DOS, could we have a non-portable-to-DOS program? That
is, we use feature X of modern operating system Y, which can't be done in
DOS without writting our own OS, then can we still include it in Allegro,
but make programs built on it not portable to DOS?
--
- Robert J Ohannessian
"Microsoft code is probably O(n^20)" (my CS prof)
http://pages.infinit.net/voidstar/
From - Thu Nov 29 18:02:18 2001
X-UIDL: 17627-968516558
X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Return-Path:
Received: from VL-MS-MR001.sc1.videotron.ca ([10.23.32.71]) by
VL-MS-MS002.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNL3Z104.5JB for <[email]>; Thu,
29 Nov 2001 18:01:49 -0500
Received: from canvaslink.com ([216.47.35.50]) by
VL-MS-MR001.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNL3Z000.T93 for <[email]>; Thu,
29 Nov 2001 18:01:48 -0500
Received: from VL-MS-MR001.sc1.videotron.ca [24.201.245.36] by canvaslink.com with ESMTP
(SMTPD32-6.00) id ADE42E2C03EE; Thu, 29 Nov 2001 17:59:48 -0500
Received: from videotron.ca ([24.202.201.127]) by
VL-MS-MR001.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNL3PV02.0BO for <[email]>; Thu,
29 Nov 2001 17:56:19 -0500
Message-ID: <[email]>
Date: Thu, 29 Nov 2001 17:56:16 -0500
From: Bob <[email]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.6) Gecko/20011120
X-Accept-Language: en-us
MIME-Version: 1.0
To: [email]
References: <[email]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [AD] Proposed changes for Allegro 5 (6?)
Precedence: bulk
Sender: conductors-[email]
Doug Eleveld wrote:
>>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.
>>
>
> Just a thought that if you combine all these load* functions into one, that code to read in all the possible types gets included in your executable, even if it can never been used. A good example of this is jpeg reading. Jpeg decoding is quite a bit of code and including it in load_bitmap will make load_bitmap a very big function.
>
> Please still give access to the load* functions, then the user can decide whether they want the bloat or not. Forcing them to use a load_bitmap function does not give them any choice but to include code in their executable that cannot be run.
>
> I think that this is actually a hard problem to make very transparent to the user. The only thing I see working well is some kind of registering function or macros. The users have to explicitly choose what decoding functions they want in the executable, but at least they are not forced to include useless code.
>
> Allegro executables are big enough. Lets try not to make them any bigger.
Firstly, if you already use load_bitmap(), you won't notice any change in
your executable size - all the bitmap loaders get included anyway. Secondly,
we could make the option of you deciding which of the default format to
include, kind like selecting which of the video drivers you want to be
compiled in.
Allegro also doesn't nativaly support jpeg. If you were to use a jpeg add-on
(let's say), then the add-on can register its format with load_bitmap so
that calls to load_bitmap can also load *.jpg on top of every other format.
--
- Robert J Ohannessian
"Microsoft code is probably O(n^20)" (my CS prof)
http://pages.infinit.net/voidstar/
From - Thu Nov 29 18:02:18 2001
X-UIDL: 17628-968516558
X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Return-Path:
Received: from VL-MS-MR002.sc1.videotron.ca ([10.23.32.72]) by
VL-MS-MS002.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNL3ZE03.LFX for <[email]>; Thu,
29 Nov 2001 18:02:02 -0500
Received: from canvaslink.com ([216.47.35.50]) by
VL-MS-MR002.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNL3ZE00.7NE for <[email]>; Thu,
29 Nov 2001 18:02:02 -0500
Received: from oxmail.ox.ac.uk [163.1.2.33] by canvaslink.com with ESMTP
(SMTPD32-6.00) id ADF12E2D03EE; Thu, 29 Nov 2001 18:00:01 -0500
Received: from athens.robots.ox.ac.uk ([163.1.8.248])
by oxmail.ox.ac.uk with esmtp (Exim 3.12 #1)
id 169a6a-0005Mw-04
for [email]; Thu, 29 Nov 2001 22:56:32 +0000
Received: from arragon.robots.ox.ac.uk (arragon [163.1.6.216])
by athens.robots.ox.ac.uk (8.8.8+Sun/8.8.8) with ESMTP id WAA01691
for <[email]>; Thu, 29 Nov 2001 22:56:32 GMT
Received: by arragon.robots.ox.ac.uk
id WAA03543; Thu, 29 Nov 2001 22:56:32 GMT
Date: Thu, 29 Nov 2001 22:56:32 +0000
From: Neil Townsend <[email]>
To: [email]
Message-ID: <[email]>
Mail-Followup-To: Neil Townsend , [email]
References: <[email]> <[email]> <[email]> <[email]> <[email]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <[email]>; from [email] on Thu, Nov 29, 2001 at 05:43:16PM -0500
Subject: Re: [AD] Proposed changes for Allegro 5 (6?)
Precedence: bulk
Sender: conductors-[email]
>>>>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 someone who does use a pure DOS system I think I'd better put
my hand up and explain why.
Whilst DOS may be old, cranky and messy it is also very predictable
and offers you complete control of the CPU. I suspect that there are
many DOS based systems out there for which a transition to windows
would be a great waste of time.
>From my point of view, removing DOS from allegro would be a disaster,
I suspect that I'm not the only one who thinks so.
Neil
From - Thu Nov 29 20:19:20 2001
X-UIDL: 17629-968516558
X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Return-Path:
Received: from VL-MS-MR003.sc1.videotron.ca ([10.23.32.73]) by
VL-MS-MS002.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNL50305.GYK for <[email]>; Thu,
29 Nov 2001 18:24:03 -0500
Received: from canvaslink.com ([216.47.35.50]) by
VL-MS-MR003.sc1.videotron.ca (Netscape Messaging Server 4.15
MR003 Jul 24 2001 16:23:26) with ESMTP id GNL50203.2E5 for
<[email]>; Thu, 29 Nov 2001 18:24:02 -0500
Received: from VL-MS-MR003.sc1.videotron.ca [24.201.245.36] by canvaslink.com with ESMTP
(SMTPD32-6.00) id A2EDEF2032A; Thu, 29 Nov 2001 18:21:17 -0500
Received: from videotron.ca ([24.202.201.127]) by
VL-MS-MR003.sc1.videotron.ca (Netscape Messaging Server 4.15
MR003 Jul 24 2001 16:23:26) with ESMTP id GNL4NZ02.VM7 for
<[email]>; Thu, 29 Nov 2001 18:16:47 -0500
Message-ID: <[email]>
Date: Thu, 29 Nov 2001 18:16:44 -0500
From: Bob <[email]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.6) Gecko/20011120
X-Accept-Language: en-us
MIME-Version: 1.0
To: [email]
References: <28A7C352840AD511AC9400508BE70AC24FFDB7@FRUITMACHINE>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [AD] Proposed changes for Allegro 5 (6?)
Precedence: bulk
Sender: conductors-[email]
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/
From - Thu Nov 29 20:19:21 2001
X-UIDL: 17631-968516558
X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Return-Path:
Received: from VL-MS-MR002.sc1.videotron.ca ([10.23.32.72]) by
VL-MS-MS002.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNL5PP00.ELQ for <[email]>; Thu,
29 Nov 2001 18:39:25 -0500
Received: from canvaslink.com ([216.47.35.50]) by
VL-MS-MR002.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNL5PP01.9IL for <[email]>; Thu,
29 Nov 2001 18:39:25 -0500
Received: from VL-MS-MR001.sc1.videotron.ca [24.201.245.36] by canvaslink.com with ESMTP
(SMTPD32-6.00) id AE9AD30032A; Thu, 29 Nov 2001 18:02:50 -0500
Received: from videotron.ca ([24.202.201.127]) by
VL-MS-MR001.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNL3UX00.RBG for <[email]>; Thu,
29 Nov 2001 17:59:21 -0500
Message-ID: <[email]>
Date: Thu, 29 Nov 2001 17:59:18 -0500
From: Bob <[email]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.6) Gecko/20011120
X-Accept-Language: en-us
MIME-Version: 1.0
To: [email]
References: <28A7C352840AD511AC9400508BE70AC24FFDB6@FRUITMACHINE>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [AD] Proposed changes for Allegro 5 (6?)
Precedence: bulk
Sender: conductors-[email]
Shawn Hargreaves wrote:
> Bob writes:
> >>> - `bmp_read8()' & co currently use longs instead of pointers.
> >>
> >> The thinking behind using longs is that this makes the pointers
> >> opaque, ie. can't be dereferenced directly by the user
> >
> > Those functions are of the fairly advanced level, so I don't
> > see users who haven't understood pointers use them :)
>
> The problem is not so much programmer ignorance, as portability.
[snip - explication]
Ah, I see now what you meant.
I like the 'typedef void* bitmap_ptr' idea though, and it seems to 'fix'
what was wrong with having a regular point. If this ok with you?
Of course, users can still cast back to chart/short/int, just like they can
cast the int to a pointer and read/write from there.
Examples of how to make proper use of the functions should be in the
documentation, instead of the example programs :)
--
- Robert J Ohannessian
"Microsoft code is probably O(n^20)" (my CS prof)
http://pages.infinit.net/voidstar/
From - Thu Nov 29 20:19:22 2001
X-UIDL: 17632-968516558
X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Return-Path:
Received: from VL-MS-MR004.sc1.videotron.ca ([10.23.32.74]) by
VL-MS-MS002.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNL6DN04.4OP for <[email]>; Thu,
29 Nov 2001 18:53:47 -0500
Received: from canvaslink.com ([216.47.35.50]) by
VL-MS-MR004.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNL6DM04.66D for <[email]>; Thu,
29 Nov 2001 18:53:46 -0500
Received: from pedos.es [193.152.161.130] by canvaslink.com with ESMTP
(SMTPD32-6.00) id AA243E8602BE; Thu, 29 Nov 2001 18:52:04 -0500
Received: from gregorio by pedos.es with local (Exim 3.12 #5 (Mega-Debian))
id 169aty-0000VO-00
for <[email]>; Fri, 30 Nov 2001 00:47:34 +0100
Date: Fri, 30 Nov 2001 00:47:34 +0100
From: Grzegorz Adam Hankiewicz <[email]>
To: [email]
Message-ID: <[email]>
Mail-Followup-To: [email]
References: <[email]> <[email]> <[email]> <[email]> <[email]> <[email]> <[email]> <[email]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <[email]>; from [email] on Thu, Nov 29, 2001 at 05:43:16PM -0500
Subject: Re: [AD] Proposed changes for Allegro 5 (6?)
Precedence: bulk
Sender: conductors-[email]
On Thu, Nov 29, 2001 at 05:43:16PM -0500, Bob wrote:
> And I agree. However, I'd hate to see DOS being the large boulder attached
> to Allegro. If all the neat stuff can be done from DOS, then you have my
> vote to keep it. Otherwise, it can stay with Allegro 4.
Always take a look from the other side: would you drop hardware scrolling
or high precision timing just because Windows can't do "the neat stuff"?
> If we do'nt drop DOS, then, if ever some feature pops up that Allegro cannot
> (easily) emulate in DOS, could we have a non-portable-to-DOS program?
With the above you already have nonportable programs to non-DOS systems...
Anyway, what I was meaning is that most of the proposed things didn't
look to me imposible to do for DOS, except for the 3d acceleration stuff.
> > Because network is something which really really really is not needed...
>
> Perhaps Allegro can only have basic operations, like open communication
> port, send bytes, receive bytes, close port. Anything more fancy can be
> implemented in add-ons.
That would end up being like the basic 3d allegro versus
allegrogl. Packfile routines are cool, but most users go directly for
high-level datafiles.
--
Grzegorz Adam Hankiewicz [email] http://gradha.infierno.org/
From - Thu Nov 29 20:19:23 2001
X-UIDL: 17635-968516558
X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Return-Path:
Received: from VL-MS-MR003.sc1.videotron.ca ([10.23.32.73]) by
VL-MS-MS002.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNL8PT05.5MK for <[email]>; Thu,
29 Nov 2001 19:44:17 -0500
Received: from canvaslink.com ([216.47.35.50]) by
VL-MS-MR003.sc1.videotron.ca (Netscape Messaging Server 4.15
MR003 Jul 24 2001 16:23:26) with ESMTP id GNL8PS02.TT3 for
<[email]>; Thu, 29 Nov 2001 19:44:16 -0500
Received: from mbox.wins.uva.nl [146.50.16.20] by canvaslink.com with ESMTP
(SMTPD32-6.00) id ACBE806035A; Thu, 29 Nov 2001 19:03:10 -0500
Received: from stol-117-137.uva.studentennet.nl [145.98.117.137]
by mbox.wins.uva.nl with SMTP (sendmail 8.10.2/config 11.20).
id fATNwT320744; Fri, 30 Nov 2001 00:58:30 +0100 (MET)
X-Organisation: Faculty of Science, University of Amsterdam, The Netherlands
X-URL: http://www.science.uva.nl/
Date: Fri, 30 Nov 2001 00:22:38 +0100
From: Evert Glebbeek <[email]>
To: Allegro Developers list <[email]>
Message-Id: <[email]>
In-Reply-To: <[email]>
References: <[email]>
<[email]>
<[email]>
<[email]>
<[email]>
<[email]>
Organization: University of Amsterdam
X-Mailer: Sylpheed version 0.6.5 (GTK+ 1.2.10; i686-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Subject: Re: [AD] Proposed changes for Allegro 5 (6?)
Precedence: bulk
Sender: conductors-[email]
On Thu, 29 Nov 2001 22:56:32 +0000 Neil Townsend <[email]> wrote:
>>>>>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 someone who does use a pure DOS system I think I'd better put
>my hand up and explain why.
>
>Whilst DOS may be old, cranky and messy it is also very predictable
>and offers you complete control of the CPU. I suspect that there are
>many DOS based systems out there for which a transition to windows
>would be a great waste of time.
>
>From my point of view, removing DOS from allegro would be a disaster,
>I suspect that I'm not the only one who thinks so.
I sometimes use DOS for a smilar reason: it's fast.
I once ran a series of Monte-Carlo simulations for something or other, and under
windows, the DJGPP version ran about 10% slower than under pure DOS, and with
MinGW it was even slower.
While I doubt games require the processor power that program did, Allegro is
also used for other things besides game programming.
From - Thu Nov 29 22:44:27 2001
X-UIDL: 17642-968516558
X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Return-Path:
Received: from VL-MS-MR002.sc1.videotron.ca ([10.23.32.72]) by
VL-MS-MS002.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNLEPB03.H39 for <[email]>; Thu,
29 Nov 2001 21:53:35 -0500
Received: from canvaslink.com ([216.47.35.50]) by
VL-MS-MR002.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNLEPA04.RUJ for <[email]>; Thu,
29 Nov 2001 21:53:34 -0500
Received: from pd4mo2so.prod.shaw.ca [24.71.223.10] by canvaslink.com with ESMTP
(SMTPD32-6.00) id A5416219032E; Thu, 29 Nov 2001 21:56:01 -0500
Received: from pd5mr1so.prod.shaw.ca
(pd5mr1so-qfe3.prod.shaw.ca [10.0.141.232]) by l-daemon
(iPlanet Messaging Server 5.0 Patch 2 (built Dec 14 2000))
with ESMTP id <0GNL00MD5ELWQX@l-daemon> for [email]; Thu,
29 Nov 2001 19:51:32 -0700 (MST)
Received: from pn2ml5so (pn2ml5so-qfe0.prod.shaw.ca [10.0.121.149])
by l-daemon (iPlanet Messaging Server 5.1 (built May 7 2001))
with ESMTP id <0GNL006OPELW0K@l-daemon> for [email]; Thu,
29 Nov 2001 19:51:32 -0700 (MST)
Received: from there ([24.65.100.169])
by l-daemon (iPlanet Messaging Server 5.0 Patch 2 (built Dec 14 2000))
with SMTP id <0GNL00HP7ELW6T@l-daemon> for [email]; Thu,
29 Nov 2001 19:51:32 -0700 (MST)
Date: Thu, 29 Nov 2001 19:51:26 -0700
From: Thomas Fjellstrom <[email]>
In-reply-to: <28A7C352840AD511AC9400508BE70AC24FFDB7@FRUITMACHINE>
To: [email]
Reply-to: [email]
Message-id: <0GNL00HP8ELW6T@l-daemon>
MIME-version: 1.0
X-Mailer: KMail [version 1.3.2]
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT
References: <28A7C352840AD511AC9400508BE70AC24FFDB7@FRUITMACHINE>
Subject: Re: [AD] Proposed changes for Allegro 5 (6?)
Precedence: bulk
Sender: conductors-[email]
On November 29, 2001 04:00 am, Shawn Hargreaves wrote:
[snip]
First I have to say I agree totally with Shawn.
> It would be very feasible
> (actually I think quite easy) to get Allegro running on
> PalmOS
Second, I was playing with Palm a while ago and this would be a seriously fun
project, Its too bad that all I have is an old US Robotics Palm Pilot
Personal. I doubt it has enough memory for the lib alone.
So, if anyone gets the hint ;) Id be more than willing to try and port
allegro to PalmOS durring my month off. (starting Dec. 7)
[snip]
--
Thomas Fjellstrom
[email]
http://strangesoft.net
From - Thu Nov 29 22:44:27 2001
X-UIDL: 17643-968516558
X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Return-Path: <[email]>
Received: from VL-MS-MR003.sc1.videotron.ca ([10.23.32.73]) by
VL-MS-MS002.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNLFUS05.20N for <[email]>; Thu,
29 Nov 2001 22:18:29 -0500
Received: from mail19.bigmailbox.com ([209.132.220.50]) by
VL-MS-MR003.sc1.videotron.ca (Netscape Messaging Server 4.15
MR003 Jul 24 2001 16:23:26) with ESMTP id GNLFUR02.6UU for
<[email]>; Thu, 29 Nov 2001 22:18:27 -0500
Received: (from www@localhost)
by mail19.bigmailbox.com (8.10.0/8.10.0) id fAU3IP530219;
Thu, 29 Nov 2001 19:18:25 -0800
Date: Thu, 29 Nov 2001 19:18:25 -0800
Message-Id: <[email]>
Content-Type: text/plain
Content-Disposition: inline
Content-Transfer-Encoding: binary
X-Mailer: MIME-tools 4.104 (Entity 4.116)
Mime-Version: 1.0
X-Originating-Ip: [213.51.194.171]
From: "Doug Eleveld" <[email]>
To: [email]
Cc: [email]
Subject: RE: Re: [AD] Proposed changes for Allegro 5 (6?)
>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.
Just my 2 cents in the discussion. If Allegro drops DOS, I will drop Allegro. I use it for some model fitting and optimization programs and I still prefer to work in DOS. I also use it for some controller software that must run on old laptops, i.e. 386/486 machines. Simply because it's fast, simple, portable (under DOS or Windows), easy to use and works on old hardware. Shouldn't Allegro 5/6 also be these things? I guess it's up to other people to decide.
Doug Eleveld
btw, I'm drunk. I hope that I not too obvious. I guess I'll see tomorrow when I re-read this post...
------------------------------------------------------------
--== Sent via Deja.com ==--
http://www.deja.com/
From - Thu Nov 29 22:44:28 2001
X-UIDL: 17644-968516558
X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Return-Path:
Received: from VL-MS-MR004.sc1.videotron.ca ([10.23.32.74]) by
VL-MS-MS002.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNLFZM02.OYW for <[email]>; Thu,
29 Nov 2001 22:21:22 -0500
Received: from canvaslink.com ([216.47.35.50]) by
VL-MS-MR004.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNLFZJ04.7MW for <[email]>; Thu,
29 Nov 2001 22:21:19 -0500
Received: from mail19.bigmailbox.com [209.132.220.50] by canvaslink.com with ESMTP
(SMTPD32-6.00) id AB916383032E; Thu, 29 Nov 2001 22:22:57 -0500
Received: (from www@localhost)
by mail19.bigmailbox.com (8.10.0/8.10.0) id fAU3IP530219;
Thu, 29 Nov 2001 19:18:25 -0800
Date: Thu, 29 Nov 2001 19:18:25 -0800
Message-Id: <[email]>
Content-Type: text/plain
Content-Disposition: inline
Content-Transfer-Encoding: binary
X-Mailer: MIME-tools 4.104 (Entity 4.116)
Mime-Version: 1.0
X-Originating-Ip: [213.51.194.171]
From: "Doug Eleveld" <[email]>
To: [email]
Cc: [email]
Subject: RE: Re: [AD] Proposed changes for Allegro 5 (6?)
Precedence: bulk
Sender: conductors-[email]
>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.
Just my 2 cents in the discussion. If Allegro drops DOS, I will drop Allegro. I use it for some model fitting and optimization programs and I still prefer to work in DOS. I also use it for some controller software that must run on old laptops, i.e. 386/486 machines. Simply because it's fast, simple, portable (under DOS or Windows), easy to use and works on old hardware. Shouldn't Allegro 5/6 also be these things? I guess it's up to other people to decide.
Doug Eleveld
btw, I'm drunk. I hope that I not too obvious. I guess I'll see tomorrow when I re-read this post...
------------------------------------------------------------
--== Sent via Deja.com ==--
http://www.deja.com/
From - Thu Nov 29 22:44:28 2001
X-UIDL: 17645-968516558
X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Return-Path: <[email]>
Received: from VL-MS-MR003.sc1.videotron.ca ([10.23.32.73]) by
VL-MS-MS002.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNLGBE02.PUA for <[email]>; Thu,
29 Nov 2001 22:28:26 -0500
Received: from mail19.bigmailbox.com ([209.132.220.50]) by
VL-MS-MR003.sc1.videotron.ca (Netscape Messaging Server 4.15
MR003 Jul 24 2001 16:23:26) with ESMTP id GNLGBE03.I1L for
<[email]>; Thu, 29 Nov 2001 22:28:26 -0500
Received: (from www@localhost)
by mail19.bigmailbox.com (8.10.0/8.10.0) id fAU3SNq31085;
Thu, 29 Nov 2001 19:28:23 -0800
Date: Thu, 29 Nov 2001 19:28:23 -0800
Message-Id: <[email]>
Content-Type: text/plain
Content-Disposition: inline
Content-Transfer-Encoding: binary
X-Mailer: MIME-tools 4.104 (Entity 4.116)
Mime-Version: 1.0
X-Originating-Ip: [213.51.194.171]
From: "Doug Eleveld" <[email]>
To: [email]
Cc: [email]
Subject: RE: Re: [AD] Proposed changes for Allegro 5 (6?)
>Allegro also doesn't nativaly support jpeg. If you were to use a >jpeg add-on (let's say), then the add-on can register its format >with load_bitmap so that calls to load_bitmap can also load *.jpg on >top of every other format.
So then what makes jpeg different than BMP or PCX or TGA or whatever?
I personally would prefer all bitmap format loading functions to be handled in the same consistant way. Allegro 4 has some legacy code issues that can't be helped. Allegro 5/6 shouldn't make the same mistake. I just think it's a shame that code gets included without the consent or thought of the programmer. Allegro 5/6 executables could be *smaller* than Allegro 4 executables, with some good API design. I think that would be real progress.
Doug
------------------------------------------------------------
--== Sent via Deja.com ==--
http://www.deja.com/
From - Thu Nov 29 22:44:28 2001
X-UIDL: 17646-968516558
X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Return-Path:
Received: from VL-MS-MR003.sc1.videotron.ca ([10.23.32.73]) by
VL-MS-MS002.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNLGGV03.JMA for <[email]>; Thu,
29 Nov 2001 22:31:43 -0500
Received: from canvaslink.com ([216.47.35.50]) by
VL-MS-MR003.sc1.videotron.ca (Netscape Messaging Server 4.15
MR003 Jul 24 2001 16:23:26) with ESMTP id GNLGGU02.X05 for
<[email]>; Thu, 29 Nov 2001 22:31:42 -0500
Received: from mail19.bigmailbox.com [209.132.220.50] by canvaslink.com with ESMTP
(SMTPD32-6.00) id ADE76432032E; Thu, 29 Nov 2001 22:32:55 -0500
Received: (from www@localhost)
by mail19.bigmailbox.com (8.10.0/8.10.0) id fAU3SNq31085;
Thu, 29 Nov 2001 19:28:23 -0800
Date: Thu, 29 Nov 2001 19:28:23 -0800
Message-Id: <[email]>
Content-Type: text/plain
Content-Disposition: inline
Content-Transfer-Encoding: binary
X-Mailer: MIME-tools 4.104 (Entity 4.116)
Mime-Version: 1.0
X-Originating-Ip: [213.51.194.171]
From: "Doug Eleveld" <[email]>
To: [email]
Cc: [email]
Subject: RE: Re: [AD] Proposed changes for Allegro 5 (6?)
Precedence: bulk
Sender: conductors-[email]
>Allegro also doesn't nativaly support jpeg. If you were to use a >jpeg add-on (let's say), then the add-on can register its format >with load_bitmap so that calls to load_bitmap can also load *.jpg on >top of every other format.
So then what makes jpeg different than BMP or PCX or TGA or whatever?
I personally would prefer all bitmap format loading functions to be handled in the same consistant way. Allegro 4 has some legacy code issues that can't be helped. Allegro 5/6 shouldn't make the same mistake. I just think it's a shame that code gets included without the consent or thought of the programmer. Allegro 5/6 executables could be *smaller* than Allegro 4 executables, with some good API design. I think that would be real progress.
Doug
------------------------------------------------------------
--== Sent via Deja.com ==--
http://www.deja.com/
From - Fri Nov 30 09:31:30 2001
X-UIDL: 17663-968516558
X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Return-Path:
Received: from VL-MS-MR002.sc1.videotron.ca ([10.23.32.72]) by
VL-MS-MS002.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNM8L403.4D8 for <[email]>; Fri,
30 Nov 2001 08:39:04 -0500
Received: from canvaslink.com ([216.47.35.50]) by
VL-MS-MR002.sc1.videotron.ca (Netscape Messaging Server 4.15)
with ESMTP id GNM8L401.5CB for <[email]>; Fri,
30 Nov 2001 08:39:04 -0500
Received: from tele-post-20.mail.demon.net [194.217.242.20] by canvaslink.com with ESMTP
(SMTPD32-6.00) id AC81F34037A; Fri, 30 Nov 2001 08:41:21 -0500
Received: from lwithers.demon.co.uk ([194.222.80.1])
by tele-post-20.mail.demon.net with esmtp (Exim 2.12 #2)
id 169nqV-0004n2-0K
for [email]; Fri, 30 Nov 2001 13:36:52 +0000
Message-ID: <[email]>
Date: Fri, 30 Nov 2001 13:36:25 +0000
To: [email]
From: Laurence Withers <[email]>
References: <[email]>
<[email]>
<[email]> <[email]>
<[email]>
In-Reply-To: <[email]>
MIME-Version: 1.0
Content-Type: multipart/signed;boundary="=_Turnpike_c$T6NFAWt4B84zbw=";
protocol="application/pgp-signature";micalg=pgp-sha1
X-Mailer: Turnpike Integrated Version 5.01 S
Subject: Re: [AD] Proposed changes for Allegro 5 (6?)
Precedence: bulk
Sender: conductors-[email]
This is a PGP signed message sent according to RFC2015 [PGP/MIME]
--=_Turnpike_c$T6NFAWt4B84zbw=
Content-Type: text/plain;charset=us-ascii
Content-Transfer-Encoding: quoted-printable
In reply to Bob <[email]>:
>And I agree. However, I'd hate to see DOS being the large boulder attached=
=20
>to Allegro. If all the neat stuff can be done from DOS, then you have my=20
>vote to keep it. Otherwise, it can stay with Allegro 4.
But so what if neat stuff can't be done from DOS? Allegro isn't an
operating system, so it doesn't need to provide services which are non-
trivial to implement if the OS doesn't have them. For instance, as Shawn
said, embedded devices are where Allegro has been used commercially. But
they may not support color graphics, mouse, keyboard, sound, etc. That
doesn't mean we should just drop such platforms; simply programs which
*require* something that is not available won't work.
>If we do'nt drop DOS, then, if ever some feature pops up that Allegro cann=
ot=20
>(easily) emulate in DOS, could we have a non-portable-to-DOS program?=20
Yes, why not? Who cares if DOS can't (for instance) create a new
process; programs which require this can't be run on DOS. Get a better
OS... ;-)
Bye for now,
--=20
Laurence Withers, [email]
http://www.lwithers.demon.co.uk/
--=_Turnpike_c$T6NFAWt4B84zbw=
Content-Type: application/pgp-signature
Content-Disposition: attachment; filename=signature.asc
-----BEGIN PGP SIGNATURE-----
Version: PGPsdk version 1.7.1
iQA/AwUBPAeLWWbrT6QxxsGNEQLsoACeO1ClEHGNwwOuUkGr31I6gZqFH3cAoLwt
FY6JYLdMGAHJadRTtmEiZYyV
=P5hT
-----END PGP SIGNATURE-----
--=_Turnpike_c$T6NFAWt4B84zbw=--