I really do think you need to do something about that proportional UI on tablets though. It uses far more screenspace than it should and the scaled up icons look cheap. The menu is also nearly unreadable so zoomed in.
You currently have
I would go for something like
With the menu permanently open and taking up just slightly more space than the pullout tab currently does.

The issue with this is that there are a million different tablet sizes, and the app is completely universal. Adding phones into the mix means that the app needs to have a UI that's usable on devices as small as an iPod Touch and as big as an iPad or Galaxy Tab 10.1. The UI we've designed seems like a good middle ground for all of the different devices, especially 7" tablets and smaller.

To this you might say, well, why doesn't the app specialize itself based on the size of the screen? The answer is, because Android is completely unreliable with its DisplayMetrics. There's no accurate way of measuring the screen - what works on one device may not work on another device, even using the official DisplayMetrics API.

So you might suggest a "smaller UI" option which the user can toggle on/off. This is a good idea, but would require a complete overhaul of all of the UI assets, which just isn't worth it at this point, since the current UI works rather well. Perhaps in an update one day. There's more important things to focus on right now.

The issue with this is that there are a million different tablet sizes, and the app is completely universal. Adding phones into the mix means that the app needs to have a UI that's usable on devices as small as an iPod Touch and as big as an iPad or Galaxy Tab 10.1. The UI we've designed seems like a good middle ground for all of the different devices, especially 7" tablets and smaller.

To this you might say, well, why doesn't the app specialize itself based on the size of the screen? The answer is, because Android is completely unreliable with its DisplayMetrics. There's no accurate way of measuring the screen - what works on one device may not work on another device, even using the official DisplayMetrics API.

So you might suggest a "smaller UI" option which the user can toggle on/off. This is a good idea, but would require a complete overhaul of all of the UI assets, which just isn't worth it at this point, since the current UI works rather well. Perhaps in an update one day. There's more important things to focus on right now.

You don't necessarily have to specialize based on the size of the screen. You could have one fixed pixel size that works on the average device (say an iPhone, since they all have the same screen), and dock the panels to the various corners of the screen.
As the screen gets bigger, the controls stay the same size and in the same relative place, simply showing more screen in the gaps that grow.
After about 720p you're probably in tablet country, so you might as well permanently unship the menu. For smaller devices, you'd need to make the bottom bar scrollable but that shouldn't be too hard.
Contrary to what you say, this is both important and worth it, because I would not give you money for the app looking like it does on my device.
Even knowing how good an app it is, how dedicated the developer is, I still wouldn't. If I had bought it, I'd use the refund button and since it's free I wouldn't buy any of the DLC, simply because it's very ugly and fairly unusable.
Users are picky, and if you don't give them perfection straight away they will throw you in the trash and forget about you.

You don't necessarily have to specialize based on the size of the screen. You could have one fixed pixel size that works on the average device (say an iPhone, since they all have the same screen), and dock the panels to the various corners of the screen.
As the screen gets bigger, the controls stay the same size and in the same relative place, simply showing more screen in the gaps that grow.

That's great, and that's exactly how it works right now.

The problem, my friend, is that this method doesn't really work. A typical 7" tablet runs at 1024x600 and a typical 10.1" tablet (over 3" bigger!) runs at a mere 1280x800, not enough to compensate for the 3" increase in screen size. The UI elements have to be completely reworked for a bigger screen that isn't running a much higher resolution - unless they can be scaled by the dimensions of the screen, which, like I said, is impossible, since the DisplayMetrics API is completely unreliable.

After about 720p you're probably in tablet country, so you might as well permanently unship the menu.
For smaller devices, you'd need to make the bottom bar scrollable but that shouldn't be too hard.
Contrary to what you say, this is both important and worth it, because I would not give you money for the app looking like it does on my device.
Even knowing how good an app it is, how dedicated the developer is, I still wouldn't. If I had bought it, I'd use the refund button and since it's free I wouldn't buy any of the DLC, simply because it's very ugly and fairly unusable.
Users are picky, and if you don't give them perfection straight away they will throw you in the trash and forget about you.

Alright. I'm sorry you don't like it. Maybe you'll like it in an update!

Edit: I did make a small improvement, but that's all I can do for the moment. Hopefully when it comes out you'll give it a download, and if you still don't like it, oh well, can't please everyone :/

The problem, my friend, is that this method doesn't really work. A typical 7" tablet runs at 1024x600 and a typical 10.1" tablet (over 3" bigger!) runs at a mere 1280x800, not enough to compensate for the 3" increase in screen size. The UI elements have to be completely reworked for a bigger screen that isn't running a much higher resolution - unless they can be scaled by the dimensions of the screen, which, like I said, is impossible, since the DisplayMetrics API is completely unreliable.

I see. I didn't know that. How does Google do it then? Their icons are the same visual size no matter what the screen and they can't have made millions of bitmaps for each possible resolution.

Alright. I'm sorry you don't like it. Maybe you'll like it in an update!

I'm sorry I don't like it too since it's quite fun to play around with, but it seems to be an uphill struggle to do anything more complicated than a couple of boxes and I simply can't be bothered to deal with the frustration.

The problem, my friend, is that this method doesn't really work. A typical 7" tablet runs at 1024x600 and a typical 10.1" tablet (over 3" bigger!) runs at a mere 1280x800, not enough to compensate for the 3" increase in screen size. The UI elements have to be completely reworked for a bigger screen that isn't running a much higher resolution - unless they can be scaled by the dimensions of the screen, which, like I said, is impossible, since the DisplayMetrics API is completely unreliable.

Alright. I'm sorry you don't like it. Maybe you'll like it in an update!

Edit: I did make a small improvement, but that's all I can do for the moment. Hopefully when it comes out you'll give it a download, and if you still don't like it, oh well, can't please everyone :/

I actually think, personally, UI should be at the top of your list. From my perspective the UI to a game like yours is going to be crucial to it's success. You need to use the menus to do pretty much everything so if it's not perfect it's going to make the whole thing suck.

Keep in mind that when you pass an array, you're actually just passing a pointer to the first element of the array. That's why my C teacher always made us declare array parameters as "char*" for example, not "char[]". If you want to allow passing in string literals, then you have to copy the string into a local buffer using strcpy before you modify it. Or if you're working in C++, just use std::string instead of C-strings, because they're a lot more safe and intuitive (they get passed by value into your function).

Keep in mind that when you pass an array, you're actually just passing a pointer to the first element of the array. That's why my C teacher always made us declare array parameters as "char*" for example, not "char[]". If you want to allow passing in string literals, then you have to copy the string into a local buffer using strcpy before you modify it. Or if you're working in C++, just use std::string instead of C-strings, because they're a lot more safe and intuitive (they get passed by value into your function).

I did have the array parameter as char* to begin with, it was one of the things I changed in an effort to make it work. I was under the impression that arrays were just a pointer to their first element in any case, not just when passed into a function?

I did have the array parameter as char* to begin with, it was one of the things I changed in an effort to make it work. I was under the impression that arrays were just a pointer to their first element in any case, not just when passed into a function?

I was thinking

Code:

int array[5];

is equivalent to

Code:

int *array
array = (int*) malloc(5*sizeof(int));

The first is allocated when the program loads, or class is allocated or whatever, and the second is dynamically allocated. That's how I know it anyway.

I used a compiler ages ago which if you had a global variable such as int array[50000]; it would increase the size of the executable file by 200kb

I did have the array parameter as char* to begin with, it was one of the things I changed in an effort to make it work. I was under the impression that arrays were just a pointer to their first element in any case, not just when passed into a function?

I was thinking

Code:

int array[5];

is equivalent to

Code:

int *array;
array = (int*) malloc(5*sizeof(int));

Arrays are static so they follow a few different rules. Most of the time you can treat arrays as if they were pointers but you can't, for example, expect sizeof on pointers to give you the size of the whole dynamic array allocated with malloc the way you could with tables.

I'm sorry I don't like it too since it's quite fun to play around with, but it seems to be an uphill struggle to do anything more complicated than a couple of boxes and I simply can't be bothered to deal with the frustration.

Add me on Steam, nullcubed

24th April 2012
Last edited by Siemz; 24th April 2012 at 07:52PM.
Post #2024

So, I'd often wondered about making a minecraft clone...
That's one 32^3 chunk. I'm running the mesh build three times every frame at the minute just out of interest, but I'll only really need to run it when blocks are added/removed. Flying cam only at the minute, I'm going to look into rendering a larger world and then try to make the fragment shader render more than just the height :)

The UI elements have to be completely reworked for a bigger screen that isn't running a much higher resolution - unless they can be scaled by the dimensions of the screen, which, like I said, is impossible, since the DisplayMetrics API is completely unreliable.

I find that very strange to hear, because all of Android's UI is based on display independent pixels and it works perfectly. User interfaces I make look exactly the same on my HTC Desire (480x800, 3.7") and my Galaxy Nexus (720x1280, 4.65"). All I have to do is specify 3 versions if bitmap resources in my applications for low, medium and high dpi devices. Note that this also is entirely optional and the UI will simply scale the icons if you don't specify multiple versions.

I managed to optimize font rendering in FreeType by creating a spritefont out of the font that is loaded. Rendered 255 characters at about 15 fps before, and now it runs fine at 60.
However, is this bad?

I managed to optimize font rendering in FreeType by creating a spritefont out of the font that is loaded. Rendered 255 characters at about 15 fps before, and now it runs fine at 60.
However, is this bad?

No, it isn't bad, it's absolutely horrific. You need to make a map of your font and put characters on a uniform grid. That way you don't have to worry about the size of the glyphs. To show what I mean:

You should keep the rest of the variables, but any change to the OpenGL state should be avoided. Switching textures is incredibly slow compared to other operations.

Welp, that's cool. I've got a world class that looks after all of the chunk objects, and will hopefully later handle loading/unloading of chunks automatically. For the moment, chunks remain in memory permanently. What I think is neat is the way they're accessed: I've got a method called getChunk() to return the chunk at a given position. What's tidy about it is that the chunks don't actually exist until they're accessed - if the requested chunk already exists, I just return a pointer to it. Otherwise, the chunk is seamlessly generated and returned in the access call.
So in the draw loop, I have this:

Well, you guys convinced me to fix the UI, and I did. For now, I added a "uiscale" advanced setting which will, quite literally, scale the user interface. For example, I could imagine "uiscale 0.5" to look quite good on large tablets. Then you can do "save all" and you're all set; the UI will always be your perfect size, every time the app runs.

Well, you guys convinced me to fix the UI, and I did. For now, I added a "uiscale" advanced setting which will, quite literally, scale the user interface. For example, I could imagine "uiscale 0.5" to look quite good on large tablets. Then you can do "save all" and you're all set; the UI will always be your perfect size, every time the app runs.

No, it isn't bad, it's absolutely horrific. You need to make a map of your font and put characters on a uniform grid. That way you don't have to worry about the size of the glyphs. To show what I mean:

You should keep the rest of the variables, but any change to the OpenGL state should be avoided. Switching textures is incredibly slow compared to other operations.

FreeType gives you per-glyph width and height values, so you can pack the glyphs in tighter than a uniform grid if you want. In my game I pack them in as tightly as possible and store their positions (and other alignment data) inside structs that I can look up in a hashmap.

Would appreciate it if people could have a play around with a group assignment I have to hand in tomorrow. It's a top-down shooter style game. If you find anything obviously wrong with it then please let me know.

Got per-vertex normals, so I can do some simple lighting now:
Each chunk is being drawn with the exact same vertex buffer - it contains the relative positions of each block within a chunk, along with the normals for each vertex and face orientation. The mesh assembly for each chunk is done in index space, and each chunk keeps hold of an index buffer in video memory. When I draw I send the chunk position as a uniform vector to the vertex shader, and then just bind and draw the chunk's vertex array :)
I'm still thinking about how to make the block types accessible to the shaders, I'm gonna have to sleep on that one.

Would appreciate it if people could have a play around with a group assignment I have to hand in tomorrow. It's a top-down shooter style game. If you find anything obviously wrong with it then please let me know.

Welp:

Btw I dont like the playersprites, the foots shouldn't be visible while standing.