Exactly. Just like I said with DOS support, if someone is willing and able to write a C++ version I'm all for it. hehe reminds me of the ALSA MIDI driver... I wrote it because I had a need. And Still I wonder if anyone else uses it.

being that OOP is much mroe than syntactical sugar, it can add ALOT to allegro. Including making updating, adding pulgins, modifying the library a snap.

Of course the same arguement could be made for dos...for what else is windows but icon based sugar?

You know what feature I want in the new allegro? HMMMM? heh, a nicer looking gui

Oh yeah, we could have AGUP as a plug-in

I'm yanking this from another thread ....

Allegro 5.0 request? A console port. Highly recommended would be Dreamcast, but since it's in short supply as of late (Sega has stopped manufacturing them I believe) XBox would probably be the next best idea. Maybe Shawn could get us some stats (kidding, kidding).

How feasible is this? I've seen hints on the mailing list that a GBA and PS port have been considered. How seriously have these been looked into? If a console port is possible, I highly recommend the Allegro crew look into the Dreamcast; not only is it not terribly difficult, but much work has already been done. Relatively speaking, it would probably be the easiest console to port to.

A console port would be awesome. and if I could get an M105 somehow maybe I could do a Palm port

p.s. Hey bob.. did you know that under konqueror, the image of winamp on your home page messes up the layout a bit?

The arguement of getting rid of DOS is completely valid. I mean why do you want some top of the line Video Card just to run Sprite based games? It DOES hender the further progress of Allegro simply because everything slows down to add support for it.
When I new video card comes out... it just works.... period. But with DOS Allegro.. we have to add new drivers... What a waste of time. And I honestly thing some things would be a lot cooler if Allegro could do.. Networking,USB support, REAL 3D. If you hate those features being in Allegro... then why upgrade? Why want a new allegro. If you want to stick with sprite games. Why is Allegro 4 soooooo bad?
What makes it so terrible that you can't deal with it? The garbage argement that it doesn't hurt anything in fact it does. Because no one will really want to write drivers for something that's suppose to be multiplatform. If it only works on some of the platforms.
I'm sorry but I write games for COMPUTER USERS to play... not just PROGRAMMERS. And weather you like it or not. Programmers are the only people still using DOS as a gamming platform. And people who have DOS as their maing OS. Honestly can't have great systems to begin with. So what's the deal with stopping progrogress.
Well then again maybe it shouldn't be called Allegro 5? Would that make people happy then? Remember the time when it was said that Allegro would never be ported to windows to begin with? I honestly love the fact now that I can play my games on more than just windows 95 systems. I can't even run the DOS games on my 98 system. So I guess that's the reason I want to get rid of DOS.
But as people keep saying. What's wrong with using Allegro 4?

Oh yeah, great Idea Chris. Lets port it over to MORE platforms instead of DOS. Then I would really be happy. No sarcasmin intended ^_^

As it occurs to me, I think it would be better to create 2 libraries, but with 1 API. You would have the full Allegro 5.0 (with OpenGL, maybe networking, maybe multithreading, with all the other features we can't put into an external module). Then, you have Allegro Lite, which supports a subset of the Allegro 5.0 features and functions. Allegro Lite is suitable for low-resource systems (like palm-top computers, etc) and perhaps even DOS.

The key feature between the two is that, while Allegro Lite has fewer functions, every Allegro Lite function has a corresponding function that provides the same functionality in Allegro 5.0. That is, if Allegro Lite has an alBltBitmap, then Allegro 5.0 will have the same function that takes the same arguments. This way, you can just link with slightly different libraries (if you adhere to Lite functions) and your code can run on all kinds of things. However, if you want, you can use the full 5.0 features, knowing that you are limitting the portability of the code.

However, Allegro Lite will suffer. Because the API for Allegro Lite functions must be derived from the functionality of Allegro 5.0. Also, Allegro Lite must not have functions or variables that aren't mirrored in Allegro 5. This means that, if in DOS you should make some strange function call when blitting to improve performance, but no 5.0-supported OS has need for such a function, then Allegro Lite must not have such a function either. It is vital that Allegro Lite be a complete and total subset of Allegro 5.0 such that Lite programs, with a simple recompile, can become full-fledged 5.0 programs. This means no OS-specific functions in Allegro Lite that are not in 5.0.

Is this a sufficient compromise to keeping DOS support? You can have DOS support (and the support of increased performance in some areas), while still preventing DOS from becoming an API burden.

Well...I know you guys love the name Allegro, but if you're planning on keeping 4.0 seperate from 5.0, and your'e rewriting everything, why don't you just rename the whole project. It'll mean less confusion for newbies. Remember guys, logic over sentiment.

So many smiley...
OK! SIMPLE question:
If Allegro drop DOS,
Can http://www.delorie.com/djgpp/zip-picker.html
drop Allegro??

I want to put my vote in for Dreamcast support. If not official dreamcast support, then partial, or unsupported dreamcast implementation would be nice. First of all, Sega DID stop making them, but has produced more to "meet expected holiday demand" and on top of that, the price has dropped to $50 US for a BRAND NEW dreamcast. Now, this just blows the socks off of the Playstation in terms of price/performance.
And to answer a few gripes, although there isn't an emulator for the PC that plays commercial Dreamcast games, there are at least 2 emulators that play several emulators written for the Dreamcast as well as some homebrew demo's and games. This is a big step for people who don't own coders cables, or who don't feel like burning alot of cdrs.
And just so everyone knows, I run WinXP and had no trouble getting the compiler tools up and running to code for the DC. The only problem is, the documentation for KallistiOS is somewhat sparse for someone with my programming knowledge. That is why I use a library like Allegro, it eliminates much of the "computer-ese" overhead.
Just a pipe dream for now, but I really want to pitch support for this, but obviously, to some extent, the dreamcast is a limited platform. I can easily understand why support wouldn't be added, but I'd like to voice my opinion all the same.
Thanks for your time,
-Flecko

I agree with Mandrake. DOS like C is alive and very well. If you ignore the thousands of people running pure DOS or millions running Win9x/ME/XP Home, then look at embedded systems as I said in the proper topic located here.

Ok, here goes my thoughs
C vs C++ topic: C++ cannot be used because the DLLs compiled by several compilers (say MSVC and Mingw32 (the compiler bundled with Dev C++)), if they use a C++ interface are just "incompatible". (And don't think even about calling those functions from other languages like Java or well, whatever).
Oh, and from ASM? A real pain! (if you never
tried... try... try... )
That above doesn't happen if the interface is a C interface.
Also (may you like it or may you not) classes and such are slower than plain C (you gotta pass the pointer to the class then hook the virtual member table... well, slower )
If you don't believe me, make a program that calls a lot of times a C function and then a C++ function in a class. Probably this last issue (speed) may not look important to you (fast computers...), but indeed the DLL one is.

DOS vs Windows topic: Personally, I would like to drop DOS support, cause I don't really see any use for it anymore, but just personally. But I guess (or should I say it is a fact?) a lot of people does still like it / use it, BUT as long as those DOS lovers people are willing to code it, I don't mind letting it in. What I would mind is seeing how other developers that don't care about DOS make the port just to keep people happy (IMHO those who want DOS, should code DOS).

And of course not cutting the library by what DOS can do and what it cannot do, but I guess we all agree on that this won't happen (If there is something DOS doesn't support, empty function for it and everybody happy, isn't it? ).
Modularization: Yes please, a must. The more independant the better. It even makes easier to follow the sources and, even better, if say the FLI video is buggy and they fix what is better? to recompile the full allegro as well as get it all again just to have the more up to date version? (even though you don't care about FLIs at all, but you want to test all those "some fixes") or to let people download their FLI module and you, that don't care at all, live without knowing what's going on there?
Of course, I must say there is a limit to modularization. For example SDL (to my eyes) is way TOO much modularized. A module to load images, a module to use putpixel, a module to play several sound effects at once... way too much )
Modules should be features that not too much people "play" with. Also modules could make ports to other platforms easier (like PalmOses that doesn't need X or Y feature of allegro)
Oh yeah, about DirectX 3 for NT 3 (4?)users... cmon, we cannot stay with it all the time, it is not like it was a version released a few days ago, but we are near DX9!
DX8 has very nice acceleration features (thanks to unifying directdraw and direct3d into directgraphics) that DX <= 7 cannot do...
Well, those are my thoughts. What do you think?
[ December 04, 2001: Message edited by: XavierGonz ]

bob> Yah but my montior is a 15' beastie that can only do 1024x768 if I turn DDC off and run it at 60Htz. (yes I do need a new monitor

Hmm... How about we all agree to stop arguing and start coding? Most of us are saying basically the same thing. (Can't we all get along I say if noone is willing to code a feature or whatever than it should deffinitly not make it into allegro no matter which version. But coding something shouldn't nessesarily mean it make it in though... UNLESS we know a fair amount of people would use/benifit from such a feature.