I was wondering if it is possible to "merge" these 2 funtions into one so that the same function can treat gui's, buttons, labels, lists, textboxes, etc...something like:
pseudo code:
Quotevoid Chk_Hide(this GUI* || this Button* || this Label*, etc...)
Quote
//instead of using a separate function for each type (button, gui, etc), it would be cool that a list of possible types can be treated with 1 function.
void ChkGui_Hide(this GUI*)
{
if (this.Visible) this.Visible = false;
}
void ChkBtn_Hide(this Button*)
{
if (this.Visible) this.Visible = false;
}
*ps: The inside of the brackets above after the function name are called parameters, right? What's an extender again? :P
Don't have the time to explain much but you should be able to get away with making one function for GUIs (your GUI function should work fine) and then one for the more abstract GUIControl. Look it up in the manual.
Is it possible to merge GUIControls + Gui's for an extender "this" inside a function parameter? I guess I could have 2 functions (GUIControls + GUI's), it beats having to do one for each control (label, textbox, button, etc)...although it would be great to call "gMyGui.Chk_Hide" or "btnMyButton.Chk_Hide" inside the same module and both work.
Ok, the manual is my friend, must have missed the info on that part. I'll go check it out again! In the meantime though if anyone knows if the above is possible, any help is appreciated :)
thnx dkh
This is called overloading functions and is not possible in AGS, but you could have something like:
function HideAnything(GUI theGui, int control_num)
{
if(control_num < 0)
theGui.Visible = false;
else if(control_num < theGui.ControlCount)
theGui.Controls[control_num].Visible = false;
}
"control_num" is the ID property of the controls. Using -1 will hide the Gui itself, any other num will hide the corresponding gui control. Is it what you're looking for?
Hi Sephiroth,
This will work nicely, actually! ;D
Overloading functions...ok, now atleast I know what it's called. I'll look it up to fully understand.
Too bad AGS doesn't support it though.
**EDIT:
Ok, I found this in the manual:
http://americangirlscouts.org/agswiki/Extender_Methods_mean_Polymorphism!#Overloading (http://americangirlscouts.org/agswiki/Extender_Methods_mean_Polymorphism!#Overloading)
You can "overload" extender functions (since they end up as members, they can have the same name):
void Hide(this GUI*) {
this.Visible = false;
}
void Hide(this GUIControl*) {
this.Visible = false;
}
This compiles fine and should do exactly what you want.
In this particular case I'm not sure why you'd want to have a function though:
if (this.Visible) this.Visible = false;
Either this is not Visible, then the function doesn't do anything. Or it is Visible, in which case it also ends up being not Visible.
What I'm saying is you'll get the same result by writing:
this.Visible = false;
Thusly, why have a function in the first place when you can do
gMyGUI.Visible = false;
gMyButton.Visible = false;
instead.
Except that in this case, I don't see why you'd need an overloading function imho. But it's nice to see we can overload member functions :) I stand corrected.
Do you mean I could've called them HideGUI and HideControl?
Ah no, I mean that you don't need an overload to accomplish what he wants, your code is totally fine and viable option, just saying overloading is used for different cases like when you need your function to accoplish the same thing with different variable types.
Like :
float Add(float a, float b);
int Add(int a, int b);
Here the 2 variable types are actually just one, because the Gui is the container for all controls, with a GUI variable you can access any controls.
Sure. I don't NEED an overload, but it makes the code more readable imho and expands on all the same named inherited members that are already there.
It would be cool though if we could actually overload functions.
Ok, so in this case I dont need to check if its visible before hiding it? I was writing this all along:
if (gMyGui.visible) gMyGui.Visible = false...as in, if its already hidden, then dont try to hiding it, just leave it as it is... I thought I would be saving a "process" this way (?)
Is it a waste of time for this "check"?
(kinda like doing "if this exists, delete it, if not, do nothing"...)
Yes, you don't need that check, having the processor compare values or change variable from true to false is almost the same execution speed so no real optimisation.
If you only need to hide a control, then just one line will do, I thought maybe you had to perform other actions on the control, because otherwise you wouldn't need a function in the first place, obviously ;)
I think the main main reason why I added that check is when Im inside the rep_exec. If I have a line like "btnMyBtn.NormalGraphic = 17", it can slow down the fps since its always changing the sprite...so I added a "check" to make sure it only does it once:
if (btnMyBtn.NormalGraphic != 17) btnMyBtn.NormalGraphic = 17;
...so I just figured I'd add the same "check" to most of my lines (so it will only do it once in rep_exec)...in this case is it still a useless idea?
That is the main reason I guess <shrug> :P
Quote from: General_Knox on Fri 22/04/2011 02:47:18(kinda like doing "if this exists, delete it, if not, do nothing"...)
Sure, this is something else, trying to delete something that doesn't exist might throw an error so this is sensible.
Quote from: General_Knox on Fri 22/04/2011 07:40:16If I have a line like "btnMyBtn.NormalGraphic = 17", it can slow down the fps since its always changing the sprite...so I added a "check" to make sure it only does it once:
I'm curious, did you actually experience a slowdown?
In any case, like Sephiroth said, those checks aren't faster than setting a variable; they are only useful if they prevent, say 10 lines from executing unnecessarily.
I can see why you think it may cause a slowdown, but the game will always execute the rendering function , so when you change NormalGraphic to 17, you're not calling the rendering function, just changing its parameter, it will be executed anyways.
If the sprites are the same size (length) then there's absolutely no difference between RenderGraphic(17) and RenderGraphic(35).
If anything your checks are actually *slower* than ignoring them altogether.
Setting a variable is far faster than making a comparison.
ah crap!! Ok, programming 101 :)
Well geeze I need to go through all my scripts and remove those checks then...
For the slowdown, Ill get you an example later today, I noticed sometimes it would go down 20 fps on certain lines in rep_exec without a "check" (but i think it was something more complex like the dynamic redraw!)
Although those checks would probably make no difference at all in practice.
It only comes into play on things like iterative processes (like in graphics processing for instance) where loops can be very very long and invoke thousands of comparisons a second.
Quote
Setting a variable is far faster than making a comparison.
That's not always true, in this case the variable is a boolean, in assembly, the only difference between comparing and setting the value is a conditional jump which are both the fastest instructions for processors(mov,jump), having the check or directly set a variable is pretty much the same execution time. The difference could be bigger if we were talking about a string or object, comparing strings takes some time.
Edit: I think if there's room for optimisation in a code, it certainly doesn't come from this kind of detail, but rather like Khris said, from several lines of code which get executed when it's not needed. The idea behind your checks is good, but not necessary in this case imho.