next »

[indie11]

How do the original graphics look like? O_O

**EDIT** I've just found out that the horizontal movement is jittery even though I am accelerating based on time ( Using Smooth Damp in Unity). Unity always gives me headaches!! This is the 3rd time trying to make a SMB like physics platformer but again getting stuck at a minor thing that makes the game look crap

This is why I hate physics based on delta time, they're awfully hard to get right. And yes, SMB uses a fixed framerate if you wonder.

This is some problem with the unity engine. Recently I've found out that a lot of people are facing this issue, there's no proper fix, some say to change monitor refresh rate, play with the editor physics settings but nothing is working out for me

I had several issues with jerky movement in unity which I ultimately resolved, here is what I did in case it helps:

1 ensure that the jerkyness is not in your camera, i found that my camera was updating out of sync with the objects. I got round this by ensuring the my cameras follow code was updated in "FixedUpdate".

2 ensure my objects did not have velocity altering code inside a "FixedUpdate" function (put it all in "Update")

the reason behind this is that unity can update its physics and rendering separately, Unity will potentially call fixed update multiple times per screen refresh (update)

Hope this helps (and doesn't just cause confustion)

I have disabled my camera follow script just to be sure that the issue is not because of the camera movement. There is a jerk even when there is a single object in the scene translating, It like happens after every second or two.. Which version of Unity3D are you using? I am downloading the last patch release of Unity3d 4.x series just to see if there is any issue with the current version I am using

[Will Sykes]

How do the original graphics look like? O_O

**EDIT** I've just found out that the horizontal movement is jittery even though I am accelerating based on time ( Using Smooth Damp in Unity). Unity always gives me headaches!! This is the 3rd time trying to make a SMB like physics platformer but again getting stuck at a minor thing that makes the game look crap

This is why I hate physics based on delta time, they're awfully hard to get right. And yes, SMB uses a fixed framerate if you wonder.

This is some problem with the unity engine. Recently I've found out that a lot of people are facing this issue, there's no proper fix, some say to change monitor refresh rate, play with the editor physics settings but nothing is working out for me

I had several issues with jerky movement in unity which I ultimately resolved, here is what I did in case it helps:

1 ensure that the jerkyness is not in your camera, i found that my camera was updating out of sync with the objects. I got round this by ensuring the my cameras follow code was updated in "FixedUpdate".

2 ensure my objects did not have velocity altering code inside a "FixedUpdate" function (put it all in "Update")

the reason behind this is that unity can update its physics and rendering separately, Unity will potentially call fixed update multiple times per screen refresh (update)

Hope this helps (and doesn't just cause confustion)

I have disabled my camera follow script just to be sure that the issue is not because of the camera movement. There is a jerk even when there is a single object in the scene translating, It like happens after every second or two.. Which version of Unity3D are you using? I am downloading the last patch release of Unity3d 4.x series just to see if there is any issue with the current version I am using

I am now using unity 5 but I was using 4.x for a while and the only jerk issue I had was related to update/fixedupdate.

what method are you using to move the object? does the object have a rigid body component? could it be that you are overwriting translation of the rigid body (e.g. it tries to move based on its velocity and then you change this with a manual translation in your update function)?

[cykboy]

How do the original graphics look like? O_O

For standard bricks, we take a flat 2d isometric sprite, cut it in certain areas and then distort the image to result in a mappable texture. Then make a cube, apply correct UV mappings and its 3d. Primarily used for lighting calculations and fancy stuff. It has limitations with graphical quality (although resolution is adjustable), but imo it works pretty well. Ramps are even more complex...

[Sik]

For a moment I thought it was isometric in its 2D form and then somehow that got mapped to a 3D cube.

[indie11]

How do the original graphics look like? O_O

**EDIT** I've just found out that the horizontal movement is jittery even though I am accelerating based on time ( Using Smooth Damp in Unity). Unity always gives me headaches!! This is the 3rd time trying to make a SMB like physics platformer but again getting stuck at a minor thing that makes the game look crap

This is why I hate physics based on delta time, they're awfully hard to get right. And yes, SMB uses a fixed framerate if you wonder.

This is some problem with the unity engine. Recently I've found out that a lot of people are facing this issue, there's no proper fix, some say to change monitor refresh rate, play with the editor physics settings but nothing is working out for me

I had several issues with jerky movement in unity which I ultimately resolved, here is what I did in case it helps:

1 ensure that the jerkyness is not in your camera, i found that my camera was updating out of sync with the objects. I got round this by ensuring the my cameras follow code was updated in "FixedUpdate".

2 ensure my objects did not have velocity altering code inside a "FixedUpdate" function (put it all in "Update")

the reason behind this is that unity can update its physics and rendering separately, Unity will potentially call fixed update multiple times per screen refresh (update)

Hope this helps (and doesn't just cause confustion)

I have disabled my camera follow script just to be sure that the issue is not because of the camera movement. There is a jerk even when there is a single object in the scene translating, It like happens after every second or two.. Which version of Unity3D are you using? I am downloading the last patch release of Unity3d 4.x series just to see if there is any issue with the current version I am using

I am now using unity 5 but I was using 4.x for a while and the only jerk issue I had was related to update/fixedupdate.

what method are you using to move the object? does the object have a rigid body component? could it be that you are overwriting translation of the rigid body (e.g. it tries to move based on its velocity and then you change this with a manual translation in your update function)?

A simple 2d sprite with a BoxCollider2D on it and no rigidbody.. I have also posted a question on unity answers, there seems to be some rendering spike even with a single cube in the scene..

http://answers.unity3d.com/questions/1014889/translate-stutter-on-60fps.html

[cykboy]

For a moment I thought it was isometric in its 2D form and then somehow that got mapped to a 3D cube.

That may be a possibility, the only hurdle regarding that method is mapping a UV rhombus instead of a standard UV square. That is why we distort the image, but this can cause slight quality loss (not majorly noticeable)

[surt]

...the only hurdle regarding that method is mapping a UV rhombus instead of a standard UV square.

How is that any harder?

[cykboy]

...the only hurdle regarding that method is mapping a UV rhombus instead of a standard UV square.

How is that any harder?

I only just came to the realisation as I wrote that reply. Working on a solution now to map them, the math isn't easy but I've got my tea.

[cykboy]

Hurray! This is a much better solution, no loss of quality and can simply squash tiles together into a sheet like this:



And have a completely 3d object:





Will be interesting to do this with more complex tiles (ramps, triangular "cutoffs")..

[Sik]

Did you seriously go ahead with my misinterpretation? lol

At least the upside seems to be that now you can draw heights at the top of the cubes without having to change the shape of the mesh to allow for the new silhouette (making it possible to have more detail than before). That seems to be a net gain.

[cykboy]

Did you seriously go ahead with my misinterpretation? lol

At least the upside seems to be that now you can draw heights at the top of the cubes without having to change the shape of the mesh to allow for the new silhouette (making it possible to have more detail than before). That seems to be a net gain.

Yep, it's now much quicker and quality is greater. This is why I love forums

[oahda]

The tilted window panel thingies do look blurry tho.

[cykboy]

The tilted window panel thingies do look blurry tho.

The ramps? Yeah, they look like shit now that we have this method for bricks. Going to try map them tonight, they have a backface too so cant do it from a single image... fun awaits

EDIT: Here's a live test (requires webgl), pretty rudimentary and isn't optimized at all: https://metajs.herokuapp.com/

[Sik]

The tilted window panel thingies do look blurry tho.

That part wasn't reimplemented yet, that's why.

[cykboy]

The tilted window panel thingies do look blurry tho.

That part wasn't reimplemented yet, that's why.

Indeed! That link is my live testbed, it'll change from time to time - don't mind sharing with you guys though. I've been working on a method to squash all the geometry (tiles) into one big mesh. It works, but now I need to rethink how I map bricks/ramps since I can only use one texture for the mesh... more fun!

I think on that demo atm you can use WASD to move around and space to jump. You will fall through the floor at some point. Basic test of a collision system that has been scrapped.

[powly]

I got a (demoscene) demo released after a long period of being less active, I'm quite happy :33

[Sik]

Which one? :​o (Pouët link?)

[cykboy]

More optimizations! So merging all geometry just wasnt enough, the scene below still has 4475 faces in it. Most of these will never be seen, but are still going to be iterated when rendering. The lines are the shadow camera, which is the main reason I need to get rid of some faces.



bottom view, player will never see this and its ugly as hell



And on some math magic and a few if statements, the new face total is 1459! It looks the exact same from the top or any side, but it has merged groups of blocks together into one big block as is evident here:



Roughly 75% decrease in the amount of faces, and for big maps I've reduced 14290 faces to 5032 faces.

[ThemsAllTook]

I just solved the last really hard problem in my collision system. There was a possibility of getting into an unresolvable state, and I now have a mechanism that detects object pairs that are unresolvable and allows them to pass through each other for just that one case. Previously, when this happened it would either infinite loop, or break all of the other objects in the simulation, so this quietly works around the problem with the minimum disruption to the overall simulation. I think this means I can finally get back to actual game code!

[powly]

Which one? :​o (Pouët link?)

This one, sorry for being slow :D I think making a game with the same style might also be cool, let's see what happens..