sc2-devel — For developers

[Sc2-devel] Conversation Information

[<con...@co...>]

Just for the fun of it, I was thinking of making a CTree like program.=20
[if you ask why, I have no answer].

anyway, I was also thinking of duplicating the animation.  [I tried this
once using some extracted stuff from the FSCP project, so I understand ho=
w
1/2 of it works],  but there is some things I dont understand.

your (name).ani file has 5 columns.  First one is image name, 2nd and 3rd
I wanted you to tell me what those are for, and the last 2 are offset for
the specific image I am assuming [SC2 PC had that anyway].

Also, Do you tinker around with pallets like the PC SC version?


Thank you in advanced.

[Sc2-devel] Melee team bucks -- 3DO check

[Alex V. <av...@bp...>]

Could a 3DO owner please check how the melee team cost (aka "bucks") is
counted? Specifically, how the cost of the ship that is still in battle is
counted towards the remaining team cost when the melee ends. Does the
remaining crew play a role in it, or is the entire cost of the ship used?
The PC version counted the ship's cost without regard for the crew.

Thank you!
Alex.

[Sc2-devel] Another possible content license

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

Jeranon mentioned this for a content license on the uqm forum:
http://creativecommons.org/

It sounds interesting.

Comments?

Serge

Re: [Sc2-devel] Star Control 2 Bug

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

On Thu, 16 Jan 2003, Romach wrote:
> I've seen this on the to do list:
> - OpenGL mode might cause lockups when entering a star system, while
>   pure SDL mode does not; can others confirm this?
>
> OpenGL is the default right? if it is, then i can confirm this, my game
> just crashed entering a star system
>
> Also: Fullscreen doesn't work (for me), i added -f but noting... (Actully,
> it seems to go the full screen for half a sec, then back to window)
These bugs have in fact been two of the first to be fixed after the alpha
release. Up to date todo, Changelog and unverified bug lists can be found
in cvs.

There are links to the relevant places in cvsweb from
http://uqm.stack.nl/cgi-bin/yabb/YaBB.pl?board=Techissues;action=display;num=1038843324

Serge

RE: [Sc2-devel] Star Control 2 Bug

[Tomer G. <to...@bi...>]

Interesting; I recall the original PC Star Control 2 often crashing upon
entering a star system. I always figured it was a divide by zero bug in the
star system bitmap generation code, I wonder if the same bug prevails in the
3DO version...

  -----Original Message-----
  From: sc2...@li...
[mailto:sc2...@li...]On Behalf Of Romach
  Sent: Thursday, January 16, 2003 6:05 PM
  To: sc2...@li...
  Subject: [Sc2-devel] Star Control 2 Bug


  I've seen this on the to do list:
  - OpenGL mode might cause lockups when entering a star system, while
    pure SDL mode does not; can others confirm this?

  OpenGL is the default right? if it is, then i can confirm this, my game
just crashed entering a star system

  Also: Fullscreen doesn't work (for me), i added -f but noting... (Actully,
it seems to go the full screen for half a sec, then back to window)

[Sc2-devel] Star Control 2 Bug

[Romach <ro...@za...>]

I've seen this on the to do list:
- OpenGL mode might cause lockups when entering a star system, while
  pure SDL mode does not; can others confirm this?

OpenGL is the default right? if it is, then i can confirm this, my game =
just crashed entering a star system

Also: Fullscreen doesn't work (for me), i added -f but noting... =
(Actully, it seems to go the full screen for half a sec, then back to =
window)

Re: [Sc2-devel] Media License: Take Two

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

On Mon, 6 Jan 2003, Patrick Fisher wrote:
> I believe the code is under the GPL - it need not be covered by the media
> license as well.
That's right. This license would only be for the files under the content/
dir. For the code, there's still GPL.

Serge

Re: [Sc2-devel] Media License: Take Two

[Patrick F. <Pat...@al...>]

I believe the code is under the GPL - it need not be covered by the media
license as well.

Patrick


----- Original Message -----
From: "Alon Tirosh" <al...@ay...>
To: <sc2...@li...>
Sent: Monday, January 06, 2003 10:55 AM
Subject: Re: [Sc2-devel] Media License: Take Two


> good point on the copyright... i should have more coffee before i look at
> these things...
> however, while the license covers the artistic works in the game (the old
> ur-quan pepsi ad problem) it doesnt cover code in any way, and while
someone
> using this code for commercial purposes is even less likely than seeing an
> ur-quan pop a can of soda on TV, it should be covered in any case. The
other
> thing we can do is simply ask the author to it in. All you really need is
to
> explicitly add software code into definitions.
> ----- Original Message -----
> From: "Serge van den Boom" <sv...@st...>
> To: <sc2...@li...>
> Sent: Monday, January 06, 2003 10:38 AM
> Subject: Re: [Sc2-devel] Media License: Take Two
>
>
> > On Mon, 6 Jan 2003, Alon Tirosh wrote:
> > > Legally speaking, the license needs to be edited to specifically
> encompass
> > > the type and specific work being done, but it should do the trick. If
> you
> > > want, ill see to it that the license is edited to legally encompass
UQM,
> > > and then get it back to you.
> > The license itself is copyrighted, so you can't just edit it and use it
> for
> > your own purposes. I'm not sure editing is necessary though.
> >
> > Serge
> >
> >
> >
> >
> > -------------------------------------------------------
> > 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
>
>
>
> -------------------------------------------------------
> 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
>

Re: [Sc2-devel] Media License: Take Two

[Alon T. <al...@ay...>]

good point on the copyright... i should have more coffee before i look at
these things...
however, while the license covers the artistic works in the game (the old
ur-quan pepsi ad problem) it doesnt cover code in any way, and while someone
using this code for commercial purposes is even less likely than seeing an
ur-quan pop a can of soda on TV, it should be covered in any case. The other
thing we can do is simply ask the author to it in. All you really need is to
explicitly add software code into definitions.
----- Original Message -----
From: "Serge van den Boom" <sv...@st...>
To: <sc2...@li...>
Sent: Monday, January 06, 2003 10:38 AM
Subject: Re: [Sc2-devel] Media License: Take Two


> On Mon, 6 Jan 2003, Alon Tirosh wrote:
> > Legally speaking, the license needs to be edited to specifically
encompass
> > the type and specific work being done, but it should do the trick. If
you
> > want, ill see to it that the license is edited to legally encompass UQM,
> > and then get it back to you.
> The license itself is copyrighted, so you can't just edit it and use it
for
> your own purposes. I'm not sure editing is necessary though.
>
> Serge
>
>
>
>
> -------------------------------------------------------
> 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

Re: [Sc2-devel] Media License: Take Two

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

On Mon, 6 Jan 2003, Alon Tirosh wrote:
> Legally speaking, the license needs to be edited to specifically encompass
> the type and specific work being done, but it should do the trick. If you
> want, ill see to it that the license is edited to legally encompass UQM,
> and then get it back to you.
The license itself is copyrighted, so you can't just edit it and use it for
your own purposes. I'm not sure editing is necessary though.

Serge

Re: [Sc2-devel] Media License: Take Two

[Alon T. <al...@ay...>]

Legally speaking, the license needs to be edited to specifically =
encompass the type and specific work being done, but it should do the =
trick. If you want, ill see to it that the license is edited to legally =
encompass UQM, and then get it back to you.=20
  ----- Original Message -----=20
  From: Chris Nelson=20
  To: sc2-devel=20
  Sent: Sunday, January 05, 2003 4:23 PM
  Subject: [Sc2-devel] Media License: Take Two


  It seems as though the spirit of the first license I proposed a while =
ago was on target, but some of its the wording left a little to be =
desired.

  As such, I've found another license which I believe might work for the =
art in UQM. The Free Media License:

  https://expressivefreedom.org/copyleft/fml-intro.html

  The author explicitly states that this license is based on concepts =
from the GPL, and it seems to me as though sc cloners could use the art =
we provide under this license, if they released their game under the =
GPL. Is this how everyone else reads the license? If there was any =
doubt, we could also explicitly grant permission for this. Would that =
work for everyone?

  If people could submit their analysis of this license to the list, it =
would be helpful.

  And, of course, if anybody knows of a better license, please post =
that, too.

        --=20
        Chris Nelson <ch...@to...>
        TFB =20

[Sc2-devel] Media License: Take Two

[Chris N. <ch...@to...>]

It seems as though the spirit of the first license I proposed a while
ago was on target, but some of its the wording left a little to be
desired.

As such, I've found another license which I believe might work for the
art in UQM. The Free Media License:

https://expressivefreedom.org/copyleft/fml-intro.html

The author explicitly states that this license is based on concepts from
the GPL, and it seems to me as though sc cloners could use the art we
provide under this license, if they released their game under the GPL.
Is this how everyone else reads the license? If there was any doubt, we
could also explicitly grant permission for this. Would that work for
everyone?

If people could submit their analysis of this license to the list, it
would be helpful.

And, of course, if anybody knows of a better license, please post that,
too.

-- 
Chris Nelson <ch...@to...>
TFB

[Sc2-devel] 3DO Version Checking

[Lee T. <tho...@lo...>]

I'm noticing a number of "3DO verson check" notes in the bug list; if these
still need checking I'll fire up Star Control 2 in the 3DO box this evening
and verify them.



-- 
Lee Thompson
tho...@lo...

Re: [Sc2-devel] Couldn't get cel data for file.ani (OSX)

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

> Also, do you remember what you did to get the build.sh configuration to  
> run?

I have a patch floating around somewhere that I need to polish up a bit
before I submit it to the list. It basically modifies the build scripts
so that they make the necessary changes for Mac OS X, and gets rid of the
duplicate symbol definitions (somebody else already submitted a patch for
that part, though.)

The duplicate symbols don't do anything to stop you running the game, but
they do stop you running it with the malloc debug library; I also noticed
that I seemed to get a lot more deadlocks with the duplicate symbols,
although that may be just coincidence.

> I wound up manually entering the linking info for  LIB_SDL_LDFLAGS  
> in config_proginfo ; the original script just assigns that variable to  
> the output from 'sdl-config --libs', which introduces multiple  
> definitions of _main in the configuration test and causes it to fail  
> because it uses -lSDLmain . Removing that linking entry for the  
> configuration part and adding it back to the build.vars file seemed to  
> fix this.

I fiddled with config.proginfo, if I remember rightly. The biggest
hassle with Mac OS X is that it seems to insist upon listing all the
libraries you want to link, including dependant libraries. As I said,
I have a patch waiting in the wings, in need of tidying up, that I'll
submit soon.

Re: [Sc2-devel] Couldn't get cel data for file.ani (OSX)

[Richard W. <rwa...@ma...>]

On Wednesday, January 1, 2003, at 04:23 PM, Stuart Lamble wrote:

>
> First of all -- are you using the latest CVS? If so, I'll see if my
> build breaks in the same way. Also, which versions of the various
> libraries -- ogg, vorbis, SDL, SDL_mixer, SDL_image -- are you using?
> Only SDL_mixer needs to be from CVS; the others work fine if you use
> the latest stable release. Make sure that SDL_image is compiled with
> png support (jpeg support is probably useful in the general case, but
> I don't think SC2 uses it.)


All of the libraries I've compiled and installed by using the unstable  
packages provided by Fink. Here's the version info that Fink shows:
sdl		1.2.5-1
sdl-mixer	1.2.4-13
sdl-image	1.2.2-1
libvorbis0	1.0-1

I'm pretty sure that SDL_image is linked w/ libpng, but since it was an  
automated build process I didn't really pay attention. I'll see if I  
can confirm that.

Also, do you remember what you did to get the build.sh configuration to  
run? I wound up manually entering the linking info for  LIB_SDL_LDFLAGS  
in config_proginfo ; the original script just assigns that variable to  
the output from 'sdl-config --libs', which introduces multiple  
definitions of _main in the configuration test and causes it to fail  
because it uses -lSDLmain . Removing that linking entry for the  
configuration part and adding it back to the build.vars file seemed to  
fix this.

Additionally, there are several multiple definitions warnings after the  
build:

ld: warning multiple definitions of symbol _DrawText
obj/debug/./src/sc2code/libs/graphics/font.o definition of _DrawText in  
section (__TEXT,__text)
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/ 
Frameworks/QD.framework/Versions/A/QD(QD.o) definition of _DrawText
ld: warning multiple definitions of symbol _CloseResFile
obj/debug/./src/sc2code/libs/resource/filecntl.o definition of  
_CloseResFile in section (__TEXT,__text)
/System/Library/Frameworks/CoreServices.framework/Versions/A/ 
Frameworks/CarbonCore.framework/Versions/A/CarbonCore(CarbonCore.o)  
definition of _CloseResFile
ld: warning multiple definitions of symbol _DetachResource
obj/debug/./src/sc2code/libs/resource/getres.o definition of  
_DetachResource in section (__TEXT,__text)
/System/Library/Frameworks/CoreServices.framework/Versions/A/ 
Frameworks/CarbonCore.framework/Versions/A/CarbonCore(CarbonCore.o)  
definition of _DetachResource
ld: warning multiple definitions of symbol _GetResource
obj/debug/./src/sc2code/libs/resource/getres.o definition of  
_GetResource in section (__TEXT,__text)
/System/Library/Frameworks/CoreServices.framework/Versions/A/ 
Frameworks/CarbonCore.framework/Versions/A/CarbonCore(CarbonCore.o)  
definition of _GetResource

  I'm thinking my problem probably has something to do with this, but  
I'm not quite sure how to go about fixing that.


- Richard

Re: [Sc2-devel] Couldn't get cel data for file.ani (OSX)

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

> After some very minor tinkering with the build scripts, I've been 
> marginally successful in compiling uqm-debug on OSX. Upon execution, I 
> get a new empty window (or fullscreen if specified), but no graphics. 

Interesting. My OSX build works fine (a few bugs, but it loads and runs
successfully, no problem with graphics. The only major problems of note
at the moment are sound... my copy of SDL_mixer CVS looks like it's
rather broken. 1.2.4 works fine, but there's no speech.)

> I haven't seen this error mentioned anywhere in the lists previously, 
> so I was wondering if anyone else has run into this problem (OS X or 
> otherwise). Any specifics as to what this might be related to would be 
> helpful as well...

First of all -- are you using the latest CVS? If so, I'll see if my
build breaks in the same way. Also, which versions of the various
libraries -- ogg, vorbis, SDL, SDL_mixer, SDL_image -- are you using?
Only SDL_mixer needs to be from CVS; the others work fine if you use
the latest stable release. Make sure that SDL_image is compiled with
png support (jpeg support is probably useful in the general case, but
I don't think SC2 uses it.)

Hope this helps,

Stuart.

[Sc2-devel] Couldn't get cel data for file.ani (OSX)

[Richard W. <rwa...@ma...>]

After some very minor tinkering with the build scripts, I've been 
marginally successful in compiling uqm-debug on OSX. Upon execution, I 
get a new empty window (or fullscreen if specified), but no graphics. 
The error messages are along these lines:

...snip...
We've loaded the Kernel
         'lbm/title.ani' -- 19 bytes
Couldn't get cel data for 'lbm/title.ani'
         'arilou.shp' -- 301 bytes
         'arilou/ariicons.ani' -- 50 bytes
Couldn't get cel data for 'arilou/ariicons.ani'
         'arilou/arimicon.ani' -- 46 bytes
Couldn't get cel data for 'arilou/arimicon.ani'
         'arilou/aritext.txt' -- 407 bytes
         'arilou/arilou.cod' -- 1 bytes
         'chmmr.shp' -- 345 bytes
         'chmmr/chmicons.ani' -- 48 bytes
Couldn't get cel data for 'chmmr/chmicons.ani'

...etc...

I haven't seen this error mentioned anywhere in the lists previously, 
so I was wondering if anyone else has run into this problem (OS X or 
otherwise). Any specifics as to what this might be related to would be 
helpful as well...

Thanks!

Re: [Sc2-devel] [PATCH] silence warnings in w_memlib.c, comparison is always true/false

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

On Mon, 30 Dec 2002 ms...@mo... wrote:
>   The following patch silences a small batch of warnings about
> comparison always true/false in src/sc2code/libs/memory/w_memlib.c.
> [...]
>   MEM_HANDLE should probably be an unsigned short, and then all of the
> h > 0 tests would have to be nuked... since negative values don't
> appear to be used, this would double the number of chunks available.
Line 392:
extents[i].handle = -1;
extents[i].handle is of type MEM_HANDLE.

> pps:
>   since the extents array is static and 20 bytes per element this patch
> lowers the runtime memory usage of the program by about 1.3 Megs.
That's considerable.

> I've not done any tests to see how small the array can safely be sized...
It would need some extensive testing in various game circumstances. I do
assume there's a reason the array is this large to start with.
(though the memlib was originally supposed to be seperate from star control
itself, so it could have been a precaution, or because of another game.

> but would be willing to write code to dynamically increase the size of the
> extent array as it is needed, so that it can be started very very small
> and grow.  I'd need to know this would be desired by whoever controls
> memlib...
There's no-one in particular in control of the memlib. But I'm not really
satisfied with the thing in its entirety for our purposes. It seems to do
pretty much what malloc itself does, and malloc probably does a better job at
it too. It could be a big speed-win too to rewrite the thing to do just
basically malloc(), as - when using threads - malloc is thread-safe by
itself, so there's no need for the extra locking that memlib does.

Serge

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

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

On Sun, 29 Dec 2002, Steven Barker wrote:
> > > > 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.
> My patch is exceedingly minimal, as all it does is remove the extra
> function declaration (which never should have been put inside another
> function to begin with).  Even if it's totally unused code, please consider
> applying the patch just to get rid of the silly compiler warning (which
> might distract other people from real bugs).
My mistake. I thought you were _adding_ a prototype within a function,
instead of removing it. Patch appleid.

> > > > 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.
> Yes, I know, C is stupid like that.  My code above actually does it right,
> since it casts to an unsigned type (COUNT) before doing the % operator.
I wouldn't necessarilly call it stupid. It's just a design decision.

> > > (I assume it's not ever used where v < -d or v >= 2*d.)
> > Certainly that should be checked instead of assumed.
> Well, the current WRAP_VAL function doesn't do any checks, and will have
> unexpected results for values outside the normal range.  My equivilant code
> above is more consistant (it will always return a value between 0 and w-1).
By 'it should be checked', I didn't mean in the code, but by the person
creating the code.

> [ long story about WRAP_VAL ]
Ah. I didn't get your point that WRAP_VAL itself was used incorrectly in the
original code. Patch applied.

Serge

[Sc2-devel] [PATCH] silence warnings in w_memlib.c, comparison is always true/false

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

  The following patch silences a small batch of warnings about 
comparison always true/false in src/sc2code/libs/memory/w_memlib.c.

  MEM_HANDLE is a signed short, MAX_EXTENTS was larger than a signed short
can be (100000) so anytime comparisons happened between MEM_HANDLEs and 
MAX_EXTENTS this warning was generated.
  MAX_EXTENTS is an upper limit on how many memory chunks can allocated 
at a time...

    TTFN,
      Mike

ps:
  MEM_HANDLE should probably be an unsigned short, and then all of the 
h > 0 tests would have to be nuked... since negative values don't
appear to be used, this would double the number of chunks available.

pps:
  since the extents array is static and 20 bytes per element this patch 
lowers the runtime memory usage of the program by about 1.3 Megs.  I've
not done any tests to see how small the array can safely be sized...
but would be willing to write code to dynamically increase the size
of the extent array as it is needed, so that it can be started very 
very small and grow.  I'd need to know this would be desired by
whoever controls memlib...


Basically code involved looks like this:
====
mem_simple_access(MEM_HANDLE h)
{
	        if (h > 0 && h <= MAX_EXTENTS && extents[h - 1].handle == h)
====

Types:
====
src/sc2code/libs/memlib.h:typedef SWORD MEM_HANDLE;
src/sc2code/libs/compiler.h:typedef signed short      SWORD;
====

Warnings looked like such:
====
gcc -o obj/debug/./src/sc2code/libs/memory/w_memlib.o -c  -I/usr/include/SDL -D_REENTRANT -I/usr/include/SDL -D_REENTRANT -g -O0 -DGFXMODULE_SDL -DSOUNDMODULE_SDL -I/usr/include/SDL -D_REENTRANT -I/home/msimons/local/sdl/include -DHAVE_CONFIG_H -I src -I src/sc2code -I src/sc2code/libs src/sc2code/libs/memory/w_memlib.c
src/sc2code/libs/memory/w_memlib.c: In function `mem_get_size':
src/sc2code/libs/memory/w_memlib.c:346: warning: comparison is always true due to limited range of data type
src/sc2code/libs/memory/w_memlib.c: In function `mem_release':
src/sc2code/libs/memory/w_memlib.c:485: warning: comparison is always false due to limited range of data type
src/sc2code/libs/memory/w_memlib.c: In function `mem_simple_access':
src/sc2code/libs/memory/w_memlib.c:540: warning: comparison is always true due to limited range of data type
src/sc2code/libs/memory/w_memlib.c: In function `mem_simple_unaccess':
src/sc2code/libs/memory/w_memlib.c:578: warning: comparison is always true due to limited range of data type
====

Index: ./src/sc2code/libs/memory/w_memlib.c
===================================================================
RCS file: /cvsroot/sc2/sc2/src/sc2code/libs/memory/w_memlib.c,v
retrieving revision 1.7
diff -u -p -r1.7 w_memlib.c
--- ./src/sc2code/libs/memory/w_memlib.c	23 Dec 2002 02:27:06 -0000	1.7
+++ ./src/sc2code/libs/memory/w_memlib.c	30 Dec 2002 10:29:01 -0000
@@ -45,7 +45,7 @@ int leak_size = -1;
 #endif
 Semaphore _MemorySem;
 
-#define MAX_EXTENTS 100000
+#define MAX_EXTENTS 32000
 
 /* Keep track of memory allocations. */
 

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

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

On Sat, Dec 28, 2002 at 11:27:00PM +0100, 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:

> > > 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 compil=
er
> > warning it generated without my patch was (paraphrased) "cast from poin=
ter
> > to integer of a different size".  It seems that in several places, poin=
ters
> > (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.  I=
f 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 li=
ke
> a good idea in itself.

There was one warning about it in src/sc2code/

> I agree with your statement about covering up symptoms, so I'll won't app=
ly
> the patch.

Ok.  Perhaps I'll look into what that code is doing, and see if I can put
together a better fix.

> > > 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 commen=
ts
> > 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.

My patch is exceedingly minimal, as all it does is remove the extra
function declaration (which never should have been put inside another
function to begin with).  Even if it's totally unused code, please consider
applying the patch just to get rid of the silly compiler warning (which
might distract other people from real bugs).

> > > 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 underst=
and
> what you mean.

Yes, I know, C is stupid like that.  My code above actually does it right,
since it casts to an unsigned type (COUNT) before doing the % operator.

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

Well, the current WRAP_VAL function doesn't do any checks, and will have
unexpected results for values outside the normal range.  My equivilant code
above is more consistant (it will always return a value between 0 and w-1).

> > 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 "compariso=
n 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 (CO=
UNT
> > is unsigned).  The other two possible result values are pMS->CurState a=
nd
> > pMS->CurState - (EMPTY_SLOT + 3), which then get compared to PLANET_LAN=
DER
> > (which has the value 0).  This whole mess has the same effect as the co=
de 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 g=
oing
> 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.
=20
> > 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.

I understand what WRAP_VAL is for, and I think it does an ok job of it (may=
be
not the best, as I say above, but certainly good enough).  My point is that
I do not think that WRAP_VAL is what we want at the place my patch changes.
Please look at the code and consider my point.

We call the DisplayLanders function in two cases, when pMS->CurState is equ=
al
to PLANET_LANDER (if we just bought a new lander) and when pMS->CurState is
equal to EMPTY_SLOT + 3 (if we have just sold a lander).

WRAP_VAL is the wrong thing to call.  It happens that WRAP_VAL(pMS-CurState,
EMPTY_SLOT + 3) =3D=3D PLANET_LANDER, when pMS->CurState is EMPTY_SLOT + 3,=
 so the
existing code works, but it's not very clear what we're checking, is it?

Loot at the other places where the value of pMS->CurState is being checked.
Here's one example (from higher up in outfit.c):

		switch (NewState =3D pMS->CurState)
		{
				case PLANET_LANDER:
				case EMPTY_SLOT + 3:
						old_slot_piece =3D pMS->delta_item < GLOBAL_SIS (NumLanders)
										? PLANET_LANDER : (EMPTY_SLOT + 3);
						LastItem =3D MAX_LANDERS - 1;
						break;
				...[other cases]...

These are the same cases that get checked later on where my patch is applie=
d.

--=20
Steven Barker                                      st...@bl...
  Artistic ventures highlighted.  Rob a museum.
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] Installer suggestions and experiences.

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

* Serge van den Boom (sv...@st...) wrote:
> Hi,
> 
> Though the next release will likely take some while, we're looking for a
> Windows installer program suitable for our needs. The one we used before
> (createinstall) had some problems and we're looking for alternatives and
> your experiences with them.
> <...>

I suggest you use the Windows Installer APIs. That way you can pretty much
do what you want, and the Windows Installer subsystem in Win32 takes care of
all the ugly bits for you. Most people these days will have the runtime
installed, and it's free to use, as it's pretty much part of the Win32 core
spec by now.

Look here:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/msi/setup/windows_installer_start_page.asp

Cheers,

  -- danp

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

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

On Sat, 28 Dec 2002, TD wrote:
> 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 :-\
I've committed this Melnorme fix. The other patches, I'll leave around for
a while. If they're still relevant after the new resource system is done,
I'll take another, closer look at them.

Meep-Eep

Re: [Sc2-devel] Installer suggestions and experiences.

[J <Sp...@th...>]

How about Wasabi?
The nullsoft installer..
----- Original Message -----
From: "Serge van den Boom" <sv...@st...>
To: "Ur-Quan Masters developers" <sc2...@li...>
Sent: Sunday, December 29, 2002 2:57 PM
Subject: [Sc2-devel] Installer suggestions and experiences.


> Hi,
>
> Though the next release will likely take some while, we're looking for a
> Windows installer program suitable for our needs. The one we used before
> (createinstall) had some problems and we're looking for alternatives and
> your experiences with them.
>
> Some requirements:
> - It should be free to use. Both the building the installer as the
>   use of the installer itself.
> - It should allow optional install of components.
> - It should work on every Windows version since Windows 95 (except for
CE).
> - The installer should be running at an acceptable speed, both for
>   many small files and for large files.
>   Though the many small files we had in the earlier version will be packed
>   together for future releases.
> - It should be able to handle system-wide installs of .dll's, registering
>   them with the system.
> - It should be able to run an external program (for setup of OpenAL,
>   directX).
> - It should be easy to reuse. That is, when the config is done once,
>   making a new installer after a change in the source should not require
>   starting from scratch. Preferably, the build could be run from the
command
>   line.
> - It should be easy to make variations of the file for various install
>   binaries (without voices, without alternative music tracks, etc).
>   This might mean script-parsable config files.
> - The installer should be able to handle uninstall.
> - The installer should preferably look good, and be able to show
>   pictures while installing.
>
> If you know something that meets this requirement, or even have experience
> with one, we'd like to hear about it.
>
> Greetings,
>
> Serge
>
>
>
>
> -------------------------------------------------------
> 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] Installer suggestions and experiences.

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

Hi,

Though the next release will likely take some while, we're looking for a
Windows installer program suitable for our needs. The one we used before
(createinstall) had some problems and we're looking for alternatives and
your experiences with them.

Some requirements:
- It should be free to use. Both the building the installer as the
  use of the installer itself.
- It should allow optional install of components.
- It should work on every Windows version since Windows 95 (except for CE).
- The installer should be running at an acceptable speed, both for
  many small files and for large files.
  Though the many small files we had in the earlier version will be packed
  together for future releases.
- It should be able to handle system-wide installs of .dll's, registering
  them with the system.
- It should be able to run an external program (for setup of OpenAL,
  directX).
- It should be easy to reuse. That is, when the config is done once,
  making a new installer after a change in the source should not require
  starting from scratch. Preferably, the build could be run from the command
  line.
- It should be easy to make variations of the file for various install
  binaries (without voices, without alternative music tracks, etc).
  This might mean script-parsable config files.
- The installer should be able to handle uninstall.
- The installer should preferably look good, and be able to show
  pictures while installing.

If you know something that meets this requirement, or even have experience
with one, we'd like to hear about it.

Greetings,

Serge