# date: 2001 - 12 - 01 From - Tue Nov 27 23:22:21 2001 From: Bob 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 From: Laurence Withers 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: >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, http://www.lwithers.demon.co.uk/ From - Wed Nov 28 08:00:27 2001 From: Stepan Roh 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 From: Sven Sandberg 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 From: "Eric Botcazou" > 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 From - Wed Nov 28 08:00:28 2001 From: Shawn Hargreaves 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 From: Lo'oRiS il Kabukimono > 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: / / / / ___-°/ irc.azzurra.org #lano / /_/__ / /|__-° digilander.iol.it/lano666 /______/| /__/ / ^°\:-.__.-:/°^°\:-.__.-:/°^ |______|/ |__L/ From - Wed Nov 28 08:00:29 2001 From: Sven Sandberg 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 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: