FreeGameDev

(Following some posts in this thread and this other one)

I made some other tests today on a self-built 0.7.1 STK (internet news disabled, and using the lowest graphical config), with monitors charts and memory usage data (left : STK 0.7.1 - low fps above roughly 60Ktris, right : STK 0.7 with a good fps). I don't know precisely how to interpret these charts (I'm not even sure I chose some relevant data to show ), but I can see one big difference between the 2 : the free video memory. Looks like the 0.7.1 tries to use the less memory possible (or does not manage to get enough), where 0.7 uses a more constant amount of memory.

hiker {l Wrote}:if you can compile stk yourself, it might be worth to try systematically which revision introduced the slowdown.

Yes, this is the best way to know what change is the cause of the slowdown (if this is not an accumulation of things). What are the minimal required folders from the SVN I have to download in order to build several versions of STK ? (to avoid downloading useless data a lot of times...)

Hi, regarding the GPU memory used, you should check with latest SVN, we have improved memory use a lot (it used to leak very hard)

Regarding a minimum set of folders, I'm sorry, I don't think you can.

One interesting thing to check would be whether the switch to irrlicht 1.8 caused this. Maybe you could jump to not long before the 0.7 tag, and build with both irrlicht 1.7 and 1.8
If irrliucht is not at cause, then you can find the problematic very fast by using binary search : start at the revision exactly between 0.7 and 0.7.1, then whatever the result you have eliminated half of revisions; continue a few more steps like this and you should find very quickly

Auria {l Wrote}:Hi, regarding the GPU memory used, you should check with latest SVN, we have improved memory use a lot (it used to leak very hard)

But then again: so was 0.7 - though we have added more features, which could explain some memory increases.

Regarding a minimum set of folders, I'm sorry, I don't think you can.

You should be able to just download the src folder, and at the end copy the executable to the place of your downloaded installation. But note that with SVN when you update to a different version, only the differences will be downloaded, not the while distribution - so usually this is rather small.

And I agree with Auria: knowing if it's caused by the irrlicht upgrade would be important. And afaik stk 0.7.1 should compile just fine with irrlicht 1.7.2

Cheers,
Joerg

OK, thank you for the indications. I forgot about SVN basics ^^'

I get an error compiling the trunk rev. 7500 :

{l Code}: {l Select All Code}

Error : library not found for -lintl

In the xcode project, the /usr/local/ folder is defined, and the lintl library is installed (I could compile the 0.7.1 tag). I tried to comment the following line in xcode project settings, as it is not in 0.7.1, then I replaced -lintl by -lcurl, always as in 0.7.1, but I could not get it work.

{l Code}: {l Select All Code}

OTHER_LDFLAGS = -lintl

Do you have an idea how to get rid of this error ?

Auria {l Wrote}:One interesting thing to check would be whether the switch to irrlicht 1.8 caused this. Maybe you could jump to not long before the 0.7 tag, and build with both irrlicht 1.7 and 1.8

I have a really limited amount of time, so I can't afford searching by myself how to do it. What would I need to do in order to switch Irrlicht version ?

What would I need to do in order to switch Irrlicht version

You can have irrlicht 1.7 (for example) installed system-wide and irrlicht 1.8 compiled in some directory (in my case it is in /home/artem/SVN/irrlicht)
After this you can just configure with no option (I suppose then it'll use those version which is installed system-wide) or configure like this:
./configure --with-irrlicht=/path_to_irrlicht1.8/ (then it'll use 1.8 version)

Hi,

regarding the intl issue, did you run the libintl installer that comes in the OSX dependency package?

I did.
Thank you for the indications KroArtem

No problem, I was also fighting with new irrlicht 1.8 some weeks ago and it is good to share experience

OK. Try adding

"-L/usr/local/lib" to OTHER_LDFLAGS (without the quotes; leave a space between this and other flags)

OK I'll try that, thank you for the help.

Cheers for your 1000th post !


EDIT : didn't work, always the same error.

Here is my xcconfig file (the same than current revision, exept the -lintl flag)

{l Code}: {l Select All Code}

// Xcode build configuration

HEADER_SEARCH_PATHS = /usr/local/include /usr/include /Library/Frameworks/IrrFramework.framework/Versions/A/Headers/ "$(PROJECT_DIR)/../../" "$(PROJECT_DIR)/../../bullet/src" "$(PROJECT_DIR)/../../enet/include" /Library/Frameworks/fribidi.framework/Headers

OTHER_CFLAGS = -Wall -DHAVE_OGGVORBIS=1  -DHAS_SOCKLEN_T -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAS_POLL=1 -DHAS_FCNTL=1 -DHAS_INET_PTON=1 -DHAS_INET_NTOP=1 -DHAS_MSGHDR_FLAGS=1 -DENABLE_NLS=1 -DHAVE_GETTEXT=1 -DHAVE_GLUT=1 -DHAVE_IRRLICHT=1 -DPACKAGE="\"supertuxkart\"" -D__MACOSX__=1 -DHAVE_RTT=0 -DENABLE_BIDI=1 -fvisibility=hidden

OTHER_LDFLAGS = -lintl -L/usr/local/lib
LIBRARY_SEARCH_PATHS = /usr/local/lib /usr/lib


I followed the wiki guide to build STK in OSX, and I was able to build 0.7.1, so I don't understand why I get this error. I'll try another revision...

Sorry, maybe i wasn't clear enough -L/usr/local/lib needs to appear before -lintl

I tried it both ways, same result...
EDIT : I got the same problem with the revision 7750 and 7900 (which have the -L/usr/local/lib option)... I'll re-check the guide to see if I did everything right.

Hmm, that's weird.
Can you issue this on terminal and post the output?

{l Code}: {l Select All Code}

ls /usr/local/lib/libintl.*


I got :

{l Code}: {l Select All Code}

/usr/local/lib/libintl.8.0.2.dylib

Hmmmm weird. Desperate attempt : just remove the -lintl flag, and drag and drop /usr/local/lib/libintl.8.0.2.dylib into the project

It creates a bunch of errors because it doesnt know _libintl_* symbols. The library should be in the root folder of the project (/trunk), or somwhere else ?

Kinsu {l Wrote}:It creates a bunch of errors because it doesnt know _libintl_* symbols. The library should be in the root folder of the project (/trunk), or somwhere else ?

I meant the Xcode project, not the directory in the Finder

I tried in the ide/xcode/ folder (and every sub-folder to be sure), but it does not know _libintl_* symbols either... I didn't have the time to redo completely the operations the guide explains so maybe there's still a little hope ^^... if it does not work, I may then try on Linux.

I still really can't understand why 0.7.1 is totally OK and some revs are not.

No no, I don't mean the Xcode project directory in the Finder... I mean in the Xcode application itself. On the left of the project window is a file with trees, add the library there (not in the Finder)

In this area : http://www.roseindia.net/tutorials/newt ... roller.gif

OK (sorry, I've never used Xcode before ^^' ), it works ! Thank you for your help
I'll now try to locate which revision introduced the slowdown (this may be related to a Bullet or Irrlicht update, in that case we could try to find out with the developers what feature was added, and if we can deactivate it...)

EDIT : When I launch the game, it exits with status 5.

Kinsu {l Wrote}:EDIT : When I launch the game, it exits with status 5.

Not sure what that indicates. Any messages on stdout/stderr?

Otherwise: can you run stk in the debugger?

Cheers,
Joerg

hiker {l Wrote}:Not sure what that indicates. Any messages on stdout/stderr?

Well I did not take the time to see, I built it in 5 minutes of free time I had ^^

hiker {l Wrote}:Otherwise: can you run stk in the debugger?

I think I prefer trying to spend less time on those builds switching to the linux or win version (I'm not used to Xcode tools, so it would take me some time to learn it)... ^^'

When I have more time I'll try to have these revisions built anyway (that would be a pity to stop only because of a linking error :/ )