Merging shaped_arenas into HEAD (complete)

[Luke-Jr]

armagetronad\src\tron\gParser.cpp(15) : fatal error C1083: Cannot open include file: 'unistd.h': No such file or directory

Fixed, maybe. Make sure HAVE_UNISTD_H isn't defined in your config.h...

armagetronad\src\tron\gParser.cpp(109) : error C2057: expected constant expression
armagetronad\src\tron\gParser.cpp(109) : error C2466: cannot allocate an array of constant size 0
armagetronad\src\tron\gParser.cpp(109) : error C2133: 'axisDir' : unknown size

wow... picky; try now, I changed the code style =p

armagetronad\src\tron\gParser.cpp(329) : error C2065: 'mkdir' : undeclared identifier

no mkdir?!?! WTF kind of "OS" is this?

The strncasecmp is solved with this (can anyone commit this?):

Code: Select all

#ifdef WIN32
#define strncasecmp strnicmp
#endif

stuck it in for now... we should move stuff like this to a header file someday...

[philippeqc]

Um, phil? UTF-8 can represent all of those languages, that's why it's the encoding of GNOME. And I think KDE too.

UTF-8 has as its first set of characters the old ASCII set, but it's much bigger than that, using up to 3 bytes to represent a character, which is 8*8*8, or 512 total characters it can contain.

At least, last I checked UTF-8 could handle them all......

Everyone read this: http://www.cl.cam.ac.uk/~mgk25/unicode.html#utf-8

and this http://www.joelonsoftware.com/articles/Unicode.html (yes, I need to read it again ty)

-ph

[Z-Man]

I just noticed you ( primarily Luke_Jr ) are merging changes from HEAD into the branch. AFAIK, this is asking for trouble for the final merge. cvs -q update -j shaped_arenas from the head ( I won't commit the result, don't worry ) already produces some conflicts because the changes in HEAD are now there twice. Nothing serious yet, but look out.

If you ask me, the correct and safe way to keep the branch you're working on up to date ( I assume that's what you're intending ) would be to merge the BRANCH to your local copy of the HEAD and start a new branch from there ( that's why I gave all my branches the version they started from as an additional label ).

[klax]

no mkdir?!?! WTF kind of "OS" is this?

No comments

[Lucifer]

Everyone read this: http://www.cl.cam.ac.uk/~mgk25/unicode.html#utf-8

Did... a long time ago... back when I was implementing UTF-8 support for the MOO programming language =p

Yep, read the same page when I was working on the very first version (in C++) of my keyword extractor.

[Luke-Jr]

I just noticed you ( primarily Luke_Jr ) are merging changes from HEAD into the branch. AFAIK, this is asking for trouble for the final merge.

CVS doesn't seem to handle merges well at all. Even merging changes from HEAD creates fictional conflicts.
I guess this is why most projects do primary development in HEAD and branch for versioned releases...

cvs -q update -j shaped_arenas from the head ( I won't commit the result, don't worry ) already produces some conflicts because the changes in HEAD are now there twice. Nothing serious yet, but look out.

Actually, I'm getting a lot of "cvs/win32/config.h already contrains the differences between 1.2 and 1.2.10.1", so it must be making *some* effort to prevent problems.
From what I can see, the only problems are in the same files I have problems merging HEAD to shaped_arenas for: .cvsignore and settings_dedicated.cfg
nNetwork.cpp seems to have a few problems also, but from an initial look, it would suggest that it is because shaped_arenas needs yet another HEAD update.

If you ask me, the correct and safe way to keep the branch you're working on up to date ( I assume that's what you're intending ) would be to merge the BRANCH to your local copy of the HEAD and start a new branch from there ( that's why I gave all my branches the version they started from as an additional label ).

That sounds like it might work... Not sure if it will do any good on this branch, however.

[Luke-Jr]

no mkdir?!?! WTF kind of "OS" is this?

No comments

Try now.

[Z-Man]

CVS doesn't seem to handle merges well at all. Even merging changes from HEAD creates fictional conflicts.
I guess this is why most projects do primary development in HEAD and branch for versioned releases...

CVS uses the same algorithms for merges as it uses for updates, as far as I know. As long as no two concurrent changes changed the same line or added lines in the same place, everything is fine.

An exception to this rule is when the two changes are exactly identical; then you get these "already contains the changes" messages. You should read them as "There almost was a conflict".

I think, but of course there's no way to be sure, that you would not have gotten any conflicts or other strange messages at all without the merging from head stuff.

You're right about none of this having a real benefit on this branch. Maybe the best way to handle things without too much pain is to continue merging in the changes from the trunk now that you started with it. As long as it's you and not me who has to resolve those phony conflicts, I'm fine with it

Another possible way of handling "branches" of this kind would be "ifdefs"; I reckon you mainly added new files with new features and did small adaptions to other files to use them. The new files can be completely wrapped in one huge #ifdef NEW_FEATURE, and the places that use them with small #ifdef blocks. It's not pretty, but if you want to work on something big and new and want to keep the rest of the sources up to date, it's the only way I see possible with CVS.

[klax]

Nice job: now there's only one error (the one you love juke-jr )

Code: Select all

armagetronad\shaped_arenas\armagetronad\src\tron\gParser.cpp(425) : error C2065: 'mkdir' : undeclared identifier

This is solved including direct.h in windows before defining the mkdir macro (commit it please):

Code: Select all

#ifdef WIN32 
#include <direct.h>
#define strncasecmp strnicmp
#define mkdir(x, y)	mkdir(x)
#endif

Tested and now all this branch works (except the png save as in head grrr)

Edit: for those who want to test it and experiment with maps here is a windows shaped_arenas branch build (I've copied /resource/included/original/map-1.0.xml to /resource/original.xml and disabled by default png save grrr)
AA shaped_arenas branch windows client cvs

Next important thing to solve IMO: the stretched textures in walls when they are not orthogonal

[Luke-Jr]

Nice job: now there's only one error (the one you love juke-jr )

Code: Select all

armagetronad\shaped_arenas\armagetronad\src\tron\gParser.cpp(425) : error C2065: 'mkdir' : undeclared identifier

This is solved including direct.h in windows before defining the mkdir macro (commit it please):

Code: Select all

#ifdef WIN32 
#include <direct.h>
#define strncasecmp strnicmp
#define mkdir(x, y)	mkdir(x)
#endif

Tested and now all this branch works (except the png save as in head grrr)

*stabs win32* ok ok

Edit: for those who want to test it and experiment with maps here is a windows shaped_arenas branch build (I've copied /resource/included/original/map-1.0.xml to /resource/original.xml and disabled by default png save grrr)
AA shaped_arenas branch windows client cvs

*Why* did you copy the file like that? It should be in ./resource/included/original/map-1.0.xml
Nothing should reference "original.xml" anymore... Found (and fixed) original.xml referenced as a default in gGame.cpp, but that shouldn't be used anyway since it's specified in settings.cfg... Either way, *nothing* in distribution should ever be in ./resource/ directly. *Everything* included should be in ./resource/included/ !!!

Next important thing to solve IMO: the stretched textures in walls when they are not orthogonal

wtf? no idea what you mean...

[Luke-Jr]

For a limited time only! Fixed versions of klax's win build w/o the copied resource: http://utopios.org/~luke-jr/tmp/AAsa/

[Z-Man]

Next important thing to solve IMO: the stretched textures in walls when they are not orthogonal

wtf? no idea what you mean...

The texture coordinates of rim walls are generated as just x+y ( or similar ) which only looks good with walls that go in either the x or y direction. Diagonal walls in one of the directions get no proper texturing at all, because all their points will get assigned the same texture coordinate.

[Luke-Jr]

Next important thing to solve IMO: the stretched textures in walls when they are not orthogonal

wtf? no idea what you mean...

The texture coordinates of rim walls are generated as just x+y ( or similar ) which only looks good with walls that go in either the x or y direction. Diagonal walls in one of the directions get no proper texturing at all, because all their points will get assigned the same texture coordinate.

hmm... interesting. never noticed that before o.o
not sure how to go about fixing it, tho :\

[philippeqc]

(I've copied /resource/included/original/map-1.0.xml to /resource/original.xml and disabled by default png save grrr)

A question for all OS (sorry if I dont disuss Mac, but I just dont know how stuff is structured in it): where should the base folder for the resources be? Before, as the resources had to be downloaded manuallly, the person doing it dealt with permissions and such. But now with the POSSIBILITY of automatic download, its a bit more complicated.

Do the bundled resource go on with the application binaries
linux/unix: /usr/games/aa/resources ...
windows: c:\programs\aa\resources ...

Do the manual and automatic resoures go into "user space" (I know it doesnt mean THAT)
linux/unix: ~/[.]armagetronad/resources ...
windows: %USERFOLDER%\Applications Data\armagetronad\resouces ...



-ph

[Luke-Jr]

(I've copied /resource/included/original/map-1.0.xml to /resource/original.xml and disabled by default png save grrr)

A question for all OS (sorry if I dont disuss Mac, but I just dont know how stuff is structured in it): where should the base folder for the resources be? Before, as the resources had to be downloaded manuallly, the person doing it dealt with permissions and such. But now with the POSSIBILITY of automatic download, its a bit more complicated.

Do the bundled resource go on with the application binaries
linux/unix: /usr/games/aa/resources ...
windows: c:\programs\aa\resources ...

OSX: %APP%/Contents/Resources/resources

Do the manual and automatic resoures go into "user space" (I know it doesnt mean THAT)
linux/unix: ~/.armagetronad/resources ...
windows: %USERFOLDER%\Applications Data\armagetronad\resources ...

OSX: ~/Library/Application Support/Armagetron/resources

Yes, this really only makes sense... Otherwise only administrators can play the game!
I'll see about modifying the code to support this...