Linux - GamesThis forum is for all discussion relating to gaming in Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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. :-)
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.
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...
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 definitely do not want to use autotools however, IMHO autotools is a huge mess, and I avoid it whenever possible.
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.
Quote:
Originally Posted by prushik
if it would truly be helpful, and github does not force me to use copyleft licenses, then I will gladly move source to github.
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 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...
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).
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.
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.
Quote:
Originally Posted by indietrash
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.
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?
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?
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?
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
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?
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?
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
