Ogre UI selection and ogre built-in UI learning in iPhone games

Write by nine days Yan Ling (jtianling) -- blog.csdn.net/vagrxie

Discuss newsgroups and documents

Ui Selection

I have read an interesting and comprehensive article on UI selection.
But it is mentioned that only online games are used, while iPhone hardware is far more limited than PC environments (especially memory shortage ), using ogre is a luxury in itself. If the UI consumes a lot of memory, there is almost no way to create a slightly complex scenario, (I tried ogre + bullet + ogrebullet. When loading a complex scenario that only contains dozens of boxes, my touch 3 generation reports a memory warning, and force the program to exit) so there are more different considerations when selecting the UI. Of course, those UIS with high efficiency under the PC are even more important.

First of all, it is obvious that iPhone games, especially simple iPhone games, have fewer requirements on the UI than online games. For me, the display of buttons and text can already include more than 90% of the requirements. If the button can be customized with more flexibility, the text can also display Chinese characters, and then there is a progress bar (for loading) it is perfect, with no other requirements. Unique

After knowing the requirements, you will find that,Cegui

This mature and flexible enough UI is a favorite for many companies to develop online games, but it is still too large and complicated. In addition, I have summarized the options of the iPhone UI.
, I talked about the cegui issue on the iPhone, so I will not consider it. (Although I have used this before, it may be faster to get started.) I think the mygui last selected by the author mentioned above may be complicated, I found related information on the Internet and found some problems under the iPhone.
. In addition, I found the official version of mygui
Not even the MACOs version. This problem is too serious. I still don't want to eat crabs any more. What I need is so simple .... So I decided to try the built-in UI of ogre (unfortunately there are too few documents). If the built-in UI cannot solve the problem, I would like to consider other UIS.

Ogre built-in UI

To be honest, there is actually no built-in ui ...... In fact, the implementation of those controls in the demo is actually directly built in the demo project. That is to say, these UIS are not part of the Ogre SDK and may be discarded or changed at any time, no one can guarantee the stability of these codes (so there is a special prefix such as SDK in class naming). However, as mentioned above, there is really no better choice, fortunately, the code is concise (because ogre didn't want to build a huge UI system, just wanted to have a UI available in the demo), even if it was directly copied for use and maintained by itself, both are acceptable. These codes are all in the sdktrays. h file of the demo and all in the ogrebites namespace.

In addition, because these codes are not part of the Ogre SDK itself (only part of the demo), and even the API documentation
None. (only the documents at the overlay layer) let alone the detailed instructions. If there is no document, the source code is the best document ........

Use

The usage here starts with ogre's 1.7.2 SDK and does not involve compilation in windows.

There are two SDK-related files (in the SDK package) in the directory

OgreSDK_vc9_v1-7-2/samples/common/include

OgreSDK_vc9_v1-7-2/include/ogre

, But because this file may need to be modified by yourself, we recommend that you copy it, change the name, and then include it in the project.

First, create your own sdktraymanager type object. We recommend that you make it a single piece. Appwizard in ogre vc9
In baseapplication, The mtraymanager member variable is already in use (Standard Application Template) and initialized properly.

The use of specific controls can no longer be simple .....

For example, label:

Mtraymgr-> createlabel (tl_topleft, "helloworldlabel", "helloworld ");

The first parameter is the location, the second parameter is the name of the label object, and the third parameter is the text displayed by the label object.

For example, button:

Create:

Mtraymgr-> createbutton (tl_topleft, "quit", "quit ");

The first parameter is the position, the second parameter is the name of the button object, and the third parameter is the text displayed on the button.

Query status: (called in your loop logic, such as framerenderingqueued)

Button * bt = (Button *) mtraymgr-> getwidget ("quit ");

If (BT-> getstate () = bs_down ){

// Put your codes here

}

For example, progress bar:

Create:

Mtraymgr-> createprogressbar (tl_topleft, "loadingcontrol", "loading", 200.0, 250.0 );

One of the last two parameters indicates the length of the progress bar and the other indicates the length of the annotated text. A box is created after the caption to make the text show very light ..... However, no comment text parameter is directly input, so you can only imagine it by caption text .... This design is understandable. For example, when the file is read during initialization, the title is displayed first, and the reading file is displayed later. But why is there no comment text parameter? I don't understand. It cannot be removed .....

Set progress: (half-score ratio, expressed as a floating point number from 0 to 1)

Progressbar * pb = mtraymgr-> createprogressbar (tl_topleft, "loadingcontrol", "loading", 200.0, 250.0 );

Pb-> setprogress (. 5); // 50%

The use of controls is relatively simple, but there are several points to note:

1. If you need a mouse pointer (iPhone does not need it ):

Mtraymgr-> showcursor ();

2. After the control is created in the preceding method, the caption cannot be displayed. Because the font has not been loaded, the following code is required:

Ogre: fontmanager: getsingleton (). getbyname ("sdktrays/caption")-> load ();

Create the effects of the preceding three controls in sequence:

Click I will quit to exit normally.

In some cases, controls at the same position are automatically arranged. This is like layout in the UI such as QT. This is very convenient because you do not need to manually specify the absolute coordinate position. (Compared to the ancient MFC), however, it seems that this layout can only be vertically arranged, not horizontally arranged.

Problem to be resolved:

1. The label will not automatically expand the size when the text is long (the button will ).

2. these UIS are still too simple. At least the custom image buttons cannot be used. Don't worry about theme switching (skin replacement). If you really use these original UIS to make a game, will be processed by others as ogre demo .... -_-! Even if you replace the images of these controls directly, one control in the game can only look like one, which may be a little monotonous .....

3. progressbar does not know how to make it easy to use. The current design is too wrong.

Fortunately, with a simple foundation, you can add these functions by yourself. Maybe you can download these functions to those who have the same requirements one day.

In addition, the loading progress bar shows a showloadingbar function in sdkmanager, which has not been tried yet. If it is easy to use, you may be able to use it directly.

Implementation

Ogre supports the UI on the overlay layer (with an overlaymanager). The UI of the demo starts from here.
All event responses are called back using the following listener. You can also see which events the UI focuses on.

/*
========================================================== ============================================

| Listener class for responding to tray events.

========================================================== ============================================
*/

Class
Sdktraylistener

{

Public
:

Virtual
~ Sdktraylistener (){}

Virtual
Void
Buttonhit (Button * button ){}

Virtual
Void
Itemselected (selectmenu * menu ){}

Virtual
Void
Labelhit (Label * label ){}

Virtual
Void
Slidermoved (slider * slider ){}

Virtual
Void
Checkboxtoggled (checkbox * box ){}

Virtual
Void
Okdialogclosed (const
Ogre: displaystring & message ){}

Virtual
Void
Yesnodialogclosed (const
Ogre: displaystring & question, bool
Yeshit ){}

};


Sdktraymanager
It is inherited from the listener:

/*
========================================================== ============================================

| Main class to manage a cursor, backdrop, trays and widgets.

========================================================== ============================================
*/

Class
Sdktraymanager: Public
Sdktraylistener, public
Ogre: resourcegrouplistener

Although the main functions of sdktraymanager may be similar to that of overlaymanager, overlaymanager is a single piece (which makes it difficult to inherit and use it, you can directly obtain the objects of this class every time you use them.

The Event Response Section is similar to the cegui UI and uses an injectxx interface.

Then, all controls have a base class: widget

This class has three member variables:

Ogre: overlayelement * melement;

Traylocation mtrayloc;

Sdktraylistener * mlistener;

Overlayelement is naturally used in combination with overlaymanager. traylocation is used to indicate the location, and listener is the previous one. here we can see some problems. Even a button will have such a large listener .... This may be related to c ++'s no convenient callback or protocol usage. If Ogre is willing to use the signal or message mode for this purpose, this is not required. Otherwise, it is the best way to create a separate listener class for each type of controls. The Ogre UI is only designed for the demo and doesn't need to be so complicated, so we use this ugly usage. Therefore, you can even wait for an event in a button control that does not respond at all.

Take the buttons as an example:

Class button: Public widget

The button is inherited from the widget and has the following member variables:

Buttonstate mstate;

Ogre: borderpaneloverlayelement * MBP;

Ogre: textareaoverlayelement * mtextarea;

Bool mfittocontents;

Mstate naturally indicates the button status:

Enum buttonstate // enumerator values for button states

{

Bs_up,

Bs_over,

Bs_down

};

Borderpaneloverlayelement provides an overlay element with borders. (Because the widget already contains an overlayelement, we can see that there are still some problems with the UI design. Maybe it is just something designed for the demo)

Textareaoverlayelement provides a text overlay element.

A button is a border control that can display text and reflect the click status. The above member variables can be fully interpreted as buttons ......

The mfittocontents variable enables the button to automatically expand to adapt to the text width value. If you manually set the button width to false, otherwise it is true. Label does not have such configuration, and then it cannot be adaptive.

In implementation, there will be

If (mfittocontents) melement-> setwidth (getcaptionwidth (Caption, mtextarea) + melement-> getheight ()-12 );

This operation. No label.

I browsed the source code a little and basically didn't have much content .......

 

The author of the original article retains the copyright reprinted. Please indicate the original author and give a link

Write by nine days Yan Ling (jtianling) -- blog.csdn.net/vagrxie