Portability?
Moderator: Moderators
Concerning keeping our porting branch up to date, would it be possible to give me a read-only access to the main CVS ? This would allow me to merge your changes into the porting branch, to stay properly in sync.
Otherwise never mind, but it'll make merging the changes a little more painful for me (with a cvs access I can use svk, which does automagic merging between CVS and Svn).
Otherwise never mind, but it'll make merging the changes a little more painful for me (with a cvs access I can use svk, which does automagic merging between CVS and Svn).
Would it be possible to get a quick briefing on the interaction of SpringClient, Lobby, server ?
From what we were able to deduce from the code, server is the master account/running games server, lobby is the online "presence" of a currently running game; SpringClient connects and authenticates to server, retrieves a list of registered lobbies, and from there goes on to a specific lobby, the game is set up, taspring ('rts' module) is launched and playing begins.
Is this somewhere near the truth? We haven't looked at the code in great detail yet, but we'd like to have an overview of how all this interlocks before starting to hack away on it.
Thanks
From what we were able to deduce from the code, server is the master account/running games server, lobby is the online "presence" of a currently running game; SpringClient connects and authenticates to server, retrieves a list of registered lobbies, and from there goes on to a specific lobby, the game is set up, taspring ('rts' module) is launched and playing begins.
Is this somewhere near the truth? We haven't looked at the code in great detail yet, but we'd like to have an overview of how all this interlocks before starting to hack away on it.
Thanks
Basically, the stuff in the directory Lobby is not used at all. Should probably remove it I guess.
server is the master server that SpringClient connects to, and which is currently run on the same machine that hosts the webpage. It keeps track of the chatrooms and the list of running games.
When hosting a game, SpringClient tells the master server of IP and settings so other players can find it. The communication between the host and players joining that game is handled by SpringClient itself though, so that traffic does not go through the master server. When the host and players have setup alliances etc, SpringClient creates a file "script.txt" and launches spring with script.txt as parameter.
Jouninkomiko can provide more details since he has written both server and springclient, but I think the above is pretty much correct at least. :)
server is the master server that SpringClient connects to, and which is currently run on the same machine that hosts the webpage. It keeps track of the chatrooms and the list of running games.
When hosting a game, SpringClient tells the master server of IP and settings so other players can find it. The communication between the host and players joining that game is handled by SpringClient itself though, so that traffic does not go through the master server. When the host and players have setup alliances etc, SpringClient creates a file "script.txt" and launches spring with script.txt as parameter.
Jouninkomiko can provide more details since he has written both server and springclient, but I think the above is pretty much correct at least. :)
Okay, that would explain why we didn't understand how lobby and server interacted :D
Thanks for the pointers. So we now have:
- Ace07 and Coryrc working on SpringClient (GUI and Utility submodule respectively)
- Gramuxius working on server
- Myself on the game engine itself, the 'rts' module in the source code (currently preliminary stages of cleaning up the code for gcc)
Muldy was also interested in helping out, but given that the need to port lobby has just vanished, I'll see with him what else there is to do that he feels like helping out with.
Thanks for the pointers. So we now have:
- Ace07 and Coryrc working on SpringClient (GUI and Utility submodule respectively)
- Gramuxius working on server
- Myself on the game engine itself, the 'rts' module in the source code (currently preliminary stages of cleaning up the code for gcc)
Muldy was also interested in helping out, but given that the need to port lobby has just vanished, I'll see with him what else there is to do that he feels like helping out with.
I'll announce it here, because the only place I'm fairly certain all porters come to right now is the forum :)
After 48 hours battling with the code, I've managed to merge the new source tarball into the porting tree. However, this has involved moving a lot of the repository structure around. I have done the restructuring and merge on my own server, and now need to replace the online repository with the one I built here. That essentially means destroying the online repository and reuploading my local copy.
The problem being that you, the porters, probably have a working copy already. The working copies you have will no longer be valid after the repository switch. That essentially means that any local modifications that you keep will also be lost.
Well, you could copy the files into the new working copy and commit, but for a totally unrelated reason, I'd rather you didn't: the line endings in the current repository are completely messed up, and therefore in your local copies also. This confuses the hell out of Subversion and Svk when trying to merge code. In the new repository I took special care to convert all line endings to unix-style, so that Subversion could work out how to convert them depending on your system.
Anyway, bottom line is:
- You need to commit any changes you want to keep to the repository
- Notify me that you've done so (by pm, or on irc)
- Once I get the go-ahead from all of you, I'll merge all your changes into the new repository and upload it on OpenSVN
- After that, you can check out a new working copy and continue where you left off.
That'll mean something like not actually doing anything for up to 24hrs (because we're all in different timezones, passing messages around might take some time). That kind of sucks, but if it means that we can continue working on clean source code and that it's easier to merge what SY is doing on their code, then I think it's time well spent doing it now, when it's still early stages.
After 48 hours battling with the code, I've managed to merge the new source tarball into the porting tree. However, this has involved moving a lot of the repository structure around. I have done the restructuring and merge on my own server, and now need to replace the online repository with the one I built here. That essentially means destroying the online repository and reuploading my local copy.
The problem being that you, the porters, probably have a working copy already. The working copies you have will no longer be valid after the repository switch. That essentially means that any local modifications that you keep will also be lost.
Well, you could copy the files into the new working copy and commit, but for a totally unrelated reason, I'd rather you didn't: the line endings in the current repository are completely messed up, and therefore in your local copies also. This confuses the hell out of Subversion and Svk when trying to merge code. In the new repository I took special care to convert all line endings to unix-style, so that Subversion could work out how to convert them depending on your system.
Anyway, bottom line is:
- You need to commit any changes you want to keep to the repository
- Notify me that you've done so (by pm, or on irc)
- Once I get the go-ahead from all of you, I'll merge all your changes into the new repository and upload it on OpenSVN
- After that, you can check out a new working copy and continue where you left off.
That'll mean something like not actually doing anything for up to 24hrs (because we're all in different timezones, passing messages around might take some time). That kind of sucks, but if it means that we can continue working on clean source code and that it's easier to merge what SY is doing on their code, then I think it's time well spent doing it now, when it's still early stages.
Erm, I have managed to get misunderstood :/
The restructuring I'm talking about has nothing to do with the actual code structure, only the "supporting structure" the repository has to handle merging Clan SY's mods into our code.
Restructuring the actual code itself we won't do at all for the time being, and if we do decide to, it won't be without prior discussion with SY.
The restructuring I'm talking about has nothing to do with the actual code structure, only the "supporting structure" the repository has to handle merging Clan SY's mods into our code.
Restructuring the actual code itself we won't do at all for the time being, and if we do decide to, it won't be without prior discussion with SY.
Sure.
The repository has been moved to a server which packs a little more kbps. You can now check out a copy of the porting tree at
https://lolut.utbm.info/svn/taspring_linux/trunk/
Not much has changed yet. I've been mostly taken trying to manage the repository (syncing cvs to svn is a bitch to get right); gramuxius has been working on making the server code more portable, and ace07 and coryrc have been discussing library choices and getting a basic GUI up. The wiki stays at the same location for now.
The repository has been moved to a server which packs a little more kbps. You can now check out a copy of the porting tree at
https://lolut.utbm.info/svn/taspring_linux/trunk/
Not much has changed yet. I've been mostly taken trying to manage the repository (syncing cvs to svn is a bitch to get right); gramuxius has been working on making the server code more portable, and ace07 and coryrc have been discussing library choices and getting a basic GUI up. The wiki stays at the same location for now.
can you convince me
Hello,
I have nearly finished to compile everything.
When it'll be done, i'll commit and I'll post a list of parts/tasks to share.
-------------------------------------------------------------------------
Meanwhile, I would like come back to an old discussion (sorry) :
GLUT vs the rest of the world.
The rest of the world beeing SDL (again) and allegro
http://allegrogl.sourceforge.net/
http://www.talula.demon.co.uk/allegro/o ... legro.html
http://www.libsdl.org/index.php
Can one of you make sure (again) that it is so stupid to use one of these libs even partially.
I'll take allegro example : the GL API seems totally preserved, so changes in the code wouldn't be so big. It seems the same with SDL.
My fear is that starting to port everything, we begin to rebuild an allegro or STL-like small lib for our own usage instead of taking one already writen for us : open images, network independently from plateform.
i.e. : list pros and cons of allegro/SDL/various glut impementations
... for my peace of mind
very important things : GL code must not be rewriten and the use of one of these libs musn't be to intrusive + must compile with VC++ and gcc. Are these libs so intrusive.
goal : ease port enhance future maintainability on 2 and more platforms
By the way, can openglut be compiled with vc++?
One clue :
Unreal Tournament
Tribes 2
Soldier Of Fortune
Neverwinter Nights
ports seems to use SDL
GLUT, SDL are doing basically the same thing but SDL seems to be better maintained.
I have nearly finished to compile everything.
When it'll be done, i'll commit and I'll post a list of parts/tasks to share.
-------------------------------------------------------------------------
Meanwhile, I would like come back to an old discussion (sorry) :
GLUT vs the rest of the world.
The rest of the world beeing SDL (again) and allegro
http://allegrogl.sourceforge.net/
http://www.talula.demon.co.uk/allegro/o ... legro.html
http://www.libsdl.org/index.php
Can one of you make sure (again) that it is so stupid to use one of these libs even partially.
I'll take allegro example : the GL API seems totally preserved, so changes in the code wouldn't be so big. It seems the same with SDL.
This way, there would be only one dependancy (no need of openal...).AllegroGL is an Allegro add-on that allows you to use OpenGL alongside Allegro -- you use OpenGL for your rendering to the screen, and Allegro for miscellaneous tasks like gathering input, doing timers, getting cross-platform portability, loading data, and drawing your textures. So this library fills the same hole that things like glut do.
My fear is that starting to port everything, we begin to rebuild an allegro or STL-like small lib for our own usage instead of taking one already writen for us : open images, network independently from plateform.
Is there someone who want to study SDL/allegro APIs a bit more deeply to check their usefullness, we would use at least the sound API.There are also a few libraries that generally go hand-in-hand with SDL, notably SDL_net (for networking) and SDL_image (for loading image files). All these libraries work on Mac OS X, Windows and Linux nearlyidentically.
i.e. : list pros and cons of allegro/SDL/various glut impementations
... for my peace of mind
very important things : GL code must not be rewriten and the use of one of these libs musn't be to intrusive + must compile with VC++ and gcc. Are these libs so intrusive.
goal : ease port enhance future maintainability on 2 and more platforms
By the way, can openglut be compiled with vc++?
One clue :
Unreal Tournament
Tribes 2
Soldier Of Fortune
Neverwinter Nights
ports seems to use SDL
GLUT, SDL are doing basically the same thing but SDL seems to be better maintained.
Would someone managing the linux port tell me how hard it is to embedd Mono in the linux version?
Since I havent been able to easily embedd Mono on Windows (I dont have a linux box), I was wondering if it would be doable to implement embedding Mono under Linux and then the MS .NET framework under windows(which is ease)
Or at least untill someone tells me how the heck I embed Mono into a win32 C++ app compiled with Visual C++ .NET 2003 (as a native app, not as a .net app)
Since I havent been able to easily embedd Mono on Windows (I dont have a linux box), I was wondering if it would be doable to implement embedding Mono under Linux and then the MS .NET framework under windows(which is ease)
Or at least untill someone tells me how the heck I embed Mono into a win32 C++ app compiled with Visual C++ .NET 2003 (as a native app, not as a .net app)
Have you even looked at Mono? Cos that isnt even close to what it does.Ace07 wrote:We won't be using Mono, because it creates exe files. Mono uses wine to then load the EXE's and play them. This is not as efficient as just having a Linux binary file, and a windows binary file.
The "exe" file format that is produced when you compile Mono applications is run by Mono. Nothing todo with WINE.
I want to use Mono as an embedded thing, were it implements a high preformance scripting engine for us. Not to run the entire damn program under.