Need testers for my little opengl game
 

It's not finished. Most of the game has been tested pretty well, however, I'm having trouble testing the network gameplay portion. I really just started working on the network part, and I suspect that there will be some race conditions that will mess things up. I can only run it on one of my machines at the moment, since one machine is a dinosaur with video card/opengl issues, and the other is being used for an experimental Linux distro that I am working on, and at the moment it only has kdrive xserver (no OpenGL). So, anybody that can test the network portions of my game would be a big help.
Also, I have released the source, so you can look at it if you want, but be warned that I wrote most of it in highschool, so its kinda sloppy. It's licensed under the beerware license.
Here is the link:
http://www.betteros.org/games/download.html

It say: "package is of bad quality" when i attept to install

I'm using cross distro linux mint&ubuntu 12.04 beta.

when i click ignore it fails to install. However my software center seems to be broken somehow.

Oh.. huh, how about that. Well, that's another reason why testing things by myself isn't good enough. I assume its a permission problem, since you don't have a user prushik with uid 1000 on your system. I'll fix the permissions and upload again soon, however, now I have to get to Korean class, so I can't fix it until I get home.
If you are determined to test it, you can try to compile it from source. It's quite easy, just:
gcc ut1l.c -lGL -lGLU -lglut -DAUDIO -lalut -lopenal -o UntitledOne
You can leave out the -DAUDIO part if you don't have openAL or if the sound is too annoying (its not done yet).

~/Desktop$ ./UntitledOne
freeglut (./UntitledOne): glXCreateContextAttribsARB not found

Maybe you should provide more detailled info about required dependencies or how to build and run the program, or a functional debian package.

Just got back from Korean class, now I hopefully I can fix some of these issues.

I think that is either a freeglut problem, or a glx problem. That's the error I get on my old HP laptop (the beast). I'll see if I can debug the problem, but I assumed it was a bug in the very old fglrx drivers that are running on that machine.

Yep, that's a good idea. What I did was pretty slapdash, but now I have time, so I'll see about fixing the debian package.
The dependencies are:
libGL
libGLU
FreeGLUT or GLUT or OpenGLUT (OpenGLUT is untested)

Optional Audio Support:
OpenAL
libalut

Ok, I uploaded a new .deb package, the files are now owned by root instead of prushik, so it should work.
I also added a list of dependencies on the webpage. I also changed the source package to a little tarball with a makefile and a pseudo-configure script. Although just compiling with gcc is still just as easy, ./configure && make is more familiar to many folks.
http://www.betteros.org/games/download.html

now i can't downlaod deb package, ita says 404 error not found.

Yes, sorry, that has been fixed. It was a typo. Sorry. I also added a 32 bit package as well as the 64 bit version.

Also, there is a solution for this, Next source code release will include a fix for this (not so much a fix, more of a workaround, but it makes the game work correctly).

Ok, just uploaded my updated source code. It should fix the glXCreateContextAttribsARB problem, and network play should also work.
Debian packages have been fixed again (hopefully).

Changes:
-missile sound has been changed to something less obnoxious
-explosion sounds are in place, but they suck
-network play connection fixes
-added a (hopefully) more accurate method of measuring time (which can be compiled out by passing -DSLOPPYTIME to gcc)

I get the same error again (glXCreateContextAttribsARB not found).

I have:
GLX version: 1.4
OpenGL version string: 1.4 Mesa 7.10.2

Did you compile from source or use a deb package? I'm pretty sure that the problem is not due to mesa or GLX but rather your video card driver. What video card do you have? Is it an ATI Radeon by any chance?
Nevermind... I checked my source again and I seem to have added the problem code back in...

If you want to get it working, remove line 307 and recompile it and it should work.
The line that says:is the problem, just comment it out or delete it completely and it will compile and run.

Sorry about that.

I could run the game but it's very slow and keys are not working as expected.

Very interesting... I haven't had any trouble with speed. If I disable the timing, then it runs too fast on my machines, even my 6 year old hp laptop (the beast).
However, I have not yet tested the new timing mechanism on more than one machine, so next time I will revert to the old timing mechanism.

Where did you see speed as an issue? During solo gameplay, network gameplay, or in the menus? Are you using 32 bit or 64 bit?

It's really not a very resource intensive game, speed shouldn't be an issue (except in network games).

Something is wrong with keyboard mapping. You probably should fix that first.

Ok, that's strange. Could you describe the problem you are having? Both of my computers have no keyboard issues, although, since the keyboard code was ported from Windows to GLUT, there definitely could be problems with it.

Pressing left and right arrow keys do nothing. On which distro have you tested it?

All testing so far has been done on Lubuntu Precise Pangolin and Ubuntu Maverick Meercat. However, the distribution should make no difference, as I know of no distribution that doesn't use the same combination of Mesa/Xorg/Xinput-drivers, except maybe some of the tiny distros that are still based on the 2.4 kernel series (DSL).
The left and right keys do not have any functionality during the menu, and also while the player is on the ground. A minimum test case for testing those keys would be navigating through the menu to some gameplay mode (Classic, Asteroids, or Targets; Using up and down keys), Selecting that mode (Return key), Leaving the ground (Up key), and then turning either left or right (left and right keys).
Also, it could be helpful to note if the problem is limited to the special keys, or if the problem is also apparent in the wasd keys as well (select classic mode)

Ok, the up key must be used first. But it's still very slow. Maybe you should make the program more configurable (at run time or by allowing command line arguments). I'm on Natty BTW.

What kind of configuration are you thinking of? Something like changing the key mappings? or something else?
Currently, entering a command line argument causes the game to jump into a network game with whatever IP address you entered on the command line, I would like to keep that on the command line even when I consider the game complete, however, I could easily parse other types of arguments if necessary, maybe change to a more GNU getopts argument style, if it was desirable.

Something like --speed=N (form slow to max speed) or anything that's interesting to tweak/test (although I don't know what.) BTW, the key mapping is ok.

I'm hesitant to allow users to configure the speed on runtime, things could get especially hairy in network games if players use different settings.
That being said, I am sure your speed issues are not a resources issue, the game uses very little resources (not even any textures, and sounds are less than 1000 bytes each), so your speed issues must be due to something wrong with my timing system. If you compile with the -DSLOPPYTIME flag, I think your problems will be resolved.
I like the idea of compile-time configuration better than runtime configuration, just from a stance of not wasting resources.

When compiling with -DSLOPPYTIME, I got errors. I could fix them but I still find the game not responsive enough on my box.

Do you have a windows version? I could give it a try on xp and see the original game behaviour.

There wasn't one besides the old outdated Windows version, but it took me like 5 minutes to cross compile a new executable. I had to disable the sound and network though. I don't have Windows on any of my machines, so note that these builds are not tested at all.
I just uploaded them to the website, there is a regular version and a sloppy timings version.
http://betteros.org/games/download.html

Unfortunately, there was some missing dll (libglut-0.dll) and when I finally could grab this one, it was still broken (bad version probably) so...

Oops, sorry about that. It should be fixed now, I compiled it statically so that it shouldn't depend on any dll's.
However, for reference, I used FreeGLUT instead of GLUT, although I thought they were binary compatible.
If you re-download, hopefully it will work.

I still got the same error (missing libglut-0.dll).

Interesting.... Cross compiling for Windows is weird.. I'll package my libglut-0.dll with the executable and upload it again soon.

Ok, I replaced the exe file on the download page with a zip file containing both executables and the dll needed to run them. Still not sure why the executables are linked to that dll, since I never even installed that dll in my toolchain...
http://betteros.org/games/download.html

I got a crash (bsod). For which version of windows is it compiled?

Maybe you should make a portable version including all required dll's to avoid that. Anyways, if you're cross-compiling, it's not that easy...

just reporting that the game runs fine on my system (Linux lolwabbit 2.6.39-gentoo-r2 #9 SMP Wed Dec 14 18:31:40 CET 2011 x86_64 Intel(R) Core(TM)2 Duo CPU T9400 @ 2.53GHz GenuineIntel GNU/Linux).

the code looked fairly nice as well. globals are indeed very bad, but you know that, judging by your comment. you should probably divide the game up into more files and use autotools for building it as well. furthermore, I would recommend putting it up on github, which makes collaboration easier. maybe someone will help you. :-)

You have almost the exact same processor as my dev machine: Intel(R) Core(TM)2 Duo CPU P8700 @ 2.53GHz
Thank you.
I would split the source up into multiple files, but I kind of like the fact that everything is contained in one file. That's why I'm even hard coding the sounds into the source, to make sure everything is contained in one file, and compiled into one executable. In any other scenario I would most certainly do that, and when it comes time to make the sequel, it will be done that way from the start. I definitely do not want to use autotools however, IMHO autotools is a huge mess, and I avoid it whenever possible. At this point, compiling is so simple that such a build system shouldn't be needed, however, I realize that many people are familiar with the GNU autotools build procedure, so to accommodate, I have a configure script myself which mimics the GNU autotools syntax and functionality, and can even be used to cross compile. Although I admit that I have been lax in updating it, it still lacks support for enabling sloppy timing, I'll do some work on it today.
As for moving to github, its probably a good idea. Personally, I am not all that familiar with git, for most of my other projects I have been using subversion repositories hosted at Assembla, since Assembla was the only host I could find that wouldn't constrain my license options to copy-left licenses.
So, if it would truly be helpful, and github does not force me to use copyleft licenses, then I will gladly move source to github.

Oh dear.... Sorry about that, my sincere apologies. I didn't even realize that a userspace program was capable of doing that in Windows.... I'm very sorry, I hope no damage was done.
I'll see if I can figure out whats going so wrong with my builds instead of just trying different permutations (which is an antipattern I'm afraid)

I like GNU AutoTools. it has a lot of nice features. admittedly, it is big and messy. you can consider the alternative, which is ever growing in popularity, CMake - https://en.wikipedia.org/wiki/Cmake.

the only constraint that github has, at least to my knowledge, is that if you do not want the source code available, you need to pay for a closed repository. copyleft isn't necessary.

github provides you with some nice features, such as pull requests. this means that a user can fork your project, do some changes, and send you a pull request for their commit. you can review their commit, and pull it if you find it agreeable. it's just all-round pleasant to work with.

git in general is amazing. with svn et al., I'm generally very afraid to bork things on larger projects, and find myself wrestling with the system whenever I need to do something remotely complex. git on the other hand is actually fun to work with. you just hack and play. it's all very pleasant, just like the github.

I believe I have discovered what has caused your BSOD. Neither timing system is functional under Windows, it seems that usleep compiles in minGW, but does nothing, so the game runs at full speed taking up 100% of your CPU. When I get home tonight I will take some time to rewrite the timing system using GLUT alternatives to the POSIX specific code.

Edit: Eh. well, turns out GLUT doesn't have a way to do exactly what I want, its timer callback is basically a busyloop without adding any sleep functions. So, with no platform independent options, I decided to use the preprocessor to use Sleep() instead of usleep if you don't compile on Unix. Now it compiles and runs at the right speed on Windows (well.... it runs on Wine).

Cmake at least looks nicer when it is compiling. I like build systems which use colors. However, really the only thing that a build system needs to do is determine if you are cross compiling, and whether or not GLUT, openAL, and ALUT are available, which are all fairly simple things to do.


Alright, I'll look into possibly setting up a repository later today.

alright, I set up a git repo on github. I think I have done everything correctly, take a look and let me know. Thanks!
https://github.com/prushik/untitledone

BTW, I've tested your game on a linux box with: Ubuntu natty, Intel Atom 1.6GHz processor, 1GB RAM. Does the game need a faster proccessor or more RAM?

It really shouldn't, although, it was developed originally on a 3GHz P4 with hyperthreading; I don't think I have tested with anything weaker than that. I lent my good friend my netbook while his laptop was out of commission, and he never returned it, and that was before I came to Korea, so I don't think I'm getting it back, so I can't test it on a netbook myself, sorry.
However, it looks to me like Untitled one uses about 25.2 MB of RAM, which is a hell of a lot more than I expected, but still not much, each of my chromium tabs uses more than that. As for processor usage, on my machine, its only using about 1% or less at all times, it really isn't resource intensive.
Do other OpenGL applications run slowly on your machine as well? Maybe your OpenGL implementation is to blame. Also, have you tried compiling with audio disabled?

Hmmm, I'll give it a try on another machine and see what happens.

Actually, it would probably be best if I added some instrumentation to the the code.
If you don't mind wasting some of your time, I will write a special build that will still run slowly, but will generate some output which you can send back to me and will tell me exactly which parts of the code are slowing it down for you. Do you mind?

Sure, no prob...

Ok, if you clone the git-hub repo, it now has some instrumentation added. Clone the repo, and add -DINSTRUMENT as an argument when you compile.
The resulting executable will print out a lot of stuff, its all just timing information, you can redirect the output to a file or you can just copy and paste some of it here. The last number on each line is the length of time that your CPU is idle per step, for me it was always 33ms or 34ms, which is pretty much as good as you can ask for. The game shouldn't start to actually slow down unless the last number reaches 0 (or if you have sloppy timing enabled), in which case the numbers before it should always add up to 34 or more, showing which part of the code uses wastes the most time.
https://github.com/prushik/untitledone

Here is what I got:

Perfect, thank you so much.
According to that it is as I suspected, the actual calculations are taking no time at all, its the code that actually draws stuff on the screen that is the problem. I think I should be able to fix it, it was something that should have been done in the beginning, but I really didn't understand OpenGL well when this was written, so its really just laziness that has prevented me from fixing it until now.
Also, according to those numbers, it looks like the menus are running at the correct speed, with the exception of whatever craziness happened at 1707 (maybe you moved or resized the window?). Are the menus in fact running at the correct speed?

Yes, they are. And I maximized the window.

Excellent, thank you

Sorry for the delay;
I have committed some changes to the git repo which should increase execution speed significantly, although if you were having speed problems, then "Asteroids" mode may still suffer from slow speeds, although it should be a bit faster.
I also made sloppy-timing the default again since I was having occasional issues with the more accurate timing system; This means that if you are having speed issues, you should compile like this:
OR

OR, if you still have issues and want to report the problems to me so I can fix them:

I have also just added some code for fullscreen friendliness.
If you configure with the --enable-fullscreen option, or compile with -DFULLSCREEN, then the resulting executable will run in fullscreen mode, and should look much better than previous fullscreen executables. Note that some gameplay modes will be easier in fullscreen mode because it gives you slightly more room to fly around, network games with one person using fullscreen will put the windowed player at a disadvantage. You should also be able to achieve better asteroids scores in fullscreen mode, although, you can't cheat in asteroids mode like you could before (by enabling fullscreen and staying near the edge where the asteroids can't reach).
I also changed the colors of the targets to make them look less flat and dull. I also changed a few ship colors as well.
Remember to test out the newer and faster rendering code.

It's better but still too slow. Maybe the issue relates to hardware (Indietrash didn't report any speed issue with a 2.5GHz CPU.)