Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 17 Nov 2008
Offline Last Active Jan 20 2015 04:46 PM

Topics I've Started

How can I recognize hand drawn shapes? (eg. the wizard in Trine)

14 August 2014 - 12:02 PM

tl;dr: I want simple hand drawn shapes (boxes, lines, circles) to be identified by my code when the user makes that pattern with their cursor.


Example video


I want to go from mouse input to solid objects based on the (rough) shape that is drawn. This is not edge or blob detection, nor vector art as far as I'm aware, but some sort of path direction/line segment detection. There are X preset shapes, and drawing something similar to one of them will create that shape at that size.


In Trine, this includes a square for a box and a line for a plank (not sure if there are others, but I don't mind that being spoiled for me if there are). So far I'm getting *way* more complex stuff than I need with my Google searches, I think, so turning here for more practical applications at my needs level. "Evolutionary visual learning" was described in one document I found, and that's far beyond anything I want.


Working in C#/Unity, in case there are any relevant libraries I should look at.



EDIT: These two assets in Unity seem to do what I want, but I'm looking to understand how it's done in case I can implement it more cheaply/effectively/simply myself for my own purposes (rather than adopting a new engine to what I already have)


Drawing Engine



How to draw visible shadow volumes, but through transparent polygons too

04 July 2014 - 09:04 PM

Disclaimer: this is older OpenGL, and while I would love to switch to all shaders (not sure if that would be appropriate here even), I'd rather complete what I have instead of switching the whole engine over at this point. It is an older project, but I'd still like to see it wrapped up in its current form.




My project is a 3d platformer, you have cubes jumping around on other cubes and they use shadow volumes to show where they are in relation to the ground. Recently I added crumbling blocks, the kind that disappear a few seconds after you touch them. That's great! I have them set so their alpha is reduced based on how long it's been since you've touched them so they fade away after a few seconds. The problem is: even at alpha zero, they're affecting the depth test for my stencil buffer.


The white/grey blocks are the crumbling ones:




(Don't mind the missing face, it's part of an efficiency measure to remove unused faces that doesn't consider disappearing blocks yet)


The problem you see here is that the shadows, while drawn fine on the left and right, are not appearing in the middle behind the player. That's because there are crumbling blocks there, though they have 0% opacity/alpha. You can even see the outline of the cube just above and to the right of the player because that's the shape cut out of the shadows.


Also: the player automatically gets a silhouette when behind another object, same stencil style test as the shadows, so that's why the player is mostly yellow and shadowed yellow but then turns green at the top. It's explained here.


I don't want to leave anything out I might be missing, so here's the whole code chunk (you can see my comments trying to remember what I wrote... I've gotten better at this since 2012... ):

// Give shadows to everything!
void drawAllShadows(int player) {
    // Blend function not causing any differences if enabled/disabled?
    // GL_BLEND is the difference between black shadows and dark versions of the colors underneath
    glEnable( GL_BLEND );
    // Not sure GL_ALPHA is doing anything, nor ALPHA_TEST
    glEnable( GL_ALPHA );
    glEnable( GL_ALPHA_TEST );
    // Color Mask with everything disabled means it doesn't use this data to draw real shapes/objects
    // instead, we're going to use it for a stencil test later
    // No Depth Test lets shadows overlap instead of their not-drawn sections deleting shadows behind them
    // GL_STENCIL_TEST limits the shadows to being drawn in the stencils, which are the levelShadows
    // Just draw the level shadows as regular polygons, but with the stencil option
    if (levelShadows) {
      // specify pointer to vertex array
      glColorPointer(3, GL_FLOAT, 0, shadowColors);
      glVertexPointer(3, GL_FLOAT, 0, shadowVertices);
      glStencilFunc(GL_ALWAYS, 0x0, 0xff);
      // if depth fails (can't see only due to z) then increment pixel's value
      glStencilOp(GL_KEEP, GL_INCR, GL_KEEP);
      glDrawElements(GL_TRIANGLES, 36*shadowsVisible, GL_UNSIGNED_INT, shadowIndices);

      glStencilFunc(GL_ALWAYS, 0x0, 0xff);
      // if depth also fails for back, decrement it so it stays at zero
      // but if one increments and the other does not...
      // (we'll come back to that later when we see where to place shadows)
      glStencilOp(GL_KEEP, GL_DECR, GL_KEEP);
      glDrawElements(GL_TRIANGLES, 36*shadowsVisible, GL_UNSIGNED_INT, shadowIndices);

      // deactivate vertex arrays after drawing

    for (int i=0; i<cubeNum; i++) {
      // cubeWithinPlayerRange demonstrates noticeable improvements,
      // castle level with 4player, sfx and music went from 7fps to 12.
      // now goes from 24 to 35fps! Wow!
      if (cubeWithinPlayerRange(i,player)) {

    for (int i=0; i<cubiorNum; i++) { drawPlayerShadow(i); }
    glColorMask(GL_TRUE, GL_TRUE, GL_TRUE, GL_TRUE);
    // Where the front and the back are not the same (so front face could be seen but back was obscured)
    // that is where a shadow is on the ground
    // or that is what I believe NOTEQUAL and REPLACE are being used for
    // all three replaces means no matter what (fail/zfail/succeed), we will the pixel with the new color
    glStencilFunc(GL_NOTEQUAL, 0x0, 0xff);

    glDisable( GL_BLEND );
    // end of shadow stuff

// 100% copied from draw_shadow for testing purposes
// full permission to copy this though, according to Josh Beam:
// http://joshbeam.com/articles/stenciled_shadow_volumes_in_opengl/
void fillScreenWithShadow() {
    // Fills the stencilled area with a shadow of 50% opacity on top of everything else
    glOrtho(0, 1, 1, 0, 0, 1);

    glColor4f(0.0f, 0.0f, 0.0f, 0.5f);
        glVertex2i(0, 0);
        glVertex2i(0, 1);
        glVertex2i(1, 1);
        glVertex2i(1, 0);


The function drawItemShadows is the exact one for the crumbling block shadows, but it works the same way as what you see here already. It increments the stencil's pixel value for front faces and decrements it for back faces, so it should be zero if both faces are visible or both are obscured, but if only one is then that's where a shadow lands. But again, the problem is that the z test there isn't taking into account transparent polygons. Before this code is where I draw the items and world itself (shadows are drawn last) and those are drawn with 3 point polygon indexes and 4 point color indexes, 4th slot being alpha.


So how do I skip alpha in my depth tests, but then apply that alpha to the shadow I draw ultimately? Is that possible, or do I need to break this up into separate passes somehow?

How do I avoid tutorials in a tamagotchi-like?

13 March 2014 - 11:17 AM

I'm working on a team right now for a pet game, like Chaos in Sonic, Nintendogs, Tamagotchi, etc. You have various stat bars that you should be keeping filled (not sure of the consequences for not doing this yet - which makes me cautious) and you can level up your character by playing with them, which gives you access to more items to customize with.


So you start the game and there's your pet with a few furniture items you can click on. You can click each furniture item to access a different menu - minigames, clothes, food, medicine.


The goal, I believe, is to level up the character by playing with them so that you can customize your character more, and that's about it.


How do I convey this objective or basic concept without tutorials? Mario, Megaman X, and any direct manipulation game seems to have no trouble with this, but I don't know of any pet games or second/third person manipulation games that don't use a tutorial. Any tips?

Players colliding and pushing against each other

22 February 2014 - 06:11 PM

New guy to the networking board here (although I have been blessed by the knowledge of the graphics boards before). I'm making my first networked game, and it's a 3d platformer. I'll be allowing players to jump on each others' heads, shove each other around, and in general physically interact a good deal - but they're just cubes, so it's rotation, position, and momentum. That's it.


So right now, I'm having my local game send my local character data of position/rotation/momentum to the remote game, where a copy character represents my local character in that remote game. So, it's a 1:1 of me in the offsite game.


Now I've got my local character, and the offsite player decides to take his offsite character and push it into the copy character. In local play, one character pushing against another leads to the pusher pushing the pushee around. In networked play though, the copy character is told to maintain that exact position based on the data my local game keeps sending about my local character. This leads to either no pushing or very slow pushing, because everything has to first go across the network twice before any real movement is made. That's bad!


So how can I fix this? If I don't send position, the momentum could ruin where they end up if any packets are lost. If I send position back and update my local character with data from the copy character, won't that overwrite my new controls/momentum/input that I'm sending locally? And if I just average everything, it moves at half speed.


The closest idea I have so far is that I should send the data both ways, but I have to be careful with my timing. Eg. I would read in the data sent back at the beginning of my game loop, so the first thing that happens is updates from across the network are applied, then I add my own changes with input, and then I finally send out that new broadcast of data at the end of the gameplay loop. But would that really work, or just lead to more cases of the players locking up against each other?



Any options for affordable ray tracing?

13 February 2014 - 12:26 AM

So as someone who has dealt with real time graphics instead of prerendered for his entire career, when I look at this..




...I feel like it's still a distant dream. Everything I'm learning is about how mirrors are too hard and how Portal's whole system was simplified to work with multiple cameras/physics in the game. That just doesn't seem right to me. There must be some way, especially with all these new consoles rolling in, to handle bending light, right?


My ideal would be something like these:






Reflections and curved/bent light, that's really all I'm looking for. Now, that might be asking for a whole new Google/Facebook (or some equally absurd and impossible amount of work), but I really think there's a workaround I just haven't heard of yet.


If all I want is these two things, do I have any options? Maybe even ones with a camera that moves?


I'd love to have a world the player can navigate where light bends in these beautiful ways. Are there any options at all for that right now?