Browse Search Popular Register Upload Rules User list Login:
Search:
AlgoGUI

Image:
screenshot of the scene

Author: s_noonan

Group: Technical

Filesize: 136.48 kB

Date added: 2018-12-09

Rating: 5.6

Downloads: 790

Views: 207

Comments: 7

Ratings: 2

Times favored: 2

Made with: Algodoo v2.1.0

Tags:
tool

Scene tag

The goal of this scene is to provide tools for quickly creating a GUI in a manner similar to Visual Basic.

Rev A: Mod toggle button. Reduced scene frequency. Added progress bar control.
Rev B: Doubled scrollBar target area. Added scene.my.GUIstrobe to main form.
Rev C: Fixed Button1 so it will click first time, even if it does not have focus.
Rev D: Changed the borders to be a texture instead of a box, eliminating 68 boxes.
Rev E: Now save object entityID upon spawning instead of saving entity as an object variable.
Rev F: Added "Close" button, which deletes all objects associated with the form. Reduced the number of "scene.my." variables.
Rev G: Added "Close" to the EntityID list.
Rev H: Added dropdown control.
Rev I: Main forms can now be dragged by dragging the title bar while sim is running.
Rev J: Added inputBox, messageBox, and yesNoCancelBox.
Rev I: Set collideSet = 0 for all Rev J components.
Rev J: Fixed Display "round(x,n)" function.
Rev K: Added internal limits to progress bar.
Rev L: Set collideSet = 0 for all components.
Rev M: Revised texture scaling.
Rev N: Scrollbar slider (1) click was (2).
Rev O: Added laser and indicator light
Rev P: Added tooltip example.
Rev Q: Modified inputBox, messageBox, and yesNoCancelBox.
Rev R: Renamed images from_pasted_XXXX to more meaningful names.
Last edited at 2019/10/16 19:55:20 by s_noonan
Please log in to rate this scene
edit
Similar scenes
Title: AlgoGUI Tutorial
Rating: 5.625
Filesize: 318.4 kB
Downloads: 111
Comments: 2
Ratings: 2
Date added: 2018/12/30 19:31:21
Made with: Algodoo v2.1.0
Rating: rated 5.6
download
Title: Destroy The City alpha v0.1
Rating: 5
Filesize: 0.83 MB
Downloads: 2706
Comments: 1
Ratings: 1
Date added: 2016/09/01 22:44:22
Made with: Algodoo v2.1.0
Rating: rated 5
download
Title: Shade's Toolbox
Rating: 5
Filesize: 28.96 kB
Downloads: 78
Comments: 1
Ratings: 1
Date added: 2018/09/21 22:49:07
Made with: Algodoo v2.1.0
Rating: rated 5
download
Title: Semi-Automatic Catapult
Rating: 5
Filesize: 44.63 kB
Downloads: 331
Comments: 0
Ratings: 1
Date added: 2011/03/02 17:13:05
Made with: Algodoo before v1.8.5
Rating: rated 5
download
Title: Simple cut tool demo
Rating: 1.6667
Filesize: 480.17 kB
Downloads: 180
Comments: 2
Ratings: 3
Date added: 2009/01/18 21:23:09
Made with: Phun
Rating: rated 1.7
download
Title: Pencils
Rating: 5
Filesize: 78.25 kB
Downloads: 63
Comments: 0
Ratings: 1
Date added: 2019/09/28 02:15:39
Made with: Algodoo v2.1.0
Rating: rated 5
download
This is probably the best looking UI in Algobox, however i can't help but remark the usual problem here: This scene takes up about 45% of the step calculation time (took the value from the profiler [the "minus" key]) mainly because there's a lot of code on many objects' postStep. I found using only one object with postStep code to be much more forgiving in terms of sim time cost (or even better, no poststep code at all, or make it appear on click then delete it after you're done using it), and then you could use entityByID (or entityByGeomID) to refer to e.g. the four boxes from the sides of the buttons (by previously saving the entityID or geomID on a scene.my var, by using onSpawn so that the code only runs when the id changes).

The rifle with aim scene uses this technique (it needs one scene.my. variable per "muscle" axle) but has close to zero simulation time overhead when on idle.
Thanks for the evaluation and suggestions. I plan on dissecting the scene and see what is causing the lag. My first guess was that it was the multitude of scene.my object variables since an object variable is created for each form and control upon spawning. I'm not sure if I agree with the statement "This scene takes up about 45% of the step calculation time ... mainly because there's a lot of code on many objects' postStep." When I check the basic (12) controls on the left of the scene, (7) have no post step code, (3) check to see if the control has focus before running postStep, (1) ("Display1") only has (5) lines of code in postStep, and (1) checks the mouse pos before running postStep (Toggle1"). I like your idea of creating postStep on demand.

After checking out the percentage draw from each example and each control, I can see that the option box and the toggle button are the heavy hitters. I will need to focus on those first. I also just realized I can reduce the percentage draw 60% by running the scene at 60 Hz instead of 300 Hz.
Well, I just realized that you used scene.my's to store entityID's, nice

Honestly this is not exactly proven, but by experience I found out that having many scene.my variables doesn't really make any lag. The problem is reading and/or writing to them on every step, so for example if we have a box and we want to change its collideSet, doing
collideSet = {scene.my.collideSet}
or doing that from postStep as in
postStep = (e)=>{collideSet = scene.my.collideSet}
will read it every step, which is a small overhead on itself. Also writing with a laser, like we did 5 years ago, writes it every step, so it's basically code running unnecessarily. all of these end up piling up and they use up a rather big amount of step time.

I believe the first step in making the buttons less laggy would be improving the 3d effect boxes. right now all 4 of them per button are executing code on every step. I think the simplest way would be by using a texture, and you could probably just rotate it. Otherwise you can store each box's entityID in a scene.my.var via onSpawn and have no other code running, then change each box's color from the button itself, using scene.entityByID.

Do you avoid onClick code for some reason? I saw that in the Submit button, you check for the mouse being upon the button and for a click. is there any reason other than to change _isDown?

I think you could do this in a much simpler way. Just use something on the lines of this:

onClick = (e)=>{
scene.my.focusID = entityID;
_isDown = true;
postStep = (e)=>{
! Keys.isDown("mouse_left") ? {
_isDown = false;
postStep = (e)=>{}
} : {}
};
_onClick
}
Last edited at 2018/12/15 01:01:06 by The Linkage
also, one more thign about the sliders. you might have noticed that they will not stay attached to the cursor if you exit their area (i.e. move the cursor too fast to the sides or up). I think a good way of solving this would be saving the initial distance in the X axis between the center of the slider box and the mouse pos, then simply using the mouse position in the X axis minus the x distance (with the desired limits) as the slider pos while the left mouse button is pressed. this way you don't have to rely on the mouse staying inside of the slider box area
S = Statement, R = Response

S: Well, I just realized that you used scene.my's to store entityID's.
R: I use scene.my.focusID to store the entityID of the active control. I use scene.my.[control _name] as object variables to store each control so that I can call each control by name at any time. I use _parentID in parts of each control that are not the main control box.

S: Honestly ... they use up a rather big amount of step time.
R: I concur.

S: I think the simplest way would be by using a texture, and you could probably just rotate it.
R: My first thought was to use a texture, but I never thought about rotating it. My concern is that if I double the size of a button in one dimension, then the border for the wider dimension will be twice as thick. If using a texture improved the control perfomance by more than 25%, then I may ingnore that issue in favor of performance.

S: Otherwise you can store each box's entityID in a scene.my.var via onSpawn and have no other code running ...
R: Good idea exept that I would try to use local _variables to to store EntityIDs.

S: ... then change each box's color from the button itself, using scene.entityByID.
R: That makes sense; use (1) postStep instead of (4).

S: Do you avoid onClick code for some reason?
R: I would use onClick but onClick code appears to execute on mouseUp, not mouseDown.

S: Just use something on the lines of this: ...
R: Another good idea that I didn't think of. I will try that.

S: ... sliders. you might have noticed that they will not stay attached to the cursor.
R: I did notice that.

S: I think a good way of solving this ...
R: I agree. I will try that.

P.S. I tried the suggested code and some variations, but could not get it to work. The scrollBar suggestion worked out well. I chose to leave the command button border control code in the borders because I didn't want to add more member variables to the button's main box. I did add a scene.my.GUIstrobe codition to the border postStep, so they should be runnining a 10% sim frequency.

P.P.S. I changed the Button1 code so it clicks even without having focus. This will cause a performance hit, but I'm not sure how to improve it.
Last edited at 2018/12/15 07:59:22 by s_noonan
Problem: My concern is that if I double the size of a button in one dimension, then the border for the wider dimension will be twice as thick

Theoretical Solution:
Make texture with borders that are 1 pixel wide and use texture clamped [true,true]
So when you want to have 2 times longer button just make texture 2.1 times so you "shrink" verticall borders and it will look same
MAIN PROBLEM: I didn't played this scene yet, I have too much work to do, so this is the only way i can still be part of algodoo:/:)
Stated Problem: My concern is that if I double the size of a button in one dimension, then the border for the wider dimension will be twice as thick.

Solution: Change the size of the buttons, save the buttons in scene, and then reload the scene. The button borders will all be the same size.

P.S.: Thanks for the suggestion. I may be able to use it elsewhere. I probably should have mentioned that the buttons re-scale on re-load. There may be other functions of the controls that only work upon re-loading. So if the controls don't work as expected, then try reloading the scene.
Last edited at 2019/02/17 22:11:25 by s_noonan