ThemsAllTook
|
|
« Reply #3120 on: January 10, 2013, 04:23:18 PM » |
|
I've switched to a fixed-timestep rendering cycle that is fixed to the vsync, and I'm measuring the performance of my game in terms of "used timestep percent". It makes so much more sense to see "9%" instead of a meaningless 694 fps Nice! I may have to adopt that myself.
|
|
|
Logged
|
|
|
|
Quarry
|
|
« Reply #3121 on: January 10, 2013, 09:18:51 PM » |
|
9% makes no sense to me, for now. Could anyone elaborate?
|
|
|
Logged
|
|
|
|
Sean A.
|
|
« Reply #3122 on: January 10, 2013, 09:28:00 PM » |
|
9% makes no sense to me, for now. Could anyone elaborate?
I think he means if the refresh rate is 60Hz each step is 1/60 of a second. The 9% refers to how much of the step is actually used so theoretically he has 91% of the step left for more calculations. Once the percent is > 100% you will see lag because it takes longer than the allocated time to render the frame.
|
|
|
Logged
|
|
|
|
_Tommo_
|
|
« Reply #3123 on: January 11, 2013, 03:26:03 AM » |
|
I think he means if the refresh rate is 60Hz each step is 1/60 of a second. The 9% refers to how much of the step is actually used so theoretically he has 91% of the step left for more calculations. Once the percent is > 100% you will see lag because it takes longer than the allocated time to render the frame.
yeah, exactly Too bad on the PC this is not "exact" in any way as the number of instructions you can run in a timestep varies from machine to machine... but on iOS, Android and consoles it works really great when you're developing on your minimum supported device: ie. you can aim for, say, 100% of the iPhone 4. @eigenbom: I might have actually taken inspiration from something you posted around here
|
|
|
Logged
|
|
|
|
InfiniteStateMachine
|
|
« Reply #3124 on: January 11, 2013, 04:52:31 AM » |
|
6 days ahead of schedule!
usually this means I can work on my own projects on company time. Assuming they dont think of new features they would like me to implement. 50/50 chance of that.
|
|
|
Logged
|
|
|
|
InfiniteStateMachine
|
|
« Reply #3125 on: January 11, 2013, 04:54:14 AM » |
|
I think I appreciate Swing now as well. It's amszing how there really isn't a multiplatform GUI implementation out there that solves all problems. I guess it's just too difficult of a problem to take on.
|
|
|
Logged
|
|
|
|
eigenbom
|
|
« Reply #3126 on: January 11, 2013, 12:49:03 PM » |
|
I think he means if the refresh rate is 60Hz each step is 1/60 of a second. The 9% refers to how much of the step is actually used so theoretically he has 91% of the step left for more calculations. Once the percent is > 100% you will see lag because it takes longer than the allocated time to render the frame.
yeah, exactly Too bad on the PC this is not "exact" in any way as the number of instructions you can run in a timestep varies from machine to machine... but on iOS, Android and consoles it works really great when you're developing on your minimum supported device: ie. you can aim for, say, 100% of the iPhone 4. @eigenbom: I might have actually taken inspiration from something you posted around here oh no, you shouldn't read my posts! i have no idea what i'm doing..
|
|
|
Logged
|
|
|
|
Liosan
|
|
« Reply #3127 on: January 11, 2013, 12:53:08 PM » |
|
Yay, I just spent 3 days at work profiling a very specific piece of code, not able to find the problem... I didn't even believe the profile when I saw it, it said that 98% of the 2.2s routine is spent in one 5-line function with tiny loop. And then - presto! I found it Changed 5 characters and sped up the whole thing 40x times (down to 50ms). The loop wasn't related (of course, that would be too obvious). Most spectacular profiling evar Liosan
|
|
|
Logged
|
|
|
|
rivon
|
|
« Reply #3128 on: January 11, 2013, 12:54:55 PM » |
|
50ms is still a lot...
|
|
|
Logged
|
|
|
|
Liosan
|
|
« Reply #3129 on: January 11, 2013, 01:01:02 PM » |
|
50ms is still a lot...
Heh, I don't do games at work We're talking about deallocating over a million objects (emergency cache eviction). I'm happy with 50ms Liosan
|
|
|
Logged
|
|
|
|
rivon
|
|
« Reply #3130 on: January 11, 2013, 01:23:43 PM » |
|
Ah, then it's ok. I thought it was something for a game which would be bad
|
|
|
Logged
|
|
|
|
Signal Walker
|
|
« Reply #3131 on: January 11, 2013, 04:37:55 PM » |
|
Programming Pong in C# (with XNA) as the first game I will have ever made not using Gamemaker, everything has worked within the first few tries at programming whatever it is. I've just got to add the "ball" (Which will just be a resized paddle because I'm lazy) and the scoring functionality and I'll be done!
|
|
|
Logged
|
|
|
|
Garthy
|
|
« Reply #3132 on: January 11, 2013, 05:44:08 PM » |
|
Congrats to all on their successes. Found a long-outstanding bug today. About once every four hours or so I would get a mysterious crash, and going through the stack trace yielded only hints each time. Because it crashed so infrequently, and I couldn't trigger it, all I could do was make additional tweaks to catch unusual cases as I went about work on other tasks. The bug has been outstanding for months. Nothing seemed to catch it. Until yesterday. I got it down to a narrow region of code, manually went through every step of the code, and found a call that inadvertently truncated a 64-bit value to a 32-bit value, and then immediately back to 64-bit. This call was only made under rare circumstances. Sometimes- and only sometimes- this contained a 64-bit memory address. This truncation clipped the top off of the address, causing the crash later in the code (not immediately, of course, that would be too easy). I've not had the crash since.
|
|
|
Logged
|
|
|
|
ThemsAllTook
|
|
« Reply #3133 on: January 11, 2013, 07:00:08 PM » |
|
I got it down to a narrow region of code, manually went through every step of the code, and found a call that inadvertently truncated a 64-bit value to a 32-bit value, and then immediately back to 64-bit. This call was only made under rare circumstances. Sometimes- and only sometimes- this contained a 64-bit memory address. This truncation clipped the top off of the address, causing the crash later in the code (not immediately, of course, that would be too easy).
Yikes! Sounds like a good time for stricter compiler warnings/static analysis/not storing pointer values in integer variables. Good that you managed to track it down - fixing that sort of bug usually leaves me feeling more grumpy than satisfied (though also relieved).
|
|
|
Logged
|
|
|
|
Garthy
|
|
« Reply #3134 on: January 11, 2013, 10:38:16 PM » |
|
Yikes! Sounds like a good time for stricter compiler warnings/static analysis/not storing pointer values in integer variables. Good that you managed to track it down - fixing that sort of bug usually leaves me feeling more grumpy than satisfied (though also relieved).
I couldn't agree more. In my defence: not storing pointer values in integer variables
Storing pointers in ints is a terrible idea 9999 times out of 10000 (there are far better mechanisms), but alas, it's what Ruby does for values, and for a good reason (it's the only 1 in 10000 I know of!). The bug was in my wrapper library which is designed to hide this (and other) nastiness from the main code, but the wrapper itself has a good chunk of "dirty code" to make the interface nicer. stricter compiler warnings
Didn't catch it! I'm using gcc, -Wall, and a stack of other options. I've even got a custom builder that upgrades certain warnings to *errors* and stops the build if it sees them. It still wasn't enough! I think the file with the bug in it came through warning-free. If I was using MSVC++, I *think* it would have found it, but it probably would have used the dreaded C4244 warnings, which throw more false positives than anything I have ever *seen*, and many library writers disable as a matter of course. static analysis
Did I mention "dirty code".
|
|
|
Logged
|
|
|
|
rivon
|
|
« Reply #3135 on: January 12, 2013, 06:08:00 AM » |
|
Use -pedantic
|
|
|
Logged
|
|
|
|
AlexStv
|
|
« Reply #3136 on: January 13, 2013, 04:35:49 AM » |
|
I couldn't get unity to render more than 100x100 blocks last time I checked I'm rendering it in chunks of 16 x 16 where each chunk generates a mesh of all the visible faces within it and renders with Unity's mesh class, then it just updates the mesh and when the chunk is modified. That picture is a total of 14 x 14 x 150 game object chunks.
|
|
|
Logged
|
|
|
|
Quarry
|
|
« Reply #3137 on: January 13, 2013, 04:14:12 PM » |
|
Can anyone tell me how I can start C with Windows? I'm getting sick of Java and C seems extremely appealing. I'll be a happy programmer if anyone can
not fucking c++ google, not fucking c++. im sick of fucking fuckkedy having to quote c like "c" to get results for c, whats this bullshit google, get real. now. please
|
|
|
Logged
|
|
|
|
Rusk
Level 1
|
|
« Reply #3138 on: January 13, 2013, 04:29:30 PM » |
|
http://www.mingw.org/ is a windows port of the gnu compiler collection and some other tools, including the C compiler.
|
|
|
Logged
|
|
|
|
nikki
|
|
« Reply #3139 on: January 13, 2013, 04:42:37 PM » |
|
or maybe you could run ubuntu in a virtual machine, forgot what it's called ah wait wubi. because programming c in linux is very nice where windows is sort of painful to set it up in and work.
|
|
|
Logged
|
|
|
|
|