alephmodular-devel Mailing List for AlephModular (Page 4)
Status: Pre-Alpha
Brought to you by:
brefin
Menu
▾
▴
alephmodular-devel — AlephModular Developers Mailing List
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(61) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(193) |
Feb
(61) |
Mar
(55) |
Apr
(5) |
May
(3) |
Jun
(1) |
Jul
(3) |
Aug
(14) |
Sep
(19) |
Oct
(48) |
Nov
(6) |
Dec
(25) |
| 2004 |
Jan
(1) |
Feb
|
Mar
(2) |
Apr
(6) |
May
(1) |
Jun
(1) |
Jul
(1) |
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(17) |
Jun
(20) |
Jul
(13) |
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2008 |
Jan
|
Feb
|
Mar
|
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Br'fin <br...@ma...> - 2003-12-16 12:15:43
|
*mutter mutter grumble* It would figure that autoconf's tools don't like Application Support. Even when you do something like: ./configure --prefix='"/Library/Application Support/Expat/expat-1.95.7/"' On the other hand, I do agree that Application Support itself was never quite right. /Library/Libraries seems a little redundant. So how about /Library/Development? -Jeremy Parsons On Dec 15, 2003, at 9:58 AM, Br'fin wrote: > Ok, the initial documents they linked to mentioned the four .o files > and not a lib. The release 1.95.7 download that I'm currently looking > at does appear to link elements into a libexpat. > > I'm inclined to try experiments with configuring it to install into > /Library/Application Support/Expat/expat-1.95.7/ > > Mmm, an OSX setup document should be added somewhere under > alephModular/documents and a note to look there in that directory > should be added to the README.txt... > Perhaps create alephModular/documents/setup (installation?) and within > that we can have setup_macosx.txt, setup_unix.txt, setup_win32.txt and > the like? > > -Jeremy Parsons |
|
From: Br'fin <br...@ma...> - 2003-12-15 14:58:16
|
On Dec 15, 2003, at 2:10 AM, Alexander Strange wrote: > > On Dec 14, 2003, at 11:52 PM, Br'fin wrote: >> Now isn't that interesting. expat itself is not distributed as a >> library per-se. I wonder why that is? Though I should imaging putting >> it's own home directory into a versioned directory and directing >> XCode to look for the external files there would still be >> appropriate. > > It's very small and self-contained; I think the reason is because > something that small would be a bit silly to make an external library. > Ok, the initial documents they linked to mentioned the four .o files and not a lib. The release 1.95.7 download that I'm currently looking at does appear to link elements into a libexpat. I'm inclined to try experiments with configuring it to install into /Library/Application Support/Expat/expat-1.95.7/ Mmm, an OSX setup document should be added somewhere under alephModular/documents and a note to look there in that directory should be added to the README.txt... Perhaps create alephModular/documents/setup (installation?) and within that we can have setup_macosx.txt, setup_unix.txt, setup_win32.txt and the like? -Jeremy Parsons |
|
From: Alexander S. <ast...@it...> - 2003-12-15 07:10:51
|
On Dec 14, 2003, at 11:52 PM, Br'fin wrote: > Now isn't that interesting. expat itself is not distributed as a > library per-se. I wonder why that is? Though I should imaging putting > it's own home directory into a versioned directory and directing XCode > to look for the external files there would still be appropriate. It's very small and self-contained; I think the reason is because something that small would be a bit silly to make an external library. |
|
From: Br'fin <br...@ma...> - 2003-12-15 04:52:51
|
Ok, I've managed to change a couple niggling things on the AM side of the preferences now that it's been decoupled from the file structures. Next up is serious setup and integration of a XML - Plist based preferences reader/writer pair. I am not going to debate preference file formats. I believe PList is a fine format. And should be fine cross-platform since I don't intend to use Apple's APIs for working with preferences. Sure it's an OSX native format with most of the tools for working with it being OSX Only. But it's also a workable XML format, and at least there are tools to work with it. For XML Libraries, I'm less decided. It looks like A1 uses expat. And from some reading up on expat, it appears to be a fine project with a good pedigree. This will also be the first existing other project to be used within AM. *looks at something* Now isn't that interesting. expat itself is not distributed as a library per-se. I wonder why that is? Though I should imaging putting it's own home directory into a versioned directory and directing XCode to look for the external files there would still be appropriate. We need to make decisions like this sooner, just because work on the preferences will depend on the external code. -Jeremy Parsons |
|
From: Br'fin <br...@ma...> - 2003-12-14 13:15:26
|
On Dec 14, 2003, at 4:23 AM, Aaron Davies wrote: > On Saturday, December 13, 2003, at 03:44 AM, Br'fin wrote: > >> I'm getting nearer and nearer to the point where I can create a >> CPreferencesReader/Writer_PList element. At this point I haven't >> decided on an XML parsing library. Nor have I decided on how I want >> to integrate such external libraries into the project. Do I set >> things up like libspeex and liblua for A1 or what? > > My take, as I've implied on mdev, is that third-party libraries should > be used in as close a manner to OS tradition as possible. In Unix, > that means looking for them in a configure script; in Mac OS X, that > means including frameworks in the bundle, if they're available, and > library binaries, if they're not; in Windows, that probably means > including appropriate DLL's with the binary. Yes, this will probably > make cross-platform coding a little more difficult, but it makes > things much easier for the end user. I do agree with respect to the end users. If you use dynamically linked libraries, include them in the app. Otherwise use statically linked libraries. The Application should be as standalone as possible. The only allowable exception is in the case of a self-compiled build. Like if there was a an apt-get version, that would be ok to have dynamically linked libraries since the overall mechanism of apt-get would do the requisite setup of needed libraries. On cross-platform: The only aspect of different library mechanisms that I can see being a problem is that a library with a framework prefers #include <Framework/Framework.h> and a library without prefers #include <Library.h> SDL seems to cheat by requiring the project have a header search path that navigates the SDL framework internals to locate the appropriate header files so #include "SDL.h" always works. It feels like there should be some middle ground, but I don't know where it is. Beyond that, library setup inclusion is more an aspect of the given platform's compiler instead of affecting code. On frameworks: If a library has them (ala SDL) Great! It's settled. If a library doesn't, I'm mixed on the prospect of trying to setup a framework for it. It might be a good idea, and it might be too much hassle too. (Proper way of doing it would be to send patches to said project to enable the framework to be built.) I admit to being impatient on the prospect. Though I suppose I could develop said patch, submit said patch, then include patch in a directory of AM's cvs with setup instructions of 'download libsource, apply patch, make/make framework/make install_framework' (instead of make/make install.) *ponder* I admit more trouble than I want to go to if there isn't a framework already. And then the element with including headers from frameworks that I listed above. I admit to still favoring the way I setup speex and lua for A1 (Installing versioned directories under /Library/Application Support) for handling libraries to be included on OSX without frameworks. Though fink support is a good reason to be more flexible, as was the setup for cross-compiling A1 for windows. -Jeremy Parsons |
|
From: Aaron D. <ag...@co...> - 2003-12-14 09:23:13
|
On Saturday, December 13, 2003, at 03:44 AM, Br'fin wrote:
> I'm getting nearer and nearer to the point where I can create a
> CPreferencesReader/Writer_PList element. At this point I haven't
> decided on an XML parsing library. Nor have I decided on how I want to
> integrate such external libraries into the project. Do I set things up
> like libspeex and liblua for A1 or what?
My take, as I've implied on mdev, is that third-party libraries should
be used in as close a manner to OS tradition as possible. In Unix, that
means looking for them in a configure script; in Mac OS X, that means
including frameworks in the bundle, if they're available, and library
binaries, if they're not; in Windows, that probably means including
appropriate DLL's with the binary. Yes, this will probably make
cross-platform coding a little more difficult, but it makes things much
easier for the end user.
--
__ __
/ ) / )
/--/ __. __ ________ / / __. , __o _ _
/ (_(_/|_/ (_(_) / / <_ /__/_(_/|_\/ <__</_/_)_
|
|
From: Br'fin <br...@ma...> - 2003-12-13 08:43:53
|
I've made progress. Within preferences.cpp I created a PreferencesCollection class that's local to AM. One version is referred to as runtime_preferences and is generally accessed at runtime through constant pointers to its internals. Changes to values within are done through other calls. The preferences dialog gets another fresh PreferencesCollection called dialog_preferences which is used during the dialogs, then either applied to the CPreferences repository (and a new runtime preferences object created and reinitialized) or is purely disposed. These changes are checked in and operational on the pref-development branch. I'm going to smooth out some of the changes. Also, I can finally start tweaking some of the AM-side preference objects now that they are decoupled from the external values. Most notably is existing use internal to the runtime preferences of GDSpec and FSSpec. Some related changes relating to how a CFileDesc is supposed to pass platform specific info to CPreferences and back again is also warranted. I'm a bit unhappy with all the casts around usage of get_value type preference calls. And so may need to smooth out CPreferences related external and internal APIs for that. I'm getting nearer and nearer to the point where I can create a CPreferencesReader/Writer_PList element. At this point I haven't decided on an XML parsing library. Nor have I decided on how I want to integrate such external libraries into the project. Do I set things up like libspeex and liblua for A1 or what? -Jeremy Parsons On Dec 9, 2003, at 6:05 PM, Br'fin wrote: > Still mulling over the preferences. But here's some updates and > thinking. > > Looking into MVC type details led me to the Model-View-Controller song > performed by Jack Dempsey at the 2003 Apple WWDC. > http://www.oreillynet.com/pub/wlg/3533 > > This may be instructional regardless of what I do with the preferences > GUI. I'm trying to balance the gui customization versus what general > platform-neutral support I can muster. > > My current plan is to setup a class to hold all of the runtime > preferences. A sibling of this instance will be created and either > man-handled or abandoned by the preferences GUI. If the changes are > ok'd, then all the info will be dumped into the CPreferences API and > flushed to disk. > > The current code will continue to use the in memory preference > structures, but will be given const pointers instead of flexible > ones... the values of these preferences can only be changed > functionally, direct access to the properties is read-only. This > shouldn't be so much of a hassle, and it will help root out the few > places in code that do preferences changes while the game is playing > (For instance view option changes and volume changes.) > > After AM is running off new preferences runtime, then I'll try and get > the preferences GUI functioning again. > > -Jeremy Parsons > > > > ------------------------------------------------------- > This SF.net email is sponsored by: SF.net Giveback Program. > Does SourceForge.net help you be more productive? Does it > help you create better code? SHARE THE LOVE, and help us help > YOU! Click Here: http://sourceforge.net/donate/ > _______________________________________________ > Alephmodular-devel mailing list > Ale...@li... > https://lists.sourceforge.net/lists/listinfo/alephmodular-devel > |
|
From: Br'fin <br...@ma...> - 2003-12-09 23:05:04
|
On Dec 6, 2003, at 1:28 PM, Br'fin wrote: > I'm thinking of trying to set this up in another way. > > One AM side pref_editor class. On creation, it initializes off the > runtime structures, but has its own copies. On cancel, it does nothing > but free its own memory. On OK it expresses it's values into the > preferences API, calls for a flush of the values to disk, and then > calls for reloading the API values into the runtime ones. > > *ponder* I have got to read up on Model-Controller-View details. > Something in that vein feels like what I'm doing. Though I'm unsure of > my balance... Model: Preferences. Controller: Pref Editor > (Cross-platform), View: GUI (Platform specific) > > -Jeremy Parsons Still mulling over the preferences. But here's some updates and thinking. Looking into MVC type details led me to the Model-View-Controller song performed by Jack Dempsey at the 2003 Apple WWDC. http://www.oreillynet.com/pub/wlg/3533 This may be instructional regardless of what I do with the preferences GUI. I'm trying to balance the gui customization versus what general platform-neutral support I can muster. My current plan is to setup a class to hold all of the runtime preferences. A sibling of this instance will be created and either man-handled or abandoned by the preferences GUI. If the changes are ok'd, then all the info will be dumped into the CPreferences API and flushed to disk. The current code will continue to use the in memory preference structures, but will be given const pointers instead of flexible ones... the values of these preferences can only be changed functionally, direct access to the properties is read-only. This shouldn't be so much of a hassle, and it will help root out the few places in code that do preferences changes while the game is playing (For instance view option changes and volume changes.) After AM is running off new preferences runtime, then I'll try and get the preferences GUI functioning again. -Jeremy Parsons |
|
From: Br'fin <br...@ma...> - 2003-12-09 22:53:07
|
On Dec 9, 2003, at 5:18 PM, Alexander Strange wrote: > > On Dec 9, 2003, at 7:03 AM, Br'fin wrote: >> You're probably right that more of the sound code needs to be >> encapsulated in general. Though I do believe I hit my initial goal >> which was to separate the game sound handling from the platform >> specific details. Adding both a play sound 2d(location) and an option >> for attaching effects/filters to a sound would definitely be neat. >> (play bullet sound next to ear, doppler shifted) > > CoreAudio's 3D mixer handles doppler effects already, but it still > holds for other things (making sounds echo in very large rooms). It might be appropriate to always have the filter anyways... since it lets AM specify.. play_sound n at x,y,z with echo(.3 sec) and doppler(velocity(x1,y1,z1)). And then the implementation code sets up the details for CoreAudio. >> I really don't know what's up with Quicktime and the AIFF music file >> that's not typed that way. It feels like there should be some way to >> peek and say: "You don't understand it? Well, treat this data as an >> AIFF." I don't generally see a problem with A1's music handling >> (Which CMusic_Carbon was adapted from.) And playing only AIFF files >> seems restrictive if/when we ever bring back in game music. >> >> -Jeremy Parsons > > There is a call NewMovieFromDataFork(); this might ignore filetypes. I can't remember if I tried something like that or not in my prior testing. I fought with things and tussled with things and eventually just implemented A1 style quicktime usage internally because I couldn't get any of the alternate ways to be recognized as a movie data. For instance, that call isn't quite clear on what formats of movies it expects to find. Like the AIFF reader may now be solely dependent on looking for file type/file extension and skipping any other recognizers that might be in a pure binary stream :/ -Jeremy Parsons |
|
From: Alexander S. <ast...@it...> - 2003-12-09 22:18:52
|
On Dec 9, 2003, at 7:03 AM, Br'fin wrote: > You're probably right that more of the sound code needs to be > encapsulated in general. Though I do believe I hit my initial goal > which was to separate the game sound handling from the platform > specific details. Adding both a play sound 2d(location) and an option > for attaching effects/filters to a sound would definitely be neat. > (play bullet sound next to ear, doppler shifted) CoreAudio's 3D mixer handles doppler effects already, but it still holds for other things (making sounds echo in very large rooms). > I really don't know what's up with Quicktime and the AIFF music file > that's not typed that way. It feels like there should be some way to > peek and say: "You don't understand it? Well, treat this data as an > AIFF." I don't generally see a problem with A1's music handling (Which > CMusic_Carbon was adapted from.) And playing only AIFF files seems > restrictive if/when we ever bring back in game music. > > -Jeremy Parsons There is a call NewMovieFromDataFork(); this might ignore filetypes. |
|
From: Br'fin <br...@ma...> - 2003-12-09 12:03:50
|
On Dec 9, 2003, at 1:32 AM, Alexander Strange wrote: > Because it's 1:30 AM, I'm not going to attempt paragraphs or even > sentences. > > * Upgrading from Carbon Sound to CoreAudio for the Mac OS X sound > implementation gives us much greater flexibility; enough that we could > expand the generic API > * CoreAudio supports n-channel sound, surround output (Dolby 5.1), 3D > effects (see the sample AUMixer3DTest), and other effects like reverb. > This lets us go far beyond active-panning stereo. It also lets us skip > most of our sound code, so: > * Split *all* of the sound code up into classes. This is the stuff > that is still in sound.cpp. For instance, a CSoundSoft3DSpatializer > (with the current code) and a CSoundCoreAudio3DSpatializer (using > examples from AUMixer3DTest). > * Also, get rid of the Quicktime code in CMusic_Carbon and restrict > CMusic to AIFF only, and play it through CoreAudio (see the sample > PlayAudioFile). This gets rid of the filetype problems. I don't mind seeing the sound classes updated, but I don't know how to do it personally. You're probably right that more of the sound code needs to be encapsulated in general. Though I do believe I hit my initial goal which was to separate the game sound handling from the platform specific details. Adding both a play sound 2d(location) and an option for attaching effects/filters to a sound would definitely be neat. (play bullet sound next to ear, doppler shifted) Keeping current class naming/usage would probable be closer to the software 3D spatializer being handled as the default case, with the option that specific platform classes could override it with more specific code. If we did go with a CSound3DSpatializer classes (That I'm not so sure of, but if we did.) The base class would be CSound3DSpatializer (and have the software version implemented) and the platform specific one would be like CSound3DSpatializer_CoreAudio. I really don't know what's up with Quicktime and the AIFF music file that's not typed that way. It feels like there should be some way to peek and say: "You don't understand it? Well, treat this data as an AIFF." I don't generally see a problem with A1's music handling (Which CMusic_Carbon was adapted from.) And playing only AIFF files seems restrictive if/when we ever bring back in game music. -Jeremy Parsons |
|
From: Alexander S. <ast...@it...> - 2003-12-09 06:32:45
|
Because it's 1:30 AM, I'm not going to attempt paragraphs or even sentences. * Upgrading from Carbon Sound to CoreAudio for the Mac OS X sound implementation gives us much greater flexibility; enough that we could expand the generic API * CoreAudio supports n-channel sound, surround output (Dolby 5.1), 3D effects (see the sample AUMixer3DTest), and other effects like reverb. This lets us go far beyond active-panning stereo. It also lets us skip most of our sound code, so: * Split *all* of the sound code up into classes. This is the stuff that is still in sound.cpp. For instance, a CSoundSoft3DSpatializer (with the current code) and a CSoundCoreAudio3DSpatializer (using examples from AUMixer3DTest). * Also, get rid of the Quicktime code in CMusic_Carbon and restrict CMusic to AIFF only, and play it through CoreAudio (see the sample PlayAudioFile). This gets rid of the filetype problems. |
|
From: Br'fin <br...@ma...> - 2003-12-06 18:28:51
|
Ok, so I have this nifty new preference API... now just how do I integrate it into AM? I'm thinking of leaving the way the code accesses preferences while running the same (sound flags and data structures in memory.) Though it will need to have initializaers and reinitializers that load the preferences values into runtime structures. There's also a few elements that change preferences (mostly volume and view size choices) The other place that uses preferences is the preferences UI. It currently does: Change runtime structures and if cancel is chosen it reloads from disk. On one hand I don't see anything horribly wrong with this, but it's interesting to note that neither the Java nor OSX APIs are setup to handle that kind of use. They expect the Preferences to hold final decisions, like once you hit the OK button and not the transitory choices before that actual point. I'm thinking of trying to set this up in another way. One AM side pref_editor class. On creation, it initializes off the runtime structures, but has its own copies. On cancel, it does nothing but free its own memory. On OK it expresses it's values into the preferences API, calls for a flush of the values to disk, and then calls for reloading the API values into the runtime ones. *ponder* I have got to read up on Model-Controller-View details. Something in that vein feels like what I'm doing. Though I'm unsure of my balance... Model: Preferences. Controller: Pref Editor (Cross-platform), View: GUI (Platform specific) -Jeremy Parsons |
|
From: Br'fin <br...@ma...> - 2003-12-03 21:47:04
|
On Dec 3, 2003, at 11:57 AM, Timothy Collett wrote: >> Thoughts? Comments? Perhaps I should take flag based arguments and >> split them all out into bools? >> > > I'd say no, leave them as flags, but document it very well, so that > it's easy for anyone who understands binary flags to tell what each > bit means. Makes it more concise. Well, I'm working on preferences for a few reasons. Including clarity and future proofing. Up to this point in time, I've been very careful. I've tried to do *nothing* that changes the preferences format. Now however, I'm trying to do one set of changes that can read the existing preferences (for all of the two people who've actually downloaded and run AM) and can read/write the new structure. While some things are being handled as raw data, they are mostly platform specific elements. I suppose it's debatable on the keycodes (And I should do some playing with keycodes as a char string just to flesh out encoding a string as XML.) Anyhow, if you want to manually tweak flags, would you rather them be a concise number and doing the math? Or just entering a key for the flag in the preferences file and using TRUE or FALSE as values? I'm leaning towards expanding the flags out in the preferences. > Also, just to be random, perhaps a good first test of the modularity > of AlephModular would be to take the preferences module out and make a > little preferences editor. I debated it, like a standalone preference converter. But even there, the only active preference reader is the CPreferencesReader_Wad class, which requires the unmodularized wad code. And of course, the end goal is being able to read/write a plist xml file without using MacOS X's CF API for doing so. There might also be interest in trying to use CPreferences within A1 as well. Though I'm a little unsure how to reconcile A1 FileDesc and associated calls with AM's CFileDesc and kin. -Jeremy Parsons |
|
From: Timothy C. <da...@ma...> - 2003-12-03 17:09:50
|
> Thoughts? Comments? Perhaps I should take flag based arguments and > split them all out into bools? > I'd say no, leave them as flags, but document it very well, so that it's easy for anyone who understands binary flags to tell what each bit means. Makes it more concise. Also, just to be random, perhaps a good first test of the modularity of AlephModular would be to take the preferences module out and make a little preferences editor. Timothy Collett Claiming that the Macintosh is inferior to Windows because most people use Windows, is like saying that all other restaurants serve food that is inferior to McDonalds'. --Randy B. Singer |
|
From: Br'fin <br...@ma...> - 2003-12-03 16:01:18
|
I've been working on preferences. I think I have the internals all set. I've been working on a reader module for wad style preferences. Still need to work on an interim wad style writer. And I still need to tie the use of CPreferences into AM as a whole (Right now AM still uses the existing preference setup and I tap into it just enough to initialize CPreferences and get a dump of the loaded info.) The internal hierarchy is a two level set of hash maps. One level determines domain and the other determines actual keys and values within that domain. Actual values that are stored are: bool double (Covers all number formats) string data (raw data quantity and length) The dump below uses the mechanism to convert the internally stored values for strings to place in the final file. So the strings have xml formatting applied to them (' and such similar things) and the data is encoded in base 64. Thoughts? Comments? Perhaps I should take flag based arguments and split them all out into bools? -Jeremy Parsons --- Preferences Dump --- environment: physics_file: /5wA/// gCk0xIFBoeXNpY3NFKS5idWlsZAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAA== sounds_file: /5wA// +6BlNvdW5kc2FpZmZFKXVuZHNsZAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAA== sounds_mod_date: 2898499547 map_checksum: 762432692 physics_checksum: 2898499547 map_file: /5wA// +6A01hcGRvdXJhfihFKWluZ2lsZAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAA== shapes_file: /5wA// +6BlNoYXBlc3JhfihFKWluZ2lsZAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAA== shapes_mod_date: 2898502613 graphics: gamma_level: 4 bit_depth: 16 size: 1 high_resolution: TRUE acceleration: FALSE device_spec: AAAAAQAQ/4AB4A== input: keycodes: AFsAVwBWAFgAAAACAAwADgANAAEAAwBZAFwAMQA4ADcAOQA6ADAALgAy input_device: 0 sound: flags: 59 channel_count: 4 volume: 4 pitch: 65536 player: name: Br'fin team: 0 last_time_ran: 3153293396 difficulty_level: 2 color: 0 ------------------------ |
|
From: Br'fin <br...@ma...> - 2003-11-15 07:00:27
|
I've tagged the files with a pref-development tag branch for my use while fleshing out and implementing preferences. Much jumps of how things work from directly accessing preference structures to actually querying a preferences system for appropriate information. And while it might be a nice idea to try a gradual transition, on certain levels, I'm not sure of its feasibility. For the internal preferences structure, I'm thinking of a two layer set of maps (using hashmaps where available) First level is the node name, (ala "/display" or "/environment") and the second level would consist of key/value pairs for that particular node. -Jeremy Parsons |
|
From: Br'fin <br...@ma...> - 2003-11-13 23:48:17
|
It looks like my attention has finally focused upon the way AM handles preferences. In addition to previous discussions with Woody and Mike with regards to preferences for AM and potentially A1, I've also been looking into how Java and MacOS X handle preferences internally. (I should also do some thinking on how I want to integrate other libraries into AM, most notably xmlpat, most likely for dealing with parsing the PList format, but that doesn't matter quite until halfway into dealing with the preferences anyhow) Revisions of the attached document can be found in the CVS repository at: alephModular/documentation/technical/CPreferences.txt -Jeremy Parsons Preferences Design GOAL We wish to rework the preferences mechanism of Aleph into a solid system that can be used now and into the foreseeable future. Rules: 1. Try to maintain read compatibility with older preference versions. A new version of Aleph should always be able to read a prior version of the preferences. It does not have to be able to write the format though. Corollary 1: At the very least do not ever complain that the prior version of preferences is unreadable, or worse. [ 770167 ] Old-style preferences cryptically choke A1 on startup [ https://sourceforge.net/tracker/index.php? func=detail&aid=770167&group_id=1997&atid=101997 ] HISTORY M2 Era Preferences M2 stored its preferences in a wad based binary format. Different areas of code (For instance player controls or graphic setup) had their own named section in the wad. That named structure was a direct serial dump of the preferences entity for that module. This makes the preferences both hard for a person to view/edit in the case of extra preferences with no ui yet. And makes it diffifult to arrange/manage the preferences over versions. A1 MML Preferences A1 shifted to an MML based preferences format (XML with a custom DTD). This allowed for human readable/editable preferences. But requires a certain amount of internal overhead for adding new keywords to the parser if one wishes to change/modify the preferences. It is also unclear if this is well suited for handling different preference versions over time. At the very least DESIGN What the preferences should be: * A centralized repository of application preferences Only the preferences system itself cares about the preferences file format. Other parts of the program query and ammend the preferences through APIs * Version aware The preference system should always be capable of reading prior versions of preferences. In case of reading a newer version of preferences, provide a warning. Allow user option to quit. Version in this case refers to general structure of the preferences file. For instance Version 1 would be binary. Version 2 would be MML (last version) Version 3 would be this format * Dictionary API Subsystems request and submit values based on keys (potentially nested) when speaking to the preferences. * Honors requests to flush When other aspects of the codes ask the the file to be written to disk, preferences does so. * Corruption resistant Attempt to do appropriate safe save techniques so that only when the preferences are fully written is the new data moved into the official preferences file location. ( write to temp file close temp file swap temp file and original file ) What the preferences proper should not have: * Preferences should not have application knowledge Preferences itself cannot initialize its values Application modules must do it for the values they know of Preferences itself cannot validate values Application modules must validate the values they know themselves. Potentially at the same time as initializing those values. Subsystems may wish to include their own version notes in the preferences. This way if they decide to use a new set of keys, then they can transition those keys themselves if an older version is found. Preferences can manage lists and dictionary of values, but is not responsible for their arrangement. width and height are just additional integer entries in a dictionary named screen. In addition screen means nothing at all to preferences, it is just an arbitrary name for a dictionary entry. Preference file requirements: * Human readable/editable Note: While not a requirement, the author of this document is partial to an XML plist based format. While the format is MacOS X native, we do not have to use OSX based apis to read/write it and it allows for both human editing in a text editor and allows people who choose to to edit them with tools that are plist aware. For instance the OSX tools: 'Property List Editor.app' and the command line command 'defaults' It was also designed for preferences by better people than us and is blissfully flexible without forcing the computerized readers of the preferences to have application knowledge. NOTES: Java and MacOS X both have mechanisms for distinguishing between system preferences and user preferences. For our needs, a simple user based mechanism will do. Java uses the concept of named preference nodes within either preference tree. Such that a class can get a section of preferences that is typically all of its own. A node is akin to a dictionary. MacOS X handles the app name for the file, then treats everything below as existing at one level. However it allows Dictionary as an explicit value type for deeper information. For our purposes, the Java outlook should be sufficient. The Java API uses the concept of value=get(key, defaultValue). This form of input is acceptable. Safe saving should be implicitly handled by AM's CFileDescs which already manage this. EXISTING PREFERENCES BREAKDOWN: struct graphics_preferences_data screen_mode_data size (index into array of screen sizes) (50%, 75%, 100%, full_screen) acceleration bool high_resolution bool texture_floor, texture_ceiling bool draw_every_other_line int bit_depth int gamma_level mac os device spec struct network_preferences_data { bool allow_microphone; bool game_is_untimed; int16 type; // look in network_dialogs.c for _ethernet, etc... int16 game_type; int16 difficulty_level; int16 game_options; // Penalize suicide, etc... see map.h for constants int32 time_limit; int16 kill_limit; int16 entry_point; }; struct player_preferences_data { char name[PREFERENCES_NAME_LENGTH+1]; int16 color; int16 team; uint32 last_time_ran; int16 difficulty_level; bool background_music_on; }; struct input_preferences_data { int16 input_device; int16 keycodes[NUMBER_OF_KEYS]; }; struct environment_preferences_data { FSSpec map_file; FSSpec physics_file; FSSpec shapes_file; FSSpec sounds_file; uint32 map_checksum; uint32 physics_checksum; uint32 shapes_mod_date; uint32 sounds_mod_date; uint32 patches[MAXIMUM_PATCHES_PER_ENVIRONMENT]; }; struct sound_manager_parameters { int16 channel_count; /* >=0 */ int16 volume; /* [0,NUMBER_OF_SOUND_VOLUME_LEVELS) */ uint16 flags; /* stereo, dynamic_tracking, etc. */ int32 unused_long; fixed pitch; int16 unused[9]; }; Scenarios: Load Preferences: This occurs when the application first initializes preferences once the preferences file is first set. Or whenever a request to reset preferences occurs. 1. application hands a preferences file (CFileDesc) to PreferencesFactory 2. PreferencesFactory wipes out preferences in memory (if any) 3. PreferencesFactory confirms file exists Otherwise, carry on with empty preferences. But not file anyways so we can write to it. 4. PreferencesFactory tests preferences file against a list of Preference Readers For each reader, ask reader 'Can you read this file?' If true, use that reader. If false, check next reader. a. The list of readers is generally configured at compile time. And for AM we see approximately 2 readers. WadPrefReader and PListPrefReader b. Each reader is asked to test the file. (For instance, a WadPrefReader would look to see if the file looked like a wad file and would return true if it was) c. If no readers are found, indicate an error somewhere In debug builds it is ok to assert here. In deployment builds, a diagnostic is recommended (throw an unknown pref file format error) however, this is not fatal, we just carry on with empty preferences 5. The found Preference Reader has full write access to the in memory preferences structure and reads the entire file into memory, converting chunks as needs be to fit the node-key-value structure. The reader only fills in the information it knows about Saving Preferences: This occurs whenever the application requests that the preferences be flushed. In fact, this is the only way to make sure the preferences are written out. The preferences will not auto-flush. It is recommended to request a flush whenever a group of preferences has been changed. But one could do things like change screen preferences and volume preferences mid-game, and denote that preferences should be flushed post-game. Calling for a preferences flush when no preferences setting functions has been called since preferences loading or last flush is a no-op. 1. We already know preferences file from the setup. 2. We already know the preferences writer from compilation. (The code base might have multiple writers building up over legacy time, however, only one will ever be active in a given build. Again, the first writer will be a WadPrefsWriter and the second will be a PListPrefWriter) 3. The preferences writer has full read access to the preferences structure. 4. The preferences writer walks the preferences structure and writes out all the information that it's format can encapsulate. 5. Any errors during preferences writing results in a thrown error (throw a preferences write error) and the original preferences file (if any) should remain untouched. |
|
From: Br'fin <br...@ma...> - 2003-11-04 00:52:14
|
I've updated the build environment to XCode. If you still have need of ProjectBuilder then cd into build/macosx/AlephModular.pbproj cvs update -r PB-2_0 The preferred compile environment is the Native target, but there is a PB Compatible target that I'll try and maintain within the project to make things easier for anyone still using PB. -Jeremy Parsons |
|
From: Br'fin <br...@ma...> - 2003-11-03 22:49:12
|
On Nov 2, 2003, at 2:15 PM, Br'fin wrote: > > As it is, I haven't managed to get ZeroLink to work. I get one > undefined symbol relating to the destructor of ofstream of ostream ( > __ZTv0_n12_NSoD0Ev ) I don't know what is missing or how to debug and > fix this. I'd like to fix the problem for completeness sake and to > ensure it's not causing other problems during normal deployment builds > where everything is linked normally. > I've filed a bug with Apple about this issue and ZeroLink. I was able to reproduce the error in a quick form with the code at the end of this email. Here is a URL that while it isn't the same error, does point out the trickiness of the setup. http://gcc.gnu.org/ml/gcc-bugs/1999-02n/msg00293.html They have complaints about problems with virtual dispatch from a virtual base class. A situation where the below would fail on delete. > ostream* strm; > strm = new ofstream(fileName); > delete strm; (ofstream has a virtual destructor, and has a virtual base class) Some of what Alexander was doing under 10.3 was hitting a crash on the delete of our ofstream. So everything rings fairly similar. I'll have to leave ZeroLink off for now and deal with it later once I have more information. -Jeremy Parsons // This code compiles and runs fine in Deployment mode. // However, when ZeroLink is enabled the program fails with the message: // ZeroLink: unknown symbol '__ZTv0_n12_NSoD0Ev' #include <fstream> #include <iostream> using namespace std; class MyOFStream : public ofstream { public: MyOFStream() { cout << "constructing MyOFStream" << endl; } ~MyOFStream() { cout << "destructing MyOFStream" << endl; } }; int main () { MyOFStream* s = new MyOFStream(); delete s; return 0; } |
|
From: Br'fin <br...@ma...> - 2003-11-02 19:15:13
|
I created a branch of AM referenced as xcode-transitional ( cvs update -dP -r xcode-transitional ) And I've been working on tweaking and tuning the project. Right now it is setup to compile with a native target against the 10.3 SDK and deploy with a target of 10.2. We may very well need to tweak things to compile and run on 10.1 if we find that our code doesn't. (There's solutions, it's just not nice and easy to setup automagically and get all the benefits of XCode) I've also setup a precompiled prefix header (marathon2/Support/prefix_header.pch) which definitely improves compile times for the native target. Most of the stuff that's in the header is used nearly globally as it is and should be fairly static. As it is, I haven't managed to get ZeroLink to work. I get one undefined symbol relating to the destructor of ofstream of ostream ( __ZTv0_n12_NSoD0Ev ) I don't know what is missing or how to debug and fix this. I'd like to fix the problem for completeness sake and to ensure it's not causing other problems during normal deployment builds where everything is linked normally. For now I've disabled ZeroLink. FixAndContinue is enabled, but isn't operational. For C++, Apple documentation indicates that FixAndContinue requires ZeroLink. :/ Pointers on this matter would be appreciated as I haven't been able to dig anything up. And of course I'd be much obliged if anyone wanted to double-check the XCode version of the project against their own attempts and notes. -Jeremy Parsons |
|
From: Br'fin <br...@ma...> - 2003-11-01 05:57:35
|
Ok, I've finally upgraded to OSX 10.3. This means that I also am working with XCode now. For AlephModular, I'm clearly the one in charge of updating the project file in CVS. I'm not sure who's grabbing the responsibility for AlephOne. XCode opens and updates existing ProjectBuilder project files. And apparently requires some major changes in the outlook of some things if you want to get the full benefits XCode offers. Target notes: XCode imports PB projects and puts existing targets into a Classic Target node. This continues to build programs the way PB does. * Both AM and A1 compiled with negligible problems using the Classic Target XCode also has a Native Target mode. This is what XCode requires in order to use its own vastly different build system. Maintaining extra information about built files. However, Native Targets are definitely outside the range of information that PB can handle. * Recommendation: Try to setup and maintain both Classic and Native build Targets for now, possibly as separate checkins. (Do one checkin with code in the Classic target, then follow up with an update to the Native Target to ease joining added files to the PB-2_0 branch) * I couldn't get either AM or A1 to work in Native Target with ZeroLink on. Separate problems though. AM ends up with a missing symbol relating to the virtual destructor of ostream or ofstream. But it's straightforward to turn ZeroLink off. A1 gave me a missing symbol with respect to _luaopen. Either case, more investigation needs to be done and this is low priority to me. * AM Compiles fine. With A1 I ended up having an issue where the resource file generation misses marathon2.resource and just skips it. Renaming/Copying marathon2.resource to marathon2.rsrc was horky, but fixed the problem. This could be done as an additional step in fix_cvs_resources.sh Build Styles XCode seems to lack the same semantics for Build Styles, as in PB could do PROP += <more values> and PROP = <override value>, but it seems as if XCode only does the latter. However, I've only just begun to grasp how XCode handles these issues and need to look into it more. With respect to AM, I believe I'm going to create a CVS branch for dealing with XCode issues and sort them out on the branch before I land these changes on AM's main branch. Hence limiting the initial main trunk checkins until I've smoothed it all out. -Jeremy Parsons http://alephmodular.sourceforge.net/ |
|
From: Br'fin <br...@ma...> - 2003-10-30 21:21:32
|
I was finally able to wrangle up some funds so I've managed to upgrade my system to 10.3. And I'm working on getting AlephModular set up in XCode. (I've tagged the existing PB project files as branch PB-2_0.) I seem to be able to get everything to run with one Caveat. I can't get ZeroLink to work. I can compile and link things normally, but when I run the everything with ZeroLink turned on, then the program bails with a missing symbol: __ZTv0_n12_NSoD0Ev It's an arcane, class mangled code, so I poked and prodded to see what was up. It looks to me like this symbol should be defined in the libstdc++ libraries (Verbose Zerolink tells me it is loading such a file, and nm seems to give an address for the symbol.) However, the symbol still goes unresolved. And the place where this is happening? A spot where Alexander has been getting crashes in his XCode builds... The Destructor for COFileRef, a subclass of OFile. And it seems tied to just defining the method and not anything specific in the definition (To test this I kept applying #if 0's around a section of code until the reference to the symbol went away.) Curious, but very very unclear :/ On the plus side, 10.3 does respect Navigation Services previews once again. -Jeremy Parsons |
|
From: Br'fin <br...@ma...> - 2003-10-27 21:23:31
|
I've been playing with abstracting sounds. And I'm certainly happier now with some of the more recent tweaks to things (CSound being an actual class for one instead of a cheat, for instance.) I liked my progress so much that I actually tackled music.cpp, putting in both abstracting classes of my own based on the existing file AND Quicktime Music support code from A1. And I like the result. If you change the filetype of Music to AIFF then builds with this code should play that old theme, finally. However, I have no idea how to take the mus2 file with no changes and tell Quicktime to treat it as if it were AIFF. Grrf. I really like how the split-up of logic occurred for CMusic. CMusic has all of the details of when to play, when to pause, when to release and when to fade. And the CMusic_Carbon class only had to implement basic operations on a file based audio sequence. In this case, open the file as a Movie during construction, then handle simple start/stop/change volume operations. -Jeremy Parsons |
|
From: Timothy C. <da...@ma...> - 2003-10-24 21:11:03
|
> With the release of Panther real soon now, I expect myself and those > developers who haven't already upgraded to pick up the new OS and use > new development tools. > > At this point we will be updating our compiler tools from > ProjectBuilder to XCode. Alexander can correct me, but I presume it > uses an updated version of the .pbproj's that we use. If so, the most > likely outcome is that the PBProject files will be branched with a > PB-2_0 tag on the last version of the project file that supports > ProjectBuilder and then the file will be updated for XCode along the > main trunk. > > I admit I'm still marshaling my funds so may not update immediately. > But I'd like to make sure we're all on the same page on this issue. Speaking as someone with the GM build installed and running since last Friday, when the seed went out to ADC Seed Program members, I can confirm that the .pbproj will be a new format. Also, projects compiled under XCode may not work under previous versions; however, there is an install option with XCode for cross-compiling support (only for previous OS X versions, unfortunately :-\ ). So be sure to check that under Custom when installing XCode! Timothy Collett Three things are certain: Death, taxes, and lost data. Guess which has occurred. ~haiku~ |
