next »

[ThemsAllTook]

It happens if you're writing code quickly, you add placeholders where you know where comments will go before thinking what to write (which you'll have a more clear idea when you're done writing that block of code).

Whoa, weird. I don't think I've ever done that...but then, I try to keep comments to an absolute minimum, and only add them when I can't get the actual code to explain itself clearly enough.

[Geti]

@Sik: I don't do that; I either write out the basic function body in comment form, or just write the code and comment as and when needed. "I'll comment this later" seems like a weird thought pattern, why not then? If you'll know what to write later on reflection, why not add the // then?

Re; not any different from writing both opening and closing parenthesis - I don't do that though, except in editors that automate it.

[nikki]

you add placeholders where you know where comments will go before thinking what to write (which you'll have a more clear idea when you're done writing that block of code).

I tend to do it the other way around:
- first write a comment explainng what my code will do to be succesfull.
- write the code
- then -depending on the hackeyness- delete the comment or not.

[Brainswitch]

Let me tell you, I can program in Lingo, so flash and I go way back.

Oh man, I remember that - never used Flash much though but dabbled a bit in Director at my brothers workplace a long time a go. Back then I remember thinking it was a lot like HyperTalk.

[standardcombo]

I picked up this book called Lingo Sorcery that showed how to do OO pattern in Director. At the time it was a nice engine, but terrible for today's standards, kinda glad they killed it. Made some fun web games in it, unfortunately those can't run anymore. Would have to install an ancient version of the Flash plugin.

[indie11]

So i've been messing around with Unity to create a 2d platformer game using custom physics.
The thing that is really pissing me off is the DeltaTime! It suddenly spikes up for no particular reason even if there is just one script in the scene. Due to this issue, I just can't get an accurate jump height. It always varies!

I have tried using FixedUpdate but it just takes away the smoothness. Anyone here faced such problem?

 

[standardcombo]

Yep. My approach would be to use Fixed Update because that will give you an accurate jump height, which is really important. Then look for ways to smooth the game. Set a maximum frame rate and look at other properties in the Edit>Project Settings>Time configuration. Unselect any game object and prefab (empty inspector) to reduce the editor's effort. Try running the game as a standalone instead of inside editor to see if that helps smooth things. If you are generating a lot of memory garbage, such as instantiating and destroying lots of objects, using for-each or an enum as dictionary key, those can induce spikes in the fps (garbage gets collected).

[indie11]

Yep. My approach would be to use Fixed Update because that will give you an accurate jump height, which is really important. Then look for ways to smooth the game. Set a maximum frame rate and look at other properties in the Edit>Project Settings>Time configuration. Unselect any game object and prefab (empty inspector) to reduce the editor's effort. Try running the game as a standalone instead of inside editor to see if that helps smooth things. If you are generating a lot of memory garbage, such as instantiating and destroying lots of objects, using for-each or an enum as dictionary key, those can induce spikes in the fps (garbage gets collected).

What is your target platform? I am making the game for android ( currently just using plain rectangles ).
I think mobile devices are particularly slow maybe that's why i get little stutter?

[Geti]

FixedUpdate should be used for physics related stuff iirc, and should be running at 60fps, smooth enough for any case. Jitter could be caused by all sorts of things, open up the profiler. If you dont have a pro license, you're up shit creek there though.

I'm grumpy cause I've got to do a bunch of formal proof stuff about AI algorithms for uni.

[indie11]

Here are the two demo using Update and FixedUpdate

Update
 - I've used a check in this, if deltaTime > (1/60) => deltaTime = (1/60) . So if there is a sudden spike the deltaTime is set to maximum(60FPS DeltaTime) . The jump height is exact in almost all the cases.
 - The camera following is also done in Update()
Update DEMO

FixedUpdate
 - No Check has been used in this. Used Update() for inputs and FixedUpdate() for physics
 - Camera following is done in FixedUpdate()
FixedUpdate DEMO



The movement in the FixedUpdate demo is jittery at times whereas the Update() one is Smooth.
So is it fine to put a limit to deltaTime?

[Quarry]

I think fixedupdate is doing 60~ runs per second and then stops updating until the next second

[Brainswitch]

FixedUpdate runs by default 50 times per second. Check your Project Settings -> Time, there you have Fixed Timestep.
Another thing in Project Settings -> Time is Maximum Allowed Timestep - I'd advise using that instead of doing it manually in each script since that will effect all scripts automatically.

[standardcombo]

When you limit the deltaTime that way, what's going to happen is, the physics may be consistent (at which point you might as well remove the deltaTime from your physics calculations). However, if you run into a device that is not updating at 60fps the game will go in slow motion.

Camera can be done in many ways but you may want to consider using LateUpdate. The logic is because there is no need to do camera logic until right before you draw, at which point all other objects have had their chance to update (sometimes multiple fixed updates per draw). If the camera doesn't come at the end it can cause jitter.

If you are targeting a slower device you may want to cap the Update at 30fps, but still keep the physics at 60fps so the gameplay is consistent across devices. This is why Fixed Update is used, it guarantees consistent logic.

[Martin 2BAM]

 "That's a great idea". Increase scope.

  Refactor

"Ughh". Suffer.

  "What am I doing with my life?". Cry.

  Feel better

 "That's a great idea". Increase scope.
...

[surt]

Wake up with solution in brang.
Sit down to code...
..um.

[indie11]

When you limit the deltaTime that way, what's going to happen is, the physics may be consistent (at which point you might as well remove the deltaTime from your physics calculations). However, if you run into a device that is not updating at 60fps the game will go in slow motion.

Camera can be done in many ways but you may want to consider using LateUpdate. The logic is because there is no need to do camera logic until right before you draw, at which point all other objects have had their chance to update (sometimes multiple fixed updates per draw). If the camera doesn't come at the end it can cause jitter.

If you are targeting a slower device you may want to cap the Update at 30fps, but still keep the physics at 60fps so the gameplay is consistent across devices. This is why Fixed Update is used, it guarantees consistent logic.

I am targeting mid and high end devices. Going with a minimal theme so I don't think there will be a problem with FPS. Will check and see how camera works in LateUpate. Thanks

[InfiniteStateMachine]

odd. I create a char[500] inside a local function then later do some image processing that uses malloc for everything. If I assign even one char in that array all my image data gets messed up. Sometimes it looks like a lot of zero's (all black) sometimes it's a random pattern of green.

If i make the char[] a char[250] it works fine. I suppose there's a chance the stack and heap are touching but I'm not totally sure, I'm gonna have to dump out the contents of my image buffers and that array and find out. This is for a photoshop plugin and they have a bunch of weird memory management stuff. Maybe I exceeded some adobe limit causing everything to go haywire.

It's not an issue because I don't need that char[] but it's one of those things I wish I knew the reason it happens. I also think it may have happened when the code for the image processing was refactored into its own method but I'd have to confirm that more thoroughly.

[standardcombo]

Ive seen that in C i think when i over-used local variable on a ray tracer. The image got messed up.

[InfiniteStateMachine]

over-used?

[Eigen]

over-used?

I imagine there's a loop and he's using a variable declared outside it without resetting it after each iteration.




Running this code: