Java-Gaming.org Hi !
 Featured games (91) games approved by the League of Dukes Games in Showcase (804) Games in Android Showcase (239) games submitted by our members Games in WIP (868) games currently in development
 News: Read the Java Gaming Resources, or peek at the official Java tutorials
Pages: [1] 2
 ignore  |  Print
 Another Stupid, Stupid Mistake...  (Read 16002 times) 0 Members and 1 Guest are viewing this topic.
wessles
 « Posted 2013-11-26 23:53:16 »

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

Originally, I was doing something amung the lines of this:
 1  2  3  4  5  6  7  8  9  10  11  12  13 `       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!

 1  2  3  4  5  6  7  8  9  10  11  12  13  14  15  16  17  18  19  20 `       // 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...  ,  , and  .

Et Toi? Any major 'DOH!' moments in your coding?
Opiop
 « Reply #1 - Posted 2013-11-27 00:57:10 »

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!
Opiop
 « Reply #2 - Posted 2013-11-27 01:08:19 »

Well, I'm sure I pretty much did permanent damage on my GPU, but I don't have it anymore so its ok
theagentd
 « Reply #3 - Posted 2013-11-27 01:49:25 »

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.

Well, I'm sure I pretty much did permanent damage on my GPU, but I don't have it anymore so its ok
Not unless it overheated...

Myomyomyo.
Opiop
 « Reply #4 - Posted 2013-11-27 02:06:51 »

That was sarcasm

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.
Slyth2727
 « Reply #5 - Posted 2013-11-27 02:17:16 »

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
Opiop
 « Reply #6 - Posted 2013-11-27 02:20:13 »

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!
HeroesGraveDev

JGO Kernel

Medals: 383
Projects: 11
Exp: 4 years

┬─┬ノ(ಠ_ಠノ)(╯°□°)╯︵ ┻━┻

 « Reply #7 - Posted 2013-11-27 02:47:11 »

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.

Longarmx
 « Reply #8 - Posted 2013-11-27 02:51:20 »

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

Opiop
 « Reply #9 - Posted 2013-11-27 03:00:20 »

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!
theagentd
 « Reply #10 - Posted 2013-11-27 07:50:56 »

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.

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.

Myomyomyo.
deepthought
 « Reply #11 - Posted 2013-11-27 15:38:17 »

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

gimbal

JGO Knight

Medals: 26

 « Reply #12 - Posted 2013-11-27 20:16:16 »

Et Toi? Any major 'DOH!' moments in your coding?

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*
StumpyStrust
 « Reply #13 - Posted 2013-11-28 00:23:44 »

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

Is it programing or programming?

Opiop
 « Reply #14 - Posted 2013-11-28 00:30:06 »

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!
gimbal

JGO Knight

Medals: 26

 « Reply #15 - Posted 2013-11-28 08:51:57 »

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

Programming (which is writing code) is only a small part of the development process
theagentd
 « Reply #16 - Posted 2013-11-28 17:18:53 »

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

Myomyomyo.
Opiop
 « Reply #17 - Posted 2013-11-28 22:29:47 »

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!
ags1

JGO Kernel

Medals: 367
Projects: 7

Make code not war!

 « Reply #18 - Posted 2013-11-28 22:39:58 »

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

Opiop
 « Reply #19 - Posted 2013-11-28 22:42:24 »

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 Do you just write programs for corporations or what?
ags1

JGO Kernel

Medals: 367
Projects: 7

Make code not war!

 « Reply #20 - Posted 2013-11-28 22:45:21 »

Actually we have coding style that forbids comments. The code is meant to be clear enough that it documents itself.

I agree with that actually - nothing worse than out-of-date zombie comments littering the code.

Opiop
 « Reply #21 - Posted 2013-11-28 22:50:22 »

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

JGO Kernel

Medals: 367
Projects: 7

Make code not war!

 « Reply #22 - Posted 2013-11-28 22:54:11 »

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.

Opiop
 « Reply #23 - Posted 2013-11-28 22:55:44 »

Wow, coding in a job sounds much more involved than I thought! Interesting, I might have to change my coding style around a little.
ctomni231

JGO Wizard

Medals: 99
Projects: 1
Exp: 7 years

Not a glitch. Just have a lil' pixelexia...

 « Reply #24 - Posted 2013-11-29 01:26:46 »

To answer the start of the thread. Coding errors happen all the time.

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.

HeroesGraveDev

JGO Kernel

Medals: 383
Projects: 11
Exp: 4 years

┬─┬ノ(ಠ_ಠノ)(╯°□°)╯︵ ┻━┻

 « Reply #25 - Posted 2013-11-29 02:46:07 »

Comments should not explain what the code does or how it does it.
That should be obvious enough from the code itself.

Comments are there to explain why the code does what it does.

Opiop
 « Reply #26 - Posted 2013-11-29 02:49:14 »

You're just very philosophical aren't you?

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.
xsvenson
 « Reply #27 - Posted 2013-11-29 09:24:10 »

Comments can be useful. About half a year ago I changed projects, I was the maintainer of the codebase and the one that was responsible for the code's health. After the change, others took over.
A few months later a colleague came to me and was all like "Nice going with the comments ! You made everything so clear!". My response was between the lines of "What's with the sarcasm, if You have a problem, ask"

Turns out, he was being sincere. My comments helped and brought some clarity, for me those comments were well worth it.

“The First Rule of Program Optimization: Don't do it. The Second Rule of Program Optimization (for experts only!): Don't do it yet.” - Michael A. Jackson
gimbal

JGO Knight

Medals: 26

 « Reply #28 - Posted 2013-11-29 10:04:37 »

Flip that around: USEFUL comments are a good thing, not comments in general. Self-documenting code should still be the priority though.
theagentd
 « Reply #29 - Posted 2013-11-29 20:39:22 »

Flip that around: USEFUL comments are a good thing, not comments in general. Self-documenting code should still be the priority though.
I recently read somewhere that the hardest part of being a programmer is naming things. I called bullshit until I realized I spent 15 minutes trying to come up with a better name for "downsampledDominantMotionVectorBuffer". I ended up with "downsampledDMVBuffer" and a comment explaining what "DMV" stood for. +1 point to anyone who can figure out what I'm working on.

Myomyomyo.
Pages: [1] 2
 ignore  |  Print

 Riven (580 views) 2019-09-04 15:33:17 hadezbladez (5505 views) 2018-11-16 13:46:03 hadezbladez (2398 views) 2018-11-16 13:41:33 hadezbladez (5767 views) 2018-11-16 13:35:35 hadezbladez (1222 views) 2018-11-16 13:32:03 EgonOlsen (4660 views) 2018-06-10 19:43:48 EgonOlsen (5681 views) 2018-06-10 19:43:44 EgonOlsen (3196 views) 2018-06-10 19:43:20 DesertCoockie (4094 views) 2018-05-13 18:23:11 nelsongames (5114 views) 2018-04-24 18:15:36
 princec 10x Ali-RS 6x VaTTeRGeR 5x KaiHH 5x mudlee 5x philfrei 5x elect 4x Rain8 3x SteveSmith 2x hansolo_ 2x gouessej 2x ral0r2 1x saocrinn 1x Akazan 1x bullen 1x Apo 1x
 A NON-ideal modular configuration for Eclipse with JavaFXby philfrei2019-12-19 19:35:12Java Gaming Resourcesby philfrei2019-05-14 16:15:13Deployment and Packagingby philfrei2019-05-08 15:15:36Deployment and Packagingby philfrei2019-05-08 15:13:34Deployment and Packagingby philfrei2019-02-17 20:25:53Deployment and Packagingby mudlee2018-08-22 18:09:50Java Gaming Resourcesby gouessej2018-08-22 08:19:41Deployment and Packagingby gouessej2018-08-22 08:04:08
 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