Re: [Alephmodular-devel] Hello

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

I'm new too, so I suppose now is as good a time as ever to say hello - 
and voice a few of my opinions too, of course. (Note that a few of my 
opinions could be incorrect)

On Thursday, December 26, 2002, at 04:12  PM, Michael Adams wrote:
> Using a good cross-platform
> 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.
      Personally, I think AlephModular's core shouldn't be founded upon 
*any* platform/library. If a particular feature can't be made 
platform-independent, it should probably be modular.
      The modules are another issue. The set of Carbon modules could 
differ from the SDL modules, forcing them to be recoded each time. Then 
again, I don't think this would become as much of an issue with AM - a 
particular feature would never be implemented into platform-specific 
code first. It would be implemented into the core, then made usable by 
the modules on each platform.

> 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.
      Yes - there's no reason we should have to support two map formats 
(Portal/True 3D). OpenGL rendering would be a nice thing for the 
future, but before anyone starts work on that, AM should be 
modularized, so that we can just swap out software rendering for OpenGL.
      B&B and slope code could possibly be closer, since (if functional 
and stable) they would be better suited for AM's core.

> Modular vs. Marathon:
> However I don't think the Marathon map
> file format should be more than another module that
> can be poped in and out.
      Not something that had ever occurred to me, but it sounds like a 
good idea. However, we'd be limited in our choices of alternate map 
formats; a 3D map will require a 3D engine, and if that has to be coded 
too, you might as well just use the original game.

> Have a merry Christmas,
Happy boxing day.

-----

      Just a note: I managed to stick some code into mouse.cpp that 
allows you to use the mouse - sort of. Carbon has a "GetMouse(point 
*mouseLoc)" function that can grab the mouse's position for you, but as 
far as I can tell, it doesn't have a corresponding SetMouse function.
      I rewrote the mouse_idle function to work with this, but you'll 
stop turning when your mouse hits the side of the screen. It's not a 
permanent fix, but at least it's no longer a pain to walk around.

-Sfiera