Another Stupid, Stupid Mistake...

Well, I felt so genius when I found the obvious solution to my problem.

For all the time I have been coding, I never figured out how to get smooth movement, until I tried to make a small physics test (did not go well :P). But in doing that, I found my solution. It wasn’t even intentional!

You see, I wanted movement like this (yes, my own game; made immedietely after my ‘discovery’).

Originally, I was doing something amung the lines of this:


       float accel = 0.3f;
       float decel = -accel;

...

       if(movingx)
           this.xvel += accel;
       else
           this.xvel += decel;
       if(movingy)
           this.yvel += accel;
       else
           this.xvel += decel;

Very messy, nothing worked, and it was all just unnessacary.

So I was trying physics out, and came up with this!


       // Variable for friction. NEVER let it go beneath 0.94. Otherwise you barely move.
        float fric = 0.96f;
       
        // Velocity vector. Self explainatory.
        Vector2f velocity = Vector2f.get(0, 0);
         
        // This is more of an 'applyForce()' method, but, ya know. YOLO (not. that is for dorks).
        public void move(float x, float y) {
                velocity.x += x;
                velocity.y += y;
        }
         
        public void update(float delta) {
                this.x += velocity.x*delta;
                this.y += velocity.y*delta;
         
                // This will dampen your movement. Clean and simple
                velocity.x *= fric;
                velocity.y *= fric;
        }

Worked like a charm, was more efficient, and is easier to do! All this suffering, nights and nights trying to solve this… Simple solution… :P, :P, and :P.

Et Toi? Any major ‘DOH!’ moments in your coding?

Eh, I’m sure I have lots, but I’m really wondering what Et Toi means, and I’m too lazy to open up translate :stuck_out_tongue: Use the French skills you’ve been talking about and translate it to me :wink:

Oh I just remembered actually. I created a voxel engine over a year ago just a few months after I started OpenGL, and I just looked at my code. To my great surprise I found out that for every block I had in the world, I was creating 4096 more in the same exact location because for some idiotic reason I thought that each block was a chunk or something… I don’t know but it really made me laugh very hard when I discovered that!

Well, I’m sure I pretty much did permanent damage on my GPU, but I don’t have it anymore so its ok :slight_smile:

More than I could possibly remember or even count, though most of them are just “Why is my screen black?!” 5 hours later Oh, I forgot to bind a texture/shader/VBO/VAO/vertex attribute/FBO there.". Debugging graphics is horrible. At best you’ll get a generic error message, at worst just a black screen (or whatever you’re trying to render isn’t rendering).

Oh, here’s one: Why isn’t my game starting? It just freezes my whole computer for a few seconds and then crashes my graphics driver. Turned out I was trying to render to a 10240x5760 render target. I don’t think my old GTX 295 with 896 MBs of VRAM liked allocating 1800 MBs of textures.

Not unless it overheated…

That was sarcasm :wink:

I hate starting new graphical projects and not seeing anything on the screen after I spend hours working on the basics. Its the most frustrating thing ever, and it’s usually because you missed one or two variables or forgot to enable something. Just terrible.

That’s why I always make a backup of my first working render whenever I start a new library so I can have a base later in other projects to get my bearings :slight_smile:

Right, but sometimes you are rendering in a different way. For example, I just started using shaders and buffer objects a lot more in my OpenGL development instead of old display lists, and sometimes things just don’t work out and I have nothing to rely on except for randomly changing code and lots of googling!

I spent 2 days debugging one of my games that was rendering nothing.

I tried everything: Checking shaders, textures, correct placement of draw calls etc.

Turns out that in my renderer class I forgot to change the variable that tells it to update the VBO.

Half of you wants to celebrate that you finally found the bug while the other half wants to go sit in the corner and cry at all the time you wasted.

I spent 2 days trying to figure out why my texture wasn’t rendering.Turns out I wasn’t saving the spritesheet in the same location to overwrite the old one (I had moved the file and saved without using save as).

Sad thing is, it’s happened multiple times…

Oh pshh… I learn from my mistakes after I make them five times, that’s the only way I’ll possibly remember not do it again!

The best way of doing OpenGL stuff is to always create a standalone test program every time you want to do something “new”. This makes debugging a million times simpler and you’ll be able to grasp the basics of what you’re trying to do without having to worry about your huge game/engine directly or indirectly messing up something, like leaking OpenGL state. When shit hits the fan (and it always does) you’ll have to start dissecting your whole engine, cutting off parts until it works to narrow it down to the problem. If you just create a new test class and try it out, you’ll figure out all the quirks before it’s completely integrated/infesting your engine. Once you’re happy with your test, THEN you can implement it. Most of the time it’ll just work right away when you port it into your engine after that, and if it doesn’t the problem either lies in the differences between the standalone implementation and your game implementation of the feature, or your game is leaking OpenGL state that’s breaking it.

This is probably the most important thing I’ve learned from doing OpenGL programming. Even if writing a test program takes half an hour or even a whole hour, implementing the full-feature version into your game takes a fraction of that time since you can reuse that code easily. And when everything explodes when you put it in your game/engine, you’ve already covered around 80% of the things that can go wrong. I still sometimes end up hacking together hundreds of lines of code and shaders and hope that it just works at the end, but every time it doesn’t I pay the price threefold. Spending those extra 30 minutes on a test programming gives you a much more predictable time schedule when working with things you have less experience.

TL;DR: Write standalone test programs to avoid having to figure out bugs in your main engine when working with things you have little experience with, or debugging it is extremely painful.

i was getting exceptions trying to load an8 files because i didn’t realize that there could be multiple points and texcoords per line of the file

Well at least you started with floats. I started doing movement and speed using integers. Next to hap-hazard and jerky movement, eventually I ran into the problem if wanting to move slower than a pixel per “tick” so I introduced delays so I could move every ‘x’ ticks and make things even more difficult to manage while not solving the jerky movement problem at all.

And then I figured out: USE FLOATS FOR SPEED AND POSITIONING. facepalm

And this is why people say that writing code is only a small part of programing.

Is it programing or programming?

Well darn, I actually don’t know! I think its programming :stuck_out_tongue: My phone didn’t auto correct it so I think that’s right…

Ha, programming is all you do when creating programs except for when you’ve been coding for years and you already know how most things work. I mean sure, you’ll run into problems still, but you can just sit down and code and not worry what this function does or how to do this. I think it all becomes trivial for experienced coders and of eventually becomes more about thinking about new ideas and staying focused than actually coding. I envy those people!

Programming (which is writing code) is only a small part of the development process :wink:

[quote=“opiop65,post:15,topic:45270”]
Not sure if I qualify as that experienced to be honest, but this is actually a really big problem. The better you get at programming, the more trivial problems get. The more trivial they get, the more boring they get until pretty much all coding is trivial. That can be a real problem if you enjoy the actual coding process more than getting a “result” (a game, an engine, a demo, a tool, a benchmark result, whatever).

Eh, I understand that, but it would be nice to get to the point where that actually happens to me, to be honest with you. To just be able to code and not worry about anything, that would be really nice!

I often find I get to the office in the morning not knowing how I will solve problem X. I work on the problem during the day and it feels easy. I have these clever insights and moments of awesome clarity, and by the end of the day I have built something successful.

Only problem is, I get into the office the next morning, and I can hardly understand what I wrote the previous day! It’s like reading someone else’s code…

Do you comment your code at all? And what do you do? I want to get a degree in computer science, but I have no idea what programmers actually do :stuck_out_tongue: Do you just write programs for corporations or what?