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 ). 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').

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 Use the French skills you've been talking about and translate it to me

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!

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.

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.

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 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).

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.

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*

Well darn, I actually don't know! I think its programming 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!

... eventually becomes more about ... staying focused than actually coding. I envy those people!

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...

That's just... Silly. What happens when you have a method that takes up 75 lines of code and isn't easily deciphered? I always imagined comments would be abundant in proffesional code, but not as much in personal projects because you know what all your functions do. Huh.

If the method was very complex, it would probably be flagged in code review and broken down into simpler methods. And there would also be several test cases for the method, demonstrating exactly what the method is expected to do.

The worse ones I realized for me, are the ones that happened logically. Like forgetting to change a variable and wondering why your animations aren't working. Also, checking to see why your sprite isn't moving because you forgot to activate the listener. Usually my IDE would catch those simple syntax errors for me.

For documenting, I think it solely depends on the project. Even though it is great when projects can document themselves, it becomes a lot more challenging when you are writing for a large group. It also becomes difficult if you are working on games, as sometimes it is difficult to come up with one word for each logic action. If the project you are working on is international, writing comments can sometimes save a lot of grief since you can actually easily get the documentation to throw into a translator. I think it depends on the job.

That's a good way of looking at it though, you shouldn't need paragraphs of comments explaining what it is. That's just a waste of space. But I hate getting undocumented code from other programmers and they expect me to be up to speed in less than two days. On the other hand, over documented code just means someone is bad at commenting and explaining.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org