Re: [Alephmodular-devel] A1's problems (was: Developer Rant #1 :) )

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

On Tuesday, January 14, 2003, at 07:19  PM, Woody Zenfell, III wrote:
>
>> There were other issues too, relating to cruft. Since shifting to 
>> MacOS X 10.2.x and PB 2.0.x, I've been unable to figure out how to 
>> run AO within the debugger. Talk about annoying.
>
> Yeah, I was unable to link the thing for about 6 months, til I found 
> -force_flat_namespace...
>
> Maybe it's the older devtools, but I find the debugger almost useless 
> within PB; it always seems to get hung up or confused or something.  I 
> always run it from the command line.  FWIW.

I found the debugger to rock, but I'm relatively unfamiliar with 
debuggers too :) Something with how A1 is linked or something, but 
under the newer tools GDB ends up reporting some problem linking to one 
library or another then exits.

I admit I don't know how to set up the project file to support multiple 
versions of PB.  Guess it's problem of it not being as refined as the 
unix make process :)

>> My overall assumption is that if AM can be steered right, then it 
>> should be possible to adapt things like AO's OpenGL code. And it 
>> wouldn't be the first time I had shoe-horned things together :)
>
> Well, I hope you're right... and hearing you state it as if _you_ plan 
> to do that sort of thing (and not just leave it to unspecified others) 
> gives me cause for hope.  :)  It probably is a Good Thing to figure 
> out a framework and then fit the pieces together, rather than vice 
> versa as would need to be done with A1... but OTOH I think examining 
> A1 could inform the design of that framework.  Learning from history 
> and all that.  But I'm sure that's all part of the plan.

A1 is both a source of learning what to do and, alas, what not to do. 
Certainly when I find something not working or serialized or what not I 
do tend to peek at what AO looks like in that area :)

> BTW thanks for the bug summary.  I find it a little curious that you 
> seem to feel that your looking for and fixing these bugs now, as 
> opposed to earlier, is somehow A1's fault... but I can see where 
> you're coming from nonetheless.

To be fair, most of the bugs I wasn't aware of before. Almost anything 
software rendering wise would have skipped my notice.

One of the bugs is probably not even noticeable in the fix. I fixed it 
when I found the compiler giving warnings about something being shifted 
by TRIG_MAGNITUDE (1024) instead
of the appropriate TRIG_whatever shifting define.

Two of them I would consider high-profile. One is the disappearing 
close creature one. And the other is that darn assertion. It felt like 
everyone on the list knew to trash the preferences if someone 
complained about the assertion, but it went on for how long?

My knowledge of the code has certainly grown since then.

> I think it's a Good Thing that AM has someone In Charge (and doubly so 
> that that  someone happens to be as thoughtful as Br'fin).
>
> Well anyway I think we've talked this one to death ... what's next for 
> us to talk about wrt AM?  Proposals for decomposition into systems and 
> subsystems etc.?  Or are you not quite at that point yet?

Yes actually. I really need to stop flexing my milestone designations. 
Though on that front I picked up a fun book. 'Game Architecture and 
Design' by Andrew Rollings and Dave Morris. Given that 1/3rd of it is 
team planning/management and another 1/3rd deals with appropriate 
architectures, it seemed like a good buy with x-mas gift certificates, 
especially since I found it half off the cover price.

I would love to see some actual proposals. My considerations right now 
are for hardware abstraction components. For instance, what would 
updated elements of portable_files or screen (the display module) look 
like?

-Jeremy Parsons