Menu
▾
▴
alleg-bigfive — Discussion about Allegro 5
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(204) |
Oct
(117) |
Nov
(50) |
Dec
(257) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(212) |
Feb
(54) |
Mar
(52) |
Apr
(34) |
May
(23) |
Jun
(17) |
Jul
(27) |
Aug
(42) |
Sep
(17) |
Oct
|
Nov
|
Dec
|
| 2004 |
Jan
(4) |
Feb
(46) |
Mar
(6) |
Apr
(8) |
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
|
From: Grim I. L <jeg...@of...> - 2004-02-17 22:05:14
|
>There are of course different viewpoints on the merits and >disadvantages of including threading in allegro, these are just mine: > >- Considering the state of development of allegro5, I think focussing > on a working games library is goal #1. Anything else should not have > priority. That doesn't mean we shouldn't leave room in the design of > course; if it is decided later that we want threading then it > should still be possible. >- Allegro 5 is supposed to become as modular as possible, to prevent > problems like with Allegro 4 where some things are in the library and > (according to most) should be in an addon, and some important addons > are still not part of the "standard" library. If we're going for > modules, I think general threading support should definitely be in a > module, and not part of the "base" package. It's not required for > most games. >- If pthreads is available and cross-platform for all or most > allegro-platforms, I'm tempted to just say "use pthreads". Reinventing > the wheel or writing the 25th layer around a system library is > generally not a good idea. If people are scared of learning > pthreads, then they probably shouldn't be using threads anyway. >- A reason to include a general threading "wrapper" would be if > allegro itself has to have one internally because pthreads isn't > good enough, in that case it may be just as easy to make it a > public interface.=20 >- Including something in the base library (and the documentation) > means people will use it too, probably even if they don't understand > what it does. Threading is one topic where I don't mind if people > have to go an extra step to include it in their games. > >Hein Zelle Points noted - and agreed. Subject dropped on my behalf. However - Allergo 5 dead? doesn't sound good to me. I was looking forward to it. What happened? "Life is a joke, but for who's amussement?" |
|
From: Thomas F. <tfj...@st...> - 2004-02-14 17:09:10
|
The only thing I have to add to that, Allegro 4 is internaly threaded, and IMO, it wasn't designed to be thread safe. Threading issues seem to pop up all the time. So if the internals of a5 will be threaded like a4, every corner of a5 needs to be well thought out, and made as thread safe as possible. -- Thomas Fjellstrom tfj...@st... http://strangesoft.net |
|
From: Hein Z. <he...@ic...> - 2004-02-12 09:51:24
|
Grim I. L=E5get wrote:
> Hmm.. I think I missed a few messages. Anyways. The ideas behind the
> threading support was also part psychology - I know I got really
> scared first time I had to learn something other than the standard
> library for C++. ("Will it work, if I use some other thing?")
> Including the threading inside allegro would help intimidated people
> who have to learn several libs to do everything they need learn just
> what they need in one lib - ofcourse, there is also the risc that
> people would get scared away because it's too big ("I'll never learn
> this").
There are of course different viewpoints on the merits and
disadvantages of including threading in allegro, these are just mine:
- Considering the state of development of allegro5, I think focussing
on a working games library is goal #1. Anything else should not have
priority. That doesn't mean we shouldn't leave room in the design of
course; if it is decided later that we want threading then it
should still be possible.
- Allegro 5 is supposed to become as modular as possible, to prevent
problems like with Allegro 4 where some things are in the library and
(according to most) should be in an addon, and some important addons
are still not part of the "standard" library. If we're going for
modules, I think general threading support should definitely be in a
module, and not part of the "base" package. It's not required for
most games.
- If pthreads is available and cross-platform for all or most
allegro-platforms, I'm tempted to just say "use pthreads". Reinventing
the wheel or writing the 25th layer around a system library is
generally not a good idea. If people are scared of learning
pthreads, then they probably shouldn't be using threads anyway.
- A reason to include a general threading "wrapper" would be if
allegro itself has to have one internally because pthreads isn't
good enough, in that case it may be just as easy to make it a
public interface.=20
- Including something in the base library (and the documentation)
means people will use it too, probably even if they don't understand
what it does. Threading is one topic where I don't mind if people
have to go an extra step to include it in their games.
Hein Zelle
>-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D=
-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-<=20
Unix is user friendly. It's just very particular about who=20
it's friends are.
Hein Zelle he...@ic...
http://www.icce.rug.nl/~hein
>-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D=
-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-<
|
|
From: Grim I. L <jeg...@of...> - 2004-02-12 08:43:35
|
>> Under MacOS X pthread is supported, but not under BeOS. And let me add
>> I'm all for adding exposed treading capabilities to the lib. Allegro
>> already uses (and will use in 5.x, that's for sure) multithreading
>> internally, and having the possibility to use threads can also be
>> useful to game programmers IMHO. Under platforms that do not support
>> them (read: DOS) routines dealing with threads could just fail.
>>
>
>Allegro could simply provide a int threads_avail() function that will say if
>threads are available or not so that the game can work accordingly.
Hmm.. I think I missed a few messages. Anyways. The ideas behind the threading
support was also part psychology - I know I got really scared first time I had
to learn something other than the standard library for C++. ("Will it work, if
I use some other thing?") Including the threading inside allegro would help
intimidated people who have to learn several libs to do everything they need
learn just what they need in one lib - ofcourse, there is also the risc that
people would get scared away because it's too big ("I'll never learn this").
Besides, if real threading is supported, some other failsafe functions that
would provide similar functionality might be possible (although it would take
a lot of work and might be beyond the scope of allegro)!
"Life is a joke, but for who's amussement?"
|
|
From: Ron O. <ron@SAFe-mail.net> - 2004-02-10 03:25:16
|
-------- Original Message -------- From: Angelo Mottola <a.m...@li...> Apparently from: all...@li... To: all...@li... Subject: Re: [Alleg5] RE: Alleg-bigfive digest, Vol 1 #222 - 5 msgs Date: Thu, 5 Feb 2004 21:51:42 +0100 > >> but there's already a cross-platform thread library called pthreads > >> (there's both Unix and Windows versions, AFAIK). > > > > Just one thing. Does pthreads support MacOS X, BeOS, etc? If not, then > > there's a crossplatform problem right there. > > Under MacOS X pthread is supported, but not under BeOS. And let me add > I'm all for adding exposed treading capabilities to the lib. Allegro > already uses (and will use in 5.x, that's for sure) multithreading > internally, and having the possibility to use threads can also be > useful to game programmers IMHO. Under platforms that do not support > them (read: DOS) routines dealing with threads could just fail. > Allegro could simply provide a int threads_avail() function that will say if threads are available or not so that the game can work accordingly. |
|
From: Angelo M. <a.m...@li...> - 2004-02-05 20:48:29
|
>> but there's already a cross-platform thread library called pthreads >> (there's both Unix and Windows versions, AFAIK). > > Just one thing. Does pthreads support MacOS X, BeOS, etc? If not, then > there's a crossplatform problem right there. Under MacOS X pthread is supported, but not under BeOS. And let me add I'm all for adding exposed treading capabilities to the lib. Allegro already uses (and will use in 5.x, that's for sure) multithreading internally, and having the possibility to use threads can also be useful to game programmers IMHO. Under platforms that do not support them (read: DOS) routines dealing with threads could just fail. -- Angelo Mottola a.m...@li... |
|
From: Chris k. <et...@ho...> - 2004-02-05 20:28:53
|
>but there's already a cross-platform thread library called pthreads >(there's both Unix and Windows versions, AFAIK). Just one thing. Does pthreads support MacOS X, BeOS, etc? If not, then there's a crossplatform problem right there. _________________________________________________________________ There are now three new levels of MSN Hotmail Extra Storage! Learn more. http://join.msn.com/?pgmarket=en-us&page=hotmail/es2&ST=1 |
|
From: Chris <kc...@st...> - 2004-02-05 02:08:24
|
Grim I. Låget wrote: >Hello and greetings, >Ok, so this is the first post I have ever done to a mailinglist... hope it >works! > Comes through a-ok here. :) >I was wondering, since I haven't found anything about it, why doesn't allegro >provide some sort of thread support? Threads are of course not avilable in >DOS, but in both UNIX(/Linux) and Windows these are avilable - and not too >hard to write an interface for that will work with both threading models. > I'm not sure Allegro should really provide threading services. Granted it should be thread-safe, and maybe even use threads internally when available, but there's already a cross-platform thread library called pthreads (there's both Unix and Windows versions, AFAIK). It's even possible that pthreads will work in DOS, though I still need to check into that. But I'm not sure it should be Allegro's place to provide threads, especially when there's already another lib to do it. That said, however.. most Allegro programs will probably be developed on Windows machines, and most people may just forego pthreads and use Win32 threads and not worry about another library dependancy. This of course would detract from Allegro's purpose of being cross-platform. >The model I am proposing in best suited for C++, but I don't see any reason >why it shouldn't work in pure C. > The only reason that can't be a C-style struct is due to the (de)constructor. That can be circumvented easilly enough with al_thread_create()/al_thread_destroy() functions. The thread_main member function can be replaced with a global function(ala "int al_thread_main(struct AL_THREAD *);"), or a function pointer of the same type, and serve the same purpose. >Any ideas about this? > It's an interesting idea, I think. But again, I'm not sure Allegro should provide thread services. That's up to the developers. - Kitty Cat |
|
From: Grim I. L <jeg...@of...> - 2004-02-04 20:56:57
|
Hello and greetings,
Ok, so this is the first post I have ever done to a mailinglist... hope it
works!
I was wondering, since I haven't found anything about it, why doesn't allegro
provide some sort of thread support? Threads are of course not avilable in
DOS, but in both UNIX(/Linux) and Windows these are avilable - and not too
hard to write an interface for that will work with both threading models.
The model I am proposing in best suited for C++, but I don't see any reason
why it shouldn't work in pure C.
I am thinking in terms of a binary tree of thread-objects. A thread-manager
would keep track of the states of the threads and start/stop/restart a thread
if needed.
The thread class would look something like this:
class THREAD_CLASS
{
public:
int thread_main();
THREAD(int * _thread_function, int * _activate_thread, int *
_restart_thread);
~THREAD();
private:
int (* thread_function)();
int (* activate_thread)();
int (* deactivate_thread)();
int (* restart_thread)();
bool running;
THREAD_ID thread; // dependent on type of thread (OS)
}
Some more stuff may need to be added, but that's the basic layout.
How it is supposed to work:
in the function thread_main() it runs either activate_thread or
deactivate_thread depending on the state of running. It checks if the thread
should be restarted in restart_thread after each "cycle" if the thread is
running and hasn't been stopped.
If activate_thread returns anything but 0 then the thread is activated - if
not, it just continues as it was. The same with restart_thread and
deactivate_thread (only they either stop or restart the thread). Restarting a
thread is as simple as stopping it, deleteing everything except the pointers
to functions it uses and starting it again.
This model should solve some of the problems with the "multitasking"-system of
the "old" allegro.
Any ideas about this?
"Life is a joke, but for who's amussement?"
|
|
From: Colin A. <kar...@ka...> - 2004-02-02 04:21:50
|
Heh Likewise... oh well. Anything new going on in Allegro these days? Thanks Colin Alston ----- Original Message ----- From: "Marcello Bastea-Forte" <mar...@ce...> To: <all...@li...> Sent: Sunday, February 01, 2004 3:39 AM Subject: Re: [Alleg5] New here > Wow, I thought I was removed from the mailing list heh, didn't realize > that simply no one has posted for 4 months... > > Marcello > > > ------------------------------------------------------- > The SF.Net email is sponsored by EclipseCon 2004 > Premiere Conference on Open Tools Development and Integration > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. > http://www.eclipsecon.org/osdn > -- > https://lists.sourceforge.net/lists/listinfo/alleg-bigfive > |
|
From: Thomas F. <tfj...@st...> - 2004-02-01 02:09:13
|
On January 31, 2004 06:39 pm, Marcello Bastea-Forte wrote: > Wow, I thought I was removed from the mailing list heh, didn't realize > that simply no one has posted for 4 months... Know how I said on Allegro.cc that Allegro 5 was basically dead? I meant it :) > Marcello -- Thomas Fjellstrom tfj...@st... http://strangesoft.net |
|
From: Marcello Bastea-F. <mar...@ce...> - 2004-02-01 01:40:38
|
Wow, I thought I was removed from the mailing list heh, didn't realize that simply no one has posted for 4 months... Marcello |
|
From: Chris <kc...@st...> - 2004-01-31 21:23:48
|
Hi,
Regarding how to handle multiple sound card voices, I've thought of a
possible solution. Please note I'm in no way a sound guru, or probably
even that competant, but I think something like this could work. For
every allocated hardware voice, a special mixer is attached to it that
does nothing but mix all streams and feed them to the voice. The only
other processing it'll do is whatever's required by the hardware/driver.
Then as pcm, and user/Allegro defined mixer, streams get allocateded,
they'll attach themselves to the special mixer with the fewest amount of
currently allocated streams. Basically something like this:
// This helps with streams that get attached to mixer streams
struct {
enum {
AL_MIXER_STREAM,
AL_PCM_STREAM,
} type;
union {
AL_MIXER_STREAM *mixer;
AL_PCM_STREAM *pcm;
} stream;
void *buffer_data; // This is given to the child mixer stream to fill,
// or is filled with the pcm stream data
} AL_MIXER_ATTACHMENT;
// These are a attached to each hardware voice, and any subsequent mixer/pcm
// stream allocations attach to these (unless a different mixer stream is
// requested, in which case it'll attach to that). These are not visible to
// the library user.
struct {
AL_MIXER_ATTACHMENT *attachment_array;
int num_attachments;
void *voice_buffer;
} AL_HARDWARE_VOICE_MIXER;
Then, it runs something like this:
pcm -> mix into buffer
hardware voice -> active attachments
mixer -> mix attachments, apply filters, mix
into buffer
I hope that's making sense.. if not, just ask away. I'll try and answer
if I can.
- Kitty Cat
|
|
From: Grzegorz A. H. <gr...@ti...> - 2004-01-31 14:15:57
|
On 2004-01-28, Chris <kc...@st...> wrote: > I suppose if I find something I want to respond to in the archive I > should just copy/paste it into an email and post it? Or is there some > other way for mailing lists? There is no point in duplicating, you can post a link to the specific archived mail and refer to it in your mail. |
|
From: Thomas F. <tfj...@sh...> - 2004-01-31 12:01:47
|
On January 28, 2004 01:54 pm, Chris wrote: > Hopefully this is working right. Never really did a mailing list before. Welcome Welcome :D > Anyway, yeah. I just signed up, and have been going through the post > archives on sourceforge. As some/most are probably aware, I was > encouraged to join from Allegro.cc (my nick there is Kitty Cat, if you > didn't gather by my email address :)). I've been interested in helping > however I can, and this includes coding and just generally tossing > around ideas. > > I suppose if I find something I want to respond to in the archive I > should just copy/paste it into an email and post it? Or is there some > other way for mailing lists? Basically, yeah. > - Kitty Cat -- Thomas Fjellstrom tfj...@st... http://strangesoft.net |
|
From: Chris <kc...@st...> - 2004-01-31 07:51:53
|
Hopefully this is working right. Never really did a mailing list before. Anyway, yeah. I just signed up, and have been going through the post archives on sourceforge. As some/most are probably aware, I was encouraged to join from Allegro.cc (my nick there is Kitty Cat, if you didn't gather by my email address :)). I've been interested in helping however I can, and this includes coding and just generally tossing around ideas. I suppose if I find something I want to respond to in the archive I should just copy/paste it into an email and post it? Or is there some other way for mailing lists? - Kitty Cat |
|
From: Robert Jr O. <roh...@vi...> - 2003-09-29 23:24:06
|
Elias Pschernig wrote: > Hm, after writing some thoughts against usefulness of sub-bitmaps, I > deleted them again, since another thought just occured to me: Maybe the > above graphics API could be split into 3 modules? [snip] It's a good idea. Clipping kinda needs to be done in a single step though, so splitting by API function won't work too well. -- - Robert Jr Ohannessian http://bob.allegronetwork.com/ |
|
From: Elias P. <el...@us...> - 2003-09-29 16:26:15
|
On Mon, 2003-09-29 at 06:04, Robert Jr Ohannessian wrote: > > > > Would there be a difference to using a sub-bitmap of the source bitmap? > > > > Yes, speed: no need to allocate memory and create a complete bitmap > structure. So yes, there is a benefit. Is is worth the cost in coding > time and debugging? > Just read a bit again in http://alleg.sourceforge.net/future/bobs_graphic_api_proposition.txt, and now I remember - you also have multiple clipping rectangles there. So I could set two cliping rectangles in my source bitmap, then blit it into another bitmap, which also has two clipping rectangles.. Hm, after writing some thoughts against usefulness of sub-bitmaps, I deleted them again, since another thought just occured to me: Maybe the above graphics API could be split into 3 modules? It would look like this: base-bitmap-API: Only non-rotating non-scaling non-source-clipping blit (maybe with dest clipping rectangles), and direct access to bitmaps (as far as possible by the type). rotoclipzoom-API: This supports rotated scaled source-and-dest clipped blitting for everyone who needs this more spezialized things. Maybe a general transformation matrix instead of rotating and scaling. And maybe bitmasks instead of multiple rectangles. paint-API: Things like putpixel, line, floodfill.. Of course, GFX drivers would be able to support all 3 modules directly (i.e. everything has vtable entries). The advantage would of course not be less amount of coding and debugging for the final A5 - but for now, just the first base API would have to be implemented (and made extensible enough to support low-level modules/addons). Things like the subbitmap question could then be resolved later, after the base A5 already is working. -- Elias Pschernig <el...@us...> |
|
From: Peter W. <tj...@us...> - 2003-09-29 06:15:00
|
On 2003-09-29, Robert Jr Ohannessian <roh...@vi...> wrote: > > Amazing. They use the AL_/al_ prefix. Talk about being incompatible! *sigh* |
|
From: Robert Jr O. <roh...@vi...> - 2003-09-29 05:05:49
|
Elias Pschernig wrote: > On Sun, 2003-09-28 at 05:11, Robert Jr Ohannessian wrote: > > >>Basically, I'd like to ask this: are there any real-world examples of >>source clip rectangles being useful at all? Should I just drop the idea >>and stay with destination-only clip rects? >> > > > Would there be a difference to using a sub-bitmap of the source bitmap? > Yes, speed: no need to allocate memory and create a complete bitmap structure. So yes, there is a benefit. Is is worth the cost in coding time and debugging? -- - Robert Jr Ohannessian http://bob.allegronetwork.com/ |
|
From: Robert Jr O. <roh...@vi...> - 2003-09-29 05:05:48
|
Peter Wang wrote: > On 2003-09-28, Robert Jr Ohannessian <roh...@vi...> wrote: > >>The question is, should reads care about the clip rectangle or not? > > > What would happen if you tried to read outside of a clip rectangle? > Returns -1 like getpixel() does now? > Right now? AFAIK we clip reads to the bitmap size, but not any sub-rectangle inside that bitmap - we basically ignore the clip rectangle for that bitmap. -- - Robert Jr Ohannessian http://bob.allegronetwork.com/ |
|
From: Robert Jr O. <roh...@vi...> - 2003-09-29 04:16:59
|
Amazing. They use the AL_/al_ prefix. Talk about being incompatible! Peter Wang wrote: > After looking at PhysicsFS, I decided to go on a hunt for a general > purpose I/O abstraction library, with layered streams support. I found > one which appears to foot the bill: > > http://www.ossp.org/pkg/lib/sio/ > > Its API looks well thought out. Also, the implementation is bound to be > better, especially since it uses a library [contained within] that > claims: > > OSSP al defines an abstract data type of a data buffer that can > assemble, move and truncate chunks of data in a stream but avoids > actual copying. > > Therefore I think it's best if we drop our own streams implementation. > Moreover, it would be best if the world could agree on single stream > abstraction interface for C, hence we would adopt sio's API as our own. > What do you think? > > > [I'm wanting more and more to offload as much work as possible onto > other people. If other people have done things and done them well, we > should just use it. We're doing that for 3d graphics. We can do that > for plenty of other things too, especially the boring things.] > -- - Robert Jr Ohannessian http://bob.allegronetwork.com/ |
|
From: Peter W. <tj...@us...> - 2003-09-29 02:51:19
|
After looking at PhysicsFS, I decided to go on a hunt for a general
purpose I/O abstraction library, with layered streams support. I found
one which appears to foot the bill:
http://www.ossp.org/pkg/lib/sio/
Its API looks well thought out. Also, the implementation is bound to be
better, especially since it uses a library [contained within] that
claims:
OSSP al defines an abstract data type of a data buffer that can
assemble, move and truncate chunks of data in a stream but avoids
actual copying.
Therefore I think it's best if we drop our own streams implementation.
Moreover, it would be best if the world could agree on single stream
abstraction interface for C, hence we would adopt sio's API as our own.
What do you think?
[I'm wanting more and more to offload as much work as possible onto
other people. If other people have done things and done them well, we
should just use it. We're doing that for 3d graphics. We can do that
for plenty of other things too, especially the boring things.]
--
王浩禎
|
|
From: Peter W. <tj...@us...> - 2003-09-29 02:47:46
|
On 2003-09-28, Robert Jr Ohannessian <roh...@vi...> wrote: > The question is, should reads care about the clip rectangle or not? What would happen if you tried to read outside of a clip rectangle? Returns -1 like getpixel() does now? -- 王浩禎 |
|
From: Peter W. <tj...@us...> - 2003-09-29 01:32:30
|
I just saw someone mention this on the Lua mailing list. I haven't tested it yet, but it looks cool. It seems like it would fit perfectly to plug this in as the bottom-most layer of the proposed streams interface [hint, hint]. In fact, for a lot of uses, you wouldn't even need our streams interface (although presumably various loaders/savers would be written to use AL_STREAMs, so you'd need it then). http://icculus.org/physfs/ -- 王浩禎 |
7 messages has been excluded from this view by a project administrator.