alephmodular-devel — AlephModular Developers Mailing List

Re: [Alephmodular-devel] Saving multiple levels (was: General Status Overview)

[Woody Z. I. <woo...@sb...>]

What about saving sort of a 'diff' for each level?  Err, I mean, each 
object stored in the file would be whole, but only those objects whose 
states differ from the state at load-the-level-from-the-Map-file time 
would be saved.  I mean, wouldn't that let you store the game-state 
exactly, but much more efficiently?  And of course you could always 
store the stuff compressed with some kind of general-purpose lossless 
compressor to save a little more space.

I mean, even if save files still ended up being 5-10MB apiece, I think 
users today would be willing to pay that much disk space.  (Especially 
if things are set up so the user can return to previous levels - in that 
case there's probably less need to keep lots of saved-game files per 
player per scenario.)  It shouldn't take terribly long to save etc. 
since most levels will probably not have changed since the last save and 
their data could just be copied.

Feels like it would be a problem to keep multiple levels in memory at 
once (if the user has changed more than one level but hasn't yet saved), 
but really the levels the user's not currently playing could be held in 
memory in this 'diff' format (prepared when the user leaves the level 
before the next one loads), so the data could not be confused with the 
current level's "live" data.  Then the in-memory diff(s) could just be 
dumped out to file when the player next saves.

Well anyway I guess the point is, this sort of thing is a possibility 
later, but I'm not sure that it requires any special preparation at the 
moment.  (Aside perhaps from being able to mark objects that have 
changed since level-loading, so it's easier to write the 'diff' output.  
That marking could be related to the copy-on-write object stuff... see 
another e-mail not yet sent to the list for that idea.  Heh heh.)  
Naturally modularization should (will) make it easier to swap in 
different saved-game handlers at some point, so sticking in the new code 
to save and load the "all the levels" format should eventually be easier 
than it would be today in A1.

The "approximate saving" scheme Br'fin talked about strikes me as a 
compromise that e.g. a game system might need to make, to fit its saved 
data into a fairly small space for e.g. a cartridge SRAM or a little 
memory card, but currently A1 primarily runs on machines with hard 
disks, which makes conserving space a much lesser concern.  Shrug.

Woody


On Friday, January 3, 2003, at 08:56  AM, Br'fin wrote:

> 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)
>
> Something I would like to see develop is the ability to swap out how a 
> save game is done. Notice how many games focus less on 'save 
> everything' and work with 'save my current stats, where I am, and what 
> I have earned'
>
> For something like PID it might be appropriate to save my current 
> level. Then for all other levels note how cleared out a given section 
> is... 'left portion of map 80% clear (10 monsters left), room of death 
> (0% clear, 100 monsters left)' and just randomize the remaining 
> monsters within the cleared section if you revisit that level.

[Alephmodular-devel] Re: [M-dev]Sloping floors and ceilings

[Joe A. <av...@fm...>]

On Friday, January 3, 2003, at 09:34  AM, Quartz wrote:
> hey- putting map creation options aside for the moment, how would the
> physics engine handle this? is that already sorted out?

I suppose the simplest thing would be to have the game engine treat it 
like a lot of small, discrete, flat polys - or actually a poly with a 
floor/ceiling divided into a lot of small, discrete, flat segments. 
This would probably require that any time we make reference to a poly's 
floor or ceiling height, we actually call a function to get it, and the 
function either returns the poly's floor or ceiling height (if it's a 
normal poly) or figures out what the floor/ceiling is right here based 
on the location in the poly (which would have to be passed to the 
function). This will require major code renovation. However, 
AlephModular could handle it pretty easily I suppose, since we're 
renovating the code _anyway_... ;)

This is a bit of a kludgey method, but I think it would be far, far 
easier than actually having the engine deal with real sloping floors 
and ceilings...

My 2cents on the adjacent-polys-vs-Dietrich's-suggestions issue:
I'm a map maker. I want to make a ramp on the floor. The easiest, most 
straightforward method from *my* perspective would probably be facing 
looking either low-to-high or high-to-low (which one isn't important), 
min height, and max height. This allows the most flexibility without me 
doing lots of geometry. (I'm assuming there is no editor for this yet 
and I have to create the ramp information by hand).

Also, this might be painfully obvious, but ramps that don't lie flush 
with surrounding polys (the sides of the ramp are visible) should use 
the standard primary/secondary texture used for every other type of 
opening, and treated like a normal opening as much as possible. I mean, 
the engine should just treat it like a normal poly with a different 
floor/ceiling height.

Joe Auricchio ~ av...@fm...

Re: [Alephmodular-devel] General status overview

[Mark L. <hav...@ma...>]

On Friday, January 3, 2003, at 08:56  AM, Br'fin wrote:

> 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)

90% of the map file is terminal and chapter screen PICTs, the geometry 
is only a few hundred K per map. Adding persistence would increase this 
to several MB per save, but modern games broke this taboo long ago (the 
worst offender is probably Deus Ex, whose saves can hit 20MB).

--Mark

"Verbing wierds language."

[Alephmodular-devel] Comments on Obsolete code

[Br'fin <br...@ma...>]

I just remembered one of the other things I meant to do for 0.3. 
Removing the obsolete code.

I already snipped out a code block in map_constructors.cpp that was 
#ifdef'd as NEW_AND_BROKEN. However it occurred to me that while some 
blocks are just going to be obsolete. Other blocks are going to be 
obsolete but useful. For instance an obsolete block that specifically 
refers to M1.

I know all these things will remain in CVS. However, who's going to 
know these blocks are there to look for at the time when we do start 
adding M1 support? Leave them in the code? Remove them anyways but add 
an extra note in the CVS log?

And as should be expected, I do have my eyes on removing the Valkyrie 
support code as part of obsolete code removal.

-Jeremy Parsons

Re: [Alephmodular-devel] General status overview

[Br'fin <br...@ma...>]

On Thursday, January 2, 2003, at 11:37  PM, Alexander Strange wrote:

>
> On Thursday, January 2, 2003, at 11:16  PM, Br'fin wrote:
>> Now does anyone have experience or links on setting up the necessary 
>> files for autoconf? Especially since I don't currently have a 
>> makefile proper.
>
> Yes, I know how to set up autoconf/automake (automake is a way to 
> easily create Makefiles).

I'd be delighted if you would set that up and send me the necessary 
files.

>> Where does unifying saving/restoring game information lay?
>> Where does the various information and strings currently stored in 
>> marathon2.rsrc go?
> Inside the source code, and modifiable (MML, for Aleph One 
> compatibility?).
>

I don't currently have a stance on MML. Likewise I don't know about a 
target for AO compatibility. Maybe once AO decides which versions of 
itself it is compatible with. ;)

My current view may be more laissez-faire. Someone can work on an AO 
Bio, but it currently lacks importance to me.


Oh, congratulations are in order for Joe for taking the idea of 
skinning network players and sending it back to the marathon-devl list. 
:)

-Jeremy Parsons

Re: [Alephmodular-devel] General status overview

[Br'fin <br...@ma...>]

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)

Something I would like to see develop is the ability to swap out how a 
save game is done. Notice how many games focus less on 'save 
everything' and work with 'save my current stats, where I am, and what 
I have earned'

For something like PID it might be appropriate to save my current 
level. Then for all other levels note how cleared out a given section 
is... 'left portion of map 80% clear (10 monsters left), room of death 
(0% clear, 100 monsters left)' and just randomize the remaining 
monsters within the cleared section if you revisit that level.

-Jeremy Parsons

[Alephmodular-devel] Organizing files wrt multiple platforms

[Woody Z. I. <woo...@sb...>]

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. 
> but
> I still think the headers could be more "granular" rather than 
> "aggregate".
> I have to confess to creating a couple new headers with more limited 
> scope,
> handling interfaces between subsystems, so that intimate changes to 
> those
> would not cause all the source files that have just casual dealings 
> with the
> subsystems to have to be rebuilt.  This interface-identification should
> probably be done a little more... rigorously, though.
>
> As for removing dead code, maybe there should be a general policy that 
> if
> you come across some, are not the one who replaced the dead code with 
> newer
> code, and verify that you think the newer code completely replaces the 
> old
> code, you're authorized to delete the dead code.  I mean, it will live 
> on in
> the CVS history anyway.  And, it makes sure that changes like this get
> double-checked (by two different people - the author and the reviewer) 
> for
> extra robustness.  Having dead code sitting around does mess up 
> grep-style
> mass searches and the like, so it would be nice to see it get threshed 
> out
> from time to time.
>
> Comments appreciated...
>
> Woody
>
> PS If "thresh" it not the stage of grain-harvesting that separates the 
> germ
> from the chaff, s/thresh/whatever that verb is/.

PPS 'wrt' (as in the subject line) is 'with respect to', in case not all 
mathematics curricula use that abbreviation.

Re: [Alephmodular-devel] General status overview

[Aaron D. <ag...@co...>]

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.
-- 
     __                        __
    /  )                      /  )
   /--/ __.  __  ________    /  / __. , __o  _  _
  /  (_(_/|_/ (_(_) / / <_  /__/_(_/|_\/ <__</_/_)_

Re: [Alephmodular-devel] Friendlier Preferences

[Woody Z. I. <woo...@sb...>]

On Friday, January 3, 2003, at 12:47  AM, Alexander Strange wrote:

> On Friday, January 3, 2003, at 02:21  AM, Mark Levin wrote:
>> (On a related note, A1's preferences are hideously complex and 
>> overdesigned... Does the user really need to be able to configure the 
>> type of texture filtering used?)
>
> Definitely. I would prefer a sliding bar going between "Conserve VRAM" 
> and "Increase Prettiness", or something of that nature.

I'm surprised that a bunch of Mac users don't demand better.

If we're trying to build preferences that are user-friendly, there 
should be either no option (the game profiles its own behavior and 
determines automatically what settings give the best quality while 
maintaining performance), or a slider to trade off between "Image 
Quality" and "Frame Rate" (or "Speed").  I suspect Unreal Tournament 
intended to do something along these lines with its "Target Frame-Rate" 
slider - I assume its intention was to maximize quality while 
maintaining the user-specified frame-rate.  Shrug, my Windows machine is 
a Celeron-400 with 128 MB RAM and a 16 MB RIVA TNT, so it's sort of 
barely able to run UT at all - I haven't been able to detect any effect 
that slider may have.

Note that it may be nice to have a 'standard preferences' setting (like 
the above) and an 'expert preferences' option (giving detailed control 
over everything), so people who really like to fiddle with such things 
can still do so.

But anyway this is like a tangent of a tangent by now, and surely won't 
become important in AM for quite some time...

Woody

Re: [Alephmodular-devel] General status overview

[Alexander S. <ast...@it...>]

On Friday, January 3, 2003, at 02:21  AM, Mark Levin wrote:
> (On a related note, A1's preferences are hideously complex and 
> overdesigned... Does the user really need to be able to configure the 
> type of texture filtering used?)

Definitely. I would prefer a sliding bar going between "Conserve VRAM" 
and "Increase Prettiness", or something of that nature.

[Alephmodular-devel] New name for "Bios"

[Kevin W. <lu...@ea...>]

Just a thought of mine, guys: "Flavors", 'steada "Bios".  It works if 
Bios are basically the modules that determine whether Aleph Modular 
will run in Marathon, Marathon 2, or Marathon Infinity mode.  If that's 
not it, enlightenment?  Oh - that reminds me.  How about "Modes"?

By the way, I'm sorta planning on being a hanger-on-er guy, as a person 
who doesn't know any but the most basic C code (from the book "The C 
Programming Language"; I've gotten almost to the end of Chapter 1 so 
far), trying to contribute an outsider's (non-coder's) perspective on 
the whole process.  Perhaps also some testing, if'n ya needs it.

BNAR,
-Lunair

Re: [Alephmodular-devel] General status overview

[Mark L. <hav...@ma...>]

> Mallocs are apt to fall by the way side in the course of shifting 
> everything to classes. If there is anything memory wise to worry about 
> at the moment it would be the mix of Mac Memory handling (NewPtr, 
> NewHandle), and the more neutral C/C++ style memories (malloc, new).

Handles are (should be) only be used by the MacOS/Carbon APIs, and so 
should eventually move to within the Mac-specific code blocks.

> GUI seems obvious. Though certain elements are far more obvious than 
> others.
>
> 'Bios' is definitely there, but it's much harder to determine where 
> the barrier is between Bios and other functions. For instance, monster 
> definitions are unquestionably within the Bios, but is monster AI 
> within the Bios? Is Monster pathfinding? where's the extent of monster 
> behavior flags?

Having anything more than flat data in a bio would be a) a ton of work 
b) better suited by biting the bullet and declaring that we intend to 
implement some sort of scripting language (which we probably will at 
some point, but it shouldn't be an initial goal). So IMO a bio should 
contain little more than the union of the default physics model and the 
app resource fork already does.

> What else do we want here guys? Conceptually? Actually? Game Core? 
> Animation? Rendering?

-High-level rendering (software, GL, whatever else comes along). This 
part is concerned mostly with the mechanics of drawing to the screen a 
subset of the world that has already been selected and configured as 
much as possible by the low-level renderer.

-Low-level rendering. This is where the scene graph storage, visible 
set determination, etc live. (Possibly this sort of divide is too 
ambitious, in which case just "rendering"). If the pipeline between the 
game state and the high-level renderer can be sufficiently modularized, 
it will be much easier to add new types of world data and/or rendering 
methods.

-World physics, including monster AI.

-Resource loading which would cover all game data stored on disk. This 
would be more of a logical division than an architectural one, but 
everything relating to disk I/O and file formats and so on should be 
encapsulated somehow.

-Preferences, which would have 3 tasks: Manage the prefs file on disk, 
display the preferences dialog with platform-specific methods, and 
expose the user's selections to the rest of the engine in a 
platform-agnostic manner. (On a related note, A1's preferences are 
hideously complex and overdesigned... Does the user really need to be 
able to configure the type of texture filtering used?)

-Input manager, if only because this task is unavoidably 
platform-specific and there has to be a line drawn somewhere.

Probably more I've forgotten...

--Mark

"...and now if you'll excuse me it's time for my daily massacre!"

Re: [Alephmodular-devel] General status overview

[Br'fin <br...@ma...>]

On Friday, January 3, 2003, at 12:22  AM, Joe Auricchio wrote:

>> 'Bios' is definitely there, but it's much harder to determine where 
>> the barrier is between Bios and other functions. For instance, 
>> monster definitions are unquestionably within the Bios, but is 
>> monster AI within the Bios? Is Monster pathfinding? where's the 
>> extent of monster behavior flags?
>
> I'd suggest that a Bio have information describing the physics of the 
> world and its various inhabitants, and their behavior, but no actual 
> code, just definitions in, say, MML or another dialect of XML. So, AI 
> code stays outside the Bio (but may be a module in its own right). In 
> fact I suppose this is a pretty good definition of a Bio - only data, 
> no code.
>
> (The way I've been imagining a Bio is you take a whole bunch of 
> defintions (monster definitions, player definitions, a default physics 
> model, etc) and you throw it all into a big, say, .bio file, and then 
> in the Environment preferences you select that Bio. If I've got it 
> wrong please enlighten me =)

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.

>> What else do we want here guys? Conceptually? Actually? Game Core? 
>> Animation? Rendering?
>
> Rendering:
> -Viewport (takes abstract information about the viewport (x/y/z, 
> theta/phi/psi, fov) and destination (resolution, color depth) and 
> figures out things like what polys are visible, then passes that down 
> to World Rendering and Inhabitant Rendering)
> -World Rendering (take the map and visible polys info and draw a 
> picture of the map - walls, floors & ceilings, liquids...)
> -Inhabitant Rendering (deals with any and all inhabitants of the map. 
> Anything that isn't a wall (or a bridge, balcony, or ramp?) goes 
> through here. May be physically subdivided (function names, different 
> source files) into sections for monsters, player, objects, scenery, 
> projectiles...)
> -Effects (fades, warps, other things applied to the whole screen at 
> once)
>
> Main Game:
> -Game Core (take the state of the world, add in what happened this 
> tick, figure out the new state of the world. Basically just calls a 
> lot of sub-modules.)
> -Physics (NOT definitions of player, monsters, weapons, etc. This 
> module actually deals with *physics* - an object is at point A and it 
> wants to move in vector V, make it happen. Includes projectiles, 
> monsters, player, anything else.)
> -Input (What does the player want to do? Also get info from networked 
> players via networking. This all gets handed to game core which 
> figures out what to do. Has sub-modules for platforms and input 
> devices (e.g., what's the difference between a joystick and a mouse in 
> gameplay? You should be able to drastically change one's behavior but 
> not the other by modules, if not by GUI.))
> -Networking (gathering, joining, synchronizing, exchanging information 
> about what each player does)
> -Player management stuff (handles player GUI, health, oxy, powerups, 
> inventory...damage?)
> -Weapons (projectile handling, ammunition management; damage?)
> -Monster AI
> -Monsters (catch whatever's left that affects monsters. "owner" of all 
> monster objects, activation, damage?)
>
> (Note that not all of these need be full replaceable modules; some of 
> them only appear here to indicate they should *NOT* be part of other, 
> related modules.)
>
> I've probably missed a few ;)
>
> Joe Auricchio ~ av...@fm...

But you have the most thorough rundown so far. And for that I certainly 
thank you. :)

-Jeremy Parsons

Re: [Alephmodular-devel] Question about modules

[Br'fin <br...@ma...>]

On Friday, January 3, 2003, at 12:35  AM, Alexander Strange 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.

For the High Level Modules I am thinking of things which are chosen and 
integrated together at compile time. I want it to be so that you could 
strip out say all the monster, physics, and GUI code and work the 
remainder into a visual mode for an editor.

Lower level elements would be good code design, hopefully.

So far the only area which has drifted into the realm of potential 
plugins is the 'Bios' area.

And in answer to your question in another post, 'Bios' is so far the 
best name running for a module to own all of the definitions that 
currently exist in the code. Everything from default physics to 
interface resources. It's ok for Marathon to refer to _pfhor_fighter or 
_fusion_pistol_blast, but kind of limiting for any other project.

-Jeremy Parsons

[Alephmodular-devel] Question about modules

[Alexander S. <ast...@it...>]

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.

Re: [Alephmodular-devel] General status overview

[Alexander S. <ast...@it...>]

On Thursday, January 2, 2003, at 11:16  PM, Br'fin wrote:
> Now does anyone have experience or links on setting up the necessary 
> files for autoconf? Especially since I don't currently have a makefile 
> proper.

Yes, I know how to set up autoconf/automake (automake is a way to 
easily create Makefiles).

> 0.4 PLANNING
>
> _High Level Modules_
>
> We still need some clarity here.
>
> GUI seems obvious. Though certain elements are far more obvious than 
> others.
>
> 'Bios' is definitely there, but it's much harder to determine where 
> the barrier is between Bios and other functions. For instance, monster 
> definitions are unquestionably within the Bios, but is monster AI 
> within the Bios? Is Monster pathfinding? where's the extent of monster 
> behavior flags?

"Bios"? I need to read the list archive some more.

> What else do we want here guys? Conceptually? Actually? Game Core? 
> Animation? Rendering?
>
> Where does unifying saving/restoring game information lay?
> Where does the various information and strings currently stored in 
> marathon2.rsrc go?
Inside the source code, and modifiable (MML, for Aleph One 
compatibility?).

[Alephmodular-devel] General status overview

[Br'fin <br...@ma...>]

0.3 STATUS

I've cleaned up the variables to have a platform neutral length.
I've worked through to squash warnings.

While I haven't done anything major with Mallocs or Enums, those are  
still potentials. But I'm still waffling on necessity.

Mallocs are apt to fall by the way side in the course of shifting  
everything to classes. If there is anything memory wise to worry about  
at the moment it would be the mix of Mac Memory handling (NewPtr,  
NewHandle), and the more neutral C/C++ style memories (malloc, new).

Enums of the sort I would be targeting are also firmly in the realm of  
the 'Bio' stuff we've been talking about. So typedef'ing them now could  
just work out to being premature.

I've been doing some thinking, and while I'm not sure what other things  
should go into 0.3, I have come up with an issue that should be worked  
into the system now.

alephversion.h and config.h under the auspices of autoconf and a  
configure/configure.in.

Yes even for using Project Builder this would work out to
	cvs co alephModular
	cd alephModular
	./configure
	open build/macosx/AlephModular.pbproj (or double click on the project  
:) )

Especially considering that configure should be able to use  
AlephModular.pbproj/project.pbxproj.in to feed the version information  
set during configuring into PB's build process.

Now does anyone have experience or links on setting up the necessary  
files for autoconf? Especially since I don't currently have a makefile  
proper.

0.4 PLANNING

_High Level Modules_

We still need some clarity here.

GUI seems obvious. Though certain elements are far more obvious than  
others.

'Bios' is definitely there, but it's much harder to determine where the  
barrier is between Bios and other functions. For instance, monster  
definitions are unquestionably within the Bios, but is monster AI  
within the Bios? Is Monster pathfinding? where's the extent of monster  
behavior flags?

What else do we want here guys? Conceptually? Actually? Game Core?  
Animation? Rendering?

Where does unifying saving/restoring game information lay?
Where does the various information and strings currently stored in  
marathon2.rsrc go?

_Process_

I'm finding myself leaning more and more towards Chris Bergmann's  
suggestion of first trying to transition the current structures into  
classes. Should we have a sub 0.4 milestone for full classification or  
make that 0.4 and push out the high level modules to 0.5? Other  
comments on Milestone planning?

At any rate, folks should not be surprised that I want a slow and  
progressive transitioning of things. I find myself very leery about big  
changes. (This has been most notable recently in the GUI discussions. I  
like the basic argument for the one GUI, but I'm not ready to commit to  
it without it having proven itself first)

-Jeremy Parsons

--------------------- 
+------------------------------------------------------
Br'fin               |      TIMSter, MU*er, Web Programmer, ... Insane?
The Denim Warrior    |                  You be the judge...
br...@ma...       |
--------------------- 
+------------------------------------------------------

[Alephmodular-devel] Hi.

[Alexander S. <fe...@it...>]

Oops, forgot to subscribe to this list earlier. Oh well.

Anyway, here's what I'm good at:
* Familiar with Sourceforge, including the admin pages and setting up 
things.
* Familiar with the Marathon source code already with Aleph One.
* I'm a Marathon purist :)
* Not very good at Carbon, but very good at OSXing and the Developer 
Tools.
* I've got friends I can make do stuff (friends who have a lot of 
bandwidth, and one who wrote something that rhymes with "Ridges And 
Ralconies")

--
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

Re: [Alephmodular-devel] 0.3 progress update ... warning count down

[Br'fin <br...@ma...>]

On Thursday, January 2, 2003, at 02:04  PM, Michael Adams wrote:
>
> Oh goody goody!  I imagine it took quite a bit of work
> to do that, but having warning free code is always
> nice.
>
Not too much work, mostly gruntwork and actually taking some time to 
appease the compiler. Now that most of the verbose but pointless 
warnings are out of the way any new ones become very obvious instead of 
being lost in the chaff. Yay!

> While your working in this area you may want to keep
> in mind a few brain dead compilers in this world that
> don't know about #warning.  I'll give you a hint: It's
> the compiler that most Windows people use.  Yep,
> that's right Microsoft's Visual C++ couldn't even get
> the preprocessor right (A1 only uses #warning in the
> Mac code not SDL).

> I don't know how you want to handle this.  I see two
> options.  Either, change the #warning's to #error's,
> which MSVC does understand, or put #ifdef around the
> #warning's.
>
> This wont become a major issue until we are actually
> trying to get it to work under Windows, but it's
> something to keep in mind and plan for.
>
> Again kudos on the warning elimination,
> Michael D. Adams
> mdm...@ya...
>
Thanks and thanks for the reminder. After a quick look at how my other 
favorite project (Bochs) uses warnings, I'll follow their example for 
now:

#ifdef __GNUC__
#warning blah blah blah
#endif

These are warnings, not errors. Little notes I've put in some spots of 
code that are dubious and should be redone at some point.

-Jeremy Parsons

Re: [Alephmodular-devel] 0.3 progress update ... warning count down

[Michael A. <mdm...@ya...>]

--- Br'fin <br...@ma...> wrote:
> I've been working to reduce the number of warnings
> generated during the 
> compilation of AlephModular. I managed to work the
> count down from 
> about 603 or so at its worst (about 80 of which were
> my fault) to 13 
> known warnings. Most of which are my #warnings with
> a handful of others 
> being issues I know about.
> 
> -Jeremy
> 

Oh goody goody!  I imagine it took quite a bit of work
to do that, but having warning free code is always
nice.

While your working in this area you may want to keep
in mind a few brain dead compilers in this world that
don't know about #warning.  I'll give you a hint: It's
the compiler that most Windows people use.  Yep,
that's right Microsoft's Visual C++ couldn't even get
the preprocessor right (A1 only uses #warning in the
Mac code not SDL).

I don't know how you want to handle this.  I see two
options.  Either, change the #warning's to #error's,
which MSVC does understand, or put #ifdef around the
#warning's.

This wont become a major issue until we are actually
trying to get it to work under Windows, but it's
something to keep in mind and plan for.

Again kudos on the warning elimination,
Michael D. Adams
mdm...@ya...


__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

Re: [Alephmodular-devel] High Level Modules

[Br'fin <br...@ma...>]

On Thursday, January 2, 2003, at 01:05  PM, Chris Pickel wrote:

> On Thursday, January 2, 2003, at 12:50  AM, Br'fin wrote:
>>> "Bio" modules? It's a little more interesting than calling them 
>>> "Definitions" modules. A "Map Scenario ala E:MR with M2's Bio."
>> Bio certainly has a nicer ring to it than Personality :) Not 
>> convinced 100% but it does ring better.
>
> Fundamentals? Foundation? Trimmings?
>
> I should note that I missed a major bastion of them when I was making 
> the list of essentials - player.cpp. It has definitions for player 
> shapes, initial items, and damage responses. (One of my dreams has 
> always been to play as an Enforcer, so player_shapes_definitions is of 
> particular interest to me)

Bio and Personality still fit better. Bio just seems to fit.

Heh, not a problem, those definitions "They're everywhere!" why you 
also left off screen_definitions.h with the internal ids used for 
display rectangles and font specifications.

>>> -------module_compatibility.cpp-------
>> Mmm, good idea. Don't know if I'd quite phrase it like that... Or 
>> more to the point... most modules are compiled together. So something 
>> that was macro-based to complain during compilation would probably be 
>> better.
>
> Then the following is probably what you're looking for. In the header 
> file for a module, you put:
> /-------
> #define Module Version
> \-------
> ...and then in the implementation for another module that needs it you 
> add:
> /-------
> #ifndef Module
>     #error Module not available
> #else
>     #if (Module != Version) // Module > Version instead?
>         #error Bad version of Module
>     #endif
> #endif
> \-------
> Replace "Module" and "Version" with whatever you need, and you're set.
>
> -Sfiera

Aww, there isn't a way this could be contained within macros?

#include "AModules.h" // With definitions for the various macros.

Then within a module have

ANNOUNCE_VERSION(GuiModule, 0.6)

And within other areas use

REQUIRE_VERSION(GuiModule, 0.5)

Hmm, drat. That's certainly a shame and a nuisance. Then again is this 
particular thread getting too paranoid? :)

-Jeremy Parsons

Re: [Alephmodular-devel] High Level Modules

[Chris P. <sf...@ma...>]

On Thursday, January 2, 2003, at 12:50  AM, Br'fin wrote:
>> "Bio" modules? It's a little more interesting than calling them 
>> "Definitions" modules. A "Map Scenario ala E:MR with M2's Bio."
> Bio certainly has a nicer ring to it than Personality :) Not convinced 
> 100% but it does ring better.

Fundamentals? Foundation? Trimmings?

I should note that I missed a major bastion of them when I was making 
the list of essentials - player.cpp. It has definitions for player 
shapes, initial items, and damage responses. (One of my dreams has 
always been to play as an Enforcer, so player_shapes_definitions is of 
particular interest to me)

>> -------module_compatibility.cpp-------
> Mmm, good idea. Don't know if I'd quite phrase it like that... Or more 
> to the point... most modules are compiled together. So something that 
> was macro-based to complain during compilation would probably be 
> better.

Then the following is probably what you're looking for. In the header 
file for a module, you put:
/-------
#define Module Version
\-------
...and then in the implementation for another module that needs it you 
add:
/-------
#ifndef Module
     #error Module not available
#else
     #if (Module != Version) // Module > Version instead?
         #error Bad version of Module
     #endif
#endif
\-------
Replace "Module" and "Version" with whatever you need, and you're set.

-Sfiera

[Alephmodular-devel] 0.3 progress update ... warning count down

[Br'fin <br...@ma...>]

Grr, bad bad mail server. No biscuit for sending multiple copies of 
that message while having my mail client tell me it failed to send the 
message.

My apologies folks.

On to the update.

I've been working to reduce the number of warnings generated during the 
compilation of AlephModular. I managed to work the count down from 
about 603 or so at its worst (about 80 of which were my fault) to 13 
known warnings. Most of which are my #warnings with a handful of others 
being issues I know about.

-Jeremy

Re: [Alephmodular-devel] High Level Modules

[Br'fin <br...@ma...>]

On Monday, December 30, 2002, at 10:24  PM, Chris Pickel wrote:
>> A very good list. I'm trying to think of what we should call this 
>> group of ... extended physics. Scenario? Personality? (Do you play a 
>> Map Scenario ala E:MR within AM with the Personality of M2?) I agree 
>> that they should have their own module. Something that might 
>> interface a bit more strongly with the other modules than any other 
>> module is allowed to.
>>
>> An extended example would include not just monster definitions, but 
>> also provide the monster control functions. (Hah! *MY* Scenario 
>> implements a segmented worm as a monster!)
>>
>> I'd really like a decent name for this!
>
> Let me think...
> "Bio" modules? It's a little more interesting than calling them 
> "Definitions" modules. A "Map Scenario ala E:MR with M2's Bio."
>
Bio certainly has a nicer ring to it than Personality :) Not convinced 
100% but it does ring better.

> Another issue that has just come to my mind is inter-module 
> dependency. It's bound to happen - someone will add an extra item on 
> to item_definitions, and then someone will write another module that 
> depends on that item. If we're not careful, AM will screw up and leave 
> the user wondering how to fix it.
>
> So, we create a "module_compatibility.h/.cpp" for modules to work 
> with. Fairly simple:
>
> -------module_compatibility.cpp-------

Mmm, good idea. Don't know if I'd quite phrase it like that... Or more 
to the point... most modules are compiled together. So something that 
was macro-based to complain during compilation would probably be better.

As for plug in or other external components that require various 
systems, it would certainly be a good idea. Like if we allowed AM to 
load an external bio, then we could have an api to check to make sure 
all the features the bio asks for are up to snuff.

-Jeremy Parsons

Re: [Alephmodular-devel] High Level Modules

[Chris P. <sf...@ma...>]

>> - device.cpp
>> - fades.cpp
>> - game_window.cpp
>> - item_definitions.cpp
>> - media_definitions.cpp
>> - scenery_definitions.cpp
>> - sound_definitions.cpp
> A very good list. I'm trying to think of what we should call this 
> group of ... extended physics. Scenario? Personality? (Do you play a 
> Map Scenario ala E:MR within AM with the Personality of M2?) I agree 
> that they should have their own module. Something that might interface 
> a bit more strongly with the other modules than any other module is 
> allowed to.
>
> An extended example would include not just monster definitions, but 
> also provide the monster control functions. (Hah! *MY* Scenario 
> implements a segmented worm as a monster!)
>
> I'd really like a decent name for this!

Let me think...
"Bio" modules? It's a little more interesting than calling them 
"Definitions" modules. A "Map Scenario ala E:MR with M2's Bio."

Another issue that has just come to my mind is inter-module dependency. 
It's bound to happen - someone will add an extra item on to 
item_definitions, and then someone will write another module that 
depends on that item. If we're not careful, AM will screw up and leave 
the user wondering how to fix it.

So, we create a "module_compatibility.h/.cpp" for modules to work with. 
Fairly simple:

-------module_compatibility.cpp-------
#define MAXIMUM_MODULES (64) /* Safe enough for the time being */

typedef struct module_reg
{
	char *name;
	uint16 version;
} module_reg;

uint16 num_modules= 0;
module_reg registered_modules[MAXIMUM_MODULES];

void register_module(char *name, uint16 version)
{
	uint16 len = strlen(name);
	module_reg new_reg;

	assert (num_modules<MAXIMUM_MODULES);

	new_reg.name = new char[len];
	strcpy(new_reg.name, name);
	new_reg.version = version;

	registered_modules[num_modules++] = new_reg;
}

bool require_module(char *name, uint16 min_version)
{
	uint16 i;
	for (i=0; i<num_modules; i++)
		if (strcmp(registered_modules[i].name, name) == 0
			&& registered_modules[i].version >= min_version)
			return true;

	// Cancel startup, alert user to the problem
	return false;
}