If you want, I could create a Makefile with a bunch of comments to help you with that.You probably want to work a little on splitting your source up in separate files, isolating functionality. Having one giant wall of code doesn't not help readability.
* linked source file is for a game I ported with h4xxel.
I agree completely. I need to get comfortable with separating the code. I currently code in vim and would have to learn the gcc command to add the files. I will check out the source when I get to a computer.
SDL_mixer supports ogg so it's no effort to support that.music would be awesome, the game is a Zelda clone so a retro sound would be preferable. I could support ogg but would most likely conveert the file to wav. If you want to be super-awesome you could check out MOD and retro tools like milky tracker.It would be my first time, but would you mind me contributing some music in ogg or mp3?
I play oozens of Instruments including some funny ones which may fit.
Well it is an NES clone game. While I wouldn't mind completely that the music be real instruments the file size for the game would grow exponentially.Oh, you strictly want computer generated/synthetical music. Count me out then.music would be awesome, the game is a Zelda clone so a retro sound would be preferable. I could support ogg but would most likely conveert the file to wav. If you want to be super-awesome you could check out MOD and retro tools like milky tracker.It would be my first time, but would you mind me contributing some music in ogg or mp3?
I play oozens of Instruments including some funny ones which may fit.
Well since it's an open source game the potential mix-ins are endless. It just depends on the interest of the community. The first step is to get the game into beta.If you can subtle throw in the bank issues, Packages of parts delivered to the wrong house and Chinese new year delays too that would be awesome.if there's no volcano, no flaming cars and no craiginator I'd be disapointed!
I figured as much. I'm still learning git and manging files evades me at the moment. I need to spend more time with the tutorials.Oh and you should not commit executables like a.out!
A make file would be awesome! I have been kicking myself for not making one earlier. I have also wanted to learn how to make a pandora binary. I figure when it's ready for more beta testing/opinions one would be made to distribute to those who are interested.If you want, I could create a Makefile with a bunch of comments to help you with that.You probably want to work a little on splitting your source up in separate files, isolating functionality. Having one giant wall of code doesn't not help readability.
* linked source file is for a game I ported with h4xxel.
I agree completely. I need to get comfortable with separating the code. I currently code in vim and would have to learn the gcc command to add the files. I will check out the source when I get to a computer.
And, Ziz is right, as the executable will be changing in accordance with the source code, there's no need to include anything generated from the source in the directory. It's generally a good idea to have binary files distributed via a website. Usually, assets are not checked into version control systems along with the source (some developers use different repositories for documentation, source code, and assets) as creating the differences between binary files often ends up replacing the previous file instead of having a neat set of differences to apply when getting the latest version (plus, the size of the repository can get pretty large pretty quick if content is being changed frequently).
I'll take a look. This could work well. My only concern is that everything will be techno and nothing zeld/rpg sounding.SDL_mixer supports ogg so it's no effort to support that.music would be awesome, the game is a Zelda clone so a retro sound would be preferable. I could support ogg but would most likely conveert the file to wav. If you want to be super-awesome you could check out MOD and retro tools like milky tracker.It would be my first time, but would you mind me contributing some music in ogg or mp3?
I play oozens of Instruments including some funny ones which may fit.
You can find nice MOD files on the Mod Archive (http://modarchive.org/), many of them have a Creative Commons license.
If you need some help with coding, I may be able to help.
Wow, this is awesome. I will check everything out and try to build it tomorrow. Thanks for the support! It's humbles me to see how much goes into a game. How many things I still have to learn. At first I think I'm awesome for installing Linux... then learning some c code... then my first sdl project... it just keeps going.Okay, I have the Linux version working with a Makefile (and have also created a directory structure which should help keep any platform-specific code separate). I've also removed the a.out file and the other script files which were compiling the game before. Right now, I'm commenting the Makefile and cleaning it up a bit.
Thanks for this, I am taking note so I remember to really learn git. It's been a pleasure to use so far but I know absolutely nothing about it. My plan is that before I work on the code for LoP again that I will study git and get the version number set. After I'm confident in the basic usage (you will probably notice a few more ugly commits) I can confidently and cleanly commit new material to the project.I was checking your project and noticed you had eight commits with each one deleting files from the repository, you can issue:
$ git rm file1
$ git rm file2
... and so on until you have deleted the files you don't need, then you can commit and the files will be removed in one commit rather than several.
I'd also recommend you tag your repository with a version number, which can be used in the script I created (gitversion.sh) to automatically generate a new build number. Using:
$ git tag -a <release stage>_<major>.<minor>.<revision> -m "<release stage> <major>.<minor>.<revision>"
Where release stage is whatever you want to call the type of release, usually most projects just skip this and use the major.minor.revision build numbering. I prefer to use the stages: prototype, alpha, beta, delta, gold. Though you can use whatever you wish. If you need help with merging the changes, you should try out the IRC on freenode (#openpandora on freenode.net).
for (o=0; o <= MAXMONSTER; o++) {
for (o=0; o < MAXMONSTER; o++) {
I don't know if it's THE bug, but there's a bug in main.c on line 1798.
Instead ofthe code should beCode:for (o=0; o <= MAXMONSTER; o++) {
Code:for (o=0; o < MAXMONSTER; o++) {
Yeah, I will have to add some aids.