Pandora Pandora Panic


B-ZaR said:
Some stuff that the forum messed up that I couldn't read anyway after I'd had a night out....

Well you seem to know what you are talking about and it is open source, you are welcome to make any additions like this, code improvements will gladly accepted.
Although I do use vectors of Sprite classes etc...can you give me some code examples of what causes the weird behavior with regards to STL.

Setting a Sprite with a pointer has been my intention for a while, I just keep forgetting to put the code in.

As for the pausing suggestions, we couldn't really think how to add it into the engine side of things...your suggestions do make some sense, although putting pausing into the engine itself would need to be game independent and not specific to PandoraPanic!.
 
Last edited by a moderator:
QUOTE

Well you seem to know what you are talking about and it is open source, you are welcome to make any additions like this, code improvements will gladly accepted.
Although I do use vectors of Sprite classes etc...can you give me some code examples of what causes the weird behavior with regards to STL.



This segfaults, because img and img2 point to the same image data in memory:
CODE

Image* img = new Image();
img->loadImage("images/MemoryBlocks/red_block.png");
Image img2(*img);
delete img;
img2.renderImage(screen, 0, 0);



QUOTE

Setting a Sprite with a pointer has been my intention for a while, I just keep forgetting to put the code in.


Great! I could suggest using shared_ptr's, because then many sprites could share image data without problems like above. It has nearly zero overhead and really makes things easier.

QUOTE

As for the pausing suggestions, we couldn't really think how to add it into the engine side of things...your suggestions do make some sense, although putting pausing into the engine itself would need to be game independent and not specific to PandoraPanic!.


Yeah, I took a peek in the engine.cpp, and the best idea I came up with would be coding a special pause state, that would be used instead of the current one in the main loop if pause was invoked. The engine could check for the pause key before every loop, and swap the current and pause states if the key was pressed.

EDIT: Why, oh why won't the quotes work!
 
Last edited by a moderator:
Here's my second contribution
CODE
http://www.cs.tut.fi/~erkkola/MemoryBlocks.tar.gz


It's a simple memorization game, where you see a combination for 3 seconds, and then you must repeat it. It has three difficulty levels, which change depending on how many levels have been completed.

Neither of my games support pausing for now, but I will add it if required. This game in particular would benefit from a covering pause screen, because otherwise you could look at the blocks as long as you want.
 
Last edited by a moderator:
One thing I remember having to do when implementing pause was to make sure you stop any timers while the game is paused. Otherwise the timers would continue counting and the player would end up losing.
 
DasFool said:
One thing I remember having to do when implementing pause was to make sure you stop any timers while the game is paused. Otherwise the timers would continue counting and the player would end up losing.

This is one of the main problems to work around in regards to pausing...

We now have a compiled Pandora version (again)
It's on the wiki or can be downloaded directly: Pandora test build

Controls are most likely borked... but if anyone has the hardware to test it, please do and hopefully we can shape things up for release. B)
 
Last edited by a moderator:
'DasFool' said:
One thing I remember having to do when implementing pause was to make sure you stop any timers while the game is paused. Otherwise the timers would continue counting and the player would end up losing.
This could be archieved with the "onPause" "afterPause" methods I suggested.
 
Last edited by a moderator:
B-ZaR said:
'DasFool' said:
One thing I remember having to do when implementing pause was to make sure you stop any timers while the game is paused. Otherwise the timers would continue counting and the player would end up losing.
This could be archieved with the "onPause" "afterPause" methods I suggested.
ok you win, I'll look into it after my shift on Sunday... unfortunately for me I have to get ready for my evening shift soon and then I'm working daytime tomorrow... blah.
 
Last edited by a moderator:
'PokeParadox' said:
'B-ZaR' said:
'DasFool' said:
One thing I remember having to do when implementing pause was to make sure you stop any timers while the game is paused. Otherwise the timers would continue counting and the player would end up losing.
This could be archieved with the "onPause" "afterPause" methods I suggested.
ok you win, I'll look into it after my shift on Sunday... unfortunately for me I have to get ready for my evening shift soon and then I'm working daytime tomorrow... blah.

I actually thought a bit more about this. Making the pause screen a separate state has other perks as well. It can be easily made into an in-game menu. This is when I thought up, that BaseState should be aware of its engine via a pointer (set with a method "void setEngine(Engine* const engine)"). If the engine then had a method "setPauseable(bool const value)", games could control when they can be paused and when not. Other kind of callbacks could be made, such as moving to a specific state (like main menu) and changing settings.

The actual switching between the pause state and game state would be done by swapping "activeState" and "pausedState" pointers. As the switch is made, "afterPause" is called for the new "activeState" and "onPause" for the new "pausedState".

If this doesn't seem to make sense, ask or do as you please :). I'm not about to hijack this project or anything. B)
 
Last edited by a moderator:
B-ZaR said:
'PokeParadox' said:
'B-ZaR' said:
'DasFool' said:
One thing I remember having to do when implementing pause was to make sure you stop any timers while the game is paused. Otherwise the timers would continue counting and the player would end up losing.
This could be archieved with the "onPause" "afterPause" methods I suggested.
ok you win, I'll look into it after my shift on Sunday... unfortunately for me I have to get ready for my evening shift soon and then I'm working daytime tomorrow... blah.

I actually thought a bit more about this. Making the pause screen a separate state has other perks as well. It can be easily made into an in-game menu. This is when I thought up, that BaseState should be aware of its engine via a pointer (set with a method "void setEngine(Engine* const engine)"). If the engine then had a method "setPauseable(bool const value)", games could control when they can be paused and when not. Other kind of callbacks could be made, such as moving to a specific state (like main menu) and changing settings.

The actual switching between the pause state and game state would be done by swapping "activeState" and "pausedState" pointers. As the switch is made, "afterPause" is called for the new "activeState" and "onPause" for the new "pausedState".

If this doesn't seem to make sense, ask or do as you please :) . I'm not about to hijack this project or anything. B)
Well actually it sounds more like you are the type of ideas man we need to give SVN access... lol
(off to work, see ya)
 
Last edited by a moderator:
'B-ZaR' said:
'PokeParadox' said:
'B-ZaR' said:
'DasFool' said:
One thing I remember having to do when implementing pause was to make sure you stop any timers while the game is paused. Otherwise the timers would continue counting and the player would end up losing.
This could be archieved with the "onPause" "afterPause" methods I suggested.
ok you win, I'll look into it after my shift on Sunday... unfortunately for me I have to get ready for my evening shift soon and then I'm working daytime tomorrow... blah.

I actually thought a bit more about this. Making the pause screen a separate state has other perks as well. It can be easily made into an in-game menu. This is when I thought up, that BaseState should be aware of its engine via a pointer (set with a method "void setEngine(Engine* const engine)"). If the engine then had a method "setPauseable(bool const value)", games could control when they can be paused and when not. Other kind of callbacks could be made, such as moving to a specific state (like main menu) and changing settings.

The actual switching between the pause state and game state would be done by swapping "activeState" and "pausedState" pointers. As the switch is made, "afterPause" is called for the new "activeState" and "onPause" for the new "pausedState".

If this doesn't seem to make sense, ask or do as you please :). I'm not about to hijack this project or anything. B)


Wouldn't it be better for the constructor to be passed the state's engine? That way we know for a fact that it has a pointer to its engine. If it was simply a set method, null pointer exceptions could occur if something is done with the engine before it's set.
 
Last edited by a moderator:
Vorporeal said:
'B-ZaR' said:
'PokeParadox' said:
'B-ZaR' said:
'DasFool' said:
One thing I remember having to do when implementing pause was to make sure you stop any timers while the game is paused. Otherwise the timers would continue counting and the player would end up losing.
This could be archieved with the "onPause" "afterPause" methods I suggested.
ok you win, I'll look into it after my shift on Sunday... unfortunately for me I have to get ready for my evening shift soon and then I'm working daytime tomorrow... blah.

I actually thought a bit more about this. Making the pause screen a separate state has other perks as well. It can be easily made into an in-game menu. This is when I thought up, that BaseState should be aware of its engine via a pointer (set with a method "void setEngine(Engine* const engine)"). If the engine then had a method "setPauseable(bool const value)", games could control when they can be paused and when not. Other kind of callbacks could be made, such as moving to a specific state (like main menu) and changing settings.

The actual switching between the pause state and game state would be done by swapping "activeState" and "pausedState" pointers. As the switch is made, "afterPause" is called for the new "activeState" and "onPause" for the new "pausedState".

If this doesn't seem to make sense, ask or do as you please :). I'm not about to hijack this project or anything. B)


Wouldn't it be better for the constructor to be passed the state's engine? That way we know for a fact that it has a pointer to its engine. If it was simply a set method, null pointer exceptions could occur if something is done with the engine before it's set.
Well, it's a matter of convienience. If it was in the constructor, all of its subclasses would have to implement a constructor where they call it. This would result in more copypaste code in the game classes. It would still be possible to get null pointer exceptions (you can get an invalid value for the constructor, or the subclass can implement the constructor wrong), but then you'd several more places where it could occur. At least this way you set the pointer in one engine side spot after which you can be sure its set regardless of the game class code.
 
Last edited by a moderator:
B-ZaR said:
Well, it's a matter of convienience. If it was in the constructor, all of its subclasses would have to implement a constructor where they call it. This would result in more copypaste code in the game classes. It would still be possible to get null pointer exceptions (you can get an invalid value for the constructor, or the subclass can implement the constructor wrong), but then you'd several more places where it could occur. At least this way you set the pointer in one engine side spot after which you can be sure its set regardless of the game class code.


I'm looking into this pausing stuff right now. Was going to do it yesterday buy my shift got jumbled and I had to work when I was already tired... so was not in any mood to do anything when I finally got home yesterday!
 
Last edited by a moderator:
I was going to make a third minigame, but after I prototyped it in python, pygame and pybox2d it kinda took off and now it's becoming a full blown platformer... :). If box2d and pygame run nicely on the pandora, I'll surely release it. Currently it uses 10-13% cpu on my Core2.
 
Last edited by a moderator:
B-ZaR said:
I was going to make a third minigame, but after I prototyped it in python, pygame and pybox2d it kinda took off and now it's becoming a full blown platformer... :) . If box2d and pygame run nicely on the pandora, I'll surely release it. Currently it uses 10-13% cpu on my Core2.
I'm pretty sure you'll be able to get python stuff working on the Pandora at some point.

I've managed to change the pausing stuff towards the ideas you've expressed, and it's working quite well. Unfortunately I've still not heard anything positive from the Pandora test build.
 
Last edited by a moderator:
Oh hi it's me. I had a PM exchange with Miggles a few weeks back, and he asked me to cut the One Button Bandit sound (the ambient casino noise) down to 20 seconds. I kinda forgot to do it until now. I've PMed him again, but just in case, I'll drop it here too.

CODE
http://users.tpg.com.au/pw2007/PP.onebuttonbandit.20s.ogg


If there's anything else I can still help with, please yell out! I'm still on board. My last few audio contributions were pretty throw-together, I'm keen to work more on them if needed. :)
 
Last edited by a moderator:
Gruso said:
If there's anything else I can still help with, please yell out! I'm still on board. My last few audio contributions were pretty throw-together, I'm keen to work more on them if needed. :)


My minigames could use some sound effects :)
 
Last edited by a moderator:
Ok, I'll look into it and PM you when I've got a list of questions. We'll workshop it.

[edit] Just grabbed the latest build and saw that your turret game is in there. Nice.
 
Last edited by a moderator:
Ok B-Zar, some sounds for thee. After playing Rotating Turret, I figured I knew what was needed without PMing you! You might like these as they are, (I do :p) but it's all open to further discussion of course.

CODE
http://users.tpg.com.au/pw2007/ROTATE.ogg
http://users.tpg.com.au/pw2007/FIRE.ogg
http://users.tpg.com.au/pw2007/WIN.ogg
http://users.tpg.com.au/pw2007/LOSE.ogg


And just so y'all know I'm not slaving over a synth here, I've sourced the sounds from freesound.org then tweaked them in Audacity. Attributions:

CODE
By wildweasel (http://www.freesound.org/usersViewSingle.php?id=54676)
Dual Neutron Disruptor.wav (http://www.freesound.org/samplesViewSingle.php?id=39023)
By inferno (http://www.freesound.org/usersViewSingle.php?id=71614)
stormplas.wav (http://www.freesound.org/samplesViewSingle.php?id=18399)
xplosm.wav (http://www.freesound.org/samplesViewSingle.php?id=18403)
By pempi (http://www.freesound.org/usersViewSingle.php?id=298011)
elevator_motor.wav (http://www.freesound.org/samplesViewSingle.php?id=33873)



When your memory game makes it into a build I'll scope that out too. Or if you'd like, PM me with a list of game functions and their FX requirements, and we'll wing it. :)
 
Last edited by a moderator:
Nice work Gruso! The rotation sound should only play as long as the turret rotates, right? I'm not sure how to do that, so I'll just let PokeParadox here add them :)
 
Last edited by a moderator:
Back
Top