[Alephmodular-devel] Re: Comments on AM

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

On Sunday, March 16, 2003, at 09:56  AM, tiennou wrote:

> Hello !
>
> First, I found your work on AM excellent ! I'm glad to see someone 
> really trying to make the code usable, and if there is times where I 
> don't understand very well what you are talking about, I like the 
> overall results...
>
> Today, I got the lastest source from CVS and it compiled fine ! This 
> is the first time I get anything built with PB.
>
> I looked through the changes you've made, and the stuff you've added. 
> It's cool !

Thank you, and I'm glad it compiled too. :)

> Anyway, I wanted to know if there was a need for something to be 
> coded, because I'm kinda lacking interest in AO. It's too much complex 
> for me ;-). I saw there were things to be done (#warnings at compile) 
> mainly around serialization. Maybe I could do that ?

Well, most of the warnings about serialization are warnings I put in 
during a phase of time where getting things working was a higher 
priority then getting things clean. In otherwords, until we're ready to 
redo the entire aspect of shapes to clean it up, cleaning up the 
serialization warnings for aspects that might not be used is low 
priority so far.

> I have a few questions on Marathon and it's source ...
>
> What is serialization ? Everyone is talking about it, but I never 
> really grasped its purpose. Has something to do with file saving.

Serialization is the process of transforming between a disk based 
format (a string of bytes in order, ala 2 bytes for height, 2 bytes for 
width, then 10 bytes for a 9 character name) and the format of the data 
in memory. In memory values may be in different locations due to 
processer data alignments or between Mac and PC singular data values 
may be in different order (big-endian versus little-endian)

What it comes down to is that Bungie's original code would save data 
something like this
	struct foo;
	write(file, foo, sizeof(foo));

And when I was first compiling things under MacOS X, well, struct foo 
is not necessarily the same size or configuration between platforms or 
compilers. Hence both AM and AO have strategies for decoding the data 
in the Bungie files into the native structures that the compilers 
generate.

> What is the purpose of the cseries files ? They are around since a 
> long time, but I don't know why they are needed.

The original Bungie source code referred to an external library of some 
sort that they were unable to include in their release. Essentially a 
missing but required library known as CSeries. I do not know where 
their library originated from. One of the earliest efforts in the 
Marathon community with the source code was to fill in those missing 
files so that Marathon would actually run.

The majority of the missing functions fortunately seemed to fall into 
the category of 'dumb but routine things you always need to do in a 
Macintosh program.' Various tricks for dealing with common low-level 
application details. The first complete set of working CSeries files 
seems to have come from Bo Lindbergh.

AM's own set of CSeries is essentially taken from AO with some minor 
changes. Minor enough that I was able to fold in some of their recent 
fixes to the CSeries files.

> Actually, I'm trying to find the origins of the original limitations 
> (Stateless lightning (in AO, the logic seemed to work, but I never 
> tried), different media types per level, and such).

All original limitations should be present in the AM code still. For 
better or for worse. I haven't had anything in mind to address the 
limits (Low priority/under my radar)

> Hmm, about OpenGL...
> I understand there is a need to keep the existing rendering engine, 
> but it would be much easier to add real 3D support in Marathon if we 
> could let OpenGL handle the rendering part. (This is an advice from 
> someone that never done something is OGL, and that doesn't know what 
> OGL need to function properly). I also think that Low-res mode and 256 
> colors mode support should be dropped. All the newer machines are now 
> able to do more advanced things.

Real 3D support is currently a non-target for AM. I would not mind 
adding OpenGL support, though. As I agree that it could be useful to 
make things nice and pretty at the larger screen sizes. As well as 
hopefully rendering everything a lot faster. I'm hoping that OpenGL 
support can be settled within the framework of the display abstraction 
at a later point in time.

256 colors mode I'm hazy on. But has proven problematic so far under 
OSX (My machine does switch to a 256 color mode, but some other AM 
users were having problems, so AM tends to default to 16 bit if 8-bit 
fails under OSX) I'll see if further work with Display Abstraction 
fixes that up at least on my machine.

Low-resolution mode isn't too hard to maintain now. I do have it 
accommodated and working within the graphics framework that's 
developing. It may be debatable if it's useful or not, but as long as 
it's working I don't see any problems with keeping it.

Newer machines might be able to do more advanced things, but the hooks 
in the engine aren't there yet. One of the later goals of the display 
abstraction is to blow-away the 640x480 limit of the current code. 
Though in such a world it may no longer be relevant to support the 75% 
and 50% windowed modes that currently exist in the code.

My own personal machine is probably a middle of the road MacOS X box as 
a 450 Mhz G4. Not the newest of machines, but not the lowest end 
machine that is supported either.

> I'm in no way trying to change the path you've chosen. Just trying to 
> confront my opinion against someone's else.
>
> Good luck with Display Abstraction !
>
Thank you, and I'm glad for the questions too. Currently display 
abstraction is going slowly, I'm trying to muck out initial setup and 
calls so I can push more responsibility onto it. In other words, my 
next goal is to have the display abstraction itself allocate and manage 
screens and windows as necessary :)

-Jeremy Parsons