I cannot seem to fix it whereby spacebar allows the text to show on screen until spacebar is pressed again to remove it. Currently it shows then gets removed straight away due to SPACE being unpressed.
The only way I can seem to do it is by putting another event_queue in the ShowQuest function, but this seems to cause problems as sometimes I need to press spacebar multiple times for it to be removed.
I'll post my whole code here for ease, so you can see it all. (Sorry if it's terrible)
]]>
Instead of using the spacebar 'directly', setup a bool called "TextActive".
Then do something like:
If press spacebar, and TextActive = true, make TextActive = false,
or if press spacebar, and TextActive = false, make TextActive = true
Then only draw text when 'TextActive' = true!
]]>
Thanks for the reply Dizzy
I thought's that's what I had done with the dialog_open part within the code
If the player is at the npc and space is pressed then dialog_open = true and then in the ShowQuest() i have if space pressed again then dialog_open = false or am I doing it the wrong way.
I tried a few ways with this and edited the following section of code:
This way performs the same way, text show then removed instantly, if I hold space then it stays on screen.
And this way
This performs the same however it will not allow me to press space again to show anything (which in my newbie eyes kinda shows the dialog_open is working, since dialog_open is now true and hence should not display anything).
Edit = I did comment out the ShowQuest() as QuestDialog() is only shown at the same time and is less to edit. (thats only drawing a rectangle on screen).
]]>Try:
]]>
Thanks for the reply Chris.
I did try following your code however, I only have 1 while loop which is the while(!done) game loop.
If i enter the code you put (Outside the bracers after my clear_to_color, so it's not in any other code), nothing happens when I press space at the NPC.
I have tried to add the code Under my DrawHuman(In the Render section and state playing section of my code) the text appears and disappears instantly, if I put a while loop here the game freezes when I get to the NPC (The while loop was the Human.x >= NPCQuestOne.x - 40)
My dialog_open (your's is space_is_pressed) is a global variable so that is outside the loop.
Is this caused by my ALLEGRO_EVENT_KEY_DOWN and _UP's for SPACE as I'm sure I need them?
Am I just placing the code in the wrong section ?.
The worst part is I understand the code you put and what is doing I just can't seem to implement it correctly and get it working :-(
]]>Someone else chime in regarding using Allegro events and whatnot, but this is straight from a working piece of A5 game code for a Joust game I'm toying with:
al_get_keyboard_state(&kbd_state); //... if(al_key_down(&kbd_state, ALLEGRO_KEY_UP)) { if(KEY_UP_PRESSED == false) { temp_man->move_vel(0, -FLAP_VELOCITY); } KEY_UP_PRESSED = true; }else{ KEY_UP_PRESSED = false; }
I think I had a problem very similar to yours before with Allegro 5, where the logic looked fine, but testing for the keys being false didn't work.
]]>Thanks again Chris.
After looking into the events you posted (I haven't used them before or seem them in the tutorials)
I think al_get_keyboard_state(&kbd_state); Goes into my while(!done) game loop.
al_key_down requires a bool which I set as global:-
bool al_key_down(const ALLEGRO_KEYBOARD_STATE kstate, int ALLEGRO_KEY_SPACE);
I added ALLEGRO_KEYBOARD_STATE kstate; to my list of allegro variables (As seen in first post code)
And then I added this code to my (state = PLAYING)
If this is done correct from what I read about al_get_keyboard_state and al_key_down then the same thing is happening. I press space dialog appears and instantly goes off screen :-(
I have now managed to take working code, implement it and break it.
EDIT - I think this may have something to do with the way I coded my keys.
I thought for now it would be easier just to use F to interact and then press space to close dialog. Although when I press F text appears and disappears the same, even though now I'm not checking any true/false values for F expect the initial press.
Oh, there's your problem.
When you load a dialog, you've got two options.
{"name":"465137-diablo-macintosh-screenshot-inventory-holding-carryings.png","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/7\/b\/7b1b34c338a910dc0bdd16b60a194dbd.png","w":640,"h":480,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/7\/b\/7b1b34c338a910dc0bdd16b60a194dbd"}
1) A dialog box where the game keeps playing: Set a flag by pressing the "dialog button" for example, and whenever that flag is set, draw the dialog box.
{"name":"Train-Conductor-2-Pause-menu.png","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/0\/3\/032b6359deebccca2118de8a7c74caf6.png","w":800,"h":480,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/0\/3\/032b6359deebccca2118de8a7c74caf6"}
2) A dialog box where the game is interrupted until the dialog exits. (Like pressing escape in most games.) In that case, the easiest way is to have a second game loop in the dialog itself.
That is, a call to say main_menu_dialog() goes to that function, and stays there until that dialog box's exit condition is satisfied, which calls return, and sends execution back to the main loop.
In case #1: You have to be careful to pass input to the dialog box while it's open.
In case #2: You have to make sure you events all get handled. You don't want to go to a new function only checking keyboard events, and then end up having all of the joystick/mouse/whatever events fill up like crazy until you return.
]]>Cheers again Chris
It's 5am here but I'm still trying to get it right. Although I kinda guess I made some progress now knowing it doesn't seem to be the code you gave me, but now rather than my actually coding.
I'm going to bed now but i'll be back at it when I wake up and hopefully make some progress
]]>Did you manage to figure this out??
]]>I'll looking at it now Dizzy, make some changes and I'll see where I'm at from them.
EDIT:- Still no further forward. I tried to add in the while loop Chris posted although my game froze up (if i debug at the loop it looks like it works, although I can't press the required key to cancel the loop, hence the freeze)
So back to editing/testing/reading etc. Something somewhere is gonna slap me in the face and it will work, just need to figure it out.
EDIT:- What I did want to ask is this taking my code(but cut right down)
On the 2nd loop, is it correct to say that the al_wait_for_event(event_queue, &ev); has now registered the F was released and now F = false, so when the code gets back to the state == playing, that since F is now false it will not go onto CheckDialog(Qs) and as such no longer display the rectangle ?
If so then this is what I cannot work out and this could be why even changing the key to a different key still doesn't work
]]>Well...yes, I think so...
Using your code above, the dialog will ONLY be displayed if you are standing in the right place AND holding down the F key!?
Is that what you want?
]]>No, I would prefer it if he stands in front of the NPC, presses a key to show Dialog and then presses a key (preferably the same key, as it would help to know how this works) for the dialog to be removed .
I'm glad I actually understand what the code is doing, that's always a start :-)
]]>Something like this might help:
]]>
Well done, I was looking at adding code to my event_key_down and up but it wouldn't have looked like that.
Thank you so much for that Dizzy it works.
Well for now it works, I just hope it stays that way.
Thanks so much for that and thank you too Chris for helping out
]]>Cool! Hope it all goes well!
]]>Well knowing how that works, can help in my other additions I want to try and do :-)
I cannot thank you enough for that :-)
]]>if(canPressKey = true){
I think you mean
if(canPressKey){
]]>
Or even, canPressKey == true
]]>Exactly because of the risk of the error above, in C, I prefer to use booleans and pointers as such without the unneeded comparison to true, false or NULL. But there's no point in arguing about programming style, so let's not.
]]>I'm just happy is working :-)
Whichever way it was decided to be done is all good
]]>Are these always identical?
int x = 1501; if(x){} if(x == true){}
That is to say, are there any cases where explicitly testing to true is not the same as implicit true?
And likewise:
if(!x){} //Maybe? if(x == false){}
That logical negation is the one I'm really wondering about.
]]>The proper way to prevent accidental assignment instead of equality comparison is to write the constant on the left hand side of the expression.
if (3 == sscanf(input.c_str() , "COORDS %lf %lf %lf" , &x , &y , &z)) { // success } else { // error, didn't read all three arguments }
That way, if you accidentally write
if (3 = sscanf(/*...*/)) { // compile error, you can't assign 3 a value }
It will error out on you. In this case you could have written sscanf on the left hand side too, and if you tried to assign to it it would error. With gcc it says "lvalue required as left operand of assignment".
As far as checking non-bool types against true or false, don't do it. true and false are usually defined as 1 and 0. However, implicit bool casts are okay :
]]>
It also depends on whether it's C89 or C99 or C++. Here's an article on the subject:
http://www.jacquesf.com/2011/04/in-defense-of-the-c99-boolean-type/
]]>