Page 3 of 3

Posted: 19 Jan 2007, 02:54
by jcnossen
Windows version is compiled with gcc as well, so the only difference could be driver/os related (linux 3d hardware drivers are sometimes slower iirc?)

Posted: 19 Jan 2007, 03:02
by Nonor
hummm... I'm using latests nvidia drivers :-/
The weird thing is that the game is getting slower only when there's a lot of units on the map. The beginning of each game is perfect.

Posted: 19 Jan 2007, 03:17
by det
You are probally not using the native executable. Spring under Wine has a bug where it gets progressively slower.

Posted: 19 Jan 2007, 09:31
by own3d
try simply executing the normal spring binary with ./spring and see if the problem persists.

Posted: 23 Jan 2007, 03:41
by CautionToTheWind
Hey det i don't think your spring.exe works with 74b3. It seems its missing the -v commandline option and starts up instead. If you could be so kind as to provide us with an updated spring.exe to load native spring, it would be greatly appreciated.

Posted: 23 Jan 2007, 09:16
by Tobi
That's right, here is some code that works (added only the if (argc > 1... line):

Code: Select all

#include <windows.h>
#include <stdio.h>
#include <tchar.h>

int main (int argc, char *argv[])
{
  STARTUPINFO si;
  PROCESS_INFORMATION pi;
  LPTSTR szModuleName=_tcsdup(TEXT("/usr/games/spring"));
  LPTSTR szCmdline=GetCommandLine();

  if (argc > 1 && strcmp(argv[1], "/V") == 0) {
  	printf( "Spring 0.74b3\n" );
  	return 0;
  }

  ZeroMemory( &si, sizeof(si) );
  si.cb = sizeof(si);
  ZeroMemory( &pi, sizeof(pi) );
  
  // Start the child process. 
  if (!CreateProcess(szModuleName,   // No module name (use command line)
                     szCmdline,      // Command line
                     NULL,           // Process handle not inheritable
                     NULL,           // Thread handle not inheritable
                     FALSE,          // Set handle inheritance to FALSE
                     0,              // No creation flags
                     NULL,           // Use parent's environment block
                     NULL,           // Use parent's starting directory 
                     &si,            // Pointer to STARTUPINFO structure
                     &pi))           // Pointer to PROCESS_INFORMATION structure
    {
      printf( "CreateProcess failed (%d).\n", GetLastError() );
      return;
    }
  
  // Wait until child process exits.
  WaitForSingleObject( pi.hProcess, INFINITE );
  
  // Close process and thread handles. 
  CloseHandle( pi.hProcess );
  CloseHandle( pi.hThread );

  return 0;
}
Paste it in spring.c and compile with i586-mingw32msvc-gcc spring.c -o spring.exe. I can't upload a drop in spring.exe atm, maybe someone else could do that.

EDIT: The new spring.exe spring launcher (replaces the one in det's post, compiled from above sourcecode):

http://www.osrts.info/~tvo/spring/spring.exe

Posted: 23 Jan 2007, 23:00
by kujeger
Thanks a lot for that code, Tobi. Darn you Betalord for making symlinking not work! Image

I edited my previous guide to use Tobi's file (changed so it works with spring in ./ ), instead of a symbolic link.


http://crom.hio.no/spring/spring-linux-winelobby.txt

Posted: 23 Jan 2007, 23:41
by hollowsoul
actually the version check in TASClient is so other lobbys can inform users that there version of spring is outof data....
kinda requested :lol:

U could just ask Betalord to include in wine console switch for TASClient to use right console switchs (since different on linux)

Posted: 25 Jan 2007, 00:43
by ZellSF
How would I make fake spring.exe launch a script to kill beryl, then restart it after the game's over?

Posted: 04 Mar 2007, 03:16
by krazycure
So, I FINALLY got spring working, even got the tasclient loaded AND connected in wine (!!!!!!!!!) but of course, when I host/join a game whenever the game is launched I'm immediately kicked back into the battle room with nothing but "Back from game".... it doesn't even try to load the native executable as far as I can tell, so what did I do wrong?

Posted: 04 Mar 2007, 09:52
by Tobi
Does it give an error in console?

Like "CreateProcessEx failed" or something like that?

If so, probably /usr/games/spring doesn't exist, which is the native spring binary it tries to load.

Posted: 11 Mar 2007, 19:02
by 10053r
I have a weird problem. Everything works as it should. The only issue is that TASClient thinks I am back from the game instantly, and spring takes like 5 minutes to actually load. Any ideas what is going on?

I installed spring from .deb, and did a bunch of symlinks to make everything be where things wanted them to be.

Re: HOWTO: Play using the Windows lobby with native executab

Posted: 11 Mar 2007, 19:22
by BrainDamage
det wrote:Install OTA Content

Code: Select all

cp ~/.wine/drive_c/Program\ Files/Spring/base/otacontent.sdz ~/spring-data/base/
cp ~/.wine/drive_c/Program\ Files/Spring/base/tacontent_v2.sdz ~/spring-data/base/
cp ~/.wine/drive_c/Program\ Files/Spring/base/tatextures_v062.sdz ~/spring-data/base/
Set symlinks to share maps, mods and demos from native install

Code: Select all

mv -f ~/.wine/drive_c/Program\ Files/Spring/maps/* ~/spring-data/maps/
mv -f ~/.wine/drive_c/Program\ Files/Spring/mods/* ~/spring-data/mods/
rm -rf ~/.wine/drive_c/Program\ Files/Spring/mods/
rm -rf ~/.wine/drive_c/Program\ Files/Spring/maps/
ln -s ~/spring-data/mods/ ~/.wine/drive_c/Program\ Files/Spring/mods
ln -s ~/spring-data/maps/ ~/.wine/drive_c/Program\ Files/Spring/maps
ln -s ~/spring-data/demos/ ~/.wine/drive_c/Program\ Files/Spring/demos
ln -s ~/.wine/drive_c/Program\ Files/Spring/script.txt ~/spring-data/
all those passages can be easily replaced by adding

SpringData=~/.wine/drive_c/Program\ Files/Spring/

to your ~/.springrc file

WARNING: REPLACE THE ~ WITH YOUR PATH TO YOUR HOME FOLDER! (spring doesn't accept relative paths AFAIK)

example code:

Code: Select all

echo "SpringData=$HOME/.wine/drive_c/Program\ Files/Spring/" >> ~/.springrc

Posted: 11 Mar 2007, 21:45
by 10053r
Turns out it was an ownership issue. If root owns the spring executable, it works fine. I had changed it to myself so that TASClient could write to the folder.