Wow, in 1 game my best went from 19 to 50! Keep those yawning abyss things, I think they work great. Do they just kill you when you step in?

My initial assumption was that the dark sperm would be repeating your moves from the previous levels. Maybe it would be interesting to have a few of your previous incarnations show up now and then. I'm not sure how you would differentiate their level number from the "hit points" of the other enemies.

Man those creaky arrows keep getting me for some reason! I can't get past level 19. Forget what I said about the art, it looks great, I was just fed up because looking through the playtesting forum just about *every* game is using pixel art!

Great! How did you come up with the music and sfx? They are awesome and add so much to the game.

Runs great. Turn based is perfect, don't change it. I got to 19 after getting over the initial difficulty hump, which didn't take too long. Difficulty seems perfect. Overall I think its awesome.

Only "criticism" so far, and this is really just my preference, but I think the game looks good in spite of the pixel art. I don't like that pixel art has become the default choice. But that is a trend I never really got in the first place.

My personal metric for a good game is how many times it makes me gasp or say "shit" or "fuck". You did well

So then it wasn't necessarily a denormal problem, which is purely a performance bug, at least on cpus. Or it was a denormal problem, and (at least some) gpus simply don't support them?

I think the size of the eyes is ok. The color makes her look like a googly-eyed albino. Is that the intent?

The controls and gameplay are good so far. The pixel art could use improvement. For instance, the lava looks amateurish to my eyes. Also, I strongly encourage everyone making a pixel art game to include an option to use a shader of some kind, for those of us who aren't particularly into seeing individual pixels. It isn't hard. If you send me a screen cap of the game in its native size (no scaling), I could show you how your game would look with the shader I wrote.

Crap even shaders have this problem??? How did you detect it? I can't believe gpu makers would conform to that.

Nice site, but there needs to be a better presentation of the information. As it stands, few will have the patience to sift through this long and ever-growing list of questions, most of which they probably don't care about.

At the *very* least, the search engine needs to be improved. As an example, I saw the question "What are the best 3d riggers?". So I tried searching for "rigging", and that question didn't come up. A question containing "rigging" did, followed by a list of completely irrelevant questions.

Is there a cross platform way to do that?

I freak out about losing my car keys. Still it always makes me mad when I am burdened by the bad decisions of others. Apparently this was really controversial when floating point was standardized, and as so often happens the wrong people won.

Don't worry about it.
The only place I can imagine this can have any noticeable effect is when you repeatedly multiply a large array of numbers by .9999 or something. Damping object speeds seems like a place where this could happen, but if you're worried about performance, you wouldn't update physics for objects that move so slow anyway.
A hundred times slower sounds awful, yeah, but since those numbers are so rare in practice, it's likely that your code is filled with much worse bottlenecks.

But even testing that the speed is that low would be 100x slower when the speeds are denormalized. Unless you explicity flush the value to 0.0. Maybe that would have a significant impact with a 100 or so objects. Or maybe not, but it is still annoying to have another little worry lodged in the brain.

WTF
http://stackoverflow.com/questions/9314534/why-does-changing-0-1f-to-0-slow-down-performance-by-10x

I've been programming for a long time, and I've never heard of this crap. I'm about to add some simple physics code, and now I have to complexify it by worrying about numbers getting too close to 0?

Do you worry about this when you code??

This is just as stupid as unsigned, both create these catastrophic traps around the most common number, 0!

I've found it very very hard to move away from c++. It is so easy to get used to the freedom it offers, and chafe at the relative restrictiveness of other languages.

That sounds like one of the "Big Ideas" that he, I think rightly, wants to avoid.

I decided that I was sick of writing little shaders for stuff that felt should be programmatic. And that it looked and felt sloppy having all these shader fragments littering the code. So, I wrote something which emulates the old multi-texturing fixed function pipeline with pixel shaders. Or at least, it implements my impressionistic take on how that might have worked, since I've never used it, and didn't bother to look at it since I heard it was a real pain to use.

So I just got it to work, but I'm wondering if I really gained anything. What do you think? Would you use it?

Old code:

Code:

 
   const char* pBkgShader =
   "uniform sampler2D textureUnit0;\n"
   "varying vec4 vColor;\n"
   "varying vec2 vTexCoord0;\n"
   "varying vec2 vTexCoord1;\n"
   "varying vec2 vTexCoord2;\n"
   "void main()\n"
   "{\n"
   "  gl_FragColor.xyz =  texture2D(textureUnit0, vTexCoord0).xyz * vColor.r;\n"
   "  gl_FragColor.xyz += texture2D(textureUnit0, vTexCoord1).xyz * vColor.g;\n"
   "  gl_FragColor.xyz -= texture2D(textureUnit0, vTexCoord2).xyz * vColor.b;\n"
   "  gl_FragColor.w = 1.;\n"
   "}\n";
   mpBkg->SetShader(NULL, pBkgShader);
   mpBkg->AddTexCoords(2);

New Code:

Code:

 
   tgl::tsStage s1(TSOUT_RGB, TSARG_TEX_RGB, TSOP_MUL, TSARG_COLOR_R, 0, 0);
   tgl::tsStage s2(TSOUT_RGB, TSARG_TEX_RGB, TSOP_MAD, TSARG_COLOR_G, 0, 1);
   tgl::tsStage s3(TSOUT_RGB, TSARG_TEX_RGB, TSOP_MSB, TSARG_COLOR_B, 0, 2);
   tgl::tsStage s4(TSOUT_A,   TSARG_ONE,     TSOP_EQU);
   mpBkg->SetTextureStage(new tgl::textureStage(s1, s2, s3, s4));
   //No need to add texture coords, the textureStage class knows how many are needed

More concise, but also much less intuitive. Do you think there is any value in this, or did I waste my time? I'll send the code to anyone who is interested.

I like his approach and attitude, especially his distrust and distaste for dogmatic programming "best practices".

I did get the sense that the proposed language is tending towards a "Jonathan Blow" language, tailored to the particularities of how he happens to work. While it may seem like coding nirvana to him, it will face too much resistance (or more damaging, indifference) if it shortchanges the features that he seems dismissive of (classes, macros, templates).

That it c++'s greatest strength, I think, that it is a designed-by-committee hodgepodge mess, that imposes nothing and can accommodate anyone. As soon as you start trying to whittle it down, and thus impose your idea of how programming should be done, you leave people behind. The only way to replace it I think is to come up with a bigger, better mess.

It sure does, thanks.

Maybe I'm outing myself as a dumbass, but I've been staring at this for too long, and I just can't figure it out.

Why does this give correct results:

Code:

vec3 deviate = vec3(0.0, 0.0, 0.0);
for (int i = 0; i < 9; i++)
{
  vec3 diff = (samples[i] - result).xyz;   
  diff *= diff;
  diff *= diff;
  deviate += diff*diff*samples[i].a;
}

But this gives garbage:

Code:

vec3 deviate = vec3(0.0, 0.0, 0.0);
for (int i = 0; i < 9; i++)
{
  vec3 diff = pow((samples[i] - result).xyz, vec3(8.0));
  deviate += diff*samples[i].a;
}

Terrain generation!

how fun!

Have you tried making a plane that's subdivided several times, moving the leading vertices to the mouse cursor, and making the following vertices trail behind that position by a few ticks, like a standard weapon or movement trail?

Have you tried simply spawning particles, or additive blended planes where the cursor is, and having them fade out or get smaller over time? At a high-framerate and without moving the mouse cursor a lot, it's an effective approach, I think.

The latter (planes) is what I was doing initially, and it looks *ok*. I don't think the former really solves the basic problem: the generation of glitchy, crap-looking junk under arbitrary, jerky mouse movement. And really even when it was working correctly it didn't look especially spectacular. There are much more important things I need to worry about right now. I may come back to it at some point though.   

I'm working on a glowing trail that follows the mouse cursor.

SWEET BABY JESUS this is hard to get right. I thought this would take me like an hour or so. NOOOOO SIR. Its been days and days of trying and scrapping one approach after the next, mounting frustration, despair looming larger and larger. If I knew it would be this hard, I would never have bothered. But now I have to see it through. I *think* I finally see the light at the end of the tunnel. But good god, this sucked.

I give up, its just not worth it. What a WASTE OF TIME.

Just Google additive hash functions, mine is a derivation of it, will get the source code online soon if you are interested...

I did, and all I could find is the naive hash function of simply adding up the bytes of whatever you are hashing, which is not what you are describing.

Naive, but efficient, but still naive, we gotta remove the "naive" part, your homework, tell me why it's naive, and how I can make it non-naive, thinking a bit about it, you'll find out how I did it

Naive, for one, because it is commutative, so "ab" hashes to "ba". I feel like we are talking about two separate things, your homework is to explain what you are doing.