next »

[JLJac]

Ok, so I actually managed to mock up the thing I want - it looks a little something like this:



30 layers parallax scrolling voxel like 3D space renderer!

Even with the smallest level size and no shadows it still eats away at the frame rate pretty badly. I think I'll try to figure out some other solution.

Maybe the past two days make a little bit more sense now?
My original idea was to have all the layers in the same texture, and do a per-pixel raytrace layer for layer in the texture until I hit something. When loading a big texture proved impossible that original approach fell flat, and I've been trying to find another solution since. Now I'm pretty tired of all this though, and am contemplating to just have fixed screen positions. It would be nice to show the depth of the rooms like this, but you can't have it all. I still have high hopes for dynamic shadows falling across the geometry though - that could be done with just depth map and a pre-baked image.

[dancing_dead]

 
A+ for effort.
parallax mapping perhaps could actually give you these kind of results, yeah, but the 3d effect would still be quite sub-par, as elements wouldn't have any detail to their z-axis, only slabs of polygons reaching into the depths of the screen. kind of what you already have going on there for the ceiling stuff, that all look like lumps of something, cut with an axe at z=0, assuming camera z is also 0.

it's certainly an unorthodox application of parallax scrolling there. fastest way to achieve something like that performance wise is, imo, real 3d. not sure what 2d workarounds could achieve similar results...

[Noogai03]

Flixel handles parallax using a "scrollFactor" variable for each FlxSprite - this is between 0 and 1 and presumably is just multiplied by the scroll amount when the sprites are rendered... Although flixel probably doesn't really lend much to this since it uses pixel copying instead of a full 3d thingy but i don't know 

[Chromanoid]

Looks cool Maybe it's easier to create a 3D level instead of drawing layer by layer? In this case you could use Unity's shadow casting.
Schrompf created a really sophisticated lighting system for his 2D top-down shooter Splatter. He talked about his shader here (in German). I am not sure if his algorithm can be useful for your game, but maybe he can help you with a solution.

[Vovosunt]

You should probably just make layers of planes and move them via script.
A shader just won't be able to handle 30+ parallax textures at once efficiently (it will have to fetch textures 30+ times X_X; and using boolean logic will not help)

Also drawing front to back with alpha testing would make this quite a bit faster.
(look here http://stackoverflow.com/a/15673819 )

But you could also just try real 3d.

As for the dynamic shadows... it could work ... with aforementioned layers and alpha testing even regular unity directional lights could work, I guess.

[gimymblert]

This would be best if done in dx11 shader but even then it's overkill! do it 3D and then shadowing is free in unity. Otherwise the shader techniques you are looking for is "relief mapping"

[Sebioff]

might give an impression how well this would work in 3D - they're using pixelart textures on 3D objects for perspective and background detail, while keeping the "foreground layer" pixelperfect.

[Whiteclaws]

might give an impression how well this would work in 3D - they're using pixelart textures on 3D objects for perspective and background detail, while keeping the "foreground layer" pixelperfect.

What he said, just render the first layer as an image and the other layers as a 3D object

[JLJac]

Thanks guys! That's certainly an option, but the thing is that I already have this 30 bitmaps thing set up - that's how the level editor works already, except it bakes them together. Making it proper 3D would be an entirely different animal all together. I still have issues accepting that 30 sprites with somewhat high-res textures can be an actual issue when Crysis can do entire islands with a bazillion polygons of rain forest and stuff, but I'll take your word for it.

Update 132
So I had a talk with James, and we decided that before I got manically obsessed with making this tiny little parallax effect work, I could probably follow through on a fixed-screen approach. Especially as we'd most reasonably want both solutions in the game anyway even if I managed to make the parallax work, so we could fix the screen in performance heavy rooms and save the parallax for cinematic set pieces.

So, I'll abandon parallax scrolling for a while in favor of importing 2D backgrounds. In the final spasms of my parallax obsession, I gave the pixel-raytracing some time, and for a wile it looked bright because a 30 iteration for-loop in the fragment shader actually didn't murder the framerate as badly as I feared. But then some stupid stuff came in the way, namely that in Unity the CG compiler always unrolls all loops (stupid, but necessary on older cards if I got it right) and then if I do some operation in the for loop it assigns new temporary variables for each iteration (STUPID, NO EXCUSE) which maxes out the shader's tiny little working memory and keeps it from compiling.

So there I was, at a road fork, where one option was to learn the thing that graphical C compiles to (looks like this:

Code:

add r8.xy, t0, c0
add r7.xy, t0, c2
add r5.xy, t0, c3
add r2.xy, t0, c4
mov r0.y, c1.w
mov r0.x, c1.z
add r9.xy, t0, r0
mov r0.y, c2.w
mov r0.x, c2.z
add r6.xy, t0, r0
mov r0.y, c0.w
mov r0.x, c0.y
add r4.xy, t0, r0
mov r0.y, c3.w
mov r0.x, c3.z

seems to be polish notation and similar horrors)  and the other was to decide that f*ck it, for now at least. So I'm trying to convince myself that #2 is the way to go.

I'll probably still get some good opportunity to pull my hair over shaders, if I'm going to do the coloration and the light stuff as a shader.

Before we leave the parallax issue, for now, I'll give you the the most current version of the "30 files, 30 sprites"-solution, to give you an idea of what could've been and might actually be if I get back to it later.

[RainWorldIsAwesome]

Holy shit, that looks awesome keep up the amazing work, with every post my hype for the game just like doubles

[Slader16]

You definitely have to figure that out, it looks amazing! 

[Christian]

Wow, that looks incredible. Hope you figure out a way to get that working, because...damn...

[aberrantmike]

slick.

[dancing_dead]

that is a ridiculously good looking fake 3d. it even has some depth details and stuff. how the hell did you prepare these 30 layers?
your game editor must really be quite something.

[gimymblert]

You should maybe focused on porting the game first before adding candy
However I don't want to discouraging you from making insane or even sub optimal stuff ... it gives personality to the project too by going path nobody would normally takes, and might even find cool things on the way.

But it's kinda our duty to warn you when appropriate, so go wild!

However regarding texture limitation, there is a thing call virtual texture (virtually infinite sized texture), you might look at it. Also it might be easier by using the kind of tiling I spoke before, it would reduce the 30+ layer loads if all layer are reduced to indexing texture.

If you want to know more about virtual texture, there is amplify on unity, they explain the basic and provide a tool. http://amplify.pt/unity/amplify-texture/

Amplify Texture is our proprietary technology that allows real-time applications to present scenes without any sort of texture limitations imposed by GPU memory limits. Virtual texturing enables up to 1 TB of unique texture data per-scene, or the equivalent to a resolution of 5 Km^2 at 1 texel/cm, without compromising performance. Our use of high-quality, more efficient texture compression will reduce your build size significantly. This is your chance to build unique, beautiful worlds in Unity.

[jamesprimate]

If you want to know more about virtual texture, there is amplify on unity, they explain the basic and provide a tool. http://amplify.pt/unity/amplify-texture/

wow this looks like just the ticket

[Nilanjan]

This is the most amazing pseudo 3d effect i've seen.Awesome work guys!!!

[Christian Knudsen]

Careful you don't fall too deep down the parallax hole and end up like

!

[JLJac]

Thanks guys! Hope we can make this dream come true
And as always Jimbert, thanks super much! That might actually be a viable solution to some of our problems. I'll give the trial a test run eventually, when I get back to this parallax thing.

Hahaha Ulillillia is wonderful! I've never seen anyone care as little about the actual interactive layer in a 2D game 

Update 133
Ok, so despite encouragement and tips I've still managed to keep out of the parallax hole. Now I'm starting to set up the infra structure for the 2D level graphics instead.

My current idea is this - encode as much visual information as possible into a texture, and then unpack it with a pixel shader. If you guys want to tell me that's a horrible inefficient way of going about it, now is the time.

So, I started by setting up a list of the stuff I need to know for each pixel:

its color [0-3] (transparent, shadowed, standard, high light)

its depth [0-29] (Needed to give it the correct fog shade, and later to do the cool dynamic shadows I'm hyped about)

if it's lit [bool] (I'll still pre-bake the light, and save whether or not each pixel is actually lit. If it's not lit, we can save time in the shader by not doing shadow calculations on it.)

if it's a rainbow pixel [bool] (If you check the screenshots you might notice a little oily effect around the edges of stuff - that)

Whether or not it has an effect color [0-3] (No effect color, effect color1, effect color2, white. You know how some plants and stuff tend to be pink or cyan? That's this. White is used for the flies' hives.)

How much of that effect color [0-255] (probably unnecessary resolution here, if I make it 0-50 the gradients would probably still look smooth, given how they're always on small surfaces)

Then I started messing around, and realized that all of this information can be stored in a 24bit rgb pixel! With quite a fat margin, I could store a lot more if I wanted to!

So this is my plan:

Red channel:
0-transparent

1-30 = depths 0-29, color shaded, not lit
31-60 = depths 0-29, color mid, not lit
61-90 = depths 0-29, color highlight, not lit

91-120 = depths 0-29, color shaded, lit
121-150 = depths 0-29, color mid, lit
151-180 = depths 0-29, color highlight, lit

Green channel:
0 = no effect, not a rainbow pixel
1 = level effect color1, not a rainbow pixel
2 = level effect color2, not a rainbow pixel
3 = white color, not a rainbow pixel

4 = no effect, rainbow pixel
5 = level effect color1, rainbow pixel
6 = level effect color2, rainbow pixel
7 = white color, rainbow pixel

Blue channel:
0-255 amount of effect color

My hope and dream is that the level editor will be able to encode each pixel with this information, save it as a .png, and then a fragment shader in unity will be able to decipher it and color the level dynamically. Tune in tomorrow to see it shattered.

Unity wizards (like Jimbert!) can you give me a quick heads up on one thing - if I want to feed a shader a palette of something like 12 colors, what's more efficient? Feeding it as params, or feeding it a tiny little secondary texture where it can pick the colors?

[Chromanoid]

Such an encoding can become problematic, when you want use interpolated scaling techniques for the textures (the colors of multiple pixels are mixed). Beside this I don't think there is a problem with that.