Making windows REALLY static

User Code & Projects tonegodgui
1

Hey toneGod,

I read through the documentation, and couldn’t find a way to make it so that menu’s drag bars are undraggable. Currently I’m using:

    MainWindow.setIgnoreMouse(true);
    MainWindow.setIsMovable(false);
    MainWindow.setWindowIsMovable(false);
    MainWindow.setIsResizable(false);

to get a window that can’t be moved, resized, or whatevered. But, when the user clicks the title bar, the buttons (that are NOT children, as you have suggested) are covered up by the window. Any workaround for this? Sorry if this is covered elsewhere.

I tried .setAsContainerOnly, but I miss having a backdrop for the elements. I’m sure there is a way around this, and once I get more familiar with the plugin I can work that out.

Thanks again!

P.S. I’m still really enjoying working with your plugin, I can safely say it’s the first GUI library that I’ve actually enjoyed working in. As opposed to working with every other GUI library, which is almost always the opposite of fun.

1 Like
2

I realized that setIsResizable(false) fixes the drag bar not moving, but it still obscures the other elements when clicked/touched

3

Ah… um, actually… you should be able to add the buttons as children.

But, if you do not want the window to be effected by z-order… I believe that you call:

[java]
Element.setEffectZOrder(false);
[/java]

But, let’s revisit the non-child issue, because this should be fine to do. What is the problem when you add child elements?

1 Like
4

I can do it, I thought you advised against it for reasons of overhead… I may be misunderstanding the distinction of when it is/isn’t okay to use certain objects such as windows/panels as parents for children buttons/labels.

I’ve found multiple ways to do the same thing, and have been using the profiler to try to find some answers as to speed, but I’m interested in what you think about when using child elements is appropriate.

5

And that method you mentioned works in the way I wanted it to, so thank you!

[java]
MainWindow.setIgnoreMouse(true);
MainWindow.setWindowIsMovable(false);
MainWindow.setEffectZOrder(false);
MainWindow.setIsResizable(false);
[/java]

This makes the window very static.

1 Like
6
@Screamconjoiner said: I can do it, I thought you advised against it for reasons of overhead... I may be misunderstanding the distinction of when it is/isn't okay to use certain objects such as windows/panels as parents for children buttons/labels.

I’ve found multiple ways to do the same thing, and have been using the profiler to try to find some answers as to speed, but I’m interested in what you think about when using child elements is appropriate.

Well…

For Android, it’s a balancing act. If your purpose is to run effects on elements (i.e. move them around, show, hide with effect, etc)… grouping things seems to be the best options. Actually… in the case of normal gui elements, nesting seems to be fine all the way around.

Where I have noticed severe performance hits is:

  1. Running multiple transform effects on larger resolution devices against elements with lots of text, etc. Which is odd, as transform effects are sent to the GPU as Matrices, not buffer updates.
  2. Dynamically swapping text out (.setText() calls), though as long as it is isn’t more than 2-4 BitmapText or TextElements and the strings are relatively small, it’s acceptable (imo anyways) This one is understandable as it is always a buffer update… a minimum of two buffers changed per setText–position and texCoords. If you change text color, a 3rd buffer is updated.

I’ve noticed Android doesn’t particularly like dynamically updating Mesh’s buffers. Though in the game I am currently writing, the entire game consists of 2 meshes whose buffers are constantly updated every frame, at least 6 different TextElements whose text is changed on a consistent basis and I an running TemporalActions against most of the quads in one of the meshes at all times and it has no issues running on any device I have tested it on… However, running transform effects against some of gui elements seems to tax the devices heavier than the game itself and these do not directly effect any of the elements buffers.

I think basically what I am getting at with the above example is… it seems to heavily depend on so many variables (i.e. # of textures, size of textures, which buffers are being altered… which is an odd one, but I have notice a performance difference between altering a positional buffer as apposed to altering texCoords… go figure /shrug) that it is almost impossible to set guidelines up for myself to follow.

Here is the usual steps I go through for putting together a screen for Android (I assume the iOS will actually perform a little better, as this seems to be the case with all games I have seen ported to both platforms):

  1. Visually design the screen with transition effects, etc without concern for performance… just whatever is most expedient for getting the layout and functionality together.
  2. Then comes the hellish part of rewriting it 2-3 different ways to determine what works best for that particular screen (or AppState… collection of controls, whatever):
    **** Such as, minimizing effects by trying different element groupings, determining whether a composite image is better suited than multiple elements, etc, etc.

There is also whether to use an AnimElement with TemporalActions or a GUI Element with the Effect system in place… both are handled by the screen, however… both have a different focus, though one can be used in place of the other depending on the circumstances. AnimElement is best suited for writing 2D games where as Element is 9-patch based and designed for GUI controls.

Lately, I’ve taken to not using the setText method of Element and adding a TextElement in it’s place. TextElement is a GUI element wrapper for AnimText (BitmapText rep that extends AnimElement… the same quad-based mesh used to create the 2D emitter in the library). The big problem with this (at the moment) is there is no documentation for the 2D framework yet, making it a little hard for others to use atm.

I do have an example game project which should be downloadable on the download section of the repo, however… then game was designed for desktop and a gamepad. It does show how to use quite a few of the 2D framework classes, such as:

Pool
PoolObjectFactory
GameTimer
ElementEmitter
AnimElement
Most TemporalActions (aside from ExecuteAction, which was added later)

And, speaking of ExecuteAction… it is one of the most useful classes in the library. It does nothing more than call a method after the duration has transpired… soooo… basically, it is used like this:

[java]
public void someMethod(String text) {
System.out.println(text);
}

ExecuteAction ea = new ExecuteAction() {
@Override
public void execute() {
someMethos(“This is a test”);
}
};
ea.setDuration(1.5f); // 1.5 seconds
screen.getAnimManager().addQueuedAction(ea, someAnimElementOrQuadData, 2f); // waits 2 seconds before starting the action’s duration

// So, in 3.5 seconds someMethod is called
[/java]

There are some really cool tricks you can do using Pool, PoolObjectFactory and AnimElement to divide up the quads of the AnimElement into reusable objects that you can retrieve by just calling Pool.getNextAvailable()… the coolest part is, a single AnimElement can contain as many Pools of quads as which to use.

sigh… I really need to write the documentation for the 2D framework. It is a God-send for Android dev. Makes typical 2D/animation-based games a breeze to write.

Ok… enough rambling from me. Hopefully something in here is useful to you!

I you do choose to take the plunge into trying out the 2D framework, I’ll be more than happy to lend as much asssistance as you need, because everything we cover in threads here can easily be turned into the documentation that I should have already wrote ;)>

7

Awesome, thanks!

My routine so far has been to pick one area of my game to push pretty far for about half of my day, then rewrite the oldest code that still works but is naive, and then document. I’ve noticed the same sort of thing about updating text elements that are nested, it takes a lot longer to update an element that references something like health or score that is being updated pretty regularly.

I was asking about this just for the start menu of my game, to see if laying the buttons out without nesting would be faster and retain the same sort of functionality.

The 2D framework sounds very interesting, and I’m going to be taking a 1-month independent study in a couple of weeks to just work on my game, so I’m sure once I’m at the stage of really refining my interface, I’ll try going down that route. Is all of the code for your 2D framework within the standard plugin?