Obsoleting CDAudio and Room-specific view

[Gilbert]

But I doubt how would a set of CDaudio functions clutter up the engine much.

[Scorpiorus]

While on this note...
What would be the problems with moving stuff like this into add-on modules? An optional plugin?

Actually, it seems to be a good way to organize things. I am not sure about CD audio functions which, as Gilbert says, shouldn't cost much space but a stuff like MP3-related functions or even the Allegro library itself could be dynamically linked at run-time. But this approach also raises several issues to be solved.

Would it require rewriting all the code, or is it pretty much cut and paste?

I think it depends on what functionality you want to move into an external module. There should be interfaces set up -- will an exteranl module just be a library with functions to use or will it be some sort of a plugin and some callback functions are needed to be declared (to call into the engine)? etc.

What systems won't plugins work under if any?

As far as I know, currently, plugins (being implemeted as windows DLLs) only work with the windows engine of AGS. I don't know whether the linux engine supports plugins or not?

would this be doable if they were DLLs?

Dos and Linux users won't tolerate this I think

Except Linux has a thing called shared object files

Yeah, sure. I just thought with DLLs you mean windows DLLs but I think writing a portable source code to work with both the windows DLLs the and linux SOs is possible.


So, instead of the engine executable file there could be (for Windows):

ac.exe
allegro.dll
mp3lib.dll
etc.

So that when you compile a game only required files are copied into the game\compiled folder.

Seems good but there are problems, I believe. What for example if the end user will have a wrong version of a library? Wouldn't then we get a numerous number of topics on why my game doesn't work etc?

It also seems to me in no way a high priority feature as the engine is not that large, anyway.

[YOke]

So, instead of the engine executable file there could be (for Windows):

ac.exe
allegro.dll
mp3lib.dll
etc.

So that when you compile a game only required files are copied into the game\compiled folder.

Seems good but there are problems, I believe. What for example if the end user will have a wrong version of a library? Wouldn't then we get a numerous number of topics on why my game doesn't work etc?

If the required libraries are included in the game there will be no problems at all. If not it will be, as you say, hell.
Or Chris could make a big checklist of what functions you want to have in the game. 

It also seems to me in no way a high priority feature as the engine is not that large, anyway.

Also very true. The only thing that could be very useful in reducing the space a game takes at this time is better, lossless image compression.

[Pumaman]

I don't want the engine to rely on external DLL files, because a lot of people say that what they like about AGS is its ability to generate a single EXE file containing the entire game, and having it rely on dll's would spoil this.

Anyway, I don't think the CDAudio functions take up much space in terms of KB, I was more just thinking about removing it from a maintainability point of view. However, since some people are using it I'll leave it in.

[Gilbert]

I think it's harmless to keep the CD audio functions.
In my opinion it's preferable to remove something if:
1) It bloats the programme in terms of disk space, memory usage or speed.
2) The feature is useless in a sense that it can be archived via a better way, and removing it can reduce confusions. (leg. the room character view thing mentioned here)

[SSH]

Is there a way that some kind of static linking ability could be added to AGS, so that all plugins are incorporated into the EXE?

[Pumaman]

Not realistically, no. They could be packed into the EXE and then extracted at run-time, but that's all a bit messy.

[YOke]

I don't want the engine to rely on external DLL files, because a lot of people say that what they like about AGS is its ability to generate a single EXE file containing the entire game, and having it rely on dll's would spoil this.

Well... That argument is very thin. As I imagined it when I wrote it, the functions exported to .dlls would be additional functions aimed at the advanced users and the specially interested.
In my opinion it would be nice to separate the functions not normally used from the engine to reduce bloat. It can increase the user friendlyness of AGS and make it even more accessible.

Just to be clear, I'm not saying that it's worth doing this now, with these two functions. I'm just discussing the future development of the engine.

[Ishmael]

I don't want the engine to rely on external DLL files, because a lot of people say that what they like about AGS is its ability to generate a single EXE file containing the entire game, and having it rely on dll's would spoil this.

Well... That argument is very thin. As I imagined it when I wrote it, the functions exported to .dlls would be additional functions aimed at the advanced users and the specially interested.
In my opinion it would be nice to separate the functions not normally used from the engine to reduce bloat. It can increase the user friendlyness of AGS and make it even more accessible.

Just to be clear, I'm not saying that it's worth doing this now, with these two functions. I'm just discussing the future development of the engine.

So you're saying that this ease of creation and distribution should be aimed only to the beginners who do not use these advanced functions yet? And it would still confuse them if they need something from the advanced part.

AGS is great the way it is, I'll be saying a strict no to any suggestions to part something from it to a .dll unless CJ can prove it's better that way.

[YOke]

I'm saying that the advanced functions don't need to be available for a game that doesn't use them, thereby reducing file size.
I agree that AGS right now is perfect the way it is, but my argument was for the development in the future. I imagine that most of the functions that are in AGS today, or their future equvivalents will have to stay in the engine, but for the sake of efficiency some rarely used functions (either because of their specialized nature or other reasons) could be "banished" to a .dll file.
And yes, it will make it easier for the beginners, but that's sort of the point with AGS too, isn't it?

[Gilbert]

Using external libraries just break compatibilities with the other ports, unless they're compiled for all plots.

[Ishmael]

I'm saying that the advanced functions don't need to be available for a game that doesn't use them, thereby reducing file size.

The majority of internet users today don't have 56k anymore, so a few kb here or there doesn't matter that much. Make your game with simpler graphics if you are worried about the filesize...

[Pumaman]

Ok, so 4 years have passed since this thread was originally started, and my question is:

Has anybody actually used the CDAudio command in a game, or can it now be removed?

[Shane 'ProgZmax' Stevens]

I've never had a need for it, and I can't see much call these days for streaming audio when you can get 500 gb hard drives for almost nothing.

[monkey0506]

Now CJ you know dragging up old, dead threads is frowned upon!

As far as the CDAudio, I wouldn't use it. AFAIK you can run WMP, iTunes, WinAMP, etc. in the background while you play an AGS game right? ...the only reasonable suggestion for not removing it that I saw previously was so users could listen to their own music instead of the game tracks...