Sounds like collecting information about algorithms would be a good idea. I had to surf the web up and down to collect bits and pieces on how to make effect or material x and y. And had to try a lot to find good parameters, functions and chains of functions. That's why I agree to collect "func'lets" and howto's (vs building uber-libs). Especially because Procedural Content Generation is (for me) the art of chaining meaningful functions. There are gui-tools for creating procedural textures - these provide the raw functions - but not the knowhow and best practices to make great things.
Maybe we should split this into a low-level and a high-level PCG-lib (library as in code AND books) for both parties. :)
Try the "Perspective Tool" (Shift-P) in GIMP. After you need to flatten the image again (Image Menu => Flatten Image).
You can use it to stretch photographed surfaces into flat squares. It can correct a lot but there are limits.
As a general hint to photo-textures: Best days for taking shots are bright and cloudy so that there is more indirect light to capture the diffuse color.
I've added them to my favorites a long time ago...but just now I realize that those dials and buttons and some additional numberpad-buttons would be great to build cockpit instruments.
Sounds like it's worse with different drivers than with different pc-gamepads. I wish vendors would at least publically print their layout - maybe some well named could be convinced - they could only win: logitech for open source , saitek works better under linux
What annoys me the most is that shoulderpad indexing is sometimes like i=L1, i+1=L2, i+2=R1,i+3=R2 and then sometimes i=L1, i+1=R1, i+2=L2, i+3=R2
Could you assert that ps2 dualshock (with usb adapter) have the same mapping (minus the new axes of the sixaxis)?
Sadly most dual-axis pc gamepads (dualshock clones) have wildly different mappings (possibly because of their different console heritage or because of just cloning the look without proper re-engineering). Would be awsome if either those vendors could meet a common standard or if there were a wrapper library that could map them to a common standard. The first step to having a wrapper library would be to collect mappings just like you did. And then select the right mapping for the gamepad version/vendor.
...or do some lobbying and ask vendors about their mappings and ask if there is a reason they prefer to go their own way and if they think it is an advantage to be incompatible...thank you for gaming...
I think that could enhance the "user experience" on the pc if one could have console like input support: Plug in some gamepads, startup super tux cart or any other game and have the buttons of all gamepads work in the same way instantly. I would wish that for my game, too.
Nice game, I'd declare it the best open jump and shoot (until proven otherwise) on linux. I like that jumpjetting and the mighty third weapon powerup. And it's nice to see several paths in one level. As for balancing: I think those energy-up-stars could give a litte more energy or other revenue. The payoffs don't seem to justify the use of the jumpjet, esp. when a fast runthrough lets you stay at nearly 100%. Nice mood, nice graphics and very nice music. Great work! And I hope OGA will enhance it even more. Maybe a small intro with the background story text (show it until keyhit). :)
Anyway I'm afraid I couldn't play through (got to level 3) due to bugs in the game (not the shootable ones) so here's my bugreport (Ubuntu 10.04 32bit). I hope you can make good use of it:
After some time, every time I collect a powerball it leads to "Failed to create thread" and a short lagging (becoming longer) and finally it leads to a segmentation fault when collecting a powerball. I think this is due to sound playing because the power-ball-sound failed, too (bgm playing ok). Hm, maybe I can playthrough by not collecting power-balls?
Another bug appeared after gameover. There where problems loading images "Reason: out of memory". But there was still plenty of memory available.
And in between it printed out a lot of 0/1 - don't know wether these are just usual/ok debug-printings.
As for packaging: Maybe move the "how-to-compile-using-cmake"-file to the main directory where the readme is? And I haven't found artists/coders credits, art licensing(?) and link to OGA.
IMHO whatever you use you should stick to what the most know and/or you know the best. Some lowest common. I doubt there will be time for unknown tools - however great they are supposed to be.
As for special C++ standards: Be aware that different compilers may have different partial support for newer standards - with mingw (gcc for windows basically) it isn't a very big concern but even mingw may lag a bit behind of linux gcc. Don't even mention different brands of C++ compilers. And I'd stick to simple make or build scripts..
I'd like to stress it even more: There isn't time for any failure in 48 hours - if 48 hours is your target. Usualy people who paricipate in such competitions seem to use their own beloved well known toolset they know in-and-out. You could imagine it as some kind of special operation. In my opinion the chances to achieve more are better with less. And avoid featuritis.
Competition results are usually rather abstract- or casual-style games - as for one because of programmer art (here OGA can excell) and as for number two because of complexity. If you shuffle the theme with some *random* verbs you may come up with games quite unique one couldn't have imagined before - yet quite simple. Often simpler than a lot of other things.
Sounds like collecting information about algorithms would be a good idea. I had to surf the web up and down to collect bits and pieces on how to make effect or material x and y. And had to try a lot to find good parameters, functions and chains of functions. That's why I agree to collect "func'lets" and howto's (vs building uber-libs). Especially because Procedural Content Generation is (for me) the art of chaining meaningful functions. There are gui-tools for creating procedural textures - these provide the raw functions - but not the knowhow and best practices to make great things.
Maybe we should split this into a low-level and a high-level PCG-lib (library as in code AND books) for both parties. :)
Try the "Perspective Tool" (Shift-P) in GIMP. After you need to flatten the image again (Image Menu => Flatten Image).
You can use it to stretch photographed surfaces into flat squares. It can correct a lot but there are limits.
As a general hint to photo-textures: Best days for taking shots are bright and cloudy so that there is more indirect light to capture the diffuse color.
:)
I've added them to my favorites a long time ago...but just now I realize that those dials and buttons and some additional numberpad-buttons would be great to build cockpit instruments.
Sounds like it's worse with different drivers than with different pc-gamepads. I wish vendors would at least publically print their layout - maybe some well named could be convinced - they could only win: logitech for open source , saitek works better under linux
What annoys me the most is that shoulderpad indexing is sometimes like i=L1, i+1=L2, i+2=R1,i+3=R2 and then sometimes i=L1, i+1=R1, i+2=L2, i+3=R2
Could you assert that ps2 dualshock (with usb adapter) have the same mapping (minus the new axes of the sixaxis)?
Sadly most dual-axis pc gamepads (dualshock clones) have wildly different mappings (possibly because of their different console heritage or because of just cloning the look without proper re-engineering). Would be awsome if either those vendors could meet a common standard or if there were a wrapper library that could map them to a common standard. The first step to having a wrapper library would be to collect mappings just like you did. And then select the right mapping for the gamepad version/vendor.
...or do some lobbying and ask vendors about their mappings and ask if there is a reason they prefer to go their own way and if they think it is an advantage to be incompatible...thank you for gaming...
I think that could enhance the "user experience" on the pc if one could have console like input support: Plug in some gamepads, startup super tux cart or any other game and have the buttons of all gamepads work in the same way instantly. I would wish that for my game, too.
Nice game, I'd declare it the best open jump and shoot (until proven otherwise) on linux. I like that jumpjetting and the mighty third weapon powerup. And it's nice to see several paths in one level. As for balancing: I think those energy-up-stars could give a litte more energy or other revenue. The payoffs don't seem to justify the use of the jumpjet, esp. when a fast runthrough lets you stay at nearly 100%. Nice mood, nice graphics and very nice music. Great work! And I hope OGA will enhance it even more. Maybe a small intro with the background story text (show it until keyhit). :)
Anyway I'm afraid I couldn't play through (got to level 3) due to bugs in the game (not the shootable ones) so here's my bugreport (Ubuntu 10.04 32bit). I hope you can make good use of it:
After some time, every time I collect a powerball it leads to "Failed to create thread" and a short lagging (becoming longer) and finally it leads to a segmentation fault when collecting a powerball. I think this is due to sound playing because the power-ball-sound failed, too (bgm playing ok). Hm, maybe I can playthrough by not collecting power-balls?
Another bug appeared after gameover. There where problems loading images "Reason: out of memory". But there was still plenty of memory available.
And in between it printed out a lot of 0/1 - don't know wether these are just usual/ok debug-printings.
As for packaging: Maybe move the "how-to-compile-using-cmake"-file to the main directory where the readme is? And I haven't found artists/coders credits, art licensing(?) and link to OGA.
But now take your deserved nap.
There you are. Added T-junctions and gave it zebras. Now this is a complete cityroads building kit.
Sorry, for my late reply (haven't seen your comment). I'll work on T-Intersections but can't promise when. Any more tiles needed, anyone?
IMHO whatever you use you should stick to what the most know and/or you know the best. Some lowest common. I doubt there will be time for unknown tools - however great they are supposed to be.
As for special C++ standards: Be aware that different compilers may have different partial support for newer standards - with mingw (gcc for windows basically) it isn't a very big concern but even mingw may lag a bit behind of linux gcc. Don't even mention different brands of C++ compilers. And I'd stick to simple make or build scripts..
I'd like to stress it even more: There isn't time for any failure in 48 hours - if 48 hours is your target. Usualy people who paricipate in such competitions seem to use their own beloved well known toolset they know in-and-out. You could imagine it as some kind of special operation. In my opinion the chances to achieve more are better with less. And avoid featuritis.
Competition results are usually rather abstract- or casual-style games - as for one because of programmer art (here OGA can excell) and as for number two because of complexity. If you shuffle the theme with some *random* verbs you may come up with games quite unique one couldn't have imagined before - yet quite simple. Often simpler than a lot of other things.
Pages