This note is not intended to push support in any direction. It's simply a documention of how the DOS port is relevant to some...

For me, DOS Allegro provides the means to collect reaction time data without the worries of the added variability introduced by Win(whatever#). I suspect that there are dozens to hundreds of psychology labs using Allegro for this very reason. Though I'm not in need of additional features it would be comforting to know that some development - code improvement - will always be considered. DOS has it's place for those with specific needs.

Whatever happens I have been thankful for Allegro and the help that I have received from the community...

KNS

[ December 06, 2001: Message edited by: kns ]

you are right bob, many of the internals are not reflected, yet many are also, such as global variables.
maybe what i said about C as being the major design mistake may be too much, i was stressing my emotion.
these are good links... with good points. I believe allegro could benifit greatly from C++ as a tool. people should not regect it, and stop saying c++ is slower.(not you bob, people in general)
http://www.itworld.com/AppDev/710/lw-02-stroustrup/
http://www.research.att.com/~bs/devXinterview.html

and of course
http://www.research.att.com/~bs/homepage.html

[post continued...]

As background, the loss of DOS support would not affect me personally, because I've moved over to MingW.

I've interpreted the statements by the core Allegro developers as: we plan to streamline and update Allegro for Windows (and presumedly Linux.) A secondary statement I interpreted was: we will not have the bandwith to do the same for DOS.

What I also heard: If you want an Allegro update for DOS that is compatible with the proposed Allegro update, then form a band of developers to make it happen. It is your job to make all the calls compatible with the Windows Allegro update, ostensibly ver. 5.0.

I have yet to hear (or don't remember) any significant reason to not go ahead with a Windows-(and Linux too?)-only update of Allegro because I have yet to hear any evidence that a separate DOS update cannot be compatible with the original proposed Allegro 5.0 update. That is, DOS "after-market" support or something similar seems to be still possible with the planned update of Allegro 5.0.

I found interesting the point about how DOS allows support for accurate timestamping of inputs in measurement systems and so forth. I've had expereience with the difficulty of an OS like NT to timestamp an event when the OS polls the input in a random manner due to its ability to run multiple programs (more) properly. And though this point was raised to garner favor for DOS support, I think it also shows a window into why Allegro core developers feel that to improve Allegro they would not support DOS directly. An operating system such as Windows NT/2000/XP and Linux are different than DOS in how they allow programs to access hardware (for games, namely video memory, video cards, and keyboards). This is manifested in the timestamping problem above. The ability to run multiple programs properly is a big reason why an OS like NT or Linux allows access to hardware much differently than DOS. For someone looking outside-in, this seems to be a big driver for change since the vast majority of people out there will use one of these "modern" operaturing system.

Again, similar to what I said in my C vs. C++ post above, DOS can be made to run multiple programs, though not always running at the same time. An example program that allows DOS to do this is called Windows 3.1. And with some clever tweaks, you get Windows 95. I wonder why these two programs always crashes?

One more point. For those Allegro programmers that don't need DOS to support specific DOS features (e.g. its inability to run multiple programs properly), perhaps Allegro in DOS is easier to program than Allegro in Windows. For such programmers I'll suggest that perhaps if Allegro was updated for Windows, it would be easier to program Allegro for Windows than for DOS.

Plucky

Ok, I would like to input some input. As I understand from current Allegro development, Allegro 4 is the end of the line for the current API structure. Because of this, I would like to offer some suggestions for what Allegro 5 should be like.
First off, DOS support should be dropped now. The limitations of DOS have clearly been seen. 4 years to develop a new release for the library is ridiculous. If future DOS support is desired, then perhaps supporting versions like 4.1, 4.2, etc. can be utilized to appease those individuals.
As for Allegro 5, it definately needs a complete API overchange. The idea of using a prefix (al_...) is a terrific idea and should be used. I would not support the idea of just implementing OpenGL or DirectX into the main functionality of Allegro is a bad idea. This would possibly alienate people who prefer other API's. It would be a good idea to support a video mode that supports them. I.e. GFX_OPENGL and GFX_DIRECTX. It is not a good idea to write "wrappers" for them. The reason for this is because writing wrappers reduces efficiency.
void foo () {
...do something
}
void foo_wrapper () {
foo ();
}
This kind of programming will not keep up with the technology these environments will evolve into. As an example, DirectX 8 is not backwards compatible with previous versions so providing native DirectX support isn't good.
Now, architecturally, it would be nice if an internal state table was maintained much like OpenGL whereby you would call a function like al_Set () or al_Get () to set and return parameters like current sound status, error messages, etc.
Reducing the number of functions is definately needed. Currently there are many functions to facilitate the loading of images (load_pcx, load_bmp, load_tga, etc.) Instead, why not kill those functions and just keep load_bitmap/save_bitmap/register_bitmap_loader style functions?
Reducing the support of drivers for video and sound would be feasible too. If Allegro 5 doesn't support DOS, then we really can drop Mode-X support. Mode-X by itself is mess to deal with and would certainly remove a lot of code. Supporting alternate drivers like the AUTODETECT drivers with the addition of features bits, we could achieve code like this:
int main () {
... Initial Driver Indicates we would like these features
alSetGfxMode (GFX_AUTODETECT | GFX_OPENGL | GFX_DIRECTX | GFX_DOUBLE_BUFFER);
al
}
Another idea is to have double-buffering support a graphics feature rather than software. Looking to the future, we could
have the graphics driver support double buffering.
We need to ensure basic functionality works on all platforms. OpenGL is a great example of this. We may have different ways of opening an OpenGL window, but after that using the functions work without dependency of external hardware differences. So separating how we initalize sound, video, and other platform specific features and how we put pixels or draw sprites could be an advantage because drivers that support specific hardware features could be written. A Driver module so to speak. This is how modern libraries such as OpenGL and DirectX work anyway.
This brings up another good design point. What if we start with a specification and then write a base library completely utilizing software that is platform independent? After that, we could write drivers that are designed to work with OpenGL or DirectX, or whatever platform we choose.
And what about adding XML file support, Threading, etc?
Anyway, just some points to consider.
Questions? e-mail me at microwerx@yahoo.com web page

You can't run or even develop DOS games with DJGPP with Windows 2000. I don't think XP is capable of the same thing. Even if you could, support is extremely limited. If I need to develop a "DOS" application, I simply write a Win32 console application with MSVC. And really, if you need to develop DOS style games, just switch over to Linux (It's free!). It provides a console mode style operating system with much better features and Allegro will run on it. DOS is really a terrible operating system (and very old I might add) and will always remain so.

For threading support, I wasn't suggesting that Allegro be threaded so to speak. But since we have the timer routines, etc. We could write a simplified version for developers to use threads in their applications.

well with allegro by using on MSVC.. you can do the coding the same in dos mode... with allegro, it made everything so SUPER-EASIER for window programmers.

please correct me if you find my reason mistaklable of in allegro 4.0 differ than my own expernices. Cuz i have not updated my allegro 3.9 to 4.0

Ideas:
I would prefer alMixedCaseFunctionNames() to al_underscore_seperated(). Using mixed case may seem to tendy or Microsoft-like to you guys, but I think it's worth it, because I can type alBlit much faster than I can type al_blit.
Fix all the font problems, placing ALL of the font routines in a single, standardized module. Make sure to support AL_FONT *al_load_font("filename.ttf"). Also, make sure antialiased/colored font rendering is as easy as possible, since many people use AA/colored text output as it is, and the existing Allegro font libraries make this difficult. It would be good to try and meet everyone's needs with the Allegro 5.0 font library, because I'd guess a lot of people (like me) are sick of writing and re-writing their own font output routines.
I think multithreading support is pointless, since the whole idea of Allegro is that it runs within a SINGLE virtualized screen - there's no point in communicating between threads/etc, if you have a good set of polling functions.
Making Allegro modular does NOT mean that Allegro should be based on DLLs. The size of allegro_core.dll + allegro_gfx.dll + allegro_sound.dll + allegro_io.dll + allegro_opengl.dll + allegro_timer.dll will most certainly add up to much more than just statically linking the whole mess, because there will be tons of uncalled functions in each DLL. I think we should abandon support of DLLs, because after working with Visual Basic a lot, I've realized how bloated each individual library (component) can become. There's a lot more pressure on developers to reduce the size of their libraries (and reduce unnecessary linkage of functions) if a simple Allegro program compiles into a 1+ meg executable.
It would be very cool if Allegro's makefile could help build plug-in libraries by setting up a bunch of standard makefile variables. That way, each plug-in could have a relatively simple makefile, without all the system-specific junk required to place headers/libs/etc in the correct directories.
I prefer mouse.x, because it looks nicer than mouse_x and looks much nicer than CMouse::GetXPos(). Also, we only need to support one mouse cursor, so there's no reason to have ugly Class::GetBlahBlah() functions like C++.
Add an option for set_gfx_mode to autodetect color depth, using either AL_BEST or AL_FASTEST.
Don't get rid of DOS...it's much better for debugging. Also, aside from threads and networking, all the functionality is already there.
Place MIDI in a module of its own, since everyone hates it.
There's no reason to get rid of global variables like mouse_x, etc. I mean, there IS only one mouse cursor on your screen.
al_main() is a great idea. Command-line arguments could be retrieved by some allegro function.
Place DATAFILES in a seperate module; they are just more bloat for people who don't use them.
double al_global_timer(); could return the number of floating-pt seconds since program start-up. I suggest you include something like that, since it's only a few lines of code, and I have to re-write them in every Allegro program I make. Since seconds are the SI unit for time, it would be much better to use seconds rather than milliseconds.
Build in Allegro functions for handing double buffers/triple buffers/etc. For example, a global variable like BITMAP *gfx_buffer could be created, then the user draws what he/she wishes to the buffer, and calls al_display_buffer(). Then all the ugly mouse cursor display code could be called inside al_display_buffer().
BITMAP *load_video_bitmap(const char *filename, PALETTE *pal);
BITMAP *load_system_bitmap(const char *filename, PALETTE *pal);
Perhaps we could make hardware acceleration a parameter for al_set_gfx_mode, and if the user chooses hardware acceleration, then triple or double buffering will be set up using the global BITMAP *gfx_buffer system. Also, we could make load_bitmap() and create_bitmap() be intelligent functions, which would return a video bitmap if possible, then a system bitmap, then a memory bitmap IF in HW accelerated mode, otherwise just return a system/memory bitmap. Then in general, create_memory_bitmap / load_memory_bitmap / create_video_bitmap / load_video_bitmap / create_system_bitmap / load_system_bitmap / ETC could be used if a specific type of bitmap is desired, and load_bitmap/create_bitmap would be used if the programmer just wants the fastest type of BITMAP * in the town. Maybe you can understand what I'm saying, maybe not. Anyway, my whole point is that software/hardware rendering can be made more transparent than it currently is, without sacrificing performance or flexibility.
There needs to be an internal Allegro variable (_allegro_blender_mode?) that is set when the set_***_blender() functions are called. That way, people can write add-ons which accelerate the existing Allegro blenders. set_trans_blender + draw_sprite comes to mind as a combination that could be made a teensy bit faster with D3D/OpenGL.
Vtables should include EVERY function which could potentially be accelerated (polygon3d_f).
Get rid of fixed-precision integer stuff. Use either radians or degrees as the default angle measure (we could vote on radians/degrees), and decide on measuring angles either CW from the right horizontal or CCW from the right horizontal. Then stick with it .
Support rotated sprites with seperate scale factors in the x/y directions (al_pivot_nonuniform_scaled_sprite? hehehe) Then V-mirror is a negative y scale, and H-mirror is a negative x scale.
Get rid of that incredibly ugly
unsigned long id; /* for identifying sub-bitmaps */
inside the BITMAP structure. Replace it with BITMAP *root_parent, which will point to the root parent of a sub-bitmap (and be passed from generation to generation of sub-bitmap), and can serve the same purpose in is_same_bitmap, without the ugly 'global unique id' generation thing.
Well, these are just ideas. I hope you find some of them to be good suggestions.
[ January 04, 2002: Message edited by: Connelly Barnes ]

Oh... I just wanted to point out that I had once a system with two mice connected, so don't be sure there's just one.

I did this only to play a self written air hockey with a friend of mine, and it was fun. I'm not sure what insert_your_os_here will do if you connect two mice right now, but I might try just for the fun of it

Oh Lord yes. I was just wishing for this yesterday.

About the naming convention : that's 4 people guys! 'DrawSprite' looks much better in the long term than 'draw_sprite'; it makes code browsing faster.

For one more time, Allegro needs to go 3D. Everyone is doing 3D; couldn't Allegro developers provide an API for 3D ? or they don't like 3D at all ? And don't say again 'use AllegGL'; OpenGL is not the most efficient way of doing 3D in Windows; Direct3D is. The API would provide wrappers above Direct3D/OpenGL/whatever 3D system is available in the target machine.

About DOS : I think that support for it should be dropped. DOS is so much outdated technologically.

About C or C++. If you plan to do it in C, why don't you keep it as C-like as possible ? I mean, using straight functions, variables, structs and enums. You may drop vtables already, and provide the functions as is. For example you could have "blit_memory_to_screen", "blit_screen_to_memory", "blit_memory_to_memory", "create_video_bitmap", "create_memory_bitmap", etc.

quote:For one more time, Allegro needs to go 3D. Everyone is doing 3D; couldn't Allegro developers provide an API for 3D ? or they don't like 3D at all ? And don't say again 'use AllegGL'; OpenGL is not the most efficient way of doing 3D in Windows; Direct3D is. The API would provide wrappers above Direct3D/OpenGL/whatever 3D system is available in the target machine.
See Shawns' thought. The link was posted on this web board somewhere...
quote:
About C or C++. If you plan to do it in C, why don't you keep it as C-like as possible ? I mean, using straight functions, variables, structs and enums. You may drop vtables already, and provide the functions as is. For example you could have "blit_memory_to_screen", "blit_screen_to_memory", "blit_memory_to_memory", "create_video_bitmap", "create_memory_bitmap", etc.

See this thread
quote:In your face, Bob!
Great! Now you only have Peter, Eric, Shawn, Michael and George to convince