Ok, in order to try and reduce bloat a bit, and clear up some confusion, I'm proposing to remove two things from AGS:
1. CDAudio support. I don't think anybody has ever used it, and indeed it'd be a waste of a CD to use CD Audio rather than OGG music.
2. The "Player character view" option on the Room Settings pane. It's confusing, doesn't always work properly and a better effect can be achieved using ChangeCharacterView or the walkable area views.
So, does anyone have any opinions on these? Is anybody using either of these features and would find it really annoying if they were removed?
Well, I think we can safely drop 2, although it IS a nice feature for newcomers...
...but leave 1 on. It's a nice feature, and I've toyed with it sometimes. I've considered using it some times for some purposes, ended up not doing it, but it's always a nice feature to have. Better to have too many than not enough.
Like CJ said, though, why not use barely-compressed OGG or MP3? CD Audio was only originally used because it worked, but they stopped doing that fairly quickly.
As for 2, I must not know what view setting you mean.
I wouldn't mind if these were removed.
CD-Audio is a nice feature but hardly practical for a game. I never had any use for no. 2.
I didnt even know that number two existed, as you stated that there is an easy work around there isnt use for it. Number one doesnt affect me so whatever you pick I am cool with.
I used the cd functions in my first game. Since there wasn't any music, you could play an audio cd by pressing P.
You could remove flipscreen. They look handy, but are useless when you try to do something with it. I think no one ever used it.
I'll say 1 can be useful if you use it but yeah it doesn't hurt without it, so I don't have problem without that.
2 is an outdated feature (yeah) and it'll just cause confusions now, so I'll say it should definitely be out.
1. More and more people make non-adventuregames in AGS and then it can be nice to be able to play your favourite CD while you are mindlessly blasting monsters or whatever. It's a feature I miss in many such games and will surely put it in there if/when I make one.
2. Die!
Well, if people are using CD Audio then there's no harm in leaving it in.
It's just that I've never actually seen a game be released with CD Audio (for obvious reasons, since most games are downloadable).
If people are using the facility to add some sort of "play my CD" function to their games then that's fine and I'll leave it in ... it just seemed like something that was probably not getting used and so bloating the engine for no good reason.
I've for a long time been thinking of setting my game so that if you have an audio CD in the CD drive when you start the game, the normal game music is dropped and random track numbers are assigned into these slots (Or they are assigned in order, whatever the player chooses, and that they could also modify the playlist) and played respectively.
I'd like to do this eventually, so I vote to leave the CD-audio support in. :)
Or you could just turn off the music in setup and use your favourite media player... actually, I dunno how doable it is, but it would be nice if you could turn on and off large features that might appear in your compiled game... ie. turn of MP3 player, CD Audio, and even configure yourself the number of objects, hotspots per room (up to a hard max of 250, say)... would this be doable if they were DLLs?
Quote from: SSH on Thu 16/12/2004 15:34:24would this be doable if they were DLLs?
Dos and Linux users won't tolerate this I think :)
I too for removing "Player character view" feature since it seems obsolete.
As for CDAudio support - I don't really know. A nice additional feature to have but I think, it depends no how much kbytes libcda code takes in a binary form.
I was gonna vote to take off both, but I can see why the CD audio thing might be useful.
But yeah, I vote for taking off the player character view.
While on this note...
What would be the problems with moving stuff like this into add-on modules? An optional plugin?
Would it require rewriting all the code, or is it pretty much cut and paste? What systems won't plugins work under if any?
Quote from: YOke on Sun 19/12/2004 00:46:29
While on this note...
What would be the problems with moving stuff like this into add-on modules? An optional plugin?
Would it require rewriting all the code, or is it pretty much cut and paste? What systems won't plugins work under if any?
hmmm.... maybe:
Quote from: Scorpiorus on Thu 16/12/2004 15:53:26
Quote from: SSH on Thu 16/12/2004 15:34:24would 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
And DOS... does anyone still use DOS at all? Especially people who use AGS? I mean, what is really the use of making a DOS game with AGS anymore?
I'm not thinking about the other platforms here, I'm thinking about if I need to pack an extra DLL into the game zip or rar file just if I want to give the player the possibility to play their favourirte music while playing the game without them having to start a cd player program and setting up the options and whatever.
Well. For that function alone it would be useless, but over time a greater number of functions will be more or less obsolete.
Could be nice to place all those functions in a separate plugin for those specially interested in it.
Quote from: YOke on Sun 19/12/2004 23:34:49
Well. For that function alone it would be useless, but over time a greater number of functions will be more or less obsolete.
Could be nice to place all those functions in a separate plugin for those specially interested in it.
...in case they start to clutter the engine load up.
IMO
But I doubt how would a set of CDaudio functions clutter up the engine much.
Quote from: YOke on Sun 19/12/2004 00:46:29While 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.
QuoteWould 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.
QuoteWhat 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?
Quote from: Scorpiorus on Thu 16/12/2004 15:53:26
Quote from: SSH on Thu 16/12/2004 15:34:24would this be doable if they were DLLs?
Dos and Linux users won't tolerate this I think :)
Quote from: SSH on Sun 19/12/2004 15:43:43
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.
Quote from: Scorpiorus on Tue 21/12/2004 13:46:35
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. :P
Quote from: Scorpiorus on Tue 21/12/2004 13:46:35
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.
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.
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)
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?
Not realistically, no. They could be packed into the EXE and then extracted at run-time, but that's all a bit messy.
Quote from: Pumaman on Tue 21/12/2004 21:39:11
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.
Quote from: YOke on Wed 22/12/2004 12:30:49
Quote from: Pumaman on Tue 21/12/2004 21:39:11
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.
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?
Using external libraries just break compatibilities with the other ports, unless they're compiled for all plots.
Quote from: YOke on Wed 22/12/2004 13:20:51
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...
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?
:)
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.
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...