| bio | website | |
|---|---|---|
| location | New York, NY | |
| age | 33 | |
| visits | member for | 2 years, 9 months |
| seen | yesterday | |
| stats | profile views | 82 |
|
May 15 |
answered | Do you actually use diagrams to model games? |
|
May 11 |
answered | Avoiding constant IF checks for loops |
|
May 10 |
comment |
OpenGL ES 2.0: Enabling hi-res on iOS How are you setting up your GL renderbuffer and projection matrix? Specifically, does e.g. glGetRenderbufferParameterivOES(GL_RENDERBUFFER_OES, GL_RENDERBUFFER_WIDTH_OES, &backingWidth); get you a backingWidth at the higher resolution? |
|
May 5 |
comment |
How to achieve realistic engine sound? I'd highly recommend you poke around back issues of Game Developer Magazine (gdmag.com) and also the GDC Vault -- for example, gdcvault.com/play/1015351/Racing-Games-A-Semi-Formal . There are quite a few presentations and bits of literature floating around about this! |
|
May 5 |
comment |
Android OpenGL ES 2.0 gameloop problems @user22241: avoid busy-waiting if at all possible. If you can determine the usual (e.g. within two standard deviations or so) error in Timer or Thread.sleep, then just account for that and set your timer early. requestRender() should get you a render at the next vblank anyway, I think, so it will "un-round" your conservative timer/sleep if you set it up correctly? (This solution bites, so hopefully someone else will suggest with a better one.) Obviously you will need some sort of interlock to not requestRender() if you aren't actually done with your update for a long frame... |
|
May 5 |
comment |
Android OpenGL ES 2.0 gameloop problems That sounds like what I expected. It seems like if you detect that you're exceeding the rate you want to limit to, you might need to swap over to RENDERMODE_WHEN_DIRTY, and manually pump requestRender(): developer.android.com/reference/android/opengl/… -- presumably that would still vsync correctly, kicking off the onDrawFrame on the next vsync. I wonder if you could put that on a timer object or something that would be more precise than Thread.sleep... |
|
May 5 |
comment |
Android OpenGL ES 2.0 gameloop problems What gave you the impression that Thread.sleep was a bad idea? (I'm curious. =) |
|
May 4 |
comment |
best structure to handle entities in an entity component based game engine Can your enemies and items overlap multiple tiles? (For example, do they move across 8x8 tiles a pixel at a time?) Or is the granularity of placement/movement 1 tile? |
|
May 4 |
comment |
Do I need Texture Units when NOT using shaders? +1, but I actually disagree that there is "no excuse to not use shaders", especially if you're targeting handheld or embedded systems -- or even some consoles. There are quite a few that are still alive and kicking that have either fixed-function pipelines or are only partially programmable. Also I've worked with a few platforms where both are available, but due to driver or hardware issues, the programmable pipeline has ... issues, and the fixed-function / GLES 1.1 pipeline is much faster. Hopefully this won't be the case much longer, but it definitely still is a concern for us! |
|
Apr 27 |
comment |
The algorithm for removing a group of adjacent balls of arbitrary shape If I understand the question correctly, you might start by looking at match-3 algorithms; these will identify the start of groups for you, and could be extended. There are a number of answers here: gamedev.stackexchange.com/questions/2607/… (full disclosure, includes one of mine) |
|
Apr 26 |
awarded | Nice Answer |
|
Feb 28 |
comment |
Program created with glCreateProgram is not identified as a valid OpenGL program outside wikipedia to the rescue. there are mentions elsewhere on gotw.ca, but they're a little deeper in: en.wikipedia.org/wiki/Rule_of_three_(C%2B%2B_programming) It helps if you think of _programId as something more like a pointer (it's a resource handle) rather than an integer. |
|
Feb 28 |
comment |
Program created with glCreateProgram is not identified as a valid OpenGL program outside @Leo: I agree, though, breakpoint on the destructor is probably a good idea; it's likely that the destruction of the temporary copy on the right hand side of the = after the operator= has taken place is destroying the program somehow. Usually operator= or copy constructor will take some measure (e.g. reference counting or the like) to make sure shared "resources" like this shaderprogram are either handed off or owned in a way that's compatible. Trying to find the gotw.ca link I was thinking of.. |
|
Feb 28 |
comment |
Program created with glCreateProgram is not identified as a valid OpenGL program outside @mh01: no disrespect intended, but not sure it's worth a -1. The question is reasonably well constructed and shows attempts to figure out the problem, including use of glGetProgramInfoLog etc. C++ in many ways is subtle and not necessarily intuitive. I didn't know about the "big three" until I read through the entire archive of gotw.ca. |
|
Feb 27 |
comment |
Program created with glCreateProgram is not identified as a valid OpenGL program outside Is this C++? Your shaderProgram = ShaderProgram(...) line may invoking assignment operator or copy constructor that's incorrect? |
|
Feb 26 |
comment |
Choose your own adventure console program Well, yes and no. Ask 10 different folks about this kind of thing and you'll probably get 10 different answers. Do whatever research interests you, then dive in and make a program. You can always improve it later =) and you'll be better equipped to understand things once you've done an implementation (even if it's going wrong). Remember to use source control (e.g. Mercurial or Subversion) so you can go back in time if one of your experiments goes wrong. =) And more than anything else, try to enjoy it. I do want to emphasize one thing, and that's making diagrams to help! |
|
Feb 26 |
answered | Choose your own adventure console program |
|
Dec 29 |
awarded | Citizen Patrol |
|
Nov 27 |
awarded | Nice Answer |
|
Aug 9 |
awarded | Nice Answer |