alephmodular-devel — AlephModular Developers Mailing List

Re: [Alephmodular-devel] CVS?

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

On Wednesday, October 8, 2003, at 02:05  PM, Timothy Collett wrote:

> Greetings.
> It looks like CVS is responding again; I ran cvs update -AdP and it 
> didn't hang like it's been doing for a few days.  However, while it 
> said "cvs server: Updating marathon2/Display", I still don't have a 
> Display folder in my marathon2 folder.  Am I doing something wrong, or 
> is CVS?  Would it be easier to just trash my install and download a 
> whole new set of sourcefiles?
>
> Thanks.
>
> Timothy Collett

No idea. Matt Lee was having problems like that himself. Just forcign 
the issue and trying multiple times finally got it all to work. He may 
have manually created the missing directories too. It sounds like your 
problem, but the solution was just random banging on it at the time. :/

-Jeremy

[Alephmodular-devel] CVS?

[Timothy C. <da...@ma...>]

Greetings.
It looks like CVS is responding again; I ran cvs update -AdP and it 
didn't hang like it's been doing for a few days.  However, while it 
said "cvs server: Updating marathon2/Display", I still don't have a 
Display folder in my marathon2 folder.  Am I doing something wrong, or 
is CVS?  Would it be easier to just trash my install and download a 
whole new set of sourcefiles?

Thanks.

Timothy Collett

"Nothing takes the taste out of peanut butter quite like unrequited 
love."
--Charlie Brown 

Re: [Alephmodular-devel] Display Abstraction Landed?

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

On Oct 7, 2003, at 1:08 AM, Br'fin wrote:
> I still haven't decided on a direction, though have been tempted to 
> try and work on the Carbon implementation of the display abstraction. 
> Right now I'm just kvetching at sf.net's CVS systems which seem to be 
> unavailable.
>
> -Jeremy Parsons
>

That's a good sign. It probably means they're finally swapping in the 
new CVS servers.

Re: [Alephmodular-devel] Display Abstraction Landed?

[Timothy C. <da...@ma...>]

> I have no idea. Currently AM plays back a batch of vidmaster films 
> fine. However I have yet to get any M2 netfilms. The closest I have is 
> an A1 netfilm on a M2 map, and that goes out of sync right towards the 
> end. Possiblly due to differences in the two engines.
>

Well, it shouldn't be too difficult for me to generate an M2 netfilm.  
I have a couple of computers here I should be able to do it on (of 
course, it won't be anything like a "real" netfilm, just one player 
running around, then the other).

Would you like me to do this?  If so, is there anything in particular 
you can think of that I should do?  If you can't, I'll just try to do 
everything that comes to mind that might cause different situations.

Timothy Collett

Yesterday it worked
Today it is not working
Windows is like that.
~haiku~

Re: [Alephmodular-devel] Display Abstraction Landed?

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

On Tuesday, October 7, 2003, at 05:18  PM, Timothy Collett wrote:

>> Well, the replays are solid in terms of sync. But if something changes
>> then the replay is off. And classic OOS errors seem to come from
>> someone's emulation getting off for some unclear reason.
>
> You know, I seem to remember something Woody was doing a while ago, 
> while chasing down OOS problems in A1.  Didn't he find some actual 
> errors in the RNG code, that could, at least in theory, lead to OOS?
>
> Yeah, this past January 12 on marathon-devel, he said he thought it 
> was a problem with Marathon's min() function.  Maybe you should look 
> into that?

I have no idea. Currently AM plays back a batch of vidmaster films 
fine. However I have yet to get any M2 netfilms. The closest I have is 
an A1 netfilm on a M2 map, and that goes out of sync right towards the 
end. Possiblly due to differences in the two engines.

>> The Real modularization part is yet to come... I should dig up one of
>> the roadmaps and probably check into into the documentation directory.
>
> That's kind of what I thought.
>
>>> A rough order might be
>>>         Modularizing basic file capabilities
>>>         Modularizing basic display capabilities
>>>         Modularizing sound handling
>>>         Modularizing preferences
>>>         Modularizing gui
>>>         Modularizing game elements
>>>         Modularizing networking
>
> Do you have any idea, at this point, what will be required a) as 
> prerequisite for these, and b) to actually do them?

Basic File handling and basic display are done. Resources falls into an 
advanced file handling and probably should be added to the list. Though 
I know not where.

-Jeremy Parsons

Re: [Alephmodular-devel] Display Abstraction Landed?

[Timothy C. <da...@ma...>]

 >Well, the replays are solid in terms of sync. But if something changes  
>then the replay is off. And classic OOS errors seem to come from  
>someone's emulation getting off for some unclear reason.

You know, I seem to remember something Woody was doing a while ago, while chasing down OOS problems in A1.  Didn't he find some actual errors in the RNG code, that could, at least in theory, lead to OOS?

Yeah, this past January 12 on marathon-devel, he said he thought it was a problem with Marathon's min() function.  Maybe you should look into that?

>The only resource we save into files currently is a map preview in the  
>saved game that is supposed to show up in Open/Save dialogs and the  
>finder. What's annoying is this worked fine in OS X 1.0, but under 1.1,  
>Nav Services still created the preview, but the finder ignored it for  
>me :/

Yeah, I remember that.  I wonder why it did that?  Very annoying.  Maybe Panther will fix it?

>That preview is currently stored in a very platform specific way,  
>supposedly so that that platform can and should show it elsewhere :/

In theory, that sounds good.  

>The Real modularization part is yet to come... I should dig up one of  
>the roadmaps and probably check into into the documentation directory.

That's kind of what I thought.

>> A rough order might be
>>         Modularizing basic file capabilities
>>         Modularizing basic display capabilities
>>         Modularizing sound handling
>>         Modularizing preferences
>>         Modularizing gui
>>         Modularizing game elements
>>         Modularizing networking

Do you have any idea, at this point, what will be required a) as prerequisite for these, and b) to actually do them?

Just curious.

Timothy Collett

He who asks is a fool for five minues. He who doesn't ask is a fool forever. 

Re: [Alephmodular-devel] Display Abstraction Landed?

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

On Tuesday, October 7, 2003, at 04:16  PM, Timothy Collett wrote:

>> My own up-to-date version of AM seemed to have no problems loading =20=

>> your
>> save game though.
>
> Hmm...that wasn't exactly the problem, I'm afraid.  I think I can load =
=20
> a game from the main menu.  The sequence of events here was the =20
> following:
> start new game
> save
> die
> attempt to resurrect
> AM quits itself
>
> But this suggests that at least the savefile was good.

Ah, hmmmm, you know, I can't think if I ever tried that or not, hmm.

>> Yes, Networking is currently disabled. It was easier to stub it out
>> then to grok everything and rewrite it in OpenTransport. The most
>> likely thing to occur here is that we graft in A1's networking ;)
>
> Star protocol & all? :-)

Heh ;)

>> With respect to replays, I don't know if there is a better way to do
>> things. There are improvements we can make ... like eliminating the
>> need for the Vidmaster's dance. But beyond that, it's hard storing =
all
>> of the world state umpty times a whatever. On the other hand, even in
>> modern games, I don't recall seeing that many replays in FPS ( and
>> usually they work in a similar fashion when they do... reset =20
>> simulation
>> to x point in time, let run :) )
>
> Yeah, I know.  But...couldn't there be some more robustness in the =20
> format?  One thing that comes to mind is making the RNG a little more =20=

> solid in synchronization, if this is possible/sensible (this would =20
> help net games, too).  Another thing is to put information about the =20=

> environment used into the film.  Ideally, each =20
> Shapes/Sounds/Map/Physics file would have some sort of checksum that =20=

> the films (and savefiles) could reference, and if it's not there, =20
> there should be some sort of warning.

Well, the replays are solid in terms of sync. But if something changes =20=

then the replay is off. And classic OOS errors seem to come from =20
someone's emulation getting off for some unclear reason.

As I recall, the wadfile based files (physics, map) do have this =20
checksum (hence how a replay or, I believe, even a saved game syncs up =20=

with the right map.) The other two files, shapes and images do not and =20=

the game tries to sync up with them (from the preferences) due to =20
modification date :/

Though any sort of checking on the files would help over the existing =20=

code with respect to replays :)

>> We have to deal with resources as long as the file system does and we
>> can run old M2 maps. This should cover a nice long while. It would be
>> nice to mix things up to have a scenario bundle. However, even then
>> this might be resource routines now working with an expanded format
>> (that is hidden from the rest of the code.)
>
> I didn't say that quite right, did I?  What I really mean is that we =20=

> shouldn't have any current file formats=97the ones we output=97using =20=

> resources.  I think that having support for *loading* resource-based =20=

> formats is great, and should remain forever (at least where it makes =20=

> sense to do so, like Map and Images).  But if any current formats (ie, =
=20
> savefiles & films) use resources, the use of them should be abstracted =
=20
> away from the core, so it's easy to plug in a new function to save =20
> them on Windows or Linux systems.

The only resource we save into files currently is a map preview in the =20=

saved game that is supposed to show up in Open/Save dialogs and the =20
finder. What's annoying is this worked fine in OS X 1.0, but under 1.1, =20=

Nav Services still created the preview, but the finder ignored it for =20=

me :/

That preview is currently stored in a very platform specific way, =20
supposedly so that that platform can and should show it elsewhere :/

> Another issue I've been thinking about is the real modularization =20
> part...you know, being able to just take the network bits for a pure =20=

> game server, and the rendering code for Visual Mode of an editor, that =
=20
> kind of thing.  How much is that inherent in what you've been doing, =20=

> and how much must be done separately?  More to the point, how much =20
> remains to be done?

The Real modularization part is yet to come... I should dig up one of =20=

the roadmaps and probably check into into the documentation directory.

Here's probably the closest thing we have ;)
http://sourceforge.net/mailarchive/=20
forum.php?thread_id=3D1453618&forum_id=3D17900

I'm still trying to erase direct knowledge of Mac-isms from these main =20=

game loops and so forth. It seems to be a step towards both modularity =20=

and going cross-platform.

Heh, going by those lists the next to work on would be sound =20
abstraction.

> A rough order might be
>         Modularizing basic file capabilities
>         Modularizing basic display capabilities
>         Modularizing sound handling
>         Modularizing preferences
>         Modularizing gui
>         Modularizing game elements
>         Modularizing networking

-Jeremy Parsons

Re: [Alephmodular-devel] Display Abstraction Landed?

[Timothy C. <da...@ma...>]

=20
On Tuesday, October 07, 2003, at 02:52PM, Br'fin <br...@ma...> wrote:

>
>On Tuesday, October 7, 2003, at 09:13  AM, Timothy Collett wrote:
>
>>> Mmm, I better go check saved games to see if I can find anything. In=20
>>> the meantime... do you know which version/date created the saved=20
>>> game? And could you email (directly to me at br...@ma...)  the=20
>>> saved > game?
>>
>> It was saved with this version; however, I'm no longer entirely sure=20
>> that I've got the pertinent changes.  Running cvs update -AdP should=20
>> bring my copy of the code fully up-to-date, yes?  Only when I ran it,=20
>> it didn't seem to do much, and Project Builder seemed to think there=20
>> weren't any changes when I built the thing.
>>
>> I'll email you the save in a separate email.
>
>I still don't know what's up with the public CVS servers, certainly I=20
>can't manage to check anything out that way currently :/

Yeah, I got an email from sf.net Saturday detailing their CVS woes.  I supp=
ose this is just more of that.  They said that it should be fixed soon.... =
*crosses fingers*

>
>My own up-to-date version of AM seemed to have no problems loading your=20
>save game though.

Hmm...that wasn't exactly the problem, I'm afraid.  I think I can load a ga=
me from the main menu.  The sequence of events here was the following:
start new game
save
die
attempt to resurrect
AM quits itself

But this suggests that at least the savefile was good.

>Yes, Networking is currently disabled. It was easier to stub it out=20
>then to grok everything and rewrite it in OpenTransport. The most=20
>likely thing to occur here is that we graft in A1's networking ;)

Star protocol & all? :-)

>With respect to replays, I don't know if there is a better way to do=20
>things. There are improvements we can make ... like eliminating the=20
>need for the Vidmaster's dance. But beyond that, it's hard storing all=20
>of the world state umpty times a whatever. On the other hand, even in=20
>modern games, I don't recall seeing that many replays in FPS ( and=20
>usually they work in a similar fashion when they do... reset simulation=20
>to x point in time, let run :) )

Yeah, I know.  But...couldn't there be some more robustness in the format? =
 One thing that comes to mind is making the RNG a little more solid in sync=
hronization, if this is possible/sensible (this would help net games, too).=
  Another thing is to put information about the environment used into the f=
ilm.  Ideally, each Shapes/Sounds/Map/Physics file would have some sort of =
checksum that the films (and savefiles) could reference, and if it's not th=
ere, there should be some sort of warning. =20

However, I'd say don't make it fatal: just tell them that it's not right, t=
hen let them watch the poor marine running into walls if they want (it can =
be a lot of fun, sometimes!).

>Networking could probably receive a lot more help in this department=20
>and mostly I'm just clueless and don't quite understand it currently. :)

Hmm...I'm afraid I'm not much help here.  I know next to nothing about netw=
orking.  Woody, any thoughts?

>We have to deal with resources as long as the file system does and we=20
>can run old M2 maps. This should cover a nice long while. It would be=20
>nice to mix things up to have a scenario bundle. However, even then=20
>this might be resource routines now working with an expanded format=20
>(that is hidden from the rest of the code.)

I didn't say that quite right, did I?  What I really mean is that we should=
n't have any current file formats=97the ones we output=97using resources.  =
I think that having support for *loading* resource-based formats is great, =
and should remain forever (at least where it makes sense to do so, like Map=
 and Images).  But if any current formats (ie, savefiles & films) use resou=
rces, the use of them should be abstracted away from the core, so it's easy=
 to plug in a new function to save them on Windows or Linux systems.

Another issue I've been thinking about is the real modularization part...yo=
u know, being able to just take the network bits for a pure game server, an=
d the rendering code for Visual Mode of an editor, that kind of thing.  How=
 much is that inherent in what you've been doing, and how much must be done=
 separately?  More to the point, how much remains to be done?

Anyway, once again, keep up the good work!

Timothy Collett

"Do what you can, with what you have, where you are."
 -Teddy Roosevelt

Re: [Alephmodular-devel] Display Abstraction Landed?

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

On Tuesday, October 7, 2003, at 09:13  AM, Timothy Collett wrote:

>> Mmm, I better go check saved games to see if I can find anything. In 
>> the meantime... do you know which version/date created the saved 
>> game? And could you email (directly to me at br...@ma...)  the 
>> saved > game?
>
> It was saved with this version; however, I'm no longer entirely sure 
> that I've got the pertinent changes.  Running cvs update -AdP should 
> bring my copy of the code fully up-to-date, yes?  Only when I ran it, 
> it didn't seem to do much, and Project Builder seemed to think there 
> weren't any changes when I built the thing.
>
> I'll email you the save in a separate email.

I still don't know what's up with the public CVS servers, certainly I 
can't manage to check anything out that way currently :/

My own up-to-date version of AM seemed to have no problems loading your 
save game though.

>> Some of the places in AM that I think are prime targets involve:
>>
>> 	* Resources
>> 	* Input Handling
>> 	* Main Event Loop (May be related to Input Handling)
>> 	* Game Related GUI (File dialogs, ok to quit?, preferences)
>> 	* Preferences
>>
>> I admit Preferences is less about platform specifics and more for 
>> overhauling how the game uses preferences internally and how the game 
>> handles preferences. I've been trying to think of a system that 
>> allows for future preferences growth, while allowing conversion of 
>> older preference formats. And which allows growth without necessarily 
>> requiring a great deal of work between changes either.
>>
>
> My vote would be stuff (somewhat) related to input handling first, 
> then network, then resources.  To be a little more specific: I think 
> that, while it made good sense back in the day, relying *entirely* on 
> the inputs for films & net games isn't the best idea in the world (if 
> you disagree, please convince me! :-) ).  For the second, I tried 
> clicking "Gather" and it just didn't do anything: I presume networking 
> is currently inoperable, and thus you have disabled even trying it.  
> It would be great to see networking working in AM, especially since 
> it's now working so well in A1.  For the third, well, it would be nice 
> to have all the resource stuff out of the way.  It's obsolete even on 
> the Mac side, after all! ;-)

Yes, Networking is currently disabled. It was easier to stub it out 
then to grok everything and rewrite it in OpenTransport. The most 
likely thing to occur here is that we graft in A1's networking ;)

With respect to replays, I don't know if there is a better way to do 
things. There are improvements we can make ... like eliminating the 
need for the Vidmaster's dance. But beyond that, it's hard storing all 
of the world state umpty times a whatever. On the other hand, even in 
modern games, I don't recall seeing that many replays in FPS ( and 
usually they work in a similar fashion when they do... reset simulation 
to x point in time, let run :) )

Networking could probably receive a lot more help in this department 
and mostly I'm just clueless and don't quite understand it currently. :)

We have to deal with resources as long as the file system does and we 
can run old M2 maps. This should cover a nice long while. It would be 
nice to mix things up to have a scenario bundle. However, even then 
this might be resource routines now working with an expanded format 
(that is hidden from the rest of the code.)

-Jeremy Parsons

Re: [Alephmodular-devel] Display Abstraction Landed?

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

On Tuesday, October 7, 2003, at 10:10  AM, Timothy Collett wrote:

>> I haven't gotten to look at things yet. My machine is suddenly 
>> choking/churning on cvs and I may need to reboot to do that. I won't 
>> get to that until later.
>>
>
> Huh.  Mine's been doing that, too, lately.  Whenever PB is open with 
> the AM project, there's a cvs process taking as much CPU time as it 
> can steal, and lately when I've tried to do fink selfupdate cvs, it 
> just sits there for ages with cvs clogging the CPU, and eventually 
> spits out a weird error message, something like couldn't malloc() some 
> large number.
>
> Is this anything like what you're seeing?

Yes, and I think it's a sf.net network problem at issue. Just trying to 
do a traceroute on the public CVS server started to breakdown like that 
too. Unable to find a connection out that way. I must say I'm surprised 
at the local churning that causes.

-Jeremy Parsons

Re: [Alephmodular-devel] Display Abstraction Landed?

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

I haven't gotten to look at things yet. My machine is suddenly 
choking/churning on cvs and I may need to reboot to do that. I won't 
get to that until later.

If you do have the latest checkout properly then you should have files 
like
alpehModular/marathon2/Display/Carbon/CDisplay_Carbon.cpp
alpehModular/marathon2/Display/CFontSpec.h

-Jeremy Parsons

Re: [Alephmodular-devel] Display Abstraction Landed?

[Timothy C. <da...@ma...>]

> Mmm, I better go check saved games to see if I can find anything. In 
> the meantime... do you know which version/date created the saved game? 
> And could you email (directly to me at br...@ma...)  the saved > game?

It was saved with this version; however, I'm no longer entirely sure 
that I've got the pertinent changes.  Running cvs update -AdP should 
bring my copy of the code fully up-to-date, yes?  Only when I ran it, 
it didn't seem to do much, and Project Builder seemed to think there 
weren't any changes when I built the thing.

I'll email you the save in a separate email.

> Some of the places in AM that I think are prime targets involve:
>
> 	* Resources
> 	* Input Handling
> 	* Main Event Loop (May be related to Input Handling)
> 	* Game Related GUI (File dialogs, ok to quit?, preferences)
> 	* Preferences
>
> I admit Preferences is less about platform specifics and more for 
> overhauling how the game uses preferences internally and how the game 
> handles preferences. I've been trying to think of a system that allows 
> for future preferences growth, while allowing conversion of older 
> preference formats. And which allows growth without necessarily 
> requiring a great deal of work between changes either.
>

My vote would be stuff (somewhat) related to input handling first, then 
network, then resources.  To be a little more specific: I think that, 
while it made good sense back in the day, relying *entirely* on the 
inputs for films & net games isn't the best idea in the world (if you 
disagree, please convince me! :-) ).  For the second, I tried clicking 
"Gather" and it just didn't do anything: I presume networking is 
currently inoperable, and thus you have disabled even trying it.  It 
would be great to see networking working in AM, especially since it's 
now working so well in A1.  For the third, well, it would be nice to 
have all the resource stuff out of the way.  It's obsolete even on the 
Mac side, after all! ;-)

Anyway, doing a fantastic job, Br'fin.  Keep it up!

Timothy Collett

In my walks, every man I meet is my superior in some way, and in that I 
learn from him.
-- Ralph Waldo Emerson

Re: [Alephmodular-devel] Display Abstraction Landed?

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

On Monday, October 6, 2003, at 11:06  PM, Alexander Strange wrote:

>
> On Oct 6, 2003, at 10:39 PM, Br'fin wrote:
>
>> I should still update the documentation. But yes, I should be done 
>> with the abstraction for the time being. (More will need to be done 
>> when new graphic features are added.)
>
> I think the next step would be 3D graphics abstraction (including 
> possibly the vis-tree and poly-sorting code; A1 split those into C++ 
> classes).

Since I'm unfamiliar with that code, I do need to ask 'What does 
abstracting the 3D Graphics do for us?' In the case of files, it was to 
abstract us from Mac file conventions and handling. (Resources are the 
main aspect left there.) In the case of the display abstraction is was 
to forcefully drag apart all the Mac-based drawing code from the 
Marathon code that used it. (For instance, the terminal was a really 
nasty piece of entangled code.)

Some of the places in AM that I think are prime targets involve:

	* Resources
	* Input Handling
	* Main Event Loop (May be related to Input Handling)
	* Game Related GUI (File dialogs, ok to quit?, preferences)
	* Preferences

I admit Preferences is less about platform specifics and more for 
overhauling how the game uses preferences internally and how the game 
handles preferences. I've been trying to think of a system that allows 
for future preferences growth, while allowing conversion of older 
preference formats. And which allows growth without necessarily 
requiring a great deal of work between changes either.

I spoke with Woody and another with regard to preferences in general 
and A1 as well. I tried to present a writeup under 
alephModular/documents/technical/CPreferences.h

I still haven't decided on a direction, though have been tempted to try 
and work on the Carbon implementation of the display abstraction. Right 
now I'm just kvetching at sf.net's CVS systems which seem to be 
unavailable.

-Jeremy Parsons

Re: [Alephmodular-devel] Display Abstraction Landed?

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

On Oct 6, 2003, at 10:39 PM, Br'fin wrote:

> I should still update the documentation. But yes, I should be done 
> with the abstraction for the time being. (More will need to be done 
> when new graphic features are added.)

I think the next step would be 3D graphics abstraction (including 
possibly the vis-tree and poly-sorting code; A1 split those into C++ 
classes).

Re: [Alephmodular-devel] Display Abstraction Landed?

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

I should still update the documentation. But yes, I should be done with 
the abstraction for the time being. (More will need to be done when new 
graphic features are added.)

Mmm, I better go check saved games to see if I can find anything. In 
the meantime... do you know which version/date created the saved game? 
And could you email (directly to me at br...@ma...)  the saved game?

-Jeremy Parsons

On Monday, October 6, 2003, at 02:51  PM, Timothy Collett wrote:

>> Log Message:
>> Landing Display Abstraction
>>
>
> Greetings.
> Does this mean that you've finished doing Display Abstraction?  Three 
> cheers for Br'fin!  It looks like you've been doing a *lot* of updates 
> over the past few weeks.
>
> I built from your CVS updates, and it seems to work, though it crashed 
> when trying to resurrect me from a save, rather than from level-start.
> Do you want anything tested?
>
> Timothy Collett

[Alephmodular-devel] Display Abstraction Landed?

[Timothy C. <da...@ma...>]

> Log Message:
> Landing Display Abstraction
>

Greetings.
Does this mean that you've finished doing Display Abstraction?  Three 
cheers for Br'fin!  It looks like you've been doing a *lot* of updates 
over the past few weeks.

I built from your CVS updates, and it seems to work, though it crashed 
when trying to resurrect me from a save, rather than from level-start.
Do you want anything tested?

Timothy Collett

"To confine our attention to terrestrial matters would be to limit the 
human spirit."
  -- Stephen Hawking 

[Alephmodular-devel] Display abstraction landed

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

I know, I'm terrible and wasn't quite sure what do do with the 
documentation for the display abstraction. But code-wise I felt it was 
time to bring the display abstraction back into the main AlephModular 
trunk.

Some minor conflicts, primarily due to the improvements to AStreams. 
But everything appears to be working well. Especially mixing the 
updated and fast software rendering with the fixes for sprites 
disappearing when too close to you.

I admit I'm not sure where I should be focusing next ;)

-Jeremy Parsons

[Alephmodular-devel] Display Abstraction whoops - Color tables

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

Heh. I ended up finding one things as I was polishing up the CDisplay 
and friends.

The Color tables are in a quasi state. (The fading code was implemented 
using cscluts.h/.cpp before CColorTable really made itself necessary.)  
This leaves us with two color table models before we get to the 
platform native methods. And of course some of the functions in cscluts 
create model color_tables from specific platform ones...

At any rate, I need to plow through the code and standardize the color 
table usage all around CColorTable so things are consistent.

cscluts.h will hang in there for now, but mainly because it's the only 
reasonable place to put some of the conversion functions between color 
resources and CColorTables. The cscluts.h view of rgb_color and 
color_table will be on their way out.

-Jeremy Parsons

[Alephmodular-devel] Status of Drawing Abstraction

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

Well, with the tweaks to the last couple of things, I believe that I've 
almost completed the base requirements of the Drawing Abstraction. Now 
there's a couple things I'd like to get done before I try and merge 
this all into the main trunk.

One is a matter of documentation. I need to reflect the current 
structure into the design documents for the abstraction. So much of the 
more recent stuff just sort of came together in one way or another and 
I need to note it more clearly.

The other issue is one of eyes. People willing to browse through the 
marathon2/Display directory and note things in the API or general C/C++ 
structure of things that are questionable. Or to question how certain 
elements were implemented in terms of CDisplay is welcome as well.

I'm a little worried about the dependancy of various headers. And I 
have no idea how to properly separate them out, or arrange them for 
efficiency. It was just my impression that changing some files should 
not require recompiling preferences.cpp.

Should there be a specific set of headers necessary? As in you need to 
include CDisplay to use that and then CBuffer and CDContext if you want 
to work with the buffer and then use its drawing commands. Or should it 
be a single master include that basically grabs the includer everything 
there is to access the entirely of the drawing abstraction?

-Jeremy Parsons

[Alephmodular-devel] Display Progress Update

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

Good news.

I finally got around to decoding PicHandles into CPictureBitmaps.

This means that the majority of Drawing Operations themselves for the 
game have been abstracted.

The menus, the HUD, the terminals, the chapter screens... they all go 
through the display abstraction. This is cool. 
overhead_map_macintosh.cpp can be folded into overhead_map.cpp, it like 
some of the other code, now only has Quickdraw calls in the debugging 
routines. And really, those could be dealt with it short order if 
necessary.

At this point the only drawing operations that aren't covered are: 
Showing before game quicktime movies. And Darkening the world window.

I've done an #ifdef mac on the movie code. It's a potentially complex 
element, and it's fairly self contained. On the other hand, it's not 
exactly a major feature of the engine either.

darken_world_window on the other hand, projects a 50% gray checkerboard 
pattern of black dots over the view area. I don't know of a great way 
to denote patterns. And am generally inclined to just stuff it into a 
drawing function

class CDContext {
	public:
		darken_rectangle(const CRectangle& bounds);
}

And let the given context due something appropriate. For software it 
can adapt the existing MacOS Code. For SDL, we just grab something from 
A1. And for OpenGL we get the option of doing a pattern over it, or 
doing an actual 50% gray dimming agent. ( Bonus points if the openGL 
darkener also blurs the screen, just to be cute :) )


My next focus is apt to be around mousing.

Mostly in the form of mouse/gui interactions. For instance, the logic 
around defaulting the mouse to hidden and only showing it in functions 
that actually do a CDIsplay::get_instance()->require_mouse() call. 
Dealing with location of mouse and mouse events/tracking will wait for 
another time. (Though thoughts on how events should be handled in AM is 
certainly welcome)

-Jeremy Parsons

[Alephmodular-devel] PicHandle->CBitmap double whammy

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

I've begun looking into what I need to do manage getting a picture 
resource and passing it around internally as a bitmap.

The starting point seems to be around the get_picture_resource_from* 
routines in images.cpp. We would need to muck with these so they are 
fetching the resource and dumping it into a CBitmap instead of 
returning it immediately. (I'm not going to worry about images.cpp 
being neutral or mac-like yet. AM has no platform neutral way of 
dealing directly with resources yet.)

My choices for that seem to involve
a) setting up a hollow pixmap, a temporary gworld and doing a draw 
picture followed by copybits.
b) importing the picture decoding from SDL and running with that

And because of the setup of things, I think going with the SDL picture 
decoder might be simpler for dovetailing with a CBitmap.


On the other side of things, CBitmap itself still has no place for a 
color table. (From a couple things in the pass, this might be advised 
in certain locations) and the current carbonized draw bitmap routine 
appears to be expecting all CBitmaps to be 8 bits per pixel with a 
color table. (Prepared before hand and setup before the bitmap is used)

I need to flesh out both sides of this equation. Hsm.

-Jeremy Parsons

Re: [Alephmodular-devel] Progress Update

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

Mmm, a good set of questions. And I admit that my progress updates so 
far haven't quite done a good job of separating the notable code 
changes with the minor ones. Then again I admit I haven't been thinking 
about public release, just sort of accepting the current state of 
things and muddling along in the code on my own. :)

For the recent stuff I suppose you could say:

	Work continues on the display abstraction branch of the project. 
Recent conquers
	include fonts, handling text and drawing. overhead_map_macintosh.cpp 
could be
	folded into overhead_map.cpp as it no longer has Mac-specific code, 
and HUD and
	terminals are on their last Mac legs. Next up: Working Picture 
resources into
	CBitmaps to put a stake through them.

We're doing behind the scenes geeky stuff, so we may as well mention 
it. I suspect it is really hard to appeal to the basic user without 
something actually on hand. My current builds hardly look any better 
than that last 0.3+ version I posted which first got Display 
Abstraction to its vindicating milestone: Fullspeed Hi-res.

-Jeremy Parsons

On Tuesday, September 23, 2003, at 03:14  AM, Matt Lee wrote:

> Jeremy Parsons wrote:
>>  Wow, that was a bit of work.
>
> Hey, I just wanted to say a couple things about this...
>
> First, I think it is great that you are still working on AM, and I 
> genuinely enjoy reading your progress updates. Second, I'm still here 
> and I did recently do some minor updates to the Web site.
>
> That said, I'm at a bit of a loss as to how to represent this progress 
> in the form of news blurbs on the site. I don't want visitors to see 
> that there haven't been any updates in months and conclude the project 
> is dead, since it obviously isn't. Yet the actual activity is pretty 
> "behind-the-scenes" and while interesting technically, probably 
> wouldn't attract attention from the average user.
>
> Should we assume for now that AM is mostly of interest to developers 
> and go ahead and post "Jeremy abstracted the Rect object into 
> CRectangle"? Or should we dumb it down a bit and just say "Work 
> continues with abstracting Macintosh-specific code into more general, 
> portable and modern code. More to come."?
>
> The once and future AM webmaster,
> Zebe.
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Alephmodular-devel mailing list
> Ale...@li...
> https://lists.sourceforge.net/lists/listinfo/alephmodular-devel
>

Re: [Alephmodular-devel] Progress Update

[Matt L. <ze...@ze...>]

Jeremy Parsons wrote:
>  Wow, that was a bit of work.

Hey, I just wanted to say a couple things about this...

First, I think it is great that you are still working on AM, and I 
genuinely enjoy reading your progress updates. Second, I'm still here 
and I did recently do some minor updates to the Web site.

That said, I'm at a bit of a loss as to how to represent this 
progress in the form of news blurbs on the site. I don't want 
visitors to see that there haven't been any updates in months and 
conclude the project is dead, since it obviously isn't. Yet the 
actual activity is pretty "behind-the-scenes" and while interesting 
technically, probably wouldn't attract attention from the average 
user.

Should we assume for now that AM is mostly of interest to developers 
and go ahead and post "Jeremy abstracted the Rect object into 
CRectangle"? Or should we dumb it down a bit and just say "Work 
continues with abstracting Macintosh-specific code into more general, 
portable and modern code. More to come."?

The once and future AM webmaster,
Zebe.

[Alephmodular-devel] Progress Update

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

Wow, that was a bit of work.

I've managed to wrangle with the fonts. I think I won. All the text 
drawing is now being handled through the CBuffer::Context (drawing 
contexts). As are many of the calls to paint/eraserect and such.

Much Rectangle math is also being handled with CRectangle instead of 
the Mac native Rect.

While I have some issues to deal with still, such as somehow massaging 
a PictureResource suitable for DrawPicture into a CBitmap suitable for 
throwing around the drawing routines. (My Next big hurdle) things feel 
like they are coming along well.

For instance, I believe I am in a good position to move all of the 
remaining code out of overhead_map_macintosh.cpp just because it is no 
longer Mac biased at all. Some of the other areas of major contention, 
such as computer_interface.cpp and game_window.cpp (the HUD) are also 
falling into line (They use DrawPicture, but the rest of the code in 
those areas are now 'neutral')

Still got cursors to deal with, and I have no good way to denote the 
'dim game window' effect used when the game pauses. (Where it fills the 
game window, but not the HUD, with a 50% black dithered pattern, thus 
darkening the world window)

-Jeremy Parsons

[Alephmodular-devel] Code to make you go hmmm....

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

	case _information_group:
		terminal_data->phase=3D NONE;
		if(dynamic_world->player_count>1)
		{
			/* Use what the server told us */
			terminal_data->maximum_line=3D =
current_group->maximum_line_count;
		} else {
			/* Calculate this for ourselves. */
			int16 width=3D 640; // =95=95=95 sync (Must =
guarantee 100 high res!)
=09
			width-=3D 2*(72-BORDER_INSET); /* 1 inch in from =
each side */			=09
			terminal_data->maximum_line=3D=20
count_total_lines(get_text_base(terminal_text),
				width, current_group->start_index,
				=
current_group->start_index+current_group->length);
		}
		break;

Something I found in computer_interface.cpp that just made me go hmmm.

For people running A1.. just how well do terminals work in netgames,=20
especially if you don't have a local copy of the map in your A1=20
directories?

-Jeremy Parsons=