alephmodular-devel Mailing List for AlephModular (Page 19)
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: Alexander S. <ast...@it...> - 2003-01-05 03:47:30
|
On Saturday, January 4, 2003, at 10:17 PM, Br'fin wrote: > > On Saturday, January 4, 2003, at 08:20 PM, Alexander Strange wrote: > >> Here's the preliminary autotools patch: >> http://astrange.ithinksw.net/alephmodular-autotools.patch.bz2 >> >> What It Does: >> Generates a PB project with the current version number, and >> InfoPlist.strings and marathon2.r. >> You can specify whether to add '.CVS' to the version with ./configure >> --with-release. >> >> What It Doesn't Do: >> Produce a Makefile that does anything useful. >> >> What You Do After Patching: >> Move the project.pbxproj to project.pbxproj.in, the InfoPlist.strings >> to InfoPlist.strings.in, and the marathon2.r to marathon2.r.in. (Why >> didn't I do it? To make the patch smaller) >> >> It also might barf on InfoPlist.strings, but the conflict stuff can >> be fixed easily. >> > Ok, got the patch essentials setup. > > I had a little trouble with autogen.sh since I didn't have libtoolize > installed. So commented out that portion of the script for the quick > run. You can replace that part of autogen.sh with 'glibtoolize'; the Developer Tools come with that. > Now I admit I am unskilled almost completely with autoconf and such. > So I can only compare with Bochs. Bochs doesn't have any Makefile.am's > (only Makefile.in's) Likewise it has a config.h.in and a configure.in, > but no configure.ac > > In a similar way, configure.in is checked in, but so is configure so > most folks just run ./configure without creating it from configure.in. configure.ac is the same thing as configure.in. > In other words, I think there must be a somewhat simpler way of > setting up autoconf. We seem to have too many files by the time we've > built configure. > > -Jeremy Parsons Comparing with another project (liboss), we have 15 more files than before we run autogen.h. It has 12 more. This is explained by the way we keep our three files in build/unix/. So, we're normal :) Also, some of these files aren't needed when we make a distribution (see http://www.gnu.org/manual/automake/html_chapter/automake_14.html#SEC89 and http://www.gnu.org/manual/automake/html_chapter/automake_15.html#SEC90). |
|
From: Br'fin <br...@ma...> - 2003-01-05 03:16:32
|
On Saturday, January 4, 2003, at 08:20 PM, Alexander Strange wrote: > Here's the preliminary autotools patch: > http://astrange.ithinksw.net/alephmodular-autotools.patch.bz2 > > What It Does: > Generates a PB project with the current version number, and > InfoPlist.strings and marathon2.r. > You can specify whether to add '.CVS' to the version with ./configure > --with-release. > > What It Doesn't Do: > Produce a Makefile that does anything useful. > > What You Do After Patching: > Move the project.pbxproj to project.pbxproj.in, the InfoPlist.strings > to InfoPlist.strings.in, and the marathon2.r to marathon2.r.in. (Why > didn't I do it? To make the patch smaller) > > It also might barf on InfoPlist.strings, but the conflict stuff can be > fixed easily. > Ok, got the patch essentials setup. I had a little trouble with autogen.sh since I didn't have libtoolize installed. So commented out that portion of the script for the quick run. Now I admit I am unskilled almost completely with autoconf and such. So I can only compare with Bochs. Bochs doesn't have any Makefile.am's (only Makefile.in's) Likewise it has a config.h.in and a configure.in, but no configure.ac In a similar way, configure.in is checked in, but so is configure so most folks just run ./configure without creating it from configure.in. In other words, I think there must be a somewhat simpler way of setting up autoconf. We seem to have too many files by the time we've built configure. -Jeremy Parsons |
|
From: Br'fin <br...@ma...> - 2003-01-05 02:19:23
|
On Saturday, January 4, 2003, at 08:47 PM, Alexander Strange wrote: > > On Saturday, January 4, 2003, at 08:20 PM, Alexander Strange wrote: >> It also might barf on InfoPlist.strings, but the conflict stuff can >> be fixed easily. > > Hmm; I just noticed that I miscapitalized InfoPlist.strings in > configure.ac. That's okay for now, since we're in HFS+, but should be > fixed. > The biggest two problems I had with the patch were really trying to get patch to work on the right set of directories (patch -p1 and running within alephModular worked) And the second was the directory 'editor code' that appeared to confuse patch for that directory. Though maybe it was working normally, go figure. Still no clue why it barfed on InfoPlist in the first place, but yeah, easy enough to fix. Still working on setting it up from your patch. And Thank you. -Jeremy Parsons |
|
From: Alexander S. <ast...@it...> - 2003-01-05 01:47:58
|
On Saturday, January 4, 2003, at 08:20 PM, Alexander Strange wrote: > It also might barf on InfoPlist.strings, but the conflict stuff can be > fixed easily. Hmm; I just noticed that I miscapitalized InfoPlist.strings in configure.ac. That's okay for now, since we're in HFS+, but should be fixed. |
|
From: Alexander S. <ast...@it...> - 2003-01-05 01:20:35
|
Here's the preliminary autotools patch: http://astrange.ithinksw.net/alephmodular-autotools.patch.bz2 What It Does: Generates a PB project with the current version number, and InfoPlist.strings and marathon2.r. You can specify whether to add '.CVS' to the version with ./configure --with-release. What It Doesn't Do: Produce a Makefile that does anything useful. What You Do After Patching: Move the project.pbxproj to project.pbxproj.in, the InfoPlist.strings to InfoPlist.strings.in, and the marathon2.r to marathon2.r.in. (Why didn't I do it? To make the patch smaller) It also might barf on InfoPlist.strings, but the conflict stuff can be fixed easily. |
|
From: Br'fin <br...@ma...> - 2003-01-04 23:56:09
|
OK, so I've been poking around, examining the code marked #ifdef OBSOLETE. Some of it looks interesting. Such as some code regarding the network microphone in the GUI, or another form of word wrapping in the terminal that doesn't use QuickDraws StyleLineBreak. Others look more fully obsolete and more obviously droppable. In my examinations I found computer_interface.cpp filled with #ifdef/#ifndef PREPROCESSING_CODE Only the MPW makefiles for export_definitions and physics_patches seem to define the variable. But nothing else did. Does anyone know what this definition is for? And does anyone mind if I consider PREPROCESSING_CODE to be obsolete and thus remove all the code associated with it? -Jeremy Parsons |
|
From: Br'fin <br...@ma...> - 2003-01-04 23:09:37
|
On Saturday, January 4, 2003, at 05:22 PM, Alexander Strange wrote: > > On Saturday, January 4, 2003, at 05:14 PM, Br'fin wrote: >> Do you still need those three files moved? README.txt->README and >> such? >> >> -Jeremy Parsons > > Not at the moment. We may want to do it at some later time. > Ok then :) -Jeremy |
|
From: Alexander S. <ast...@it...> - 2003-01-04 22:22:26
|
On Saturday, January 4, 2003, at 05:14 PM, Br'fin wrote: > Do you still need those three files moved? README.txt->README and such? > > -Jeremy Parsons Not at the moment. We may want to do it at some later time. |
|
From: Br'fin <br...@ma...> - 2003-01-04 22:13:40
|
On Saturday, January 4, 2003, at 04:38 PM, Alexander Strange wrote: >>> Automake expects files with these names (it also wants NEWS, but I'm >>> going to automatically create a blank file with that name in the >>> script that runs all these) >>> >> *eyebrow quirks* That's interesting, do you happen to know the reason >> for that? Or is that just general GNUification of a project's >> structure? >> >> I don't mind doing it, I'm just curious as to why automake needs >> these non-code files... >> >> -Jeremy Parsons > > It seems to just be GNU standards to make it easy to find everything. > Reading the manual, it looks like you can turn it off with the > 'foreign' option. > > I've almost finished; just have to create Makefile.am's for the > directories with no actual code in them, and process project.pbxproj > and InfoPList.strings. > Oh, good eye on InfoPList.strings. I had forgotten that one. Do you still need those three files moved? README.txt->README and such? -Jeremy Parsons |
|
From: Alexander S. <ast...@it...> - 2003-01-04 21:58:35
|
On Saturday, January 4, 2003, at 04:32 PM, Br'fin wrote: > > On Saturday, January 4, 2003, at 04:22 PM, Alexander Strange wrote: > >> >> On Saturday, January 4, 2003, at 04:03 PM, Br'fin wrote: >>> Do you have a list of mpw files I should be removing? >> >> Here's some other files that should be renamed (in alephModular/): >> README.txt to README >> changelog.txt to ChangeLog >> gpl.txt to COPYING >> >> Automake expects files with these names (it also wants NEWS, but I'm >> going to automatically create a blank file with that name in the >> script that runs all these) >> > *eyebrow quirks* That's interesting, do you happen to know the reason > for that? Or is that just general GNUification of a project's > structure? > > I don't mind doing it, I'm just curious as to why automake needs these > non-code files... > > -Jeremy Parsons It seems to just be GNU standards to make it easy to find everything. Reading the manual, it looks like you can turn it off with the 'foreign' option. I've almost finished; just have to create Makefile.am's for the directories with no actual code in them, and process project.pbxproj and InfoPList.strings. |
|
From: Br'fin <br...@ma...> - 2003-01-04 21:31:49
|
On Saturday, January 4, 2003, at 04:22 PM, Alexander Strange wrote: > > On Saturday, January 4, 2003, at 04:03 PM, Br'fin wrote: >> Do you have a list of mpw files I should be removing? > > Here's some other files that should be renamed (in alephModular/): > README.txt to README > changelog.txt to ChangeLog > gpl.txt to COPYING > > Automake expects files with these names (it also wants NEWS, but I'm > going to automatically create a blank file with that name in the > script that runs all these) > *eyebrow quirks* That's interesting, do you happen to know the reason for that? Or is that just general GNUification of a project's structure? I don't mind doing it, I'm just curious as to why automake needs these non-code files... -Jeremy Parsons |
|
From: Alexander S. <ast...@it...> - 2003-01-04 21:22:48
|
On Saturday, January 4, 2003, at 04:03 PM, Br'fin wrote: > Do you have a list of mpw files I should be removing? Here's some other files that should be renamed (in alephModular/): README.txt to README changelog.txt to ChangeLog gpl.txt to COPYING Automake expects files with these names (it also wants NEWS, but I'm going to automatically create a blank file with that name in the script that runs all these) |
|
From: Alexander S. <ast...@it...> - 2003-01-04 21:10:35
|
On Saturday, January 4, 2003, at 04:03 PM, Br'fin wrote: > > On Saturday, January 4, 2003, at 02:58 PM, Alexander Strange wrote: > >> Here's how I plan to do the autoconf/automake setup: >> >> * Keep everything in alephModular/builds/unix/. Have a script that >> copies them to alephModular/, then generates the configure scripts >> and etcetera. Autoconf has its own way to do this, but I don't know >> what it is. >> >> * The project.pbxproj won't be automatically generated, because you'd >> have to do a reverse-configure thingy to commit after it's edited. >> > I actually don't mind having to take diffs from project.pbxproj before > and after an edit and applying them to the project.pbxproj.in file. > (With only the .in file in the repository) Alright; it's a one-line change to configure.ac >> * Get rid of the MPW stuff or move it off somewhere else; it has name >> conflicts. > > Understood. I don't mind labeling and removing the MPW make and build > files for being Obsolete. > > Do you have a list of mpw files I should be removing? The only real offender is alephModular/marathon2/makefile, but all the *.make files can be moved out, for neatness. >> * Build the individual sections of the code as separate static >> libraries, then link them together. If someone has a list of the AM >> modules, I'll use that; otherwise, I'll figure out a temporary one >> from A0. > > For now I think it's just going to be the one directory of > alephModular/marathon2. I think we're making progress on module > definitions. But the code isn't in any shape for it currently. |
|
From: Br'fin <br...@ma...> - 2003-01-04 21:03:12
|
On Saturday, January 4, 2003, at 02:58 PM, Alexander Strange wrote: > Here's how I plan to do the autoconf/automake setup: > > * Keep everything in alephModular/builds/unix/. Have a script that > copies them to alephModular/, then generates the configure scripts and > etcetera. Autoconf has its own way to do this, but I don't know what > it is. > > * The project.pbxproj won't be automatically generated, because you'd > have to do a reverse-configure thingy to commit after it's edited. > I actually don't mind having to take diffs from project.pbxproj before and after an edit and applying them to the project.pbxproj.in file. (With only the .in file in the repository) For the other project I work on, Bochs, you have to do that same kind of effort whenever you edit the Makefile or whenever you edit the configure script. It seems fairly typical of the process. > * Get rid of the MPW stuff or move it off somewhere else; it has name > conflicts. Understood. I don't mind labeling and removing the MPW make and build files for being Obsolete. Do you have a list of mpw files I should be removing? > * Build the individual sections of the code as separate static > libraries, then link them together. If someone has a list of the AM > modules, I'll use that; otherwise, I'll figure out a temporary one > from A0. For now I think it's just going to be the one directory of alephModular/marathon2. I think we're making progress on module definitions. But the code isn't in any shape for it currently. > * The configure script won't be very useful, since this is Carbon-only > at the moment; so it'll just detect Carbon and set up everything for > that. Definitely understood. Trying to setup autoconf now is laying framework for the future. The only major changes and benefits for the current time are moving project builder compile flags to a more flexible space. Likewise setting up one place to specify version. -Jeremy Parsons |
|
From: Joe A. <av...@fm...> - 2003-01-04 20:11:50
|
Br'fin wrote: > Well, the hardest part of saying 'no code' on the Bios is in the areas > where current code links definitions to external resources. The second > hardest part involves 'How do we set up one copy of AlephModular to > handle M2 files versus Minf files versus M1 files?' Each one is a > mildly different Bios. So even if the specific map loader isn't coded > right into the Bios file, there still needs to be a way to specify > which Map Loading object to apply. Similar details surround terminal > rendering. Hmmm... that's true. I've been thinking of a Bios as a glorified physics model. But I don't think that data format code should be in the same place as gameplay definitions. We should have separate modules for data formats. I'm not going to work any more on this now because I just got back from a massive LAN party and I'm exhausted and high on caffeine and my brain just doesn't want to do anything. =\ (catching up slowly and painfully on archives) looks like Mark already mentioned this... Bios should be completely separate from everything else. You should be able (ultimately) to play an MInf+B&B map with Minf bios and, say... TI shapes (as much as possible) with enhanced textures. It would be extremely strange, but it should be possible except for incompatibilities between the formats (e.g., M1 shapes doesn't have VacBobs - but if it DID have VacBobs, by golly they would look right!). The net effect here would be while everything looks like Irae, it plays like straight Inf, on a map with B&B. This is doable now, it's just an example to show how little dependence there should be between Bios and everything else. > But you have the most thorough rundown so far. And for that I > certainly thank you. :) You're very welcome ;). This is what I'm discovering I do best. I'm nothing special as a coder, but I'm good at problem solving. I guess I get it from my father (programmer for 25 years, at Apple for 20 or so of that (employee #283 :) I forgot to include: -Map file reading and management -Shapes management (possibly divided into sprites, textures, and/or 3d models) -Sound -Prefs Joe Auricchio ~ av...@fm... Some of the above may make no sense, or may only be half thought-out. See above disclaimer about LAN party and tired. =\ |
|
From: Joe A. <av...@fm...> - 2003-01-04 20:10:22
|
Br'fin wrote: > Well, the hardest part of saying 'no code' on the Bios is in the areas > where current code links definitions to external resources. The second > hardest part involves 'How do we set up one copy of AlephModular to > handle M2 files versus Minf files versus M1 files?' Each one is a > mildly different Bios. So even if the specific map loader isn't coded > right into the Bios file, there still needs to be a way to specify > which Map Loading object to apply. Similar details surround terminal > rendering. Hmmm... that's true. I've been thinking of a Bios as a glorified physics model. But I don't think that data format code should be in the same place as gameplay definitions. We should have separate modules for data formats. I'm not going to work any more on this now because I just got back from a massive LAN party and I'm exhausted and high on caffeine and my brain just doesn't want to do anything. =\ (catching up slowly and painfully on archives) looks like Mark already mentioned this... Bios should be completely separate from everything else. You should be able (ultimately) to play an MInf+B&B map with Minf bios and, say... TI shapes (as much as possible) with enhanced textures. It would be extremely strange, but it should be possible except for incompatibilities between the formats (e.g., M1 shapes doesn't have VacBobs - but if it DID have VacBobs, by golly they would look right!). The net effect here would be while everything looks like Irae, it plays like straight Inf, on a map with B&B. This is doable now, it's just an example to show how little dependence there should be between Bios and everything else. > But you have the most thorough rundown so far. And for that I > certainly thank you. :) You're very welcome ;). This is what I'm discovering I do best. I'm nothing special as a coder, but I'm good at problem solving. I guess I get it from my father (programmer for 25 years, at Apple for 20 or so of that (employee #283 :) I forgot to include: -Map file reading and management -Shapes management (possibly divided into sprites, textures, and/or 3d models) -Sound -Prefs Joe Auricchio ~ av...@fm... Some of the above may make no sense, or may only be half thought-out. See above disclaimer about LAN party and tired. =\ |
|
From: Alexander S. <ast...@it...> - 2003-01-04 19:58:29
|
Here's how I plan to do the autoconf/automake setup: * Keep everything in alephModular/builds/unix/. Have a script that copies them to alephModular/, then generates the configure scripts and etcetera. Autoconf has its own way to do this, but I don't know what it is. * The project.pbxproj won't be automatically generated, because you'd have to do a reverse-configure thingy to commit after it's edited. * Get rid of the MPW stuff or move it off somewhere else; it has name conflicts. * Build the individual sections of the code as separate static libraries, then link them together. If someone has a list of the AM modules, I'll use that; otherwise, I'll figure out a temporary one from A0. * The configure script won't be very useful, since this is Carbon-only at the moment; so it'll just detect Carbon and set up everything for that. |
|
From: Br'fin <br...@ma...> - 2003-01-04 15:38:23
|
On Saturday, January 4, 2003, at 07:50 AM, Chris Bergmann wrote: >> We have classes we can use for encapsulation. We have the ability to >> define Class Foo and have platform specific subclass FooPlatform. > > Indeed. The danger here is that virtual functions can be slower than > you'd expect. With care and experience, you can write a completely > virtual API which performs quite well. And of course many APIs are not > performance critical. It's something that needs to be looked on a > case-by-case basis. My take on it is - where something can be decided > at compile time without loss of flexibility, that path is preferable. > I agree on the case-by-case basis. With files and basic GUI functions (for instance menus and dialogs) virtual is probably fine. However the display class that provides the glue between AM rendering and the current platform's screen could benefit from not having virtual functions. > All three methods (classes, single files, multiple files) have > difficulties, especially if the code is evolving. For this reason, i'd > like to put forward that (in effect) the entirety of the > platform-specific code is moved away from the generic code into a > separate API layer. IE. Abstraction of file classes is performed at > the file class level; not inside the save/load code itself. Same goes > for sound code; network code; etc. This may sound obvious but it's > easy to overlook and could make for an awful mess later on if not > approached thoughtfully. > Agreed on providing abstraction at a low level. That already mirrors some of how internally Bungie was handling cross platform issues. External code calls foo and internally foo is allowed to call _foo, _bar, and _baz to handle the internal implementation for the current platform. -Jeremy Parsons |
|
From: Chris B. <zzk...@uq...> - 2003-01-04 12:50:36
|
> Ultimately the desirability of a large or small save file should be up > to anyone deriving a new game work from AlephModular. The basic save > code of AlephModular will be a derivative of the existing save code > for M2 and Minf. I would be willing to entertain features that would > make alternate save code pieces and strategies easier to implement. Given Jeremy's stated goals and direction for AM, i'd have to agree that 20MB is not very reasonable for a save file. We're not targeting top-of-the-line machines here, nor do many people have 500GB drives. I'd say the norm is around 20GB, the top-of-the-line "off-the-shelf" machine would have maybe 80GB, and the previous generation top-of-the-line would have maybe 10-15GB. If we continue to support (or allows support) for OS9, that brings us to machines with 0.5GB - 2GB. With that in mind, i don't see any reason that the "save module" couldn't be replaced with something a lot more efficient. Marathon maps currently don't have a lot of dynamic elements, I honestly can't see much need for more than a few tens of KB per level (ie. save the states and positions of platforms, lights, monsters etc.) There's no need for a diff scheme here - that would probably work but it's overkill considering that we know that a large portion of the data can't change and therefore doesn't need to be saved anyway. - > We have classes we can use for encapsulation. We have the ability to > define Class Foo and have platform specific subclass FooPlatform. Indeed. The danger here is that virtual functions can be slower than you'd expect. With care and experience, you can write a completely virtual API which performs quite well. And of course many APIs are not performance critical. It's something that needs to be looked on a case-by-case basis. My take on it is - where something can be decided at compile time without loss of flexibility, that path is preferable. This generally means one of two approaches: 1. A single .cpp file with #ifdefs surrounding certain key code elements. This is nice where a large portion of the code is reusable, and there are only slight differences between the platforms. It saves rewriting/maintaining separate versions of the larger body of code. The downside here is tracking the #ifdefs; ie. when porting to a new platform, you have to find all the bits of code you need to rewrite. I usually solve this by putting in a compiler error/warning directive (as suitable) whenever one of these codeblocks detects an unsupported platform. 2. Seperated .cpp files, one for each platform. This can be a real pain to maintain, if you're not planning carefully. Ideally they share a common public header but each implement it differently internally. The downside is that any change to the header may break the compilation of all the platforms. Generally people only take the care to fix their own platform, without paying much attention to what they've broken on another platform (with good reason- often they can't test their changes as they don't have said platform available.) YMMV. All three methods (classes, single files, multiple files) have difficulties, especially if the code is evolving. For this reason, i'd like to put forward that (in effect) the entirety of the platform-specific code is moved away from the generic code into a separate API layer. IE. Abstraction of file classes is performed at the file class level; not inside the save/load code itself. Same goes for sound code; network code; etc. This may sound obvious but it's easy to overlook and could make for an awful mess later on if not approached thoughtfully. chris |
|
From: Br'fin <br...@ma...> - 2003-01-04 08:25:13
|
On Friday, January 3, 2003, at 11:08 PM, Aaron Davies wrote: > I don't really see a problem here. 20 MB is almost irrelevant these > days--hell, I just saw a 500 GB drive going for $1000 the other day. > In a year's time, it'll be $400. Anyway, it would only be that large > once the player's visited all levels (i.e. at the end of a linear > scenario). Intelligently writing the save-file code will avoid having > to slurp up and kick out the entire file every save/load. I don't know > if that's possible with wad files, but we don't really have to stay > with wad. Maybe the save file could actually be an archive (tar/zip) > of separate maps plus a file of current user data? Whether a "diff" on > the canonical map is any use would depend on how long it would take to > "apply" it when reloading the level. *chuckle* You've obviously not seen my Hard Drive. I'm running off a 20GB hard Drive that tends to have 600 mb free at most after a reboot and on really bad days will end up having memory usage eat up all available free space. Given the way I usually use machines, I probably won't be upgrading again for a few years and probably won't be buying any new hard drives in the interim aside from something like an iPod :) Ultimately the desirability of a large or small save file should be up to anyone deriving a new game work from AlephModular. The basic save code of AlephModular will be a derivative of the existing save code for M2 and Minf. I would be willing to entertain features that would make alternate save code pieces and strategies easier to implement. -Jeremy Parsons |
|
From: Br'fin <br...@ma...> - 2003-01-04 08:13:02
|
ixNay on extensions like this.
What Bungie did with including .c files(now .cpp files) when dealing
with Cross-platform support struck me as wrong when I realized this.
AlephOne managed to take these areas and mangle them further.
We have classes we can use for encapsulation. We have the ability to
define Class Foo and have platform specific subclass FooPlatform.
We have enough platform specific code that it might not fit within a
single file so it could very well be
guiModular/
sdl/
sdlImplementationDisplay.h
sdlImplementationDisplay.cpp
...
macosx/
macosxImplementationDisplay.h
macosxImplementationDisplay.cpp
...
display.h
display.cpp
Now I admit that I have a better idea currently of what's wrong than
what's right.
So I'm open to suggestions. But this is the wrong tangent.
-Jeremy Parsons
On Friday, January 3, 2003, at 02:33 PM, Michael Adams wrote:
> Extentions that I have seen used include ".inc"
> (include) and ".inl" (inline). I have yet to see a
> definate standard.
>
> Michael D. Adams
> mdm...@ya...
>
> --- "Woody Zenfell, III" <woo...@sb...>
> wrote:
>> I'm finally getting around to posting some thoughts
>> I had sent to Br'fin
>> before the AM list was in place. This is one such
>> message.
>>
>> The following is a message I sent to the M-Dev list
>> about a year ago,
>> but it seems relevant now again. There's nothing
>> terribly exciting or
>> clever here, but it may spark some discussion.
>>
>> Note that with a movement toward classes and
>> objects, a lot of this
>> material may need to be rethought, FWIW.
>>
>> Woody
>>
>> ----- Original Message -----
>> From: "Woody Zenfell" <woo...@ho...>
>> Sent: Thursday, January 17, 2002 7:55 PM
>>
>>> Personally, I'd like to see some standardization
>> on the handling of
>>> chunks
>>> of code that differ for different platforms.
>> There are currently many,
>>> MANY
>>> ways this is done, which gets to be awfully
>> confusing.
>>>
>>> In my code, <basefilename>.cpp contains code for
>> both (all) platforms.
>>> <basefilename>_macintosh.cpp has code for the Mac
>> OS version;
>>> <basefilename>_sdl.cpp has code for the SDL
>> version. I even tried to
>>> name
>>> ones that only apply to the SDL version
>> <whatever>_sdl.cpp to maintain
>>> this
>>> convention. A .cpp file never #includes any other
>> .cpp file, so a
>>> project
>>> file will incorporate the
>> <basename>_<platform>.cpp AND <basename>.cpp
>>> (if
>>> it exists).
>>>
>>> One (non-trivial) drawback to my approach is that
>> elements that used to
>>> be
>>> file-private can no longer be (if they need to be
>> seen by both shared
>>> code
>>> and platform-specific code). In those cases, I
>> made
>>> <basename>_private.h
>>> that's intended to be #included only by one or two
>> files. <basename>.h
>>> continues to provide "externally visible" elements
>> to the rest of the
>>> code
>>> base. This is still a sort of global namespace
>> pollution, and if the
>>> project got big enough, we could start to have
>> linkage problems as names
>>> conflict, but so far it seems to be OK.
>>>
>>> In some cases, there's like <basefilename>.cpp,
>> that #includes
>>> <basefilename>_<platform>.cpp depending on
>> preprocessor conditionals.
>>> This
>>> lets shared code and platform-specific code keep
>> their private elements
>>> private ("static"). But when managing the project
>> files, it's somewhat
>>> confusing - if you compile both <basename>.cpp and
>>> <basename>_<myplatform>.cpp, you have problems.
>>>
>>> In other cases, there's like
>> <basename>_<platform>.cpp, which #includes
>>> <basename>.cpp or <basename>_shared.cpp. I
>> actually like this better
>>> than
>>> the above - it feels better having the project
>> files choose the branch
>>> rather than the preprocessor. This, like the
>> previous one, preserves
>>> "privacy", but has the same multiple-definition
>> problem. Unfortunately,
>>> it's more likely to produce errors at link-time
>> than compile-time,
>>> compared
>>> to the above. (Earlier errors are better.
>> <basename>.cpp is more
>>> likely to
>>> compile on its own than <basename>_<platform>.cpp
>> would be, I think.)
>>>
>>> In general, I'd prefer to see .cpp files that are
>> #included by other
>>> .cpp
>>> files have a different extension. I'm sure
>> there's one in standard use
>>> out
>>> there for this purpose (something like ".ipp"?).
>> It would make it
>>> clearer
>>> which one a project file should reference
>> directly, and which ones will
>>> get
>>> rolled in some other way.
>>>
>>> In still OTHER cases, there's like <basename>.cpp,
>> which gives
>>> Mac-specific
>>> routines, and <basename>_sdl.cpp, which gives
>> SDL-specific routines. I
>>> don't like this, although (given the CVS and
>> project file hassles
>>> involved
>>> with renaming something) I understand how the
>> practice developed.
>>> Still, if
>>> someone's going to be massively reworking this
>> stuff, I'd prefer to see
>>> this
>>> cleaned up while the opportunity is at hand.
>>>
>>> I'm sure there are still a couple MORE conventions
>> used to combat this
>>> problem (base class/derived classes? preprocessor
>> conditionalization
>>> within
>>> a single source file?), but those are all I
>> remember off the top of my
>>> head,
>>> and I think they're sufficient to illustrate the
>> problem.
>>>
>>> I guess I'd prefer to see something that allows
>> separate compilation but
>>> manages namespaces explicitly, like encapsulation
>> in classes or use of
>>> the
>>> C++ namespace construct. But, it could be a major
>> pain to
>>> retroactively fit
>>> this onto existing code. As a second choice, I
>> might like using
>>> <basename>_<platform>.cpp, which #includes
>>> <basename>.<included-source-extension> or
>>> <basename>_shared.<included-source-extension>. As
>> a third choice, I
>>> like
>>> the other way around (basename.cpp #includes
>>> basename_platform.included-source-extension).
>> Note that perhaps oddly,
>>> I'm
>>> not too keen on my own scheme! Oh well, it made
>> sense at the time, and
>>> I do
>>> like it better than the #include mechanisms if
>> included files have a
>>> .cpp
>>> extension (which, note, they did when I used my
>> scheme).
>>>
>>> Another option (not currently used) would be to
>> have subdirectories of
>>> each
>>> major source directory for Mac, SDL, etc. Shared
>> code would live in the
>>> major source directory; platform-specific code
>> would live in one of the
>>> subdirectories. It might still be nice for the
>> source files to have
>>> _sdl or
>>> _macintosh after them, though, to make it doubly
>> clear what file you're
>>> working with in your editor/build system. I don't
>> know whether the
>>> subdirectories would be worth it, but it's
>> something to consider.
>>>
>>> Oh sure, heck, while we're airing out such things,
>> could I also say it
>>> annoys me that so many headers cover so many
>> source-files? I mean,
>>> MSVC is
>>> smart enough to not recompile source files if no
>> "relevant" changes were
>>> made in the header, but most build systems aren't,
>> so changing a source
>>> file
>>> and an entry in its related header file forces you
>> to rebuild like half
>>> the
>>> project. I mean, yeah yeah, interfaces are
>> supposed to be stable, etc.
>>
> === message truncated ===
>
>
> __________________________________________________
> Do you Yahoo!?
> Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
> http://mailplus.yahoo.com
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Alephmodular-devel mailing list
> Ale...@li...
> https://lists.sourceforge.net/lists/listinfo/alephmodular-devel
>
|
|
From: Aaron D. <ag...@co...> - 2003-01-04 04:08:03
|
On Friday, January 3, 2003, at 08:56 AM, Br'fin wrote:
>
> On Friday, January 3, 2003, at 04:29 AM, Aaron Davies wrote:
>
>> On Thursday, January 2, 2003, at 10:16 PM, Br'fin wrote:
>>
>>> Where does unifying saving/restoring game information lay?
>>
>> Speaking of that, one feature I've been interested in for a long time
>> is PID-style persistent level data--a save file containing the maps
>> for *all* levels completed so far, so that you can re-enter a level
>> and have your previous work there remain. This would allow for much
>> easier design of non-linear scenarios, as well as reducing the
>> redundancy in certain overly linear ones
>> (*cough*cough*TI*cough*cough*). It's also a pre-requisite for porting
>> PID to A1/AM, a project I expect to materialize any day now, now that
>> the PID shapes file has been cracked.
>>
>> So anyway, if this sort of progressive save file is going to be a
>> possibility later, that should be kept in mind now.
>>
>
> Well, given that the map file for M2 is 19.5 megabytes, I don't think
> a PID-style of save all the maps is approachable. Unless your map,
> externally, is actually handled like the original PID map. (a 2D grid
> of values+extra lists of information is so much smaller than a full
> map of lines, points, and polygons)
I don't really see a problem here. 20 MB is almost irrelevant these
days--hell, I just saw a 500 GB drive going for $1000 the other day. In
a year's time, it'll be $400. Anyway, it would only be that large once
the player's visited all levels (i.e. at the end of a linear scenario).
Intelligently writing the save-file code will avoid having to slurp up
and kick out the entire file every save/load. I don't know if that's
possible with wad files, but we don't really have to stay with wad.
Maybe the save file could actually be an archive (tar/zip) of separate
maps plus a file of current user data? Whether a "diff" on the
canonical map is any use would depend on how long it would take to
"apply" it when reloading the level.
--
__ __
/ ) / )
/--/ __. __ ________ / / __. , __o _ _
/ (_(_/|_/ (_(_) / / <_ /__/_(_/|_\/ <__</_/_)_
|
|
From: Alexander S. <fe...@it...> - 2003-01-03 19:40:59
|
On Friday, January 3, 2003, at 02:27 PM, Michael Adams wrote: > You may be interested to look at libtool. It is a > cross platform wrapper around dynamically loaded > stuff. > > http://sources.redhat.com/autobook/autobook/autobook_toc.html > > (That link is also a good book for anyone wanting to > learn automake and autoconf.) > > However, dynamic stuff is always a pain to write > correctly, and I'm not to sure of libtool's support > for Classic, OSX or Win32. Some dynamic stuff could > be turned into scripts in some scripting language and > that would avoid the incompatabilities of shared > libraries, but also has it's own problems. > > Just a few thoughts, > Michael D. Adams > mdm...@ya... Yes, autoconf/automake already wrap around libtool. And libltdl uses dlopen(), so we'd still end up doing it :) libtool can link shared libraries on OS X, but can't use the OSX module-loading API. So you still need dlcompat. Scripting is much more useful than modules if you make a scenario, because you don't need to compile anything. -- Alexander Strange "Is God willing to prevent evil, but not able? Then he is not omnipotent. Is he able, but not willing? Then he is malevolent. Is he both able and willing? Then whence cometh evil? Is he neither able nor willing? When why call him god?" -- anonymous, Boethius' Consolation of Philosophy |
|
From: Michael A. <mdm...@ya...> - 2003-01-03 19:33:56
|
Extentions that I have seen used include ".inc"
(include) and ".inl" (inline). I have yet to see a
definate standard.
Michael D. Adams
mdm...@ya...
--- "Woody Zenfell, III" <woo...@sb...>
wrote:
> I'm finally getting around to posting some thoughts
> I had sent to Br'fin
> before the AM list was in place. This is one such
> message.
>
> The following is a message I sent to the M-Dev list
> about a year ago,
> but it seems relevant now again. There's nothing
> terribly exciting or
> clever here, but it may spark some discussion.
>
> Note that with a movement toward classes and
> objects, a lot of this
> material may need to be rethought, FWIW.
>
> Woody
>
> ----- Original Message -----
> From: "Woody Zenfell" <woo...@ho...>
> Sent: Thursday, January 17, 2002 7:55 PM
>
> > Personally, I'd like to see some standardization
> on the handling of
> > chunks
> > of code that differ for different platforms.
> There are currently many,
> > MANY
> > ways this is done, which gets to be awfully
> confusing.
> >
> > In my code, <basefilename>.cpp contains code for
> both (all) platforms.
> > <basefilename>_macintosh.cpp has code for the Mac
> OS version;
> > <basefilename>_sdl.cpp has code for the SDL
> version. I even tried to
> > name
> > ones that only apply to the SDL version
> <whatever>_sdl.cpp to maintain
> > this
> > convention. A .cpp file never #includes any other
> .cpp file, so a
> > project
> > file will incorporate the
> <basename>_<platform>.cpp AND <basename>.cpp
> > (if
> > it exists).
> >
> > One (non-trivial) drawback to my approach is that
> elements that used to
> > be
> > file-private can no longer be (if they need to be
> seen by both shared
> > code
> > and platform-specific code). In those cases, I
> made
> > <basename>_private.h
> > that's intended to be #included only by one or two
> files. <basename>.h
> > continues to provide "externally visible" elements
> to the rest of the
> > code
> > base. This is still a sort of global namespace
> pollution, and if the
> > project got big enough, we could start to have
> linkage problems as names
> > conflict, but so far it seems to be OK.
> >
> > In some cases, there's like <basefilename>.cpp,
> that #includes
> > <basefilename>_<platform>.cpp depending on
> preprocessor conditionals.
> > This
> > lets shared code and platform-specific code keep
> their private elements
> > private ("static"). But when managing the project
> files, it's somewhat
> > confusing - if you compile both <basename>.cpp and
> > <basename>_<myplatform>.cpp, you have problems.
> >
> > In other cases, there's like
> <basename>_<platform>.cpp, which #includes
> > <basename>.cpp or <basename>_shared.cpp. I
> actually like this better
> > than
> > the above - it feels better having the project
> files choose the branch
> > rather than the preprocessor. This, like the
> previous one, preserves
> > "privacy", but has the same multiple-definition
> problem. Unfortunately,
> > it's more likely to produce errors at link-time
> than compile-time,
> > compared
> > to the above. (Earlier errors are better.
> <basename>.cpp is more
> > likely to
> > compile on its own than <basename>_<platform>.cpp
> would be, I think.)
> >
> > In general, I'd prefer to see .cpp files that are
> #included by other
> > .cpp
> > files have a different extension. I'm sure
> there's one in standard use
> > out
> > there for this purpose (something like ".ipp"?).
> It would make it
> > clearer
> > which one a project file should reference
> directly, and which ones will
> > get
> > rolled in some other way.
> >
> > In still OTHER cases, there's like <basename>.cpp,
> which gives
> > Mac-specific
> > routines, and <basename>_sdl.cpp, which gives
> SDL-specific routines. I
> > don't like this, although (given the CVS and
> project file hassles
> > involved
> > with renaming something) I understand how the
> practice developed.
> > Still, if
> > someone's going to be massively reworking this
> stuff, I'd prefer to see
> > this
> > cleaned up while the opportunity is at hand.
> >
> > I'm sure there are still a couple MORE conventions
> used to combat this
> > problem (base class/derived classes? preprocessor
> conditionalization
> > within
> > a single source file?), but those are all I
> remember off the top of my
> > head,
> > and I think they're sufficient to illustrate the
> problem.
> >
> > I guess I'd prefer to see something that allows
> separate compilation but
> > manages namespaces explicitly, like encapsulation
> in classes or use of
> > the
> > C++ namespace construct. But, it could be a major
> pain to
> > retroactively fit
> > this onto existing code. As a second choice, I
> might like using
> > <basename>_<platform>.cpp, which #includes
> > <basename>.<included-source-extension> or
> > <basename>_shared.<included-source-extension>. As
> a third choice, I
> > like
> > the other way around (basename.cpp #includes
> > basename_platform.included-source-extension).
> Note that perhaps oddly,
> > I'm
> > not too keen on my own scheme! Oh well, it made
> sense at the time, and
> > I do
> > like it better than the #include mechanisms if
> included files have a
> > .cpp
> > extension (which, note, they did when I used my
> scheme).
> >
> > Another option (not currently used) would be to
> have subdirectories of
> > each
> > major source directory for Mac, SDL, etc. Shared
> code would live in the
> > major source directory; platform-specific code
> would live in one of the
> > subdirectories. It might still be nice for the
> source files to have
> > _sdl or
> > _macintosh after them, though, to make it doubly
> clear what file you're
> > working with in your editor/build system. I don't
> know whether the
> > subdirectories would be worth it, but it's
> something to consider.
> >
> > Oh sure, heck, while we're airing out such things,
> could I also say it
> > annoys me that so many headers cover so many
> source-files? I mean,
> > MSVC is
> > smart enough to not recompile source files if no
> "relevant" changes were
> > made in the header, but most build systems aren't,
> so changing a source
> > file
> > and an entry in its related header file forces you
> to rebuild like half
> > the
> > project. I mean, yeah yeah, interfaces are
> supposed to be stable, etc.
>
=== message truncated ===
__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
|
|
From: Michael A. <mdm...@ya...> - 2003-01-03 19:27:32
|
You may be interested to look at libtool. It is a cross platform wrapper around dynamically loaded stuff. http://sources.redhat.com/autobook/autobook/autobook_toc.html (That link is also a good book for anyone wanting to learn automake and autoconf.) However, dynamic stuff is always a pain to write correctly, and I'm not to sure of libtool's support for Classic, OSX or Win32. Some dynamic stuff could be turned into scripts in some scripting language and that would avoid the incompatabilities of shared libraries, but also has it's own problems. Just a few thoughts, Michael D. Adams mdm...@ya... --- Alexander Strange <ast...@it...> wrote: > Does the modular concept just extend to code design, > or does it > actually mean that the various parts will be turned > into swappable, > dynamically loaded plugins? > > If it does, I would recommend using the > dlopen()/dlsym/etc APIs. > They're available on almost all Unixes, and there's > an emulator library > for OS X at > http://www.opendarwin.org/projects/dlcompat/. There > might > be something like that on Windows, too; I have no > idea how plugins are > handled in Classic MacOS. > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Alephmodular-devel mailing list > Ale...@li... > https://lists.sourceforge.net/lists/listinfo/alephmodular-devel __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com |
