Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

Dark GDK / Need help triggering an event ONLY once.

Author
Message
Dum_Bass
6
Years of Service
User Offline
Joined: 20th Mar 2013
Location: Hiding in your closet.
Posted: 28th May 2013 16:46 Edited at: 29th May 2013 11:08
Using VC++ & Dark GDK:

This may be more of a pure programming question but it is relative to the DarkGDK library. I am currently trying to make a more graphically intensive and slightly fluffed up version of "BREAKOUT" (or "Break-A-Brick, ect.) as a stepping stone towards more involved game design. I have one specific problem that has chaffed my buttocks through many prior progamming exercises and this one too. I wish to set a "trigger" that I can turn on and off.

As it pertains to my current work: I have the player's "paddle", if you will, and I have a brick smashing wrecking ball. I want the ball to instantate and follow one set of arguments but when the player clicks the mouse for the first time I want the wrecking ball to fly off the paddle and then the heart stopping, life changing action begins. Here are some very simplified prototype codes:


And:


SOOOO... I was using the creation of a sprite to hold the inPlay bool in a true state. All of my variables are declared privately within the header for this class. The sprite was used because I am just too damned thick to figure out how to do it any other way and this method has worked in the past. It is not working now. Further, I call on the Ball::Movement() function within the "LoopGDK()" loop. I have tried every combination of messy, hack coded workarounds I can think of.

Any help would be greatly appreciated and I solidly promise I will still find a way to screw it up. As a warning though, before you suggest them; I already have Beginning C++ Game Programming by Michael Dawson and Programming Principles and Practice Using C++ by Bjarne Stroustrup (The C++ programming Bible as far as I am concerned). The problem is that I fell into the crack between these two books. The first one is too simple and I am starting to outgrow most of it's teachings and Prof. Stroustrup is just too damned brilliant for me to keep up with, even though I try and try and try.

It would serve a greater good beyond my personal need if someone would illustrate how one should set up a function that sets up a trigger that can be turned on or off dependent on the circumstances inputted.

Please forgive my simple mindedness. Its genetic.

Haikus are easy; But sometimes they don’t make sense; Pteredactyl pie
Timidon
14
Years of Service
User Offline
Joined: 26th Jun 2005
Location: Bakersfield, Ca. USA.
Posted: 28th May 2013 20:44
Are you getting "syntax errors", or is the code "not doing what you expected."?

maybe?

"if (inPlay>0)"

give the condition a clear path of condition? I could be talking out of my bumm as well.

There are many answers but just one question" ~ Jerilith the Mad
Hawkblood
9
Years of Service
User Offline
Joined: 5th Dec 2009
Location:
Posted: 28th May 2013 23:09
Yes. Simply put a variable like "alreadyRun=true;" inside your condition and have the condition include it as part of the condition, and there you go.....

and

Be sure you initialize "alreadyRun" as false, and you can even make it part of the "Ball" class.

The fastest code is the code never written.
Dum_Bass
6
Years of Service
User Offline
Joined: 20th Mar 2013
Location: Hiding in your closet.
Posted: 29th May 2013 15:56 Edited at: 30th May 2013 07:20
Thank you both for your quick responses. To answer both questions in order.

Timidon: No compile or runtime errors. The error is in my logic. I HAVE gotten this to work before but in a Van Gouh-esque bout of ennui I scrapped the project I was working on (Slash and Burn style) and began anew with less tangled code. Now I am back to digging at the same thorn that was in my side as before.

Hawkblood: I am nowhere near a compiler to test this but your suggestion reads like it will produce the same results. I may be wrong I will check later.

My ultimate goal is to avoid the uneccesary creation of a new sprite all together. In a perfect world I would like something like this to work.



Then later on when certain conditions are met, in this case the player really sucks and loses the ball, inPlay = false. Because, the player will be clicking the crap out of the mouse while playing. Think pinball flippers.

Once again, thanks a zillion for input.

edit:
I did run your suggestion. Alas, it did in fact just produce exactly the same output as my own failed code. I do wonder however, if part of my problem is that the call for the Ball::Movement function should not be in the main game loop...

I'm not suggesting we should eradicate all stupid people. I am just saying lets remove all of the warning lables and let the situation sort its self out.
Dum_Bass
6
Years of Service
User Offline
Joined: 20th Mar 2013
Location: Hiding in your closet.
Posted: 10th Jun 2013 07:45 Edited at: 10th Jun 2013 07:54
I intend this to be my final post for this thread.

I have solved my issue but in a way that still "sorta" betrays my holy trinity for programming: never use magic constants, never use global variables, and never, ever leave a pointer unattended. So instead of using a global (extern) bool I used a very public one. What follows is still in prototype phase but it works as intended and will be built upon (so some comments may not yet truely describe what a funtion accomplishes).

Pertainant Class Member Functions:


Snippets from my main function:


I hope that I have included everything so people can make sense of this. I guess I was just hoping for some sort of code wizardry that felt a little cleaner, but then again this really isn't such a bad solution. I just want to be sure of not falling into a habit of leaving too many variables laying around in public code space.

The general moral to the story is: couldn't get an on off trigger to work within the LoopGDK loop or as a class member variable. Had to set it in the DarkGDK wrapper.

Again the invite is out there for anyone to humble me with their expertiece. Sorry 'bout any mistypes. Me much sleepy.

I'm not suggesting we should eradicate all stupid people. I am just saying lets remove all of the warning lables and let the situation sort its self out.

Login to post a reply

Server time is: 2019-09-17 09:34:49
Your offset time is: 2019-09-17 09:34:49