sc2-devel — For developers

Re: [Sc2-devel] Look Ma, no compiler warnings!

[Serge v. d. B. <sv...@st...>]

On Sat, 28 Dec 2002, Serge van den Boom wrote:
> On Sun, 22 Dec 2002, Steven Barker wrote:
> > On Sun, Dec 22, 2002 at 08:14:29PM +0100, Serge van den Boom wrote:
> > > Well, they might eliminate some warnings (not all though), but I think
> > > these warnings warrant some closer attention.
> > I agree with your caution.  I'll try to justify my patches as best I can.
> > I'm also curious about other compiler warnings you mention.  Those four
> > patches fix all the ones I see on my system (tested with both gcc 2.95.4
> > and 3.2.2pre2).
> They're mainly about negative shifts. We've actually got a patch lying here
> ready for that, but it will change the save game format, so we'll keep that
> for later, and apply it together with a number of other changes that affect
> the save game format later.
Correction: this bug has already been patched, without the save game format
being changed. It will however be handled in a different way eventually.

Serge

Re: [Sc2-devel] Look Ma, no compiler warnings!

[Serge v. d. B. <sv...@st...>]

On Sun, 22 Dec 2002, Steven Barker wrote:
> On Sun, Dec 22, 2002 at 08:14:29PM +0100, Serge van den Boom wrote:
> > Well, they might eliminate some warnings (not all though), but I think
> > these warnings warrant some closer attention.
> I agree with your caution.  I'll try to justify my patches as best I can.
> I'm also curious about other compiler warnings you mention.  Those four
> patches fix all the ones I see on my system (tested with both gcc 2.95.4
> and 3.2.2pre2).
They're mainly about negative shifts. We've actually got a patch lying here
ready for that, but it will change the save game format, so we'll keep that
for later, and apply it together with a number of other changes that affect
the save game format later.

> > Why expand the size of MEM_HANDLE? Is that size actually needed?
> > Wouldn't a few type casts be better? I'd like to hear your rationale.
> Well, the code in question looks pretty shady in many ways.  The compiler
> warning it generated without my patch was (paraphrased) "cast from pointer
> to integer of a different size".  It seems that in several places, pointers
> (typically char *s) get cast to MEM_HANDLEs.  To be truely correct for all
> archetectures something better will have to be done to rework that code, but
> my fix will make it a lot saner for 32 bit systems in the mean time.  If you
> think that covering up the symptom of this issue is worse than leaving it,
> don't apply the patch.
Pointers cast to integers? I haven't noticed those. That doesn't sound like
a good idea in itself.
I agree with your statement about covering up symptoms, so I'll won't apply
the patch.

> > Putting an external function declaration inside a function is not good
> > practice. The right solution would be to include the correct .h file.
> I think the function the declaration is inside of is unused (the comments
> claim it's "unimplemented").  The warning was for a redeclaration of the
> function, as GetUNICODEKey is defined elsewhere in the file.  This is
> definately the right fix for it, unless we want to remove the
> "unimplemented" functions entirely.
'unimplemented' meant what it says. I don't know why that remark is still
there, maybe it's not completely implemented yet. Anyhow, the input code is
being revised, this should be taken care of in time.
For now, I'll leave it as it is.

> > Your WRAP_VAL patch is downright wrong. (take a look at the actual
> > definition of the macro).
> I did.  Its basically a mod operator?  Its common cases are equivelant to
> (((COUNT)(v)) % (d)), right?
Actually, % returns a negative value when the first argument is negative.
It's something every programming language does differently. But I understand
what you mean.

> (I assume it's not ever used where v < -d or v >= 2*d.)
Certainly that should be checked instead of assumed.

> In any case, I'm pretty sure that WRAP_VAL is the wrong thing to use in
> this case.  The warning the compiler gave was something like "comparison is
> always false due to data type", refering to the fact that one of the
> comparisons in the expansion of WRAP_VAL(pMS->CurState, EMPTY_SLOT + 3),
> namely "pMS->CurState < 0", is always false, since  CurState's type (COUNT
> is unsigned).  The other two possible result values are pMS->CurState and
> pMS->CurState - (EMPTY_SLOT + 3), which then get compared to PLANET_LANDER
> (which has the value 0).  This whole mess has the same effect as the code I
> supstituted, testing against pMS-CurState against PLANET_LANDER (0) and
> EMPTY_SLOT + 3 directly.
There's a reason for using defines for constants. (If this is not evident to
you, you better ask in some C or general programming newsgroup; I'm not going
to spend time on this). Throwing them out is not acceptable.
Using something like WRAP_VAL makes perfect sense; this macro is meant to
apply wrap-around on a value, and that's exactly what it's doing here.

> It's also a lot easier to understand, since those are precisely the two
> states for which DisplayLanders should be called (when a new lander was
> purchased, and when one was sold, respectively).
I disagree. WRAP_VAL handles wrap-around. Once you know this, the code is
much easier to parse for a human.


Greetings,

Serge

Re: [Sc2-devel] Patch to fix Melnorme sale of life data text...

[TD <td...@pa...>]

I actually submitted a fix for the Melnorme ogg repeating issue (plus
another misplaced ogg in that txt file) and text disappearing at the
bottom of the screen a while ago but no one ever commited them to
the CVS :-\

----- Original Message -----
From: <ms...@mo...>
To: <sc2...@li...>
Sent: Friday, December 27, 2002 11:44 PM
Subject: Re: [Sc2-devel] Patch to fix Melnorme sale of life data text...


> On Fri, Dec 27, 2002 at 03:47:17AM -0500, ms...@mo...
wrote:
> > The following patch fixes a bug in the TODO list
> > - Selling bio data gives an incomplete message: 'The 1000' [nothing].
> >
> > ... when selling life data to the melnorme merchants.
>
>   While reading father into the TODO list I noticed that this item is
> fixed by the above patch as well:
> ---
>   - Melnorme conversation Will repeat the same sentence 3 times.
>     (because of numbers to be inserted).
> ---
>
>   The following [untested] patch fixes the rainbow problem.  Based on what
I
> see from the content file the Melnorme would say three sentences but the
> second two would have been incorrect for the text.  I see no reason this
> patch shouldn't also be applied...
>
> Index: ./content/comm/melnorm/melnorm.txt
> ===================================================================
> RCS file: /cvsroot/sc2/sc2/content/comm/melnorm/melnorm.txt,v
> retrieving revision 1.8
> diff -u -p -r1.8 melnorm.txt
> --- ./content/comm/melnorm/melnorm.txt 17 Oct 2002 17:23:20 -0000 1.8
> +++ ./content/comm/melnorm/melnorm.txt 27 Dec 2002 10:44:09 -0000
> @@ -530,11 +530,11 @@ I wish to sell you Rainbow world locatio
>  #(SOLD_RAINBOW_LOCATIONS1) melno075.ogg
>  Your ship's log indicates that you discovered the whereabouts of
>
> -#(SOLD_RAINBOW_LOCATIONS2) melno076.ogg
> +#(SOLD_RAINBOW_LOCATIONS2)
>   of the Rainbow worlds which so fascinate us.
>  In exchange, we will give you
>
> -#(SOLD_RAINBOW_LOCATIONS3) melno076.ogg
> +#(SOLD_RAINBOW_LOCATIONS3)
>   Credits.
>
>  #(sell_precursor_find)
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Sc2-devel mailing list
> Sc2...@li...
> https://lists.sourceforge.net/lists/listinfo/sc2-devel
>

[Sc2-devel] TODO list annotation...

[<ms...@mo...>]

  I hear that a number of things are being worked on from references on the
irc channel, but it's hard to figure out who is doing what and how extensive
their changes are expected to be.  

  ... is there somewhere else online that a list of things currently under 
development is maintained?

  So I was wondering if the TODO list could be annotated with which items are
actively being worked on, or if maybe a 'PENDING' file could be added... so 
people wandering in could see which TODO items have no one working on them.

    Thanks,
      Mike

Re: [Sc2-devel] Patch to fix Melnorme sale of life data text...

[<ms...@mo...>]

On Fri, Dec 27, 2002 at 03:47:17AM -0500, ms...@mo... wrote:
> The following patch fixes a bug in the TODO list
> - Selling bio data gives an incomplete message: 'The 1000' [nothing].
> 
> ... when selling life data to the melnorme merchants.

  While reading father into the TODO list I noticed that this item is
fixed by the above patch as well:
---
  - Melnorme conversation Will repeat the same sentence 3 times.
    (because of numbers to be inserted).
---

  The following [untested] patch fixes the rainbow problem.  Based on what I
see from the content file the Melnorme would say three sentences but the
second two would have been incorrect for the text.  I see no reason this
patch shouldn't also be applied...

Index: ./content/comm/melnorm/melnorm.txt
===================================================================
RCS file: /cvsroot/sc2/sc2/content/comm/melnorm/melnorm.txt,v
retrieving revision 1.8
diff -u -p -r1.8 melnorm.txt
--- ./content/comm/melnorm/melnorm.txt	17 Oct 2002 17:23:20 -0000	1.8
+++ ./content/comm/melnorm/melnorm.txt	27 Dec 2002 10:44:09 -0000
@@ -530,11 +530,11 @@ I wish to sell you Rainbow world locatio
 #(SOLD_RAINBOW_LOCATIONS1) melno075.ogg
 Your ship's log indicates that you discovered the whereabouts of 
 
-#(SOLD_RAINBOW_LOCATIONS2)	melno076.ogg
+#(SOLD_RAINBOW_LOCATIONS2)
  of the Rainbow worlds which so fascinate us.
 In exchange, we will give you 
 
-#(SOLD_RAINBOW_LOCATIONS3)	melno076.ogg
+#(SOLD_RAINBOW_LOCATIONS3)
  Credits.
 	     
 #(sell_precursor_find)

[Sc2-devel] Patch for yehat and ilwrath subtitle truncation problem.

[<ms...@mo...>]

TODO item:
- Subtitles in conversation will sometimes hang off the end (e.g. the
  Ilwrath reacting to the Ur-Quan Drone) or not appear at all (e.g. the
  Yehat).


  This appears to happen for races whose subtitle text is setup to begin 
somewhere other than the top center of the display window.  The code
that handles display of the messages will truncate the text if a line
is too long to be displayed.  If the text placement is moved to the top
center this problem goes away for the two listed races...

  I did not do a code trace of this bug to read the text display code...

  I would recommend setting all races to display in standard position 
(left, top, center)... then check the longest text line from each of their
message files to be sure they are not truncated due to the font in use
by that race.

  I'd be happy to produce a patch to switch the other races to standard
placement and check each race's longest line... but only if I hear back 
that a patch to that effect will be accepted...

    Later,
      Mike
  

...This may be related to the TODO item:
- subtitles may go past the bottom boundary


  The following is a grep which will allow quick reference of the different
races text display configuration... at least the following races don't use 
the 'normal' top of the display window to begin text:
  comandr, rebel, starbas, zoqfot, yehat, vux.

grep -A 1 -E '(AlienTextTemplate)|(TEXT_X_OFFS)' ./src/sc2code/comm/*/*.c
====
./src/sc2code/comm/ilwrath/ilwrathc.c:
  ilwrath_desc.AlienTextTemplate.baseline.x =
                  TEXT_X_OFFS + (SIS_TEXT_WIDTH >> 1);
  ilwrath_desc.AlienTextTemplate.baseline.y = 64;
  ilwrath_desc.AlienTextTemplate.align = ALIGN_CENTER;
  ilwrath_desc.AlienTextWidth = SIS_TEXT_WIDTH - 16;
====
./src/sc2code/comm/yehat/yehatc.c:
  yehat_desc.AlienTextTemplate.baseline.x = SIS_SCREEN_WIDTH * 2 / 3;
  yehat_desc.AlienTextTemplate.baseline.y = 107 * 2 / 3;
  yehat_desc.AlienTextTemplate.align = ALIGN_CENTER;
  yehat_desc.AlienTextWidth = (SIS_TEXT_WIDTH - 16) * 2 / 3;
====

  Here is a sample text that is truncated by the cvs mainline which is fixed
with this patch... 'Approached Earth,' is lost without the patch.

content/comm/ilwrath/ilwrath.txt
=======
#(SEND_MESSAGE) ilwra022.ogg
By The Fetid Breath Of The Dark Twin, Kazon!
A Hu-Man In An Alien Starship... How Fascinating!
When I Intercepted That Ur-Quan Drone, And Learned That An Unidentified Starship Had Approached Earth,
I Never Expected To Find Such A Remarkable Vehicle In The Hands Of A Hu-Man.
Hu-Mans Are Prey Animals - Weak And Helpless-
But Here Is A Hu-Man In An Armed Starship!
And Therefore In Direct Violation Of The Oath Of Fealty.
I Am Sure Our Masters, The Ur-Quan, Will Punish Earth Most Severely For This Treachery....
When I Present Them With The Twisted Wreckage Of Your Ship And Your Many Charred Corpses.
=======

Index: ./src/sc2code/comm/yehat/yehatc.c
===================================================================
RCS file: /cvsroot/sc2/sc2/src/sc2code/comm/yehat/yehatc.c,v
retrieving revision 1.2
diff -u -p -r1.2 yehatc.c
--- ./src/sc2code/comm/yehat/yehatc.c	27 Sep 2002 22:38:19 -0000	1.2
+++ ./src/sc2code/comm/yehat/yehatc.c	27 Dec 2002 10:27:48 -0000
@@ -646,10 +646,10 @@ init_yehat_comm (void)
 	yehat_desc.init_encounter_func = Intro;
 	yehat_desc.uninit_encounter_func = uninit_yehat;
 
-	yehat_desc.AlienTextTemplate.baseline.x = SIS_SCREEN_WIDTH * 2 / 3;
-	yehat_desc.AlienTextTemplate.baseline.y = 107 * 2 / 3;
+	yehat_desc.AlienTextTemplate.baseline.x = TEXT_X_OFFS + (SIS_TEXT_WIDTH >> 1);
+	yehat_desc.AlienTextTemplate.baseline.y = 0;
 	yehat_desc.AlienTextTemplate.align = ALIGN_CENTER;
-	yehat_desc.AlienTextWidth = (SIS_TEXT_WIDTH - 16) * 2 / 3;
+	yehat_desc.AlienTextWidth = SIS_TEXT_WIDTH - 16;
 
 	if (LOBYTE (GLOBAL (CurrentActivity)) != WON_LAST_BATTLE)
 	{
Index: ./src/sc2code/comm/ilwrath/ilwrathc.c
===================================================================
RCS file: /cvsroot/sc2/sc2/src/sc2code/comm/ilwrath/ilwrathc.c,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 ilwrathc.c
--- ./src/sc2code/comm/ilwrath/ilwrathc.c	3 Sep 2002 00:57:52 -0000	1.1.1.1
+++ ./src/sc2code/comm/ilwrath/ilwrathc.c	27 Dec 2002 10:27:49 -0000
@@ -603,7 +603,7 @@ init_ilwrath_comm (void)
 
 	ilwrath_desc.AlienTextTemplate.baseline.x =
 			TEXT_X_OFFS + (SIS_TEXT_WIDTH >> 1);
-	ilwrath_desc.AlienTextTemplate.baseline.y = 64;
+	ilwrath_desc.AlienTextTemplate.baseline.y = 0;
 	ilwrath_desc.AlienTextTemplate.align = ALIGN_CENTER;
 	ilwrath_desc.AlienTextWidth = SIS_TEXT_WIDTH - 16;
 

[Sc2-devel] Patch to fix Melnorme sale of life data text...

[<ms...@mo...>]

The following patch fixes a bug in the TODO list
- Selling bio data gives an incomplete message: 'The 1000' [nothing].

... when selling life data to the melnorme merchants.


  A minor correction on this bug: 
- the audio plays three times before the inventory decrement happens.
- the text really does appear if you wait but in three separate chunks, 
  one per speech repetition.


  The problem is the content file says that the three text chunks are split
in three audio pieces (and lists the same audio file three times) when in fact 
the audio is really in one chunk in a single file... if the audio track file 
name is omitted in the content file for the additional chunks of text 
everything works out great.

  There are probably several other places this bug occurs, I can see another
one in the rainbow worlds sale handling... 


  The DoSell function (src/sc2code/comm/melnorm/melnorm.c), feeds several
chunks into the A/V output system:
===
    NPCPhrase (SOLD_LIFE_DATA1);
    NPCPhrase (-(int)GLOBAL_SIS (TotalBioMass));
    NPCPhrase (SOLD_LIFE_DATA2);
    NPCPhrase (-(int)added_credit);
    NPCPhrase (SOLD_LIFE_DATA3);
===

  The NPCPhrase function (src/sc2code/commglue.c), does a lookup function on
it's argument to decide what audio and what text to feed into the A/V system.
It calls SpliceTrack with a filename for the audio and a text string to 
display with the audio.  This information is looked up from the race content
files (in this case ./content/comm/melnorm/melnorm.txt).

  It turns out the code in SpliceTrack (src/sc2code/libs/sound/*/trackplayer.c)
is designed for three types of input: 
- Audio track, with no text.
- Text, with no audio.
- Audio with Text.

... so it shouldn't be given a audio track name when none actually exists.


old behavior:
=========
  The X
  units of biological data we downloaded from your computer earn you Y
  Credits.
==========

new behavior:
==========
  The X units of biological data we downloaded from your computer earn
you Y Credits.
==========

Index: ./content/comm/melnorm/melnorm.txt
===================================================================
RCS file: /cvsroot/sc2/sc2/content/comm/melnorm/melnorm.txt,v
retrieving revision 1.8
diff -u -p -r1.8 melnorm.txt
--- ./content/comm/melnorm/melnorm.txt	17 Oct 2002 17:23:20 -0000	1.8
+++ ./content/comm/melnorm/melnorm.txt	27 Dec 2002 08:36:44 -0000
@@ -518,10 +518,10 @@ I have some data on alien lifeforms.
 #(SOLD_LIFE_DATA1) melno074.ogg
 The 
 
-#(SOLD_LIFE_DATA2) melno074.ogg
+#(SOLD_LIFE_DATA2)
  units of biological data we downloaded from your ship earn you 
 
-#(SOLD_LIFE_DATA3) melno074.ogg
+#(SOLD_LIFE_DATA3)
  Credits.
 
 #(sell_rainbow_locations)

[Sc2-devel] Re: Mac OS X status

[Mr. K. <mk...@ma...>]

I have a working PB build, but I don't have any of the linker symbols 
crap hunted down.  Interestingly enough, SDL has in it a mechanism for 
building a Mac OS X framework, then allowing a coder to create a SDL 
Application the same way one could make a "Cocoa Application" or 
"Carbon Bundle," so that solves quite a few problems.

I would like to help out on the pb side (I know much about the linker 
through nightmarish experiences and working with a poster's certain 
other sourceforge project: fink).  Where can I download some working 
source files?

I am a graphic artist as well as a programmer, and I could make a nice 
icns for uqm/sc2 in photoshop, assuming we get to the .app stage.  If 
such a service would be helpful, feel free to bounce ideas about what 
the icon would look like.

Regards,
Andrew Hoyt

Mr. Kiwi -- mkiwi <-- in transition between hacker s/n and real name :)

[Sc2-devel] For anyone experiencing hangs when playing UQM

[Geoffrey H. <tcp...@sn...>]

I have added a patch to the most recent CVS which should help people
locate deadlocks in the code.

I am aware that several Mac users have een having these issues.
What you need to do, is update to the latest CVS, then in
libs/threads/thrcommon.c replace:
#undef DEBUG_SEM_DEADLOCK
with
#define DEBUG_SEM_DEADLOCK
(around linne 38)

and recompile.

this will enable the deadlock debugging code, which will spit out a
message every time a Semaphore set takes longer than 60 seconds.

There are plenty of cases where this is valid (if you stay inn
orbit/station/melee/conversation for very long, you'll get these, and
that is okay), but when you hit a deadlock, within 60 seconds, you should
see a message telling you what is goinng on.

Hopefully these messages can help us track down the deadlock condition.

If you don't want  to actually debug the code, sending the messages to
this list may help one of us track it down.

Thanks,
   Phrac
-- 
  Geoffrey Hausheer
  XXXXXXXXXXXXXXXXXXXXX

Re: [Sc2-devel] Mac OS X status

[Max H. <ma...@qu...>]

At 11:14 Uhr +1100 23.12.2002, Stuart Lamble wrote:
>Max Horn wrote:
>>  At 11:25 Uhr -0500 22.12.2002, Peter Berger wrote:
>>  >-Like everyone else, I found all the multiply defined symbols.  I
>>  >did some massive subst-ing, and sent the patch to MeepEep.
>>  >-I've gotten a working uqm binary by building from the command line
>>  >against the -l versions of the SDL libraries.
>>  >-My attempts so far to get a projectbuilder app have been met with
>>  >failure at the link phase -- but part of that might be my
>>  >inexperience with PB.
>>  >
>>  >I think a great stretch goal for 0.2 would be to have a working PB
>>  >file included with the release.
>>
>>  Personally,  I see no value in a PB file at all <shrug>. I guess it's
>>  really up to personal preference, whether you like to use PB or not
>>  (for me it's just too damn outright sluggish).
>
>The ultimate value of having a PB build is that it works nicely to
>produce a full bundle of the application, whereas with a build using
>gcc, you have to do that manually.

Well, in the case of Exult and ScummVM, I simply have a makefile 
target to do that. Assembling a bundle is really a trivial thing to 
do.



Cheers,

Max
-- 
-----------------------------------------------
Max Horn
Software Developer

Re: [Sc2-devel] Mac OS X status

[<sj...@de...>]

Max Horn wrote:
> At 11:25 Uhr -0500 22.12.2002, Peter Berger wrote:
> >-Like everyone else, I found all the multiply defined symbols.  I 
> >did some massive subst-ing, and sent the patch to MeepEep.
> >-I've gotten a working uqm binary by building from the command line 
> >against the -l versions of the SDL libraries.
> >-My attempts so far to get a projectbuilder app have been met with 
> >failure at the link phase -- but part of that might be my 
> >inexperience with PB.
> >
> >I think a great stretch goal for 0.2 would be to have a working PB 
> >file included with the release.
> 
> Personally,  I see no value in a PB file at all <shrug>. I guess it's 
> really up to personal preference, whether you like to use PB or not 
> (for me it's just too damn outright sluggish).

The ultimate value of having a PB build is that it works nicely to
produce a full bundle of the application, whereas with a build using
gcc, you have to do that manually. The way I'd like to see it is
SC2 being released as a .app (tarred and gzipped, or maybe a .dmg --
which way doesn't really matter), holding the binary, the contents,
etc., etc., etc.

That would probably involve a fair amount of code patching, though.

There's also the advantage that if somebody wants to get involved,
but they're not familiar with the Unix command line, they don't have
to learn the arcana of tcsh et al.

*shrugs* I'm happy with the Unix command line, so I'll be not worrying
too much about getting it working with PB. It's kinda like "I'll worry
about that when everything else is working properly." :)

Re: [Sc2-devel] Look Ma, no compiler warnings!

[<st...@bl...>]

On Sun, Dec 22, 2002 at 08:14:29PM +0100, Serge van den Boom wrote:

> Well, they might eliminate some warnings (not all though), but I think
> these warnings warrant some closer attention.

I agree with your caution.  I'll try to justify my patches as best I can.
I'm also curious about other compiler warnings you mention.  Those four
patches fix all the ones I see on my system (tested with both gcc 2.95.4
and 3.2.2pre2).

> Why expand the size of MEM_HANDLE? Is that size actually needed?
> Wouldn't a few type casts be better? I'd like to hear your rationale.

Well, the code in question looks pretty shady in many ways.  The compiler
warning it generated without my patch was (paraphrased) "cast from pointer
to integer of a different size".  It seems that in several places, pointers
(typically char *s) get cast to MEM_HANDLEs.  To be truely correct for all
archetectures something better will have to be done to rework that code, but
my fix will make it a lot saner for 32 bit systems in the mean time.  If you
think that covering up the symptom of this issue is worse than leaving it,
don't apply the patch.

> Putting an external function declaration inside a function is not good
> practice. The right solution would be to include the correct .h file.

I think the function the declaration is inside of is unused (the comments
claim it's "unimplemented").  The warning was for a redeclaration of the
function, as GetUNICODEKey is defined elsewhere in the file.  This is
definately the right fix for it, unless we want to remove the
"unimplemented" functions entirely.

> Your WRAP_VAL patch is downright wrong. (take a look at the actual
> definition of the macro).

I did.  Its basically a mod operator?  Its common cases are equivelant to
(((COUNT)(v)) % (d)), right?  (I assume it's not ever used where
v < -d or v >=3D 2*d.)

In any case, I'm pretty sure that WRAP_VAL is the wrong thing to use in
this case.  The warning the compiler gave was something like "comparison is
always false due to data type", refering to the fact that one of the
comparisons in the expansion of WRAP_VAL(pMS->CurState, EMPTY_SLOT + 3),
namely "pMS->CurState < 0", is always false, since  CurState's type (COUNT
is unsigned).  The other two possible result values are pMS->CurState and
pMS->CurState - (EMPTY_SLOT + 3), which then get compared to PLANET_LANDER
(which has the value 0).  This whole mess has the same effect as the code I
supstituted, testing against pMS-CurState against PLANET_LANDER (0) and
EMPTY_SLOT + 3 directly.

It's also a lot easier to understand, since those are precisely the two
states for which DisplayLanders should be called (when a new lander was
purchased, and when one was sold, respectively).

> The NumVisits patch is correct. SBYTE is good enough though. Applied in t=
hat
> form.

Ah, yes, I think I had it that way at one point.  I went back and forth a
few times.  SBYTE is just as good for the sizes of values we're dealing
with.  A bigger type might be better if we ever intend to change the game
to cover more situations than were in the original SC2, but I think that
it is both unlikely to happen any time soon and that it would require
major rewrites anyway to get rid of other similar limits.

--=20
Steven Barker                                      st...@bl...
  "Consider a spherical bear, in simple harmonic motion..."
  		-- Professor in the UCB physics department
Get my GnuPG public key at: http://www.blckknght.org/publickey.asc
Fingerprint: 272A 3EC8 52CE F22B F745  775E 5292 F743 EBD5 936B

Re: [Sc2-devel] Mac OS X status

[Max H. <ma...@qu...>]

At 11:25 Uhr -0500 22.12.2002, Peter Berger wrote:
>-Like everyone else, I found all the multiply defined symbols.  I 
>did some massive subst-ing, and sent the patch to MeepEep.
>-I've gotten a working uqm binary by building from the command line 
>against the -l versions of the SDL libraries.
>-My attempts so far to get a projectbuilder app have been met with 
>failure at the link phase -- but part of that might be my 
>inexperience with PB.
>
>I think a great stretch goal for 0.2 would be to have a working PB 
>file included with the release.

Personally,  I see no value in a PB file at all <shrug>. I guess it's 
really up to personal preference, whether you like to use PB or not 
(for me it's just too damn outright sluggish).


Max
-- 
-----------------------------------------------
Max Horn
Software Developer

Re: [Sc2-devel] Look Ma, no compiler warnings!

[Serge v. d. B. <sv...@st...>]

On Sun, 22 Dec 2002, Steven Barker wrote:
> I've made a few patches to various files to eliminate all the compilers
> warnings that the build was generating.  Patches for the changes are at
> http://www.blckknght.org/~steve/uqm/
Well, they might eliminate some warnings (not all though), but I think
these warnings warrant some closer attention.

Why expand the size of MEM_HANDLE? Is that size actually needed?
Wouldn't a few type casts be better? I'd like to hear your rationale.

Putting an external function declaration inside a function is not good
practice. The right solution would be to include the correct .h file.

Your WRAP_VAL patch is downright wrong. (take a look at the actual
definition of the macro).

The NumVisits patch is correct. SBYTE is good enough though. Applied in that
form.

Greetings,

Serge

[Sc2-devel] Mac OS X status

[Peter B. <pe...@tg...>]

-Like everyone else, I found all the multiply defined symbols.  I did 
some massive subst-ing, and sent the patch to MeepEep.
-I've gotten a working uqm binary by building from the command line 
against the -l versions of the SDL libraries.
-My attempts so far to get a projectbuilder app have been met with 
failure at the link phase -- but part of that might be my inexperience 
with PB.

I think a great stretch goal for 0.2 would be to have a working PB file 
included with the release.

-p

[Sc2-devel] Look Ma, no compiler warnings!

[<st...@bl...>]

Hello everybody,

I've made a few patches to various files to eliminate all the compilers
warnings that the build was generating.  Patches for the changes are at
http://www.blckknght.org/~steve/uqm/

Happy holidays!

--=20
Steven Barker                                      st...@bl...
  Under a government which imprisons any unjustly, the true place for a
  just man is also a prison.
  		-- Henry David Thoreau
Get my GnuPG public key at: http://www.blckknght.org/publickey.asc
Fingerprint: 272A 3EC8 52CE F22B F745  775E 5292 F743 EBD5 936B

[Sc2-devel] Minor typo patch

[<sj...@de...>]

I got bored, so I wandered through some of the conversation files.
Here's a patch for a number of grammatical and spelling typos (nothing
that should clash with the .oggs, but hey.)

I got as far as the Ilwrath file. Some day, I'll get around to the other
21.

On another note -- I seem to be getting a _lot_ of lockups under Mac OS
10.2.2. I'll be updating to 10.2.3 in due course, but in the meantime,
I've noticed that the frequency seems to have dropped since I patched
the source to not have any name clashes with the Quicktime/Quickdraw
libraries. I seem to recall somebody posting a patch for that to the
list already, so I won't submit mine.

Time to get some sleep. Have a good christmas, all.

[Sc2-devel] Patch for missed keystroke bug, against current CVS.

[<ms...@mo...>]

Patch against current CVS code for missed key stroke bug.
========

  The current input routines keep track the Pressed/Not Pressed state of 
all keys on the keyboard (using function ProcessKeyboardEvent, with 
array KeyboardDown).  The main loops inside the game core periodically
poll all of the keys they have an interest in to see if a key is currently
pressed (using function KeyDown).

  The buttons states are checked something between 5 and 20 times a second.
Since the code only cares about what the state is 'right now', it is very
likely that a quick key tap will be completely missed by the game.  This
leads to things like selecting a menu item not, or tapping the movement
keys having no effect.  If you don't like repeating yourself a bunch,
this can be extremely irritating to try and use.

  The following set of patches are just bandaids which fix the 'missed
keystroke problem'.  They work by introducing the idea of 'pressed since
we last polled the key but not pressed now'... when a key is polled it
will return 'is pressed' if the key is either currently held down or
if the key has been tapped and released since the poll happened.

  It does this by storing 0x1 in the KeyboardDown array for any key
currently held down, and 0x2 for any key that was pressed since last 
check.  0x2 gets cleared every time KeyDown returns true.  0x1 gets
cleared anytime the key is released.

  I have been using this code for about the last 24 hours and it seems to
work very well.

  I hear that slayne is planning to rewrite the input handling routines from
scratch to correct this and a number of other issues like switching
polling input to input queue, adding/fixing support for joysticks, and
support for configurable key mappings ('x' == fire, '5' == 'select', etc).

  Since the input system is to be overhauled, there appeared to be little 
interest in this on IRC.  I figured I would send it here for archive 
purposes...

    TTFN,
      Mike

ps:
  it would have been hundreds of lines shorter if the original case
statement didn't have a bazillion returns in it... sigh.


Index: sc2/src/sc2code/libs/input/sdl/input.c
===================================================================
RCS file: /cvsroot/sc2/sc2/src/sc2code/libs/input/sdl/input.c,v
retrieving revision 1.7
diff -u -p -r1.7 input.c
--- sc2/src/sc2code/libs/input/sdl/input.c	6 Dec 2002 17:49:15 -0000	1.7
+++ sc2/src/sc2code/libs/input/sdl/input.c	20 Dec 2002 01:58:59 -0000
@@ -113,11 +113,11 @@ ProcessKeyboardEvent(const SDL_Event *Ev
 				if (kbdtail == kbdhead)
 					kbdhead = (kbdhead + 1) & (KBDBUFSIZE - 1);
 			}
-			KeyboardDown[Event->key.keysym.sym]=TRUE;
+			KeyboardDown[Event->key.keysym.sym] = 3;
 		}
 		else
 		{
-			KeyboardDown[Event->key.keysym.sym]=FALSE;
+			KeyboardDown[Event->key.keysym.sym] &= 2;
 		}
 	}
 }
@@ -408,111 +410,107 @@ KeyHit () // Does this clear the top of 
 
 //Status: Unimplemented
 int
-KeyDown (UNICODE which_scan)
+KeyDown (UNICODE i)
 		// This might use SK_* stuff, of just plain old chars
 {
-	int i;
+	int which_scan = i;
+	int alt_scan = 0;
 
-	i = which_scan;
-	if (i == '\n')
+	switch (which_scan)
 	{
-		if (KeyboardDown[SDLK_KP_ENTER])
-			return (1);
-		i = SDLK_RETURN;
-	}
-	else if (i >= 128)
-	{
-		switch (i)
-		{
-			case SK_LF_ARROW:
-				if (KeyboardDown[SDLK_KP4])
-					return (1);
-				i = SDLK_LEFT;
-				break;
-			case SK_RT_ARROW:
-				if (KeyboardDown[SDLK_KP6])
-					return (1);
-				i = SDLK_RIGHT;
-				break;
-			case SK_UP_ARROW:
-				if (KeyboardDown[SDLK_KP8])
-					return (1);
-				i = SDLK_UP;
-				break;
-			case SK_DN_ARROW:
-				if (KeyboardDown[SDLK_KP2])
-					return (1);
-				i = SDLK_DOWN;
-				break;
-			case SK_HOME:
-				if (KeyboardDown[SDLK_KP7])
-					return (1);
-				i = SDLK_HOME;
-				break;
-			case SK_PAGE_UP:
-				if (KeyboardDown[SDLK_KP9])
-					return (1);
-				i = SDLK_PAGEUP;
-				break;
-			case SK_END:
-				if (KeyboardDown[SDLK_KP1])
-					return (1);
-				i = SDLK_END;
-				break;
-			case SK_PAGE_DOWN:
-				if (KeyboardDown[SDLK_KP3])
-					return (1);
-				i = SDLK_PAGEDOWN;
-				break;
-			case SK_INSERT:
-				if (KeyboardDown[SDLK_KP0])
-					return (1);
-				i = SDLK_INSERT;
-				break;
-			case SK_DELETE:
-				if (KeyboardDown[SDLK_KP_PERIOD])
-					return (1);
-				i = SDLK_DELETE;
-				break;
-			case SK_KEYPAD_PLUS:
-				i = SDLK_KP_PLUS;
-				break;
-			case SK_KEYPAD_MINUS:
-				i = SDLK_KP_MINUS;
-				break;
-			case SK_LF_SHIFT:
-				i = SDLK_LSHIFT;
-				break;
-			case SK_RT_SHIFT:
-				i = SDLK_RSHIFT;
-				break;
-			case SK_CTL:
-				if (KeyboardDown[SDLK_LCTRL])
-					return (1);
-				i = SDLK_RCTRL;
-				break;
-			case SK_ALT:
-				if (KeyboardDown[SDLK_LALT])
-					return (1);
-				i = SDLK_RALT;
-				break;
-			case SK_F1:
-			case SK_F2:
-			case SK_F3:
-			case SK_F4:
-			case SK_F5:
-			case SK_F6:
-			case SK_F7:
-			case SK_F8:
-			case SK_F9:
-			case SK_F10:
-			case SK_F11:
-			case SK_F12:
-				i = (i - SK_F1) + SDLK_F1;
-		}
+		case '\n' :
+			which_scan = SDLK_KP_ENTER;
+			alt_scan = SDLK_RETURN;
+			break;
+		case SK_LF_ARROW :
+			which_scan = SDLK_KP4;
+			alt_scan = SDLK_LEFT;
+			break;
+		case SK_RT_ARROW:
+			which_scan = SDLK_KP6;
+			alt_scan = SDLK_RIGHT;
+			break;
+		case SK_UP_ARROW:
+			which_scan = SDLK_KP8;
+			alt_scan = SDLK_UP;
+			break;
+		case SK_DN_ARROW:
+			which_scan = SDLK_KP2;
+			alt_scan = SDLK_DOWN;
+			break;
+		case SK_HOME:
+			which_scan = SDLK_KP7;
+			alt_scan = SDLK_HOME;
+			break;
+		case SK_PAGE_UP:
+			which_scan = SDLK_KP9;
+			alt_scan = SDLK_PAGEUP;
+			break;
+		case SK_END:
+			which_scan = SDLK_KP1;
+			alt_scan = SDLK_END;
+			break;
+		case SK_PAGE_DOWN:
+			which_scan = SDLK_KP3;
+			alt_scan = SDLK_PAGEDOWN;
+			break;
+		case SK_INSERT:
+			which_scan = SDLK_KP0;
+			alt_scan = SDLK_INSERT;
+			break;
+		case SK_DELETE:
+			which_scan = SDLK_KP_PERIOD;
+			alt_scan = SDLK_DELETE;
+			break;
+		case SK_KEYPAD_PLUS:
+			which_scan = SDLK_KP_PLUS;
+			break;
+		case SK_KEYPAD_MINUS:
+			which_scan = SDLK_KP_MINUS;
+			break;
+		case SK_LF_SHIFT:
+			which_scan = SDLK_LSHIFT;
+			break;
+		case SK_RT_SHIFT:
+			which_scan = SDLK_RSHIFT;
+			break;
+		case SK_CTL:
+			which_scan = SDLK_RCTRL;
+			alt_scan = SDLK_LCTRL;
+			break;
+		case SK_ALT:
+			alt_scan = SDLK_LALT;
+			which_scan = SDLK_RALT;
+			break;
+		case SK_F1:
+		case SK_F2:
+		case SK_F3:
+		case SK_F4:
+		case SK_F5:
+		case SK_F6:
+		case SK_F7:
+		case SK_F8:
+		case SK_F9:
+		case SK_F10:
+		case SK_F11:
+		case SK_F12:
+			which_scan = (which_scan - SK_F1) + SDLK_F1;
+	}
+
+	if (KeyboardDown[which_scan])
+	{
+		KeyboardDown[which_scan] &= 1;
+		return 1;
 	}
 
-	return (KeyboardDown[i]);
+	if (alt_scan)
+		if (KeyboardDown[alt_scan])
+		{
+			KeyboardDown[alt_scan] &= 1;
+			return 1;
+		}
+
+	return 0;
 }
 
 INPUT_STATE
@@ -529,7 +527,10 @@ AnyButtonPress (BOOLEAN DetectSpecial)
 	for (i = 0; i < sizeof (KeyboardDown) / sizeof (KeyboardDown[0]); ++i)
 	{
 		if (KeyboardDown[i])
+		{
+			KeyboardDown[i] &= 1;
 			return (DEVICE_BUTTON1);
+		}
 	}
 #if 0
 	for (i = 0; i < JOYSTICKS_AVAIL; i++)

[Sc2-devel] Non-coder help wanted.

[Serge v. d. B. <sv...@st...>]

Hi,

A number of people have been asking how they can help if they can't code.
Well now we've got something. We've set up a bugzilla database, and we need
someone to enter all the previously reported bugs. Yes, it might not be the
most fun job there is, but you'll be helping the port along, as we can spend
our time on the code.
The job can be shared by several people, but they'll need to work together
to prevent the same bug from being reported more than once.

We prefer to have people who know something about the internals, either
because they've looked at the source, have been active in the irc channel
for a while, or read a lot of comments on the boards. This so they can
recognise different incarnations of the same bug.

Let us know if you're interested.

Serge

Re: [Sc2-devel] Sc2 source code for Windows

[Serge v. d. B. <sv...@st...>]

On Sun, 15 Dec 2002, Dan Plimak wrote:
> * th...@sp... (th...@sp...) wrote: Where can I find the source
> > code for the Windows version of Sc2?  The only Sc2 source code that I see
> > on sourceforge.net is for Unix and BeOS.  Can anyone point me in the right
> > direction?
> There is only one source tarball of the 0.1 release for all platforms,
> called uqm-0.1-source.tgz, and builds quite happily for Windows OOTB.
> (Provided you follow the instructions and get the correct library versions
> of OpenAL, SDL and friends.)
>
> [...]
>
> You're probably better using the CVS method if you're interested in the
> source, however.

At the time of the release, I patched the source to put the saved data and
temp files in a seperate dir, so that it could be installed system-wide on
*nix. This however broke the Windows compilation, and hence I didn't commit
it to CVS yet. I think the source tarball of the 0.1 release contained this
code though, so that won't be directly usable for Windows.

I've been really busy catching up with some non-uqm stuff I had been
postponing before the release, so I've only now gotten around to fixing and
commiting the code for the seperate data and temp files to CVS (with some
additional cleanups).

I advice everyone who wants to use the source to always use the most
recent CVS version.

Serge


P.S.  If you exit the game in full game mode, the temporary files won't be
      deleted. It's a known bug which will be addressed in time.

Re: [Sc2-devel] Candidate for Media License

[<st...@bl...>]

On Thu, Dec 12, 2002 at 07:04:37AM -0500, Chris Nelson wrote:

Hi Chris.

>    TFB is currently reviewing a license which we believe might fit our
>    criteria:
>=20
>    The Free Art License.

I presume you are refering to http://artlibre.org/licence.php/lalgb.html
(or the original French version at http://artlibre.org/).

I inquired about that license on the debian-legal mailing list, specificly
asking if the terms of that license would allow the evenutal inclusion of
UQM in the Debian distribution (once it's stable).  They pointed out several
problems with the license, though some of them may be due to imprecise
translation to English.  The discussion (starting with my message) is at
http://lists.debian.org/debian-legal/2002/debian-legal-200212/msg00187.html

The most troubling clause of the license is  #8, which states:

  8. THE LAW APPLICABLE TO THIS CONTRACT
  This license is subject to French law.

To begin with, it is rather unclear if this is an attempt to claim French
jurisdiction for all actions related to the license (ie you would have to
sue me in France if I violate the license) or if it might require non-French
courts to base their findings on French law (something they'd not be too
likely to do).  And even if the intention of the clause were clear, it would
be extremely difficult for non-French citizens to obey the license under
French Law (which they may have access to or be able to understand).

Another problem with the license is that clause #3 seems to forbid the
algamation of art into a larger work not covered by the Free Art License.
This might (under a certain interpretation) prevent us from distributing the
content along with the game proper (which is under the GPL).  It would
certainly rule out it's inclusion in any major software distribution.

I do think that the aims of the lincese are good, in that it attempts to
apply copyleft to works of art.  However it falls a bit short in execution.
Please use a different license.

Perhaps if you describe exactly what freedoms you want to give to the users
of the content, we (the readers of the list) can help find (or write) an
appropriate license (good places to find a vocabulary for describing
freedoms are http://www.gnu.org/philosophy/free-sw.html and
http://www.debian.org/social_contract#guidelines).

--=20
Steven Barker                                      st...@bl...
  Be independent.  Insult a rich relative today.
Get my GnuPG public key at: http://www.blckknght.org/publickey.asc
Fingerprint: 272A 3EC8 52CE F22B F745  775E 5292 F743 EBD5 936B

RE: [Sc2-devel] Help understanding globdata.h macro

[Jim M. <jim...@co...>]

Stuart,
	Thanks, for the tip. I did figure it out, nothing like a good night of
sleep to help cure a brain fart.

Jim

-----Original Message-----
From: sc2...@li...
[mailto:sc2...@li...]On Behalf Of Stuart Lamble
Sent: Saturday, December 14, 2002 6:57 PM
To: sc2...@li...
Subject: Re: [Sc2-devel] Help understanding globdata.h macro


> Hello,
> 	It seems my C is a bit rusty, could some one explain how the following
> #define is expanded. I understand simple macro's, but can't figure out how
> the game states are being loaded.

Easiest way would be to run the code through cpp. I don't know the
equivalent
way under Windows, but under Unix-class OSs, just run:
  cpp file.c
(with appropriate -I flags), and the result is piped to stdout.

I'm too lazy to do it right now myself :)

As an aside -- looks like there are issues with the SDL frameworks under
Mac OS X (10.2.2). Time to download and compile Unix-based libraries, and
nuke the frameworks, methinks. Ho hum. If nothing else, I'm learning heaps
about how the Mac OS compile system works. :)


-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
_______________________________________________
Sc2-devel mailing list
Sc2...@li...
https://lists.sourceforge.net/lists/listinfo/sc2-devel

Re: [Sc2-devel] Sc2 source code for Windows

[Dan P. <da...@sy...>]

* th...@sp... (th...@sp...) wrote: Where can I find the source
> code for the Windows version of Sc2?  The only Sc2 source code that I see
> on sourceforge.net is for Unix and BeOS.  Can anyone point me in the right
> direction?

There is only one source tarball of the 0.1 release for all platforms,
called uqm-0.1-source.tgz, and builds quite happily for Windows OOTB.
(Provided you follow the instructions and get the correct library versions
of OpenAL, SDL and friends.)

And it's right here:

  http://prdownloads.sourceforge.net/sc2/uqm-0.1-source.tgz?download

You're probably better using the CVS method if you're interested in the
source, however.

HTH,

  -- danp

[Sc2-devel] Sc2 source code for Windows

[<th...@sp...>]

Where can I find the source code for the Windows version of Sc2?  The =
only Sc2 source code that I see on sourceforge.net is for Unix and BeOS. =
 Can anyone point me in the right direction?

Alva

Re: [Sc2-devel] Help understanding globdata.h macro

[<sj...@de...>]

> Hello,
> 	It seems my C is a bit rusty, could some one explain how the following
> #define is expanded. I understand simple macro's, but can't figure out how
> the game states are being loaded.

Easiest way would be to run the code through cpp. I don't know the equivalent
way under Windows, but under Unix-class OSs, just run:
  cpp file.c
(with appropriate -I flags), and the result is piped to stdout.

I'm too lazy to do it right now myself :)

As an aside -- looks like there are issues with the SDL frameworks under
Mac OS X (10.2.2). Time to download and compile Unix-based libraries, and
nuke the frameworks, methinks. Ho hum. If nothing else, I'm learning heaps
about how the Mac OS compile system works. :)