alleg-bigfive — Discussion about Allegro 5

[Alleg5] (no subject)

[kenza e. <elc...@ho...>]

elc...@ho...

_________________________________________________________________
MSN Hotmail sur i-mode™ : envoyez et recevez des e-mails depuis votre 
téléphone portable ! http://www.msn.fr/hotmailimode/

[Alleg5] Bye bye

[Peter W. <tj...@oz...>]

Just a note to say this list has been shut down.  Discussions can go on 
the usual developers' list, i.e. [AD].

Peter

RE: [Alleg5] Behold the Next Generation of Allegro: AllegroPro

[Korval <Ko...@co...>]

Well, there is a roadmap. It's accepted by me ;) I'm committed to seeing
this project through, at the very least, to the point where other people can
work on it, and I intend on following that roadmap.

In any case, from your postings in the Allegro 4 ML, you seem to be pretty
knowledgeable about hardware sound. I don't have any real understanding of
sound, hardware or otherwise. Certainly not enough to be able to go and
design a good, hardware-compatible, sound API.

So, I'm asking you to lend this project your expertise and design a sound
system. What I'm looking for out of a design is not a bare list of feature.
Look at what I did for graphics; I went so far as to specify, line by line,
precisely how blitting works. I want a similarly in-depth document detailing
regarding sound features. API functions are not to be defined; it is enough
to say that there is such an API. Naming the functions and parameters is not
reasonable for a design document. That kind of thing comes later.

If you accept my invitation, don't feel constrained to stay within the
limits of Allegro 4's sound API. The determining factors in your design
should be:

1: What makes for good, fast hardware implementation?
2: What makes things relatively nice for the user?

Note that your emphesis should be on hardware-based sound, not software.
AllegroPro is trying to encourage high-performance game programming, not
high-compatibility with age-old architectures.

-----Original Message-----
From: all...@li...
[mailto:all...@li...]On Behalf Of Karthik
Kumar V
Sent: Sunday, April 18, 2004 8:55 AM
To: all...@li...
Subject: Re: [Alleg5] Behold the Next Generation of Allegro: AllegroPro


Hi,

Nice design. I have always fancied about Allegro5 being the best, easy to
use API ever for makimg games.

When we see Allegro5, it shouldn't just include the core libraries alone,
it should be something that anybody can get used to and work.
Like, if you take the value proposition to an end-user of Allegro, he
should see its advantages as a potential game development toolkit than
something on the lines of DirectX and OpenGL. :P Well, I'm sure not all
people would agree with this, but what I'm saying is: think about it.

We people should pool in our ideas to make it a extensive, generic,
bug-free,
easy to use API. The reason why I think Allegro stands out as an excellent
game programming tool, is because of its ease of use in spite of powerful
features. So, that's all I'm saying....

Is there a formalized roadmap, accepted by everybody for development?
Please do let us all know.

Re: [Alleg5] Behold the Next Generation of Allegro: AllegroPro

[Karthik K. V <f20...@bi...>]

Hi,

Nice design. I have always fancied about Allegro5 being the best, easy to 
use API ever for makimg games. 

When we see Allegro5, it shouldn't just include the core libraries alone, 
it should be something that anybody can get used to and work.
Like, if you take the value proposition to an end-user of Allegro, he 
should see its advantages as a potential game development toolkit than 
something on the lines of DirectX and OpenGL. :P Well, I'm sure not all 
people would agree with this, but what I'm saying is: think about it.

We people should pool in our ideas to make it a extensive, generic, bug-free,
easy to use API. The reason why I think Allegro stands out as an excellent
game programming tool, is because of its ease of use in spite of powerful 
features. So, that's all I'm saying....

Is there a formalized roadmap, accepted by everybody for development? 
Please do let us all know. 

On Sat, 17 Apr 2004, Korval wrote:

> Behold the Next Generation of Allegro: AllegroPro
> http://home.comcast.net/~Korval/.
> 
> At that site is a design document for what you might call Allegro 5. It is
> the effective successor to Allegro 4. I decided to change the name for two
> reasons.
> 
> 1: Like it or not, the Allegro name is a bit tarnished given the current and
> past versions of Allegro. Allegro is considered a newbie library. Adding
> the -Pro suffix is an attempt to make it clear that this is a whole new
> library while still keeping the name. This is a library for making
> professional-quality 2D games, and it is designed to make that possible.
> 
> 2: To divorce it from Allegro 5.0. In designing AllegroPro, I have taken
> various features and so forth from the available documents for Allegro 5.0,
> as well as existing stuff from 4.0. However, the design is very much not
> Allegro 5.0, and I want people familiar with 5.0 to know that this ain't it.
> 
> One more point deserves mentioning before I go into how this affects the
> Allegro community: the design isn't complete. I have designed some of the
> core facilities, the important parts of the graphics system, and part of the
> threading system. I have some ideas for how I want input to look and behave.
> However, I'm not a sound programmer; I've never done anything with sound on
> a game before. So I have no idea how hardware sound works or what a good API
> for the user for such things might be.
> 
> I am officially extending an invitation to Bruce Perry to design the sound
> system and API, if he wants to contribute. He's definately the first person
> I would think of on this forum who knows enough about sound to be able to
> design a sound API. If anyone else has strong credentials in that field who
> wants to contribute, so be it. Because I don't know much about sound,
> whoever it is that gets to contribute to this area will, basically, have
> free run to design as they see fit. I don't know enough to offer reasonable
> input on the subject.
> 
> As for the Allegro community... you might have noticed a lot of "I"'s in
> some of the previous paragraphs. As it has been pointed out, people don't
> usually pick their dictators; they decide to be dictators and then dictate.
> So, I'm officially taking on that role.
> 
> Now, this does not mean that I am not interested in outside input. However,
> as the maintainer of the design document for AllegroPro, I will have final
> say as to what goes into the design and what doesn't. I'm a pretty
> reasonable guy, though, and if you can make a good case for some feature,
> then it can find its way into the core.
> 
> Am I hijacking Allegro 5's development? Well, yeah. It wasn't going anywhere
> anyway. They don't have a compiling codebase or a coherent design. I intend
> to provide some of these. The worst that can happen is that this initive
> doesn't go anywhere either. Which means that nobody is in a different
> position.
> 
> So, what am I looking for? Well, on that site, you will also find a roadmap
> for the implementation of AllegroPro. This roadmap lists the sequence of
> steps that need to be taken in order to get AllegroPro functional. That
> means that the core components work, and work modestly well. Once we get
> there, it will be much easier for others to work on the project.
> 
> There are two ends someone can help on. They can assist design by critiquing
> the design that I have created. The best way to do that is to add threads to
> this forum. The mailing list can be used too, but I don't read it nearly as
> often as this forum.
> 
> The other end is, after a component has been designed, that design has to be
> converted into an API, and that API has to be implemented. If anyone wants
> to be involved in that, your help would be appreciated.
> 
> So, besides writing this design document, what am I going to do? Well, I
> intend to implement the core (read the design document to learn what this
> means), the threading component, and the graphics component. I intend to
> write an OpenGL-based driver for the graphics component, as well as the
> generic graphics driver (using parts from Allegro 4 where necessary). Of
> course, the last two things come after the primary roadmap portion is
> complete.
> 
> I would prefer to discuss issues related to AllegroPro in the Allegro.cc
> forums on Allegro Development. Though I will be monitoring this list, I am
> more often on the forums than I am on this list.
> 
> Over the next week, I intend to finish up the thread design, start on the
> input component, and spec out the core error mechanism. Also, I will be
> accumulating responses to/suggestions for the current design and evaluating
> them. From there, we will follow the roadmap.
> 
> I do not intend offense towards anyone who may have been considered the
> "guiding light" of Allegro 5. However, Allegro 5 development has been
> stalled for some time, and I do not intend to have Allegro simply die off
> due to lack of interest. I intend to build a modern Allegro and make it a
> useful library for game development.
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> 

-- 

Karthik Kumar V
Updated Page -> http://www.geocities.com/kkgoesnuts

A Fortune Cookie :
- ------- ------ -

"Every person can be described as an equilateral triangle of side s, the
vertices representing what (s)he thinks, says and does. For an average
person, s = 10 miles ~ 16000 metres. When s = 0 metres, a person is said to
be a MAHATMA. Everybody should try to make their s get close to 0."

Re: [Alleg5] Behold the Next Generation of Allegro: AllegroPro

[Grzegorz A. H. <gr...@ti...>]

On 2004-04-17, Korval <Ko...@co...> wrote:
> Behold the Next Generation of Allegro: AllegroPro
> http://home.comcast.net/~Korval/.

Good luck with your efforts! Just in case you want to avoid another
pointless debate, state clearly what license AllegroPro will be.

[Alleg5] Behold the Next Generation of Allegro: AllegroPro

[Korval <Ko...@co...>]

Behold the Next Generation of Allegro: AllegroPro
http://home.comcast.net/~Korval/.

At that site is a design document for what you might call Allegro 5. It is
the effective successor to Allegro 4. I decided to change the name for two
reasons.

1: Like it or not, the Allegro name is a bit tarnished given the current and
past versions of Allegro. Allegro is considered a newbie library. Adding
the -Pro suffix is an attempt to make it clear that this is a whole new
library while still keeping the name. This is a library for making
professional-quality 2D games, and it is designed to make that possible.

2: To divorce it from Allegro 5.0. In designing AllegroPro, I have taken
various features and so forth from the available documents for Allegro 5.0,
as well as existing stuff from 4.0. However, the design is very much not
Allegro 5.0, and I want people familiar with 5.0 to know that this ain't it.

One more point deserves mentioning before I go into how this affects the
Allegro community: the design isn't complete. I have designed some of the
core facilities, the important parts of the graphics system, and part of the
threading system. I have some ideas for how I want input to look and behave.
However, I'm not a sound programmer; I've never done anything with sound on
a game before. So I have no idea how hardware sound works or what a good API
for the user for such things might be.

I am officially extending an invitation to Bruce Perry to design the sound
system and API, if he wants to contribute. He's definately the first person
I would think of on this forum who knows enough about sound to be able to
design a sound API. If anyone else has strong credentials in that field who
wants to contribute, so be it. Because I don't know much about sound,
whoever it is that gets to contribute to this area will, basically, have
free run to design as they see fit. I don't know enough to offer reasonable
input on the subject.

As for the Allegro community... you might have noticed a lot of "I"'s in
some of the previous paragraphs. As it has been pointed out, people don't
usually pick their dictators; they decide to be dictators and then dictate.
So, I'm officially taking on that role.

Now, this does not mean that I am not interested in outside input. However,
as the maintainer of the design document for AllegroPro, I will have final
say as to what goes into the design and what doesn't. I'm a pretty
reasonable guy, though, and if you can make a good case for some feature,
then it can find its way into the core.

Am I hijacking Allegro 5's development? Well, yeah. It wasn't going anywhere
anyway. They don't have a compiling codebase or a coherent design. I intend
to provide some of these. The worst that can happen is that this initive
doesn't go anywhere either. Which means that nobody is in a different
position.

So, what am I looking for? Well, on that site, you will also find a roadmap
for the implementation of AllegroPro. This roadmap lists the sequence of
steps that need to be taken in order to get AllegroPro functional. That
means that the core components work, and work modestly well. Once we get
there, it will be much easier for others to work on the project.

There are two ends someone can help on. They can assist design by critiquing
the design that I have created. The best way to do that is to add threads to
this forum. The mailing list can be used too, but I don't read it nearly as
often as this forum.

The other end is, after a component has been designed, that design has to be
converted into an API, and that API has to be implemented. If anyone wants
to be involved in that, your help would be appreciated.

So, besides writing this design document, what am I going to do? Well, I
intend to implement the core (read the design document to learn what this
means), the threading component, and the graphics component. I intend to
write an OpenGL-based driver for the graphics component, as well as the
generic graphics driver (using parts from Allegro 4 where necessary). Of
course, the last two things come after the primary roadmap portion is
complete.

I would prefer to discuss issues related to AllegroPro in the Allegro.cc
forums on Allegro Development. Though I will be monitoring this list, I am
more often on the forums than I am on this list.

Over the next week, I intend to finish up the thread design, start on the
input component, and spec out the core error mechanism. Also, I will be
accumulating responses to/suggestions for the current design and evaluating
them. From there, we will follow the roadmap.

I do not intend offense towards anyone who may have been considered the
"guiding light" of Allegro 5. However, Allegro 5 development has been
stalled for some time, and I do not intend to have Allegro simply die off
due to lack of interest. I intend to build a modern Allegro and make it a
useful library for game development.

Re: [Alleg5] Compilation of the CVS sources

[Elias P. <el...@us...>]

On Sun, 2004-04-11 at 04:36, Bill wrote:
> I want the Allegro 5 sources.
> 

There is no Allegro 5 source yet, just some design ideas at:

http://alleg.sourceforge.net/future/

Bob and tjaden both started writing a base system though, but both ran
out of time to bring it quite far. tjaden's at least got far enough to
include a simple 3d model loader example (linux only). Since his new
homepage is gone again, I uploaded the last version he sent me here:

http://allefant.sourceforge.net/allegro/cvsroot-20030502.tar.bz2.gz

But, there's really not much to see in it, even if you have linux..

-- 
Elias Pschernig <el...@us...>

Re: [Alleg5] Compilation of the CVS sources

[Bill <Bi...@ve...>]

I want the Allegro 5 sources.

Robert Jr Ohannessian wrote:

> You pry shouldn't use that module. It's a fork of the Allegro 4 WIP, 
> not entirely sure when, but it's surely outdated.
>
> Bill wrote:
>
>> I got the CVS sources for Allegro 5(allegro_new module) but ran into 
>> some compilation problems. I'm compiling on MinGW 3.2.3. Here is what 
>> I've done thus far to fix it:
>> *Copy asmdef.inc and asmcapa.h from [Allegro 4.0.3 dir]/obj/mingw32/ 
>> to [Allegro 5 dir]/obj/mingw32/
>> *Open up asmdef.inc and find the defines for MASK_COLOR_*. Replace 
>> them so they look like this:
>> #define AL_MASK_COLOR_8 0
>> #define AL_MASK_COLOR_15 31775
>> #define AL_MASK_COLOR_16 63519
>> #define AL_MASK_COLOR_24 16711935
>> #define AL_MASK_COLOR_32 16711935
>> This is because of A5's new define convention. A4 didn't have the AL_.
>> *Go ahead and compile.
>> Things should compile alright until linking. It'll error saying 
>> allegro.def is missing. I haven't figured out what to do with this 
>> one. I don't think I can copy Allegro 4.0.3's def file over. Anyone 
>> know how to fix that?
>>
>> ~William
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by: IBM Linux Tutorials
>> Free Linux tutorial presented by Daniel Robbins, President and CEO of
>> GenToo technologies. Learn everything from fundamentals to system
>> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click

Re: [Alleg5] Compilation of the CVS sources

[Robert Jr O. <roh...@vi...>]

You pry shouldn't use that module. It's a fork of the Allegro 4 WIP, not 
entirely sure when, but it's surely outdated.

Bill wrote:
> I got the CVS sources for Allegro 5(allegro_new module) but ran into 
> some compilation problems. I'm compiling on MinGW 3.2.3. Here is what 
> I've done thus far to fix it:
> *Copy asmdef.inc and asmcapa.h from [Allegro 4.0.3 dir]/obj/mingw32/ to 
> [Allegro 5 dir]/obj/mingw32/
> *Open up asmdef.inc and find the defines for MASK_COLOR_*. Replace them 
> so they look like this:
> #define AL_MASK_COLOR_8 0
> #define AL_MASK_COLOR_15 31775
> #define AL_MASK_COLOR_16 63519
> #define AL_MASK_COLOR_24 16711935
> #define AL_MASK_COLOR_32 16711935
> This is because of A5's new define convention. A4 didn't have the AL_.
> *Go ahead and compile.
> Things should compile alright until linking. It'll error saying 
> allegro.def is missing. I haven't figured out what to do with this one. 
> I don't think I can copy Allegro 4.0.3's def file over. Anyone know how 
> to fix that?
> 
> ~William
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click

[Alleg5] Compilation of the CVS sources

[Bill <Bi...@ve...>]

I got the CVS sources for Allegro 5(allegro_new module) but ran into 
some compilation problems. I'm compiling on MinGW 3.2.3. Here is what 
I've done thus far to fix it:
*Copy asmdef.inc and asmcapa.h from [Allegro 4.0.3 dir]/obj/mingw32/ to 
[Allegro 5 dir]/obj/mingw32/
*Open up asmdef.inc and find the defines for MASK_COLOR_*. Replace them 
so they look like this:
#define AL_MASK_COLOR_8 0
#define AL_MASK_COLOR_15 31775
#define AL_MASK_COLOR_16 63519
#define AL_MASK_COLOR_24 16711935
#define AL_MASK_COLOR_32 16711935
This is because of A5's new define convention. A4 didn't have the AL_.
*Go ahead and compile.
Things should compile alright until linking. It'll error saying 
allegro.def is missing. I haven't figured out what to do with this one. 
I don't think I can copy Allegro 4.0.3's def file over. Anyone know how 
to fix that?

~William

Re: [Alleg5] too much fog

[Thomas F. <tfj...@st...>]

On March 2, 2004 11:42 pm, Peter Wang wrote:
> Thomas Fjellstrom wrote:
> >Your ftp at strangesoft.net is still around...
>
> Thomas, I can't remember the password :-)  Anyway, you can delete it or
> redirect it or leave it be.  If I haven't said so already, thanks for
> hosting loadpng in the meantime :-)

Alrigty, redirected to your new address :)

> Peter


-- 
Thomas Fjellstrom
tfj...@st...
http://strangesoft.net

Re: [Alleg5] too much fog

[Peter W. <tj...@oz...>]

Thomas Fjellstrom wrote:

>Your ftp at strangesoft.net is still around...
>  
>

Thomas, I can't remember the password :-)  Anyway, you can delete it or 
redirect it or leave it be.  If I haven't said so already, thanks for 
hosting loadpng in the meantime :-)

Peter

Re: [Alleg5] too much fog

[Thomas F. <tfj...@st...>]

On February 28, 2004 05:43 pm, Peter Wang wrote:
> Elias Pschernig wrote:
> >Get a new site! :) loadpng, AGUP, and so on, is all without an official
> >address now..
>
> Ok, ok :-)  I've put up my site to http://tjaden.mtxis.com.ve/ and the
> a5 work is at http://tjaden.mtxis.com.ve/a5/
>
> Peter

Your ftp at strangesoft.net is still around...

-- 
Thomas Fjellstrom
tfj...@st...
http://strangesoft.net

Re: [Alleg5] 64-bit processors

[Thomas F. <tfj...@st...>]

On February 26, 2004 12:32 pm, Chris wrote:
> Grim I. L=E5get wrote:
> >Well, today we have the opteron, Athlon64 and others from AMD
> >but who says that it will be that way in 5 years from now. Experience
> > tells us that we will have 64-bit processors, but rumours (old ones yes,
> > but I have seen nothing to make me thing otherwhise yet) tell me that
> > Intel (at least) will drop back-wards compatibility with the x86
> > instruction set
>
> Intel was originally going to do this, but from what I heard, Microsoft
> told them no, or else you can forget about Windows compatiblity. MS is
> going with AMD's x86-extended set, as opposed to Intel's all-new set,
> which would lead me to believe Intel's turning around and using an
> x86-extended set themselves.

=46rom what I understand, Intell originally planed on the Itanium rocking t=
he=20
boat, but it flopped (like a fish out of water), horribly. Microsoft even=20
started working on a version of windows for it, but dropped it soon after.=
=20
After people started showing interest in AMD's x86-64 architecture, Intel=20
jumped on it.

One notable company that's been attacted to the Opteron is Google :) They h=
ave=20
stated they will not use the Itanium in thier clusters, to power hungry, ru=
ns=20
too hot... But they will use Opterons, go figure.

>
> - Kitty Cat


=2D-=20
Thomas Fjellstrom
tfj...@st...
http://strangesoft.net

Re: [Alleg5] too much fog

[Robert Jr O. <roh...@vi...>]

Right :)

David A. Capello wrote:

> On vie, feb 27, 2004 at 12:09:28 -0500, Robert Jr Ohannessian wrote:
> 
>>My code (C with STL for bootstrapping, and a partial Win32 driver)
>>http://bob.allegronetwork.com/allegro5/alleg.zip
> 
> 
> http://bob.allegronetwork.com/allegro5/alleg5.zip
> 

Re: [Alleg5] too much fog

[David A. C. <da...@us...>]

On vie, feb 27, 2004 at 12:09:28 -0500, Robert Jr Ohannessian wrote:
> My code (C with STL for bootstrapping, and a partial Win32 driver)
> http://bob.allegronetwork.com/allegro5/alleg.zip

http://bob.allegronetwork.com/allegro5/alleg5.zip

-- 
David A. Capello - www.davidcapello.com.ar

Re: [Alleg5] too much fog

[Peter W. <tj...@oz...>]

Elias Pschernig wrote:

>Get a new site! :) loadpng, AGUP, and so on, is all without an official
>address now..
>  
>

Ok, ok :-)  I've put up my site to http://tjaden.mtxis.com.ve/ and the 
a5 work is at http://tjaden.mtxis.com.ve/a5/

Peter

[Alleg5] RE: dumped work on sites

[Grim I. L <jeg...@of...>]

>I've dumped my stuff and Peter's on my website:
>
>My code (C with STL for bootstrapping, and a partial Win32 driver)
>http://bob.allegronetwork.com/allegro5/alleg.zip
>
>Peter's code (C++, Unix drivers)
>http://bob.allegronetwork.com/allegro5/a5-c++-branch-20030419.tar

Does this work? or is it not nearly done to work yet?

"Life is a joke, but for who's amussement?"

[Alleg5] 64-bit processors and n00bs

[Grim I. L <jeg...@of...>]

Actually, I thought I heard AMD's would be 32-bit x86 compatible right from 
the start, as long as it's in 32-bit mode (ie. in a 32-bit-only OS).

Well, as far as I know, they are compatible regardless of them running in 32 
or 64 bit mode - haven't tried one so I really don't know, mind you. Anyways, 
who would want to run a 64-bit processor with a 32-bit OS with 32-bit 
programmes if you can get a 64-bit os and have all the source for the 32-bit 
programmes (and a 64-bit compiler)? The power in open source is revealed - it 
comes in adaptability as well as loads of other things.

Anyways, I'm sort of a n00b as well (when it comes to codeing, I haven't ever 
finished a project that is nearing the detail or complexity of something like 
Allergo). However, I have some ideas how n00bs could help out in a project 
like this: first of, we could be testers. Instead of implementing a new API 
that no-one can figure out, why not use n00bs to test if it accesable enough 
for anyone? This isn't the only way n00bs could have an impact on the API - we 
could also help design the API feel. What kind of naming is used and so on. 
This may seem like something that doesn't really have anything to do with 
programming, but this is really what programming is. A wise man said (as wise 
men often do) that when you are makeing a new programme you should design and 
plan 1/3 of the time and only code 1/6 of the time, so if we follow this wise 
mans words n00bs are much needed to help plan the project.

Just some thoughts.

"Life is a joke, but for who's amussement?"

Re: [Alleg5] too much fog

[Robert Jr O. <roh...@vi...>]

I've dumped my stuff and Peter's on my website:

My code (C with STL for bootstrapping, and a partial Win32 driver)
http://bob.allegronetwork.com/allegro5/alleg.zip

Peter's code (C++, Unix drivers)
http://bob.allegronetwork.com/allegro5/a5-c++-branch-20030419.tar


Peter Wang wrote:

> David A. Capello wrote:
> 
>> I think that Allegro 5 will take off when someone start write the core
>> (modules loading, threading, etc.) and put it in him website in a "de
>> facto" way.  (I don't know what Peter did, because I lost him code and
>> him web-site doesn't work).
>>  
>>
> 
> Just a note about my web site: I switched ISPs last year and so my old 
> web site is offline (finally).  I'll put up my Allegro 5 work somewhere 
> else, hopefully in the near future.
> 
> Peter
> 
> 
> 
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click

Re: [Alleg5] too much fog

[Elias P. <el...@us...>]

On Fri, 2004-02-27 at 04:20, Peter Wang wrote:
> Just a note about my web site: I switched ISPs last year and so my old 
> web site is offline (finally).  I'll put up my Allegro 5 work somewhere 
> else, hopefully in the near future.
> 

Get a new site! :) loadpng, AGUP, and so on, is all without an official
address now..

-- 
Elias Pschernig <el...@us...>

Re: [Alleg5] too much fog

[Peter W. <tj...@oz...>]

David A. Capello wrote:

>I think that Allegro 5 will take off when someone start write the core
>(modules loading, threading, etc.) and put it in him website in a "de
>facto" way.  (I don't know what Peter did, because I lost him code and
>him web-site doesn't work).
>  
>

Just a note about my web site: I switched ISPs last year and so my old 
web site is offline (finally).  I'll put up my Allegro 5 work somewhere 
else, hopefully in the near future.

Peter

[Alleg5] too much fog

[David A. C. <da...@us...>]

I think that there are some people in this list that really want to
help, but they don't known how (like me), because Allegro 5 doesn't
have a design, only parts flying around, but nothing concrete yet.  So
we can't help in nothing because nothing was made yet.

I think that Allegro 5 will take off when someone start write the core
(modules loading, threading, etc.) and put it in him website in a "de
facto" way.  (I don't know what Peter did, because I lost him code and
him web-site doesn't work).

Anyway, when I said that we could see some alternative libraries, I
was refering to libraries like GLib (http://www.gtk.org/), that could
help us in the portability for modules, unicode, threads, data types,
etc.

P.S.: What about the name Allegro De Facto 5.0? :-)

-- 
David A. Capello - www.davidcapello.com.ar

Re: [Alleg5] Any chance of a newbie helping?

[Chris <kc...@st...>]

Ron Ophir wrote:

>Hi all,
>
>Although I'm a n00b, I'd really like to try and help the development of Allegro 5. Maybe if Bob or Peter could spare some time helping me understand a few things, I'll be able to help.
>
>Best regards,
>Ron Ofir.
>

This goes ditto for me. If there's anyway I can help, just let me know.

- Kitty Cat

Re: [Alleg5] 64-bit processors

[Chris <kc...@st...>]

Grim I. Låget wrote:

>What you would want to ask is, will there be a 
>64-bit processor in 5 or 10 years from now that will support the x86 
>instruction set.
>

Actually, I thought I heard AMD's would be 32-bit x86 compatible right 
from the start, as long as it's in 32-bit mode (ie. in a 32-bit-only 
OS). A 64-bit OS with 32-bit compatibility is probably a bit more iffy 
as to whether it'll actually work or not, although it's supposed to. I'd 
tend to think it'll be along the lines of 16-bit compatibility in 32-bit 
mode, for current 32-bit CPUs.

>Well, today we have the opteron, Athlon64 and others from AMD 
>but who says that it will be that way in 5 years from now. Experience tells us 
>that we will have 64-bit processors, but rumours (old ones yes, but I have 
>seen nothing to make me thing otherwhise yet) tell me that Intel (at least) 
>will drop back-wards compatibility with the x86 instruction set
>

Intel was originally going to do this, but from what I heard, Microsoft 
told them no, or else you can forget about Windows compatiblity. MS is 
going with AMD's x86-extended set, as opposed to Intel's all-new set, 
which would lead me to believe Intel's turning around and using an 
x86-extended set themselves.

>Regardless of the processor I don't think it will have a major impact on the C 
>(java, c++. basic - you name it) language or Allegro 5, 6 or any other version 
>- be that 32, 64 or 128 bit processors, as long as there is a port to the new 
>processor and the os' that run on them.
>

As far as I can tell, the only difference for C/C++ code will be the 
size of a few integer types. And even there, I believe there's int32_t, 
int16_t, int8_t, ect if you need a specific size (you just need to 
include a header for them, though).

- Kitty Cat