From: Greg E. <gre...@ca...> - 2008-03-16 06:43:15
|
I'm trying to compile the XCode project included with AlephOne-20071103. Mostly it works, but there are a couple of problems: 1) All the sound is coming out choppy, as though it's missing every second bufferful of sound, or something like that. 2) The dialog boxes don't come out looking like they do in the precompiled version. There are no graphics, only text in a very small font. (The dialogs do function, however.) The only changes I've made to the XCode project were to add a couple of header search paths so that it could find the libmad and boost headers on my system. Anyone know what might be going on? I'm using MacOSX 10.4.4 on a G4, with XCode 2.4.1. -- Greg |
From: Gregory S. <wo...@tr...> - 2008-03-16 11:38:39
|
On 3/16/08, Greg Ewing <gre...@ca...> wrote: > I'm trying to compile the XCode project included with > AlephOne-20071103. Mostly it works, but there are a > couple of problems: > > 1) All the sound is coming out choppy, as though it's > missing every second bufferful of sound, or something > like that. This happens if you're on an old machine and build using the Debug target. Build Release, or trying playing around with the "samples" field in your preferences file. > 2) The dialog boxes don't come out looking like they do > in the precompiled version. There are no graphics, > only text in a very small font. (The dialogs do > function, however.) Does it work if you re-select the default theme in Environment preferences? > I'm using MacOSX 10.4.4 on a G4, with XCode 2.4.1. You should really try to keep up with Mac OS X patch releases and security updates--unless that machine never gets on the Internet. You're going to need Xcode 2.5 to build the next release of Aleph One, anyway! |
From: Greg E. <gre...@ca...> - 2008-03-17 00:04:02
|
Gregory Smith wrote: > On 3/16/08, Greg Ewing <gre...@ca...> wrote: > >> 1) All the sound is coming out choppy > > This happens if you're on an old machine and build using the Debug > target. Build Release, or trying playing around with the "samples" > field in your preferences file. If you're talking about the 8/16 bit setting, I tried changing it to 8 bit. After closing the Sounds dialog, it immediately started making a continuous staccato sound until I changed it back again. I tried turning all the other options off, and reducing to 1 channel, but this made no improvement. Can you elaborate on what exactly it is about a debug build that causes this to happen? Is there some way of configuring the project so that it will work properly while still allowing debugging? >> 2) The dialog boxes don't come out looking like they do >> in the precompiled version. > > Does it work if you re-select the default theme in Environment preferences? Yes, that fixed that one, thanks. > You're going to need Xcode 2.5 to build the next release of Aleph One, Is this because you need some feature that is only present in Xcode 2.5, or just because that's the version you happen to be using? It's frustrating the way Apple keeps changing the Xcode project format in ways that break older versions of Xcode. It mightn't be so bad if they provided a *reasonable* way of updating your Xcode to cope, but a 1GB download every time is a bit much. :-( Anyhow, thanks for your help. -- Greg |
From: Gregory S. <wo...@tr...> - 2008-03-17 00:57:01
|
On Mar 16, 2008, at 7:58 PM, Greg Ewing wrote: > If you're talking about the 8/16 bit setting, I tried changing > it to 8 bit. After closing the Sounds dialog, it immediately > started making a continuous staccato sound until I changed > it back again. The setting is called, exactly, "samples" in your preferences file. Increasing that buffer size might help if your CPU is overloaded. Decreasing it seemed to help Forrest on his dual G4, for reasons I don't understand. It's also possible it won't help at all. > Can you elaborate on what exactly it is about a debug build > that causes this to happen? Is there some way of configuring > the project so that it will work properly while still allowing > debugging? Debug builds are built without compiler optimization--which I guess is what makes the sound code not work. You can build it with optimizations (that make debugging more difficult) by choosing the Release target. > Is this because you need some feature that is only present > in Xcode 2.5, or just because that's the version you happen > to be using? Xcode 2.5 is the minimum version that works with Mac OS X 10.5. Gregory |
From: Timothy C. <da...@ma...> - 2008-03-17 01:14:29
|
Gregory Smith wrote: > Xcode 2.5 is the minimum version that works with Mac OS X 10.5. > It's also a *free* upgrade that works just fine with Tiger. Why would you *not* upgrade to 10.4.11 and XCode 2.5?? Timothy Collett -- The only thing you can't trade for your heart's desire is your heart. ~ Miles Naismith Vorkosigan |
From: Greg E. <gre...@ca...> - 2008-03-17 02:04:54
|
Gregory Smith wrote: > The setting is called, exactly, "samples" in your preferences file. Okay, found it (after having some difficulty finding the right preferences file, as it seems to be put under Application Support now rather than Preferences -- is there some reason for that?) Anyway, reducing it to 256 seems to cure the sound problem. Thanks for all the help, Greg |
From: Gregory S. <wo...@tr...> - 2008-03-17 02:07:38
|
On Mar 16, 2008, at 9:59 PM, Greg Ewing wrote: > > Okay, found it (after having some difficulty finding the right > preferences file, as it seems to be put under Application > Support now rather than Preferences -- is there some reason for > that?) It was useful having NIBs and SDL preferences separate while there were separate builds. Now that there is only SDL, I'm not sure how to move them back to ~/Library/Preferences where they belong. Gregory |
From: Greg E. <gre...@ca...> - 2008-03-17 02:27:20
|
Gregory Smith wrote: > Now that there is only SDL, I'm not sure how to > move them back to ~/Library/Preferences where they belong. Maybe put them in a subfolder under ~/Library/Preferences? Or is there some guideline against doing that? BTW, a thought about preferences -- it seems to me that most of the stuff in the Environment section doesn't belong in an application-wide preferences file. If it's to be configurable at all, it ought to be stored per-scenario. Lumping together the application-wide and scenario-specific preferencs means that every time I start on a new scenario, I have to set up my preferred graphics options, key bindings, etc. all over again. -- Greg |
From: Gregory S. <wo...@tr...> - 2008-03-17 02:46:57
|
On Mar 16, 2008, at 10:21 PM, Greg Ewing wrote: > Gregory Smith wrote: >> Now that there is only SDL, I'm not sure how to >> move them back to ~/Library/Preferences where they belong. > > Maybe put them in a subfolder under ~/Library/Preferences? > Or is there some guideline against doing that? There's no reason they can't live in ~/Library/Preferences, it's just, how do I get all 20,000 Aleph One users to move theirs there? I guess I reset them and make them set everything up again. > BTW, a thought about preferences -- it seems to me that > most of the stuff in the Environment section doesn't belong > in an application-wide preferences file. If it's to be > configurable at all, it ought to be stored per-scenario. We don't have application-wide preferences, only per-scenario prefs. Assuming your scenario uses MML correctly. Gregory |
From: Alexei S. <isv...@sy...> - 2008-03-17 03:50:19
|
> There's no reason they can't live in ~/Library/Preferences, it's just, > how do I get all 20,000 Aleph One users to move theirs there? I guess > I reset them and make them set everything up again. Try to read from ~/Library/Preferences. If it doesn't exist (or is invalid old Carbon prefs), then try to read from Application Support. When saving preferences, save to new location always. -Alexei Svitkine |
From: Greg E. <gre...@ca...> - 2008-03-17 08:32:49
|
Gregory Smith wrote: > We don't have application-wide preferences, only per-scenario prefs. > Assuming your scenario uses MML correctly. That's the point. Things like key bindings *should* be application-wide. If I prefer a particular control setup, I want it for all the scenarios I play. I can't imagine wanting to change it from one scenario to another. Conversely, I don't think the choice of map, physics etc. belongs in the preferences at all. It should be solely determined by the configuration of the scenario you're playing. If these two concerns were separated properly, then it wouldn't be necessary to specify a unique preferences file name in the MML of every scenario, and it wouldn't be necessary to use a separate copy of Aleph One for every scenario. The scenario folder should be a self-contained "document" that can be played by Aleph One wherever it happens to be installed, without any chance of parts of it getting confused with another scenario. -- Greg |
From: Timothy C. <da...@ma...> - 2008-03-17 11:24:16
|
Greg Ewing wrote: > Conversely, I don't think the choice of map, physics > etc. belongs in the preferences at all. It should be > solely determined by the configuration of the scenario > you're playing. What about standalone maps, shapes, and physics? Ones not part of any scenario? Timothy Collett -- The only thing you can't trade for your heart's desire is your heart. ~ Miles Naismith Vorkosigan |
From: Larson, T. E. <TEL...@we...> - 2008-03-17 13:30:01
Attachments:
smime.p7s
|
Greg Ewing <> wrote: [snip app-wide key bindings] [snip per-scenario config] > If these two concerns were separated properly, then it wouldn't be > necessary to specify a unique preferences file name in the MML of > every scenario, and it wouldn't be necessary to use a separate copy of > Aleph One for every scenario. I gotta agree with that. I have no idea how hard it would be to implement, though. Tim -- Tim Larson AMT2 Unix Systems Administrator InterCall, a division of West Corporation Eschew obfuscation! |
From: Gregory S. <wo...@tr...> - 2008-03-17 13:47:44
|
On Mon, 17 Mar 2008, Greg Ewing wrote: > That's the point. Things like key bindings *should* > be application-wide. If I prefer a particular control > setup, I want it for all the scenarios I play. I > can't imagine wanting to change it from one scenario > to another. I've used different controls for different scenarios. They should not be application-wide. > Conversely, I don't think the choice of map, physics > etc. belongs in the preferences at all. It should be > solely determined by the configuration of the scenario > you're playing. That is an absurd suggestion. > If these two concerns were separated properly, then > it wouldn't be necessary to specify a unique preferences > file name in the MML of every scenario Why do we care? The scenario needs to identify itself uniquely one way or another in MML--so what's the harm in making the prefs file name configurable as well? > and it wouldn't be necessary to use a separate copy of Aleph One for > every scenario. This is already unnecessary. > The scenario folder should be a self-contained "document" > that can be played by Aleph One wherever it happens to be > installed, without any chance of parts of it getting > confused with another scenario. Scenarios with unique preferences filenames already have this property. Gregory |
From: Greg E. <gre...@ca...> - 2008-03-17 23:32:25
|
Timothy Collett wrote: > What about standalone maps, shapes, and physics? Ones not part of any > scenario? You would have to construct a valid one-level scenario containing them, and play that. This could be as simple as putting all the relevant files in a folder together and pointing A1 at it. It would also help if A1 recognised aliases/shortcuts in place of the actual files (not sure whether it already does). -- Greg |
From: Alex B. <bol...@um...> - 2008-03-18 14:07:43
|
Greg Ewing wrote: > Timothy Collett wrote: > >> What about standalone maps, shapes, and physics? Ones not part of any >> scenario? >> > > You would have to construct a valid one-level scenario > containing them, and play that. > > This could be as simple as putting all the relevant > files in a folder together and pointing A1 at it. > > It would also help if A1 recognised aliases/shortcuts > in place of the actual files (not sure whether it > already does). > You mention unnecessary annoyances, but this one takes the cake for sure. What about multiplayer, which is almost exclusively done with Infinity? I can't believe how much of a pain it would be to need a fresh Aleph One application for /every single map pack./ It would be a huge waste of time, not to mention the space for copying the Shapes, Sounds, and Images files every time. Your complaint about having to reset the controls for each Aleph app is valid, but that's about it. The rest of it would be far too much of a hassle for half the userbase to justify doing it for the other half. The most optimal thing would be a scenario browser within Aleph One, but even that would probably be impractical. |
From: Greg E. <gre...@ca...> - 2008-03-17 02:15:25
|
Timothy Collett wrote: > Why would you *not* upgrade to 10.4.11 and XCode 2.5?? As I said, engaging in 1GB downloads is not something I do on a whim. I don't use Xcode very much myself, and it seems that every time I download someone's project, it turns out he used a slightly later Xcode version than I've got, with the result that I can't load the project file, even though I could quite probably compile it just fine if only I could figure out what options to set up. I get a bit tired of that sort of carry-on. -- Greg |
From: Greg E. <gre...@ca...> - 2008-03-17 08:34:38
|
Gregory Smith wrote: > There's no reason they can't live in ~/Library/Preferences, it's just, > how do I get all 20,000 Aleph One users to move theirs there? You could look for one in Application Support and move it to Preferences if you find one. Eventually things would come right. -- Greg |
From: Greg E. <gre...@ca...> - 2008-03-18 00:13:47
|
Gregory Smith wrote: > I've used different controls for different scenarios. They should not be > application-wide. But this would be the exception rather than the rule, wouldn't it? There could be a way of saving a set of prefs for a particular scenario if you want, but if you don't, I think there should be an app-wide prefs set to fall back on. >>Conversely, I don't think the choice of map, physics >>etc. belongs in the preferences at all. It should be >>solely determined by the configuration of the scenario >>you're playing. What's so absurd about it? In most cases, the map, shapes, physics and sounds are all designed to work together as an integral part of the scenario. The idea of arbitrarily swapping them around is what's absurd to me. > Why do we care? Because the experience I have every time I fire up a newly-installed scenario is "WT*??? Why aren't any of the controls working? Oh, bugger, it's because it's gone back to all the silly defaults." Then I have to go into Preferences and work through all the dialogs to set them up all over again. This seems like a totally unnecessary annoyance to me. > The scenario needs to identify itself uniquely one way or > another in MML But only because of the wrongheaded way all this is designed to begin with. If the *natural* behaviour was to look in the same folder as the map for all the other parts of the scenario, then there would be no need to spell this out in the MML every time, and no need to store the map/shapes/physics/sound filenames in a preference file. -- Greg |
From: Greg E. <gre...@ca...> - 2008-03-18 00:19:59
|
Gregory Smith wrote: > On Mon, 17 Mar 2008, Greg Ewing wrote: > > > and it wouldn't be necessary to use a separate copy of Aleph One for > > every scenario. > > This is already unnecessary. > Scenarios with unique preferences filenames already have this property. How do you tell Aleph One to play a scenario that isn't in the same folder as the application? I haven't been able to get that to work. -- Greg |
From: Gregory S. <wo...@tr...> - 2008-03-18 00:41:28
|
On Mar 17, 2008, at 8:14 PM, Greg Ewing wrote: > > How do you tell Aleph One to play a scenario that isn't > in the same folder as the application? I haven't been > able to get that to work. Drag the scenario folder on top of the app. Gregory |
From: Greg E. <gre...@ca...> - 2008-03-18 22:57:49
|
Alex Bolton wrote: > I can't believe how much of a pain it would be to need a fresh > Aleph One application for /every single map pack./ It would be a huge > waste of time, not to mention the space for copying the Shapes, Sounds, > and Images files every time. You have to do *something* to link the maps with the resources that the maps are expecting. I don't see how it's substantially harder to set up a folder containing links/aliases/shortcuts (not copies!) to the relevant files than it is to navigate through a bunch of dialogs setting up the same things. If you have a number of map files that all share the same resources, you should be able to put them all in the same folder, and just double-click the map file that you want to run. > The most optimal thing would be a scenario browser within Aleph One, but > even that would probably be impractical. What I'm suggesting gives you a scenario browser for free, by making use of what the Finder (or equivalent on your platform) already provides. Scenarios (whether single or multiplayer) are just folders or files that you feed into the application, and it knows what to do with them. -- Greg |
From: Darren W. <dd...@gm...> - 2008-03-18 23:34:25
|
You've obviously never played alephone online, because that just doesn't make sense at all. You're suggesting that people should shut down the application and double-click a new map file every time you want to gather from a new map pack? People switch map packs all the time, and it would be a huge hassle and would make waits between games even longer. This may be the most ridiculous suggestion I've seen since I've been a subscriber to this list. Maybe what you want is one global preferences file that keeps track of controls, and then have each scenario file use it's own preferences for the environment settings. That wouldn't be too bad, but still probably unnecessary. On Tue, Mar 18, 2008 at 4:52 PM, Greg Ewing <gre...@ca...> wrote: > > If you have a number of map files that all share > the same resources, you should be able to put them > all in the same folder, and just double-click the > map file that you want to run. > > -- > Greg > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Marathon-devel mailing list > Mar...@li... > https://lists.sourceforge.net/lists/listinfo/marathon-devel > |
From: <fo...@we...> - 2008-03-19 00:04:56
|
I still like my old idea whereby, if Aleph doesn't find its requisite files in the folder with it, it searches all subfolders of its folder for those files and then presents you with a menu or list with the names of those subfolders to choose from, and then behaves as though it were running in that folder. That way, you could have your Aleph One folder, containing only the Aleph One application plus subfolders for all the various scenarios you have installed, and when you double-clicked on Aleph One it would tell you "pick a scenario:" and list all the subfolders of your Aleph One folder that contain valid scenario data. Pick one and it runs that scenario. And the existing behavior would still be preserved, for if Aleph found its requisite files in its own folder it would just run exactly like it does now. All you'd be replacing is the "I can't find map/shapes/sounds/etc" message with "I found several sets of those, pick one". -Forrest |
From: Greg E. <gre...@ca...> - 2008-03-19 01:49:17
|
Darren Watts wrote: > You've obviously never played alephone online, because that just doesn't > make sense at all. You're right, I haven't, so I'm not familiar with all the issues involved. But from the discussions I've seen, it seems like rather a mess -- with some things being downloaded from the gatherer, and others having to be selected locally, and if you get anything wrong, all hell breaks loose. > You're suggesting that people should shut down the > application and double-click a new map file every time you want to > gather from a new map pack? You wouldn't have to shut down the application if there were a way to navigate to a folder and select a map file from within A1. You can do that now, except for the navigating-to-a-folder part, which seems to have got lost in the SDL version. It surely can't be too difficult to get it back. The only difference would be that the location of the map file would imply which shapes/physics/sounds files to use as well, instead of having to select them individually. As a consequence, there also wouldn't be any need to store them in a preferences file. > Maybe what you want is one global preferences file that keeps track of > controls, and then have each scenario file use it's own preferences for > the environment settings. I don't see how having a separate preferences file for each scenario helps with net play. Unless I've missed something, you can't switch from one preferences file to another within A1, so if you don't want to quit A1 between net games, you only have one preferences file for all your net play anyway. -- Greg |