• Content count

  • Joined

  • Last visited

Community Reputation

178 Neutral

About kdmiller3

  • Rank

Personal Information


  • Twitter
  • Github
  • Twitch
  • Steam
  1. Lua scripting woes

    Things like this are why I have a love/hate relationship with Lua. You might want to add validation checks for your function arguments and throw errors when something goes wrong. You'll want your host application to print out the call stack on errors so you can track down where the problem occurred. Ultimately, though, you need to exercise all your code (whether at runtime or as part of a test framework) to make sure everything is sound. The problems you're experiencing seem common to all dynamically-typed languages (including JavaScript) since there's fewer ways for the language to help you out than with statically-typed languages (like C). I don't think there's an easy solution aside from being careful with your code and disciplined with testing. Dynamically-typed languages usually work great for small things but start getting harder to use as projects grows in scope. (Background: I worked on several commercially-released titles that used Lua extensively and added Lua scripting to an older game as part of an unofficial patch.)
  2. Calculating "Spread" for shotgun shot

    This would achieve the same effect in a slightly simpler way: [code] //determine deviation from target using a bell curve type distribution double deviation = Functions.RandInRange(0, Spread) - Functions.RandInRange(0, Spread);[/code]
  3. You might want to do something more like Sleep(20) since its input parameter is time in milliseconds.
  4. How is an FPS game built

    That's actually how some games do it. You exporting two sets of animations from the same original source, one for the weapon and one for the hands. The big advantage is that you don't duplicate the arm geometry for every weapon, which adds up to major savings if you have a lot of weapons or your arm models are detailed. Of course, many first-person games just show the end of the weapon so the player character's hands and arms aren't visible.
  5. Bitmap Fonts performance issue.

    I suspect the Bitmap font display lists push an orthographic projection matrix, which you'll need to do yourself here. (Check out the OpenGL FAQ item [url="http://www.opengl.org/resources/faq/technical/transformations.htm"]9.030[/url]) The only thing you lose with a texture-based font is pixel-perfect accuracy when scaling or rotating. Everything else is achievable. Position: push a translation matrix or simply add an offset when generating vertex positions Size: build multiple textures from the font; most of the time you want only a few point sizes anyway Color: use glColor to set the text color; this assumes modulate texture blend mode (the default), I strongly recommend doing all your screen-space rendering at the same time near the end of the rendering process. You'll only need to push the projection matrix and related render state once instead of for every character. You'll may want to to disable Z-buffering so text always draws on top of everything else. Here's how I do it: [code] // push projection transform glMatrixMode(GL_PROJECTION); glLoadIdentity(); glOrtho(0, windowWidth, windowHeight, 0, -1, 1); // use screen coordinates glMatrixMode(GL_MODELVIEW); glLoadIdentity(); // disable depth testing glDisable(GL_DEPTH_TEST); // draw screen-space items // ... // restore depth testing glEnable(GL_DEPTH_TEST); // reset camera transform glMatrixMode(GL_PROJECTION); glPopMatrix(); glMatrixMode(GL_MODELVIEW); glPopMatrix(); [/code] This is old-style (1.x) OpenGL and deprecated in the latest versions but shows the general principle.
  6. Bitmap Fonts performance issue.

    Many games draw text the same way they draw screen-aligned sprites: pack glyph bitmaps into a texture sheet and draw screen-aligned rectangles with appropriate texture coordinates. At a minimum you'll need texture coordinates (u0, v0, u1, v1) for each character, but you'll most likely want a position offset (x, y) so you can cut out empty space around glyph bitmaps and a width (w) so you can compute character positions and string widths more easily. For text that doesn't change often, you can build a draw list from your text rendering and use that draw list to render text until it changes. Protip: to ensure texels line up perfectly with pixels, subtract 0.5 from the integer vertex positions. (A half-texel shift compensates for bilinear filtering, but a half-pixel shift compensates for both bilinear filtering and multisampling.)
  7. To goto or not to goto?

    [quote name='Trienco' timestamp='1312703714' post='4845702'] [code] while (1) { if (a_fails) break; if (b_fails) break; break; } [/code] [/quote] This construct eliminates the risk of an infinite loop: [code] do { if (a_fails) break; if (b_fails) break; // do stuff } while (false); [/code] I'm still not fond of it, though.
  8. MSVC++ 2010 optimization option?

    If you're trying to create a location where you can place a debugger breakpoint, you can insert a nop instruction via inline assembly (__asm nop) or a compiler intrinsic (__nop()). I haven't tried the compiler intrinsic but the optimizer definitely won't try to remove inline assembly.
  9. Enabling vsync will reduce CPU usage since the application will "sleep" while waiting for the next vertical blank instead of running as fast as it can. In SFML 1.6 it should be as simple as calling the UseVerticalSync method of your render window object. (SFML 2.0 renames it to EnableVerticalSync.) I'll echo the general sentiment around here that you should avoid multithreading if at all possible since it gives even veteran game developers a hard time. Getting a game to work properly is hard enough already without the added complexity of threads.
  10. It looks like you're missing a row. If you're submitting a 32x32 block of grid squares, you actually need a 33x33 grid of vertices. (You'll be submitting the vertices along the edges between squares twice and the vertices as the corners four times.)
  11. I suspected that's what you wanted but I wasn't sure. To achieve that access pattern: [code] for (int yOuter = 0; yOuter < 4; ++yOuter) { for (int xOuter = 0; xOuter < 4; ++xOuter) { for (int yInner = 0; yInner < 32; ++yInner) { for (int xInner = 0; xInner < 32; ++xInner) { float value = vector[((yOuter * 4 + yInner) * 32 + xOuter) * 4 + xInner]; ... } } } } [/code] The nested loop structure is exactly the same as before; only the index calculation changed. A simple optimization: [code] for (int yOuter = 0; yOuter < 128; yOuter += 32) { for (int xOuter = 0; xOuter < 128; xOuter += 32) { for (int yInner = yOuter; yInner < yOuter + 32; ++yInner) { for (int xInner = xOuter; xInner < xOuter + 32; ++xInner) { float value = vector[yInner * 128 + xInner]; ... } } } } [/code]
  12. translating between experience curves

    Instead of trying to fit a formula, treat the original table of thresholds as a piecewise-linear function and use it to convert each player's current experience level to a level and fraction. Let's assume the experience chart looks like this: [code] level 2 at 10000 XP level 3 at 30000 XP level 4 at 60000 XP level 5 at 100000 XP [/code] A character with 75830 total experience would be level 4 and working their way towards 5. Their fractional level would be (75830 - 60000) / (100000 - 60000) = 0.39575. Add that to the integer part to get 4.39575. Under the new experience system you describe, that corresponds to 4.39575 * 5000 XP = 21978.75 XP, which you could round up to 21979. This way players keep their current level progress but advance more quickly after the conversion since each XP is worth more towards level progression. You can use this technique to convert to any other experience chart, not just the linear one you describe.
  13. If you want the values in each "chunk" to be contiguous, treat your data like a 2D array of 2D arrays: [code]array[4][4][32][32][/code] (The first [4][4] is the outer array and [32][32] is the inner array.) You can achieve this access pattern in a 1D vector like this: [code]vector[(((yOuter * 4) + xOuter) * 4 + yInner) * 32 + xInner][/code] Walking through the array of arrays then looks like this: [code] for (int yOuter = 0; yOuter < 4; ++yOuter) { for (int xOuter = 0; xOuter < 4; ++xOuter) { for (int yInner = 0; yInner < 32; ++yInner) { for (int xInner = 0; xInner < 32; ++xInner) { float value = vector[(((yOuter * 4) + xOuter) * 4 + yInner) * 32 + xInner]; ... } } } } [/code] You can (and should!) optimize this but it shows how things work.
  14. As far as maths goes..

    Beyond standard algebra, you'll run across several kinds of math almost constantly in modern (3D) game development. [list][*]linear algebra: vectors for positions, directions, and velocities; matrices for transforms and orientations; vector operations like dot product and cross product[*]trigonometry: going back and forth between angles and vectors[*]differential equations: most of these are basic mechanics and involve position, velocity, and acceleration[*]numerical methods: numerical integration (e.g. acceleration to velocity, velocity to position) and differentiation (vice versa)[/list] You'll need to know a lot of these even if you aren't a graphics programmer or physics programmer. They come up in gameplay programming far more often than you might think. Calculus doesn't come up nearly as often but it doesn't hurt to learn anyway.
  15. The one-button game thing wasn't a joke but a deliberate constraint to challenge designers. It led to some [url="http://www.casualgirlgamer.com/articles/entry/35/best-one-button-games/"]interesting results[/url], with Canabalt being a notable success. As for two buttons, there's always Konami's [url="http://en.wikipedia.org/wiki/Track_%26_Field_%28video_game%29"]Track and Field[/url].