15,876 reputation
13672
bio website vectorstorm.org
location Melbourne, Australia
age
visits member for 3 years, 11 months
seen 12 hours ago

Mobygames Profile (not entirely accurate): http://www.mobygames.com/developer/sheet/view/developerId,80048/


Jan
26
reviewed Close Procedural generation of plausible genealogy tree with time query without history
Jan
26
answered How to render apart blocks of a cone
Jan
16
revised Textures “don't work” when I don't specify any texture parameters. Is this a driver bug or intended behavior?
More edits for simplicity and ease-of-reading.
Jan
16
revised Textures “don't work” when I don't specify any texture parameters. Is this a driver bug or intended behavior?
Rearranged for easier readability.
Jan
16
answered Textures “don't work” when I don't specify any texture parameters. Is this a driver bug or intended behavior?
Jan
10
comment OpenGL - Arcball camera rotation
You can't implement arcball control that way. If you're using pitch and yaw accumulators (such as your 'pPitch' and 'pYaw' values), then you're not building an arcball; you're just using normal euler angles, like you'd see in a ground-based FPS shooter. You already have all the right pieces in your code; you just want to actually render using 'pViewMat' as your view matrix, instead of using 'pPitch' and 'pYaw' to build a new one.
Jan
9
comment OpenGL - Arcball camera rotation
There's not enough information here to actually tell us what problem you're having, but if I was a betting man, I'd bet that you have code not shown that's using those 'pPitch' and 'pYaw' values to set the view matrix, instead of actually using the 'pViewMat' matrix that you set up in Camera::update(). Since your pPitch and pYaw values are crazypants and not actually related to the camera position or target position in any way, that'd explain why the camera isn't pointing at the target.
Jan
9
comment OpenGL - Arcball camera rotation
...you're not doing anything with the 'pPitch' or 'pYaw' values. You put numbers into them and clamp them, but they don't actually influence anything in any of the code you show here.
Jan
5
reviewed Close How to Render an xml tile grid in java
Jan
5
reviewed Close The recommended road map to be a good graphics/game engine programmer
Jan
5
reviewed Close Reflect angle on pong clone
Jan
5
reviewed Close Multi Resolution graphic for ios 4 and ios 5
Jan
5
reviewed Close Drawing visible tiles - side scrolling
Jan
5
reviewed Close Particles in XNA - can't get em to work
Jan
5
reviewed Close client-server network model for top-down WASD game
Jan
5
reviewed Close Which server platform to choose
Jan
5
reviewed Close Looking for Bezier curve OpenGL open source implemention
Jan
5
reviewed Close Deforming meshes in OpenGL
Dec
28
reviewed Close Are there any resources about performance tweaks?
Dec
24
comment What is the cause of this lighting artifact on my dynamic terrain mesh?
So the idea is, if (fabs(TR-BL) < fabs(TL-BR)) { Make BR-BL-TL and BR-TL-TR } else { Make BR-BL-TR and BL-TL-TR }. Any non-planar quad (such as virtually every quad in a heightmap-based terrain) will 'buckle' as it's turned into triangles for rendering, and that 'buckle' will happen along the new triangle edge that you add, so it's going to run diagonally through the quad, one way or the other. The theory is that you get far fewer buckling-related artifacts if you make sure to put that buckle in between the diagonal vertices which are the most similar to each other.