[Alephmodular-devel] Hello

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

Hello, I've joined the AlephModular list and thought
I'd introduce myself.

I'm running on a WinXP machine with MSVC7/.Net on it. 
So most of my stuff will come from that perspective. 
I have been working with A1 to do the windows builds
and would be glad to do so here if that is needed.  I
enjoy debugging and hope to contribute in that area
also.  I will probably install GNU/Hurd in the near
future so I may beable to do some work over there.  I
have a buisy schedule with my collidge studies.  So I
am unlikely to be able to contribute large new
features, but I am eager to assist in anyway I can
even if that only be tweeking existing features
(either as bug fix or porting) or fixing stuff like
'#ifndef's around header files.

Now I would like to mention a few of my concerns/goals
for AM.  These may  be a little bit contraversial and
may offend some (I have trouble with that).

Crossplatform:
Something that you may hear me whine about often is
being cross platform.  I think AM is already moving in
this direction, but I want to reenforce and encourage
it.  With A1 it happened to often that sometime would
get implemented on one platform but not another. 
Please try to orginize the code so we only have one
code base.  A good example is the preference dialogs. 
A new crosshair chaging feature was added, but only on
the Mac version.  It was never added to the SDL
version.  The preference file actually has hackable to
change it, but because of the way the preferences
dialog was split between platforms it wasn't in the
GUI.  Please avoid this.  Using a good crossplatform
foundation library (like SDL or whatever) and having
everyone write for that foundation would prevent the
need to rewrite code for every new platform that comes
along.  If you have to write some utility functions
like makeButtion that are #ifdef'ed for multiple
platforms that's alright, but please don't do #ifdef
platform tricks with stuff like a showPeferencesDialog
function.  Based on the mailing list archives I think
you are leaning towards this, but I think it should be
made clear.

2.5D vs. 3D:
I feel that while AM should remain a true 2.5D map
format, moving to a 3D rendering would be no great
loss.  That is maybe the algorithms to render are 3D
(e.g. hand it off to OpenGL), but the game play and
map editing are still the ease of 2.5D.  As it is now
making a map is *very* easy.  Just look at the number
of scenarios, many of which are very high quality, for
Marathon that have been built by ordinary people.  I
don't see this for other 3D engines.  I don't mean to
exclude by this 3D models, sloped floors or 3D
objects, but the easy editing that Marathon has should
be preserved.  By 3D objects (anyone have a better
name?) I mean something that you can stand on instead
of falling through.  You could emulate B&B using
something like this.

Modular vs. Marathon:
I must agree and dissagree with some things that have
been expressed earlyer.  In order for AM to be
sucessful it will have to be able to read and run the
old Marathon maps.  What good is a game with no maps
it can run.  However I don't think the Marathon map
file format should be more than another module that
can be poped in and out.  Suppose someone writes a
Doom map file reader.  Then the Marathon and Doom
modules would be equals as far as how the code works,
but the Marathon module is still takes presidence in
cronology and maintinance.

Well, I think I've kicked over enough hornet's nets
for now.  I'm busy reinstalling Windows onto a new
hard drive, but once everything is up maybe I can
assist in porting.

Have a merry Christmas,
Michael D. Adams
mdm...@ya...

P.S. Please forgive my spelling.  I'm to busy to
spellcheck right now.


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