Creating a UI via a class (for a game)

kanaida said:

What I wanted to do what not use multiple activities, seems kinda unprofessional looking. I was thinking just make a few panels, populate them via a few classes and simply make the one's i'm not using invisible while overlapped on top of each other.

Click to expand...

If you want my opinion, it's exactly the contrary. Creating multiple panels and consuming memory in invisible panels is highly unprofessional. Look at the forum questions; it's what all beginners do.

In most games made by professionals (or skilled amateurs), all is done in the same activity because everything is drawn. When you need another screen, you erase the current one and draw the new one. Another reason is the loss of context when you change the activity.

About your menu, I don't know what to answer because your questions are extremely vague.

I don't see any reason why not use several activities for the menus. It will not affect the actual game performance.

Hey guys, thanks. I will consider using different activities for the menu part. I'm just kind of used to seeing animated backgrounds, and animations during button presses with buttons that fade into the next screen etc... A little more console like is what I meant. In reality it's not that much more important, it just looks a bit more 'integrated'. Maybe I can just force the fade transition effect.

As for the other part, the actual drawing and game loop. I'm having trouble passing the activity as a parameter to my game class so I can draw stuff to it easily. It complains (because my game object is process global).

It was supposed to go something like this

[Process Globals] - to store my game object, and it's children inside it to keep the state the same.

[Main Activity] - used to display the objects, either as a bunch of views to hold the little game components such as clouds, tiles, characters, etc... but I wasn't sure how slow that would be v.s. some light code to draw all the stuff using a canvas to a bitmap, then draw that bitmap when completed, to the screen (double buffering).

A timer would keep track of how often to call .NextFrame() to advance the loop (an interval of 16 is roughly 60fps). I would stop the timer to pause the game.

Activity pause and resume would be used to pause the game and drawing or start it up again.

If possible without requiring the hardware acceleration manifest entry that needs jelly bean. People have been making games for much longer than when jelly bean came out, probably even without any acceleration and still managed to make things smooth. I'm trying to explore how to achieve that as well. Part of it is realizing, my old sega genesis easily achieved 60fps had a processor that ran at around 7.6Mhz, by contrast my android is 1180Mhz x2 so its interesting for me to learn all the tricks needed to get stuff to that level of performance.

kanaida said:

Hey guys, thanks. I will consider using different activities for the menu part.

Click to expand...

If your menu uses standard views (panels, labels, buttons, etc.), it is maybe more convenient to use different activities for each submenu. But if you draw completely your menu (with graphic functions), there's no need to switch to other activities. You just erase the display and you draw another menu. As you want to do an animated menu with an animated background, it's probably the way to go.

kanaida said:

I'm having trouble passing the activity as a parameter to my game class so I can draw stuff to it easily

Click to expand...

That will be easier to understand with a bit of code.

kanaida said:

but I wasn't sure how slow that would be v.s. some light code to draw all the stuff using a canvas to a bitmap, then draw that bitmap when completed, to the screen (double buffering).

Click to expand...

To use this technique, you have to prepare your scene in a separate thread (because you won't have the time in the main thread). It's possible with a class named SurfaceView. Unfortunately, I know no library for B4A that wraps this class, and the technique is considered deprecated by Google. SurfaceView doesn't (and won't) benefit from the hardware acceleration, so forget the idea.

kanaida said:

If possible without requiring the hardware acceleration manifest entry that needs jelly bean.

Click to expand...

The rendering pipeline of Android benefits from the hardware acceleration since Honeycomb (3.0). Not using the HA is a very big mistake because that adds not only speed to your drawings, but also smoothness to their animation (JB, for example, uses a triple buffering).

kanaida said:

People have been making games for much longer than when jelly bean came out, probably even without any acceleration and still managed to make things smooth.

Click to expand...

That's right. These people use the OpenGL ES API. OpenGL uses the GPU for its rendering, so it is always hardware accelerated. On devices under Gingerbread or Froyo, nothing can beat its performance. That's less true since Honeycomb.
B4A has two libraries giving you access to the API, so you can try it.
OpenGL is complex and needs more than a couple of weeks to be learnt. Probably many months to be mastered at a decent level. Java users have an easy solution: they use a game engine. That eases a lot the use of OpenGL. Unfortunately, B4A has no game engine (I mean nothing that can really deserve this name) and the only class made with OpenGL to make it more easy to use has poor performance. It's a common problem with OpenGL: if you don't master it and cannot use at its best, you won't get the performance that you expect. That's why it's probably better to consider alternatives. There are two for B4A: GameView and Accelerated Surface. Try them and make your own opinion.