Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!


1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


radioteeth

Member Since 19 Oct 2005
Offline Last Active Today, 10:08 AM

#5212959 How do I know if I'm an intermediateprogramming level?

Posted by radioteeth on 25 February 2015 - 02:50 PM

http://sijinjoseph.com/programmer-competency-matrix/




#5199377 A few general questions to point me in the right direction

Posted by radioteeth on 21 December 2014 - 02:10 AM

the glow effect is usually either a part of a sprite texture (additively blend a blurred version with the texture) and then the texture is just rendered additively to the scene.

 

alternatively, for a more dynamic and 'present' glow a fragment shader is used, where the scene is rendered into a framebuffer texture and this texture is then fed into the shader via fullscreen quad, this shader then additively blends the original texels with blurred texels. typically a box-blur is used because of its speed (and thus, two passes for horizontal/vertical). Another approach is using the prefix sum via Summed Area Table (related http://docs.nvidia.com/gameworks/content/gameworkslibrary/graphicssamples/d3d_samples/d3dcomputefiltersample.htm)




#5199376 Compute Fog of war with unit Line-of-sight

Posted by radioteeth on 21 December 2014 - 01:58 AM

 My first suggestion is to only check a fixed number of tiles per frame. Secondly, group units together that are near one-another using some clustering algorithm, and then use the largest visibility radius of those units to do the visibility check for all of them as if they are one unit. This will reduce what is mostly redundant checking.

 

 Thirdly, perhaps use a lower-resolution FOW map than what the actual map tiles are at. Maybe FOW tiles are 2x2 game tiles. This will speed everything up 4x. Using a separate map to represent FOW simplifies rendering as another pass over the scene.

 

 Oh, and another idea is not to trace lines from each unit to each tile, or vice-versa, but to find all occlusion-tiles (non-pathing tiles) and cast FOW 'shadows' outward from them away from units. This would basically be starting with all tiles within view radius, then subtract hidden tiles - instead of tracing lines to all of them. Make sure you don't cast FOW shadows into another unit's visible area, though.

 

 Good luck.

 

 

EDIT:

 

 A quick way to roughly check if one tile is within another's shadow is to use the dot product of the vector from the unit to the non-pathing tile and the vector from the unit to the tile you are checking for visibility. Check that the dot product of these two vectors is *close* to 1.0, in that, they are almost the same (but not demanding exact).. The more margin (epsilon?) you allow for, the less likely your FOW will have holes behind occluders, but the more likely that occluders will cast larger FOW 'shadows'. I hope this all makes sense.




#5197919 Weird particle lag?

Posted by radioteeth on 12 December 2014 - 09:17 PM

enabling/disabling GL_VERTEX_ARRAY for each single particle is a red flag.

 

using individual VBOs for each particle is a red flag.

 

Update the positions of all your particles and dump that to a single VBO in a single glBufferSubData call. Then render all of them with one single DrawElements call. Doing all these state changes and stuff for each individual particle is not going to work.




#5195263 Super Cool Effects

Posted by radioteeth on 28 November 2014 - 04:51 PM

particle systems and blending.




#5191742 Can't load .wav files with SDL

Posted by radioteeth on 07 November 2014 - 07:21 PM


The Windows operating systems (Vista, Win7, Win8, etc...) by default hides the file extensions to prevent less computer-savvy users from accidentally changing the extension and confusing programs trying to open them.

 

I couldn't believe when they started doing this, I believe it was after 98/ME... and, yes, I used ME between 98 and XP, once upon a time.




#5191609 Can't load .wav files with SDL

Posted by radioteeth on 06 November 2014 - 07:45 PM

Actually, the error message should be "Mix_LoadWAV_RW with NULL src", shouldn't it? Did you accidentally copy the error message wrong? wacko.png

 

Are you positive your filepath is correct? Could you post the filepath you are using? It seems to be saying it that Mix_LoadWAV() isn't even receiving the raw binary data from the file. It's not a parsing issue, or anything like that - it's not even getting the file data.

 

Try logprinting your fileName.c_str() to make sure it's correct.

 

In these cases sometimes I actually dive into SDL's actual code to see what causes certain errors.




#5188342 Mouse OnClick with explosion effects

Posted by radioteeth on 21 October 2014 - 11:30 AM

create a little array of explosions that contains their position, and lifetime, or time of creation. Then every frame you just draw all the active explosions in the array that haven't burned up yet. When you click, you find an empty/dead explosion slot in the array and fill it with the mouse position and current time.




#5187759 Looking for cheap AO baking solutions

Posted by radioteeth on 17 October 2014 - 07:26 PM

I'm working on a 3D tile game (NOT blocky minecraft worlds) and have had good success using a distance transform (aka distance field) of the world for performing ambient occlusion approximation.

 

http://www.iquilezles.org/www/material/nvscene2008/nvscene2008.htm




#5183593 generating branching structures without recursion

Posted by radioteeth on 28 September 2014 - 07:13 PM

 I thought I had this figured out, but now I'm starting to believe that I was mistaken. I'm working on generating simple branching structures (trees, basically) using a simple command scripting language that supports looping, but not recursion. There is also a stack that I can use the push/pop commands to save the current branch state and load it back to continue working from.

 

 I'm very limited with what I can do with this scripting system, and for some reason I thought I had this figured out, but apparently I don't. Either I can't remember what I thought of, or what I thought of was totally wrong. My original 'aha' solution involved using two nested loops, and I keep thinking I had some clever use of the push/pop orientation stack that let the loops properly generate branches on branches to a defined depth, but I just can't remember or see what I was going to do.

 

 Is it even possible? Am I just going mad?




#5181739 glViewport Makes no sense

Posted by radioteeth on 20 September 2014 - 12:05 PM

What's happening is you are setting your glViewport the 2nd time, rendering to an FBO, and then doing whatever with the FBO to actually get it to the screen while your glViewport is still the right half of the screen. So the FBO gets dumped to just that area.

 

EDIT: add another glViewport for the entire screen before you draw the stereo FBO to the screen.




#5181073 BSP trees with modern OpenGL

Posted by radioteeth on 17 September 2014 - 12:56 PM

I just iterate through everything (game objects) I know that I know are visible and throw them into a separate binary tree (every frame) using their squared distance as each node's value with a pointer to the object. Then when I render, I just walk through the binary tree from furthest to nearest. FYI: The reason I used a squared distance to populate the tree is to avoid using a sqrt.




#5180013 BSP portal visibility

Posted by radioteeth on 13 September 2014 - 12:12 AM

http://www.cs.utah.edu/~jsnider/SeniorProj/BSP/default.htm

 

The inner nodes of the tree only describe splitting planes, and the leaves themselves are the geometry formed by all the splitting planes. Convex hulls are formed, and where they are missing a polygon (a splitting plane is there instead) that is the portal shared with another convex hull.




#5170951 Basic Fluid Dynamics

Posted by radioteeth on 01 August 2014 - 02:18 PM


To be honest though, doesn't the SV_Position semantic go from [0, screenWidth] x [0, screenHeight] from the top left corner? If so, if there's a pixel at (10,10), the bottom one would be (10,11) and top (10,9), wouldn't it?

 

I know that OpenGL is flipped upside down (like TGA) where the bottom left is (0,0), I'm not sure about D3D though. In reality, it doesn't matter if you call it top/bottom head/toe, etc.. What matters is that the 'greater' value has the 'lesser' value subtracted - regardless of the orientation (semantics). In this case, you have the coordinate with (0,1) added, and (0,-1) added, to create two coordinates, and all that was happening here was you were subtracting the larger coordinate from the lesser coordinate, instead of the other way around.




#5170917 Basic Fluid Dynamics

Posted by radioteeth on 01 August 2014 - 11:22 AM

float2 bottom = PositionToTexCoord(input.position.xy + float2(0.0f, 1.0f));
float2 top = PositionToTexCoord(input.position.xy - float2(0.0f, 1.0f));

 

and you are doing

 

float div = 0.5f * ((r.x - l.x) + (t.y - b.y));

 

try swapping the +/- where you define bottom and top






PARTNERS