• What are you working on? April 2012
    2,483 replies, posted
  • [QUOTE=Iceguize;35698834]It crashes on the first iteration of the second loop when it tries to [CODE]filename[j] = fileExtension[j - periodPos - 1];[/CODE] The whole thing works perfectly if I declare [CODE]char filename[255] = "test.png";[/CODE] inside the function. I think it has something to do with the way it passes arrays into the function.[/QUOTE] Can you give a unit test that causes it to crash? It works fine for me with the following: [cpp] char filename[255] = "test.png"; char fileExt[8] = "jpg"; replaceFileExtension(filename, fileExt); [/cpp] Prints "test.jpg"
  • [QUOTE=icantread49;35698567]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.[/QUOTE] 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 [b]is[/b] both important and worth it, because [I]I would not give you money for the app looking like it does on my device[/I]. 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.
  • [QUOTE=shill le 2nd;35698899]Can you give a unit test that causes it to crash? It works fine for me with the following: Prints "test.jpg"[/QUOTE] 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"); [/CODE]
  • [QUOTE=Iceguize;35699023]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"); [/CODE][/QUOTE] EDIT: It's considered undefined behaviour to modify a string literal, because that literal isn't necessarily defined as a writeable array in memory.
  • [QUOTE=Lexic;35698912]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. [/quote] 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. [quote] 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 [b]is[/b] both important and worth it, because [I]I would not give you money for the app looking like it does on my device[/I]. 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.[/QUOTE] Alright. I'm sorry you don't like it. Maybe you'll like it in an update! [b]Edit:[/b] 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 :/
  • [QUOTE=xThaWolfx;35698539]I fear I might have broken something.. [t]http://i.imgur.com/BzKVb.png[/t][/QUOTE] It's not a bug, it's a feature!
  • [QUOTE=icantread49;35699106]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.[/QUOTE] 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. [QUOTE=icantread49;35699106]Alright. I'm sorry you don't like it. Maybe you'll like it in an update![/QUOTE] 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.
  • [QUOTE=shill le 2nd;35699100]EDIT: It's considered undefined behaviour to modify a string literal, because that literal isn't necessarily defined as a writeable array in memory.[/QUOTE] I guess that does make sense when I think about it.
  • [QUOTE=icantread49;35699106]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! [b]Edit:[/b] 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 :/[/QUOTE] 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.
  • [QUOTE=Iceguize;35699255]I guess that does make sense when I think about it.[/QUOTE] 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).
  • [QUOTE=shill le 2nd;35699347]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).[/QUOTE] 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];[/CODE] is equivalent to [CODE]int *array; array = (int*) malloc(5*sizeof(int));[/CODE]
  • [QUOTE=Iceguize;35699536]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];[/CODE] is equivalent to [CODE]int *array array = (int*) malloc(5*sizeof(int));[/CODE][/QUOTE] 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
  • [QUOTE=Iceguize;35699536]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];[/CODE] is equivalent to [CODE]int *array; array = (int*) malloc(5*sizeof(int));[/CODE][/QUOTE] 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.
  • [QUOTE=Lexic;35699229] 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.[/QUOTE] Add me on Steam, nullcubed
  • So, I'd often wondered about making a minecraft clone... [img]http://i.imgur.com/sRIBd.png[/img] 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 :)
  • [QUOTE=icantread49;35699106]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.[/QUOTE] 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? [cpp]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];[/cpp]
  • [QUOTE=Mordi;35700067]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? [cpp]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];[/cpp][/QUOTE] 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: [img]http://puu.sh/rhTI[/img] 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.
  • Have I forgotten to enable something that is making this happen? the sphere is meant to be behind the cube [IMG]http://i.imgur.com/SvVKc.png[/IMG] this is my enabled stuff [cpp] glEnable(GL_CULL_FACE); glEnable(GL_DEPTH_TEST); glEnable (GL_BLEND); glBlendFunc (GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);[/cpp]
  • 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: [cpp] 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(); } }[/cpp] Which gives me this: [img]http://i.imgur.com/0z2rO.png[/img] Suddenly, infinite world! (with limited draw distance) :D
  • Made fantastic progress with Chrome today, got around the segfault, it was caused by my toolchain.
  • 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.
  • [QUOTE=Siemz;35699763]Whack -a sobo app is done [url]http://www.habbpad.nl/Whack-a Sobo.apk[/url] QR code [img]http://chart.googleapis.com/chart?cht=qr&chs=100x100&choe=UTF-8&chld=H|0&chl=http://goo.gl/BZuIA[/img] Android 2.2 and higher only :)! Screeny [img]http://www.habbpad.nl/d.png[/img] [b] 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.. [/b][/QUOTE] it won't install
  • [QUOTE=icantread49;35700837]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.[/QUOTE] uiscale 1: [img]http://i.imgur.com/XlEIf.jpg[/img] uiscale 0.5: [img]http://i.imgur.com/IFqt7.jpg[/img] It really depends on personal taste and the size of your screen.
  • [QUOTE=Overv;35700167]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: [img]http://puu.sh/rhTI[/img] 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.[/QUOTE] 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. [url]http://dl.dropbox.com/u/2666635/Working.rar[/url] Also, need to download [url]http://dl.dropbox.com/u/2666635/models.rar[/url] 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 [media]http://www.youtube.com/watch?v=4lVvXZp24jw[/media]
  • 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: [IMG_THUMB]http://i45.tinypic.com/2hx9duo.png[/IMG_THUMB] After: [IMG_THUMB]http://i45.tinypic.com/29mr634.png[/IMG_THUMB] Before: [IMG_THUMB]http://i46.tinypic.com/1qk2hl.png[/IMG_THUMB] After: [IMG_THUMB]http://i45.tinypic.com/zikle9.png[/IMG_THUMB]
  • Got per-vertex normals, so I can do some simple lighting now: [img]http://i.imgur.com/u2tCw.png[/img] 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.