Closed Thread Subscribe

icantread49 · 24th April 2012

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.

**Socram** · 24th April 2012

Catdaemon posted:

Nobody's gonna get that

Are jellyfish even know for their speed or something? I've never heard that... all I picture is a blob floating through the ocean not giving a fuck and hurting people.

**Lexic** · 24th April 2012

Socram posted:

Are jellyfish even know for their speed or something? I've never heard that... all I picture is a blob floating through the ocean not giving a fuck and hurting people.

I got it, but I had been listening to the Gorillaz earlier so.

Iceguize · 24th April 2012

Why does it crash when I try to assign the values of an array that I passed into a function?

Code:

void replaceFileExtension(char filename[255], char fileExtension[8])
{
   int periodPos, i;

   /*Find the index of the last period in the filename*/
   for(i = 0; filename[i] != '\0'; i++)
   {
      if(filename[i] == '.')
      {
         periodPos = i;
      }
   }
   for(int j = periodPos + 1; j < i; j++)
   {
      filename[j] = fileExtension[j - periodPos - 1]; //Crashes here.
   }
   std::cout << filename;
}

I need to load in multiple with the same name, but different file extensions.

Trying to get animated sprites from a sprite sheet.

**geel9** · 24th April 2012

Iceguize posted:

Why does it crash when I try to assign the values of an array that I passed into a function?

Code:

void replaceFileExtension(char filename[255], char fileExtension[8])
{
   int periodPos, i;

   /*Find the index of the last period in the filename*/
   for(i = 0; filename[i] != '\0'; i++)
   {
      if(filename[i] == '.')
      {
         periodPos = i;
      }
   }
   for(int j = periodPos + 1; j < i; j++)
   {
      filename[j] = fileExtension[j - periodPos - 1]; //Crashes here.
   }
   std::cout << filename;
}

I need to load in multiple with the same name, but different file extensions.

Trying to get animated sprites from a sprite sheet.

You're not limiting your loop. i will go past the length of filename and crash.

Iceguize · 24th April 2012

geel9 posted:

You're not limiting your loop. i will go past the length of filename and crash.

It crashes on the first iteration of the second loop when it tries to

Code:

filename[j] = fileExtension[j - periodPos - 1];

The whole thing works perfectly if I declare

Code:

char filename[255] = "test.png";

inside the function. I think it has something to do with the way it passes arrays into the function.

**ShaunOfTheLive** · 24th April 2012

Also, periodPos is not guaranteed to be assigned a value, so it could be uninitialized

Richy19 · 24th April 2012

Cube to sphere with proper normals... hells yea.

**ShaunOfTheLive** · 24th April 2012

Iceguize posted:

It crashes on the first iteration of the second loop when it tries to

Code:

filename[j] = fileExtension[j - periodPos - 1];

The whole thing works perfectly if I declare

Code:

char filename[255] = "test.png";

inside the function. I think it has something to do with the way it passes arrays into the function.

Can you give a unit test that causes it to crash? It works fine for me with the following:

    char filename[255] = "test.png";
    char fileExt[8] = "jpg";
    replaceFileExtension(filename, fileExt);

Prints "test.jpg"

**Lexic** · 24th April 2012

icantread49 posted:

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.

Iceguize · 24th April 2012

shill le 2nd posted:

Can you give a unit test that causes it to crash? It works fine for me with the following:

Prints "test.jpg"

Ahh, seem to work if you pass an array into it like that.

This doesn't, I thought that it should?

Code:

    replaceFileExtension("test.png", "jpg");

**ShaunOfTheLive** · 24th April 2012

Iceguize posted:

Ahh, seem to work if you pass an array into it like that.

This doesn't, I thought that it should?

Code:

    replaceFileExtension("test.png", "jpg");

EDIT: It's considered undefined behaviour to modify a string literal, because that literal isn't necessarily defined as a writeable array in memory.

icantread49 · 24th April 2012

Lexic posted:

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 :/

calzoneman · 24th April 2012

xThaWolfx posted:

I fear I might have broken something..

It's not a bug, it's a feature!

**Lexic** · 24th April 2012

icantread49 posted:

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.

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.

icantread49 posted:

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.

WhatTheEf · 24th April 2012

The dino taxi game is cool. Personal highscore ~1000. Thanks for rampage mode.

Iceguize · 24th April 2012

shill le 2nd posted:

EDIT: It's considered undefined behaviour to modify a string literal, because that literal isn't necessarily defined as a writeable array in memory.

I guess that does make sense when I think about it.

**iPope** · 24th April 2012

icantread49 posted:

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.

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.

**ShaunOfTheLive** · 24th April 2012

Iceguize posted:

I guess that does make sense when I think about it.

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).

Iceguize · 24th April 2012

shill le 2nd posted:

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 was thinking

Code:

int array[5];

is equivalent to

Code:

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

Dotmister · 24th April 2012

Iceguize posted:

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

Look up heap vs stack

**esalaka** · 24th April 2012

Iceguize posted:

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.

icantread49 · 24th April 2012

Lexic posted:

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

Siemz · 24th April 2012

-snip im a retard.

r0b0tsquid · 24th April 2012

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 :)

**Overv** · 24th April 2012

icantread49 posted:

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.

**Mordi** · 24th April 2012

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?

GLuint glyphTexture[223];
int glyphTexW[223];
int glyphTexH[223];
float glyphTexCoordW[223];
float glyphTexCoordH[223];
FT_Int glyphAdvanceX[223];
FT_Int glyphAdvanceY[223];
FT_Int glyphOffsetX[223];
FT_Int glyphOffsetY[223];

**Overv** · 24th April 2012

Mordi posted:

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?

GLuint glyphTexture[223];
int glyphTexW[223];
int glyphTexH[223];
float glyphTexCoordW[223];
float glyphTexCoordH[223];
FT_Int glyphAdvanceX[223];
FT_Int glyphAdvanceY[223];
FT_Int glyphOffsetX[223];
FT_Int glyphOffsetY[223];

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.

Richy19 · 24th April 2012

Have I forgotten to enable something that is making this happen?
the sphere is meant to be behind the cube

this is my enabled stuff

glEnable(GL_CULL_FACE);
glEnable(GL_DEPTH_TEST);
glEnable (GL_BLEND);
glBlendFunc (GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);

r0b0tsquid · 24th April 2012

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:

        for (int i = -3; i <= 3; i++)
        {
            for (int j = -3; j <= 3; j++)
            {
                world.getChunk(i + camx / chunk_size + 0.5, 0, j + camz / chunk_size + 0.5->draw();
            }
        }

Which gives me this:

Suddenly, infinite world! (with limited draw distance)
:D

Hexxeh · 24th April 2012

Made fantastic progress with Chrome today, got around the segfault, it was caused by my toolchain.

icantread49 · 24th April 2012

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.

**ShaunOfTheLive** · 24th April 2012

Siemz posted:

Whack -a sobo app is done
http://www.habbpad.nl/Whack-a Sobo.apk
QR code

Android 2.2 and higher only :)!

Screeny

Not to hate, its just an app i do not hate sob' i luv him i wanna be like him when i grow up

also , got the source from a site..

it won't install

icantread49 · 24th April 2012

icantread49 posted:

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.

uiscale 1:

uiscale 0.5:

It really depends on personal taste and the size of your screen.

**robmaister12** · 24th April 2012

Overv posted:

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.

**AaRoNg11** · 24th April 2012

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.

http://dl.dropbox.com/u/2666635/Working.rar

Also, need to download http://dl.dropbox.com/u/2666635/models.rar
and extract to media folder.

Known bugs - Nothing after you die (waiting on art assets for that)
Nothing when you win the game.

Video for anyone who doesn't want to download

ben1066 · 24th April 2012

My "SSAO" finally works. I've made sure it's applied before any other effect and I think it works quite well, although I need to get together a better blur...

Before:

After:

Before:

After:

r0b0tsquid · 24th April 2012

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.

Icedshot · 24th April 2012

xThaWolfx posted:

I fear I might have broken something..

You forgot to sort triangles by depth i think. Ive seen that picture before, myself

Sebixxx · 24th April 2012

AaRoNg11 posted:

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.