The GUI part of UltimateStunts will probably be created earlier than planned. That's why I am starting this thread about how the GUI should be implemented.
Just to make things clear:
The purpose of the GUI program is to make it easy for users to start a game session.
The user just starts the GUI program, fills in whether he wants to start a game session, or to join an existing session, and the GUI program automatically starts the client(s) (and/or server), whatever is needed. It will also take care of a graphical frontend for the configuration files.
We need to know which graphics-library we will use.
There are several options, e.g.:
A-the windows API
B-Qt, GTK etc.
C-SDL, Clanlib etc.
There are also several reasons why (not) to choose a specific API:
1-Platform dependence / independence
2-Easy/difficult to learn programming
3-Efficient/inefficient GUI developing
My opinion results in the following scheme:
/ | 1 2 3 4
A | - - + -
B | 0 0 + 0
C | 0 ? ? +
D | + + - +
I personally prefer D, because UltimateStunts already has a openGL/glut dependence, openGL and glut are available on almost ANY platform, and because really nice results are possible.
What kind of GUI do we want?
Of course we can make it look like the original Stunts starting screen (you know, with those traffic signs "opponent", "car", etc.). But then I want it to look better. We could make some kind of rendering in a professional modeller, like 3D Studio.
It should have the possibility to go fullscreen. I think it was the game "worms 2", which had a non-fullscreen configuration tool, and (in my opinion) it looked ugly. Of course, users should be able to choose for this, but it shouldn't be default. Just like a windowed game-screen shouldn't be default.
It shouldn't use a "standard" widget-set. Widget-sets with user-defineable themes (like in Qt and GTK) are acceptable, but those standard windows-like grey buttons shouldn't exist in a game.
Why not implementing the "GUI" into the client?! I think the purpose of the GUI should be (for example):
* choosing cars
* choosing tracks (if you do not play on a remote server)
* view highscores
* selecting a server where you want to play
We could implement a GUI into the existing client, but also allow to skip the GUI by setting the parameters using some command line switches or parameters. If you run a local game, the client could just run a server on localhost and connect to it.
Anyway it does not really matter if we write a third (GUI-)program or implement that stuff into the client, but I think it will be nicer if these two work together...
As graphic library I would choose SDL (SDL offers a lot of more features for developing games than just glut/opengl, but also allows you to programm opengl games), because I know it well and I know that there are some nice widget libraries around for SDL we might want to use. I would not like to use Gtk/qt/windowsAPI !!!
I agree about the purposes. Let me list some things:
A: before playing
* Selecting to either join a remote game, or start a local server
When joining a remote game:
-> Enter the hostname+port
When starting a local server:
-> Select a track
-> Enter server portnumber
-> Enter number of human and AI players
-> Choosing AI opponents and their cars
* Choosing a car
*Setting graphic and sound options, directory setting etc.
B: After playing
* Viewing the highscores
I'm not sure about the replays. Viewing a replay requires a large part (almost any part) of the client program. On the other hand, the replay viewer requires some GUI functionality, like the forward/backward buttons. This is a reason to integrate both.
Let me tell the pre-history of UltimateStunts.
I don't know when (probably 2001), but I started the first attempt as a C program using svgalib. I found out that there was a way in svgalib to put texture on triangles, so I became enthusiastic about its possibilities (I didn't have openGL). But after developing test-programs for a while, I discovered problems that could not be solved. I had to switch to a different library. This meant rewriting EVERYTHING I made till then.
My next Linux-distro had Mesa in it, so I could start writing openGL applications. The only way I knew for doing this, was via the Qt widget-set. Unfortunately, these applications weren't accelerated on voodoo-1 boards. And, more important, when I installed another distribution, I was unable to recompile these applications. So I started searching for an alternative.
This is how I found a tutorial on how to get 3dfx acceleration using Mesa+glut. Glut seemed to be pretty simple; I didn't need all those Qt widgets. And, it was VERY platform-independent: I was able to compile from the same sources on both Linux and windows boxes. So I switched to glut.
Unfortunately, I didn't write the Qt versions in a very clever way. So, again, I had to restart from the beginning.
From then on, I became very careful with library dependencies. I choose the libraries carefully (portability, platform independence, future needs etc.), and I minimise the number of classes depending on the library.
So, do we want to get a SDL dependence? I first want to get a clear view of what SDL is.
Let me list some advantages / disadvantages:
+ Easier, faster programming
+ More efficient program (the library is made by more progessional programmers)
+ (possibly) nicer graphics
- Platform dependence, inherited from library
- Compilation difficulties (finding the library, version conflicts etc.)
I want UltimateStunts to be compatible with at least the following platforms:
* Linux (i386, ppc, alpha etc.)
* windows, using Cygwin
* Mac OS/X
I also got mails from a user on a Solaris SPARC computer, so it would be nice when all unices are supported.
SDL supports Linux, Win32 (including Cygwin), BeOS, MacOS, Solaris, IRIX, and FreeBSD, so in my opinion this is acceptable.
The next thing is the compilation. I would like to see an example of how a typical openGL/SDL program can be compiled on any of the targeted platforms.
Okay, I can imagine that all problems will be solved one day, especcially because you claim to be a SDL-expert. Then, we could decide to port the client-program to SDL. This shouldn't be too difficult, because I only have one class with glut-dependence, and a few others with openGL-dependence, but the even openGL code can probably remain unchanged.
Because SDL is pretty platform-independent, I see no big problems appearing. So my proposal is to do the following:
1: Port the client from glut to SDL in one of the next releases, touching as few code as possible (that is: only grapics.cpp and callback.cpp).
2: Optimise some definitions (graphics.h and callback.h) to fit SDL better. This requires updating more cpp-files.
3: Define a (set of) classes for developing the GUI, integrated into the client.
4: Implement the GUI.
It could be possible to use SDL also as a sound library, butSDL is not able to handle 3D sound (as far as I can see on their website). So, I think it's better to continue using fmod and openal. (there is an openal-implementation based on SDL, but that's less relevant to us).
SDL will also be useful for creating 2D graphics, like the dashboard. This might be faster than openGL 2D graphics, but that probably depends on the hardware and the openGL- and SDL-implementations.
Thanks, good descision.
SDL also freatures good timing functions that work platform independent. So there will be no more need to fetch milliseconds from the gettimeofday() function :)
In addition it has support for platform indepedent threads. Maybe after switching to SDL we can compile a native Win32 version without cygwin...
About the timer and threads, I agree as far as we are talking about the graphical client.
But the server will also need timer- and thread-functionality. And I don't want the server to be dependent of ANY kind of graphics library. Are you sure that the SDL timer and thread-API's can still be used on (UNIX-)boxes without graphics-output? e.g. can SDL be compiled without video- or sound-support?
What do you mean with a "native win32-version without cygwin"? Something compiled with VisualC++? Something without the need for a UNIX-environment?
The current UltimateStunts depends in several ways on UNIX-environments:
-It uses the BSD socket library (very common in UNIX-land, but windows-developers probably use winsock or directplay (?I am not a windows-developer).
-It sometimes uses typical UNIX-headerfiles
-The compilation process is configured in a typical UNIX-way, with configure-scripts, Makefile's etc.
If you do not want the server to depend on a graphic library (like SDL), you could link the library static (into the executable). It will also just include the code we use, so all the graphic code in SDL will not be included.
Right, the network stuff will probable not run on windows.
VC also knows Makefiles (nmake I think).
One example why a GUI in the client is better:
After a race you want to see the highscore and some statistics about the last race. This should be displayed by the gui, but only the client (and the server?!) doeknow that. Then we would need some complicated interprocess communication (that will never run on windows :) )... Or share that information using textfiles :D ?!?!
Okay, highscores are a problem. Replays too. I am beginning to think you're right.
The reason to keep the two separate is to keep both source trees simple. An integrated program will contain routines for 3D graphics, network traffic, sound, user interface, input devices, file loading, etc. Of course this is not a real problem, so it will probably better to avoid the problems of having separate programs.
Another advantage of having separate programs is to keep library dependences separate. But of course, this can be avoided at compile-time, by providing the possibility to make a version without GUI.
And, for commandline-freaks (why would they play this game anyway?), we could also add a commandline-option like "--nogui", in order to get all options from commandline, instead of from the built-in GUI.
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.