next »

[JLJac]

Thanks guys! This looks really promising! Anyone have a good starting point when it comes to the actual code syntax?

Update 227
We have working short cuts! A creature can go into a hole in one place and pop out in another. When in the shortcut, the creature is completely detached from all rooms, which means that no camera is viewing it and its sprites will be discarded. I don't quite know yet if this is a good idea. It doesn't feel like the best possible optimization to delete all sprites of a creature and then recreate them just because that creature isn't visible for 2 seconds... But I'll handle that problem when it becomes a problem. Trying hard with the premature optimization avoidance here, it's so tempting to try to make everything perfect now that I have the chance to recode the entire thing!

[gimymblert]

Thanks guys! This looks really promising! Anyone have a good starting point when it comes to the actual code syntax?

http://forums.tigsource.com/index.php?topic=25183.msg1002539#msg1002539

Quick question to you wizards out there:

1. can I do parallax scrolling as a shader? That is, can I feed a shader some parameters (camera position) on every draw command?

2. Can I use shaders to apply different palettes to the same sprite, do color cycling etc?

1. You can do this by passing a float to the shader parameter and shifting each texture plan by UV coordinate.

2. The best way to do it is to have a greyscale texture and then use a look up 1D texture (called a ramp) with the indexed colors. Basically you use the grayscale value to fetch the coordinate onto the indexed textures. You can also stack ramps in a 2D texture and pass a variable to pick the right stack for the right variable. Be careful to disable any filtering or that will pick the ramp on interpolated grays. However it can be a desirable effect depending on how you order your indexed color.

This also is how you do color circling, You index a rainbow lookup and then use it to shift from the color, but it also mean you might need to extract the hue as a coordinate from saturation and value, which became a bit complex. There is way to do it programmatically too, but it involve going through HSL extraction.

The best way is to have all indexes and stack the color varied ramp on top of each other and animate the relevant UV coordinate to shift through a varying index.

1. code for passing is really simple
http://forum.unity3d.com/threads/62770-passing-custom-variables-into-surface-shader
script

Code:

    void Start(){
     
        public Color colorBalance = Color.white;
     
    }
     
    void Update(){
     
        myMaterial.SetColor ("colorBalance", colorBalance);
     
    }

shader

Code:

    Properties {
     
        colorBalance ("colorBalance", Color) = (1,1,1,1)
     
    }
     
    ...
     
    float4 colorBalance; //declared outside of structs
     
    ...

http://docs.unity3d.com/Documentation/ScriptReference/Material.html


2. HSL conversion
http://www.chilliant.com/rgb2hsv.html

You can also use strumpy shader editor for convenience.
http://forum.unity3d.com/threads/56180-Strumpy-Shader-Editor-Now-Open-Source
https://www.assetstore.unity3d.com/#/content/456

If you are willing to pay shader forge is much more powerful.
http://forum.unity3d.com/threads/222049-Shader-Forge-A-visual-node-based-shader-editor
https://www.assetstore.unity3d.com/#/content/14147

[jamesprimate]

you the man Gimym!

[JLJac]

Thank you soooo much! 

Update 228
I realize that as I'm converting the game to c#, the devlog might be less than exciting for long time readers, as most of the stuff will be old news so to speak. But I'll just go ahead and type down what's going on, regardless of the entertainment value This is a record of the development process rather than anything else, and perhaps the goal of it is to be helpful rather than entertaining. Also it's a good resource for James and I, to have our progress logged somewhere. This time though, I'll spice it up with being even more technical 

Multiple rooms are in! It went surprisingly easily, as happens once in a looong while when programming. I had laid some ground work, but it was still smoother than expected. Rooms are instances of a room class, and on creation they're passed a name. They'll go look for a text file with the same name in a "Levels" folder, and get their data from there. I've written a little thing that can translate level architecture into text and back.

Then we have a tile property which is an "exit", which can be hooked up to a shortcut. The game has a world map, which is essentially an array of level names and what other levels they connect to. If a creature pops into a shortcut and encounters an "exit" tile, the world map is asked about to which other room this exit leads, and the shortcut continues transporting the creature in the new room. Then the little in-shortcut representation of the creature reaches the shortcut opening, and the actual physical creature is spawned.

As of now, all levels are loaded simultaneously. In the future, I want to create some kind of "lazy loading" system, which loads levels as you enter them, and unloads them a while after you've left them. That way non player creatures will be able to move about a bit on off-screen levels as well. We'll see exactly what this system will look like later on - either it could be a simple cap (max 5 levels loaded at a time, if more, unload the one that has been off-screen the longest) or something more complex (unload levels where creatures are dormant/dead earlier than levels where creatures are engaged in activities).

Lots of exciting stuff to do now! Almost can't decide what to start with! 

[Kinaetron]

When you say you're porting the game to C# are you using Unity or Monogame ?

[Christian]

I will admit, that the last few pages have been like in another language. The programming heavy stuff isn't as exciting as the gameplay stuff. But! I have been recommending this thread for those who are looking tips and help with Unity. That last 20 pages are so helpful in that regards

[JLJac]

I'm using Unity, but the game logic itself is just c#, so it's still not impossible to detach it from unity if we wanted to. As of now, it doesn't look like there would be any reason to though

Maybe the programming heavy stuff speaks to another (narrower) demographic - in either case our policy with this devlog has always been to just blurt out whatever is happening here, from graphic design on the logo to intricate technical issues, and that seems to have been working so far. As of now though, the game is largely designed already, and it's just a question of making it run in this new engine. So, for those of you who're interested in technical stuff, this is your time The rest will just have to bear with us for a moment. Soon I'll get into shaders, and then we'll have some posts of wizardry so profound that when we return to the ordinary coding stuff it'll look like a first grade reading assignment, if that's any comfort o.0

[RainWorldIsAwesome]

I love this.

[JLJac]

Update 229
 

HAHAHAHAHA shaaaaaaders!

After 3 hours I managed to output a flat color. Great success!

Poking around in this code feels like being an epileptic hippo trying to build a card house in a china shop. I download a little sample and insert it. It doesn't work. I try to adapt it. It doesn't work. Three hours later I manage to make it do anything that's not just an error message.

Then I try to change something - that's the way I prefer to learn. I switch a number for something else, try to bypass the code and output a plain color, something like that. This is where the china shop hippo comes in - everything I change always make the thing spit out error messages and fail.

Contrary to everything I know about code, you can make it crash without changing logic, but just by changing numbers. What'll happen if I go through this loop a couple more times? It'll crash! What will happen if I just add 4 to this value? It'll crash! In one of the few applicable examples of a 2d pixel shader I painstakingly found, there's a for-loop that executes three times.

Code:

    float remaining=1.0f;
    float coef=1.0;
    float fI=0;
    for (int j = 0; j < 3; j++) {
   	fI++;
    	coef*=0.32;
     	texcol += tex2D(_MainTex, float2(i.uv.x, i.uv.y - fI * _BlurAmount)) * coef;
    	texcol += tex2D(_MainTex, float2(i.uv.x - fI * _BlurAmount, i.uv.y)) * coef;
    	texcol += tex2D(_MainTex, float2(i.uv.x + fI * _BlurAmount, i.uv.y)) * coef;
   	texcol += tex2D(_MainTex, float2(i.uv.x, i.uv.y + fI * _BlurAmount)) * coef;
    	//texcol += tex2D(_MainTex, float2(i.uv.x, i.uv.y)) * coef;

   	remaining-=4*coef;
    }

It throws error messages and won't execute. If you change it to execute 2 times, it'll run. You see that line that's commented out? If you run that one istead of the one above it, the shader will run. Both those solutions are working! And both of them are super random!

I haven't felt this clueless in a long time. There doesn't really seem to be any complete documentation either haha.

I'll take a look at Gimym JIMBERT's tutorials next, maybe I just need to soak up an hour or two more of video before I'm ready!

[dancing_dead]

doesn't Unity use GLSL for shaders?
your code sample looks like HLSL to me (tex2D is a HLSL function, I think GLSL had something else...).
then again, if it does compile, then Unity probably works with HLSL, too.

anyhow, it is very much a normal thing that just changing numbers produce errors in shaders, since many of these functions only accept strict ranges (usually floating point values 0 to 1 or -1 to 1).
for example, color channel values have a range of 0 to 1, instead of 0 to 255 (in case of an 8bit channel). likewise, tex2D also accepts 0 to 1 for texture coordinates, anything outside that range doesn't make sense for the function, since you're then asking to read texture data from coordinates that simply don't exist in the gpu realm.

also, try and make the shader compiler output some error codes, these should tell you what goes wrong where. alas, no idea how to go about that with GLSL, only worked with HLSL.

update:
ah, sorry, it seems that the preferred Unity shader language is Cg, which is similar to HLSL, so tex2D is a legit function for Unity's shaders.
there probably are some guides for Cg specifically, which would tell you what's what.

[gimymblert]

wait what LOOP IN SHADER that's crazy talk here stop that now!
If there is loop chance you are doing it wrong.

Also worth looking here first too:
http://docs.unity3d.com/Documentation/Components/Rendering-Tech.html
http://docs.unity3d.com/Documentation/Components/SL-Reference.html

also it support swizzle and typing of number might depend on your card, so you must know basic class of card, this is covered in the link above

Basically there is almost three phases:
- Application data to gpu (can be hidden by unity through preprocessor command)
- vertex data to fragment
- fragment computing

vertex and fragment have a struct (to hold data) and a function (to prcess the data)

unity add an optional phases of - lighting pass (can be hide in preprocessor command)

IT IS BEST TO START WITH A SHADER ALREADY DONE and remove/add stuff, the basic structure is always the same.

In unity all you need for color is just:
wait what LOOP IN SHADER that's crazy talk here stop that now!
If there is loop chance you are doing it wrong.

Also worth looking here first too:
http://docs.unity3d.com/Documentation/Components/Rendering-Tech.html
http://docs.unity3d.com/Documentation/Components/SL-Reference.html

also it support swizzle and typing of number might depend on your card, so you must know basic class of card, this is covered in the link above

Basically there is almost three phases:
- Application data to gpu (can be hidden by unity through preprocessor command)
- vertex data to fragment
- fragment computing

vertex and fragment have a struct (to hold data) and a function (to prcess the data)

unity add an optional phases of - lighting pass (can be hide in preprocessor command)

IT IS BEST TO START WITH A SHADER ALREADY DONE and remove/add stuff, the basic structure is always the same.

In unity all you need for color is just:

Code:

Shader "Solid Red" {
    SubShader {
        Pass { Color (1,0,0,0) }
    }
} 

Since you are not doing any "shading" I would advise to use fixed function command, and for color manipulation, just compute and pass it through script, it will be easier first.

[JLJac]

Thanks guys! Yeah, it's cg!

Hehe I don't know about the loop in the shader, it was there when I downloaded it.

It makes sense how numbers can crash it I guess, given how extremely slimmed for performance these programs are made to be... They execute like... millions of times per frame, it's gotta be o.0 Craaaazy!

Update 130
When I got a shader "working" (i.e. I was able to at least output pixel colors, and get pixel colors from texture coordinates) my next step was to import a Rain World level in order to start writing a prototype for my level background shader. In order to do that, I needed to tweak the level editor some. In order to do that, I needed to make the level editor's png-output work on my new computer. And this is Director we're talking here, so I have spent literally half of today diving in 10 year old internet forums searching for something that would put me at square one - where I believed I was when I woke up this morning.  Found a solution though!

And, we have a historical milestone here - today for the first time ever, the unity build loaded a level saved by the director level editor!



Yes, it's super unpolished, yes it lacks slopes. Yes, the player's graphics is two space worms asteroids ... But still! This is the embryo of the actual game! It works! Levels can be saved, loaded, the player can move between them!

Tomorrow, I'll try to import a texture into Unity - stay tuned!

[Slader16]

Woah, that's amazing!

[OniWorld]

Oh wow director, I used to create multiuser isometric chat environments with director/lingo back when I was 13/14 years old. Are you still using it today? I thought it died long ago.

[jamesprimate]

And, we have a historical milestone here - today for the first time ever, the unity build loaded a level saved by the director level editor!

hey i know that level, its garbage worms! with space worms asteroid? space worms/rain world crossover confirmed. 

[RainWorldIsAwesome]

Lately in class I find myself doodling Rain World levels for fun. I'm way too obsessed 

[JLJac]

Hahaha OK I'll work faster!

Yep, that's the garbage worm level, it was at the top of the list 

Update 131
Managed to import a texture and display it as a Futile sprite, so that's cool! It's not super cool yet, the texture is super small for some unknown reason, and obviously I haven't written any cool shader or anything yet, so it just sits there at the side of the level. But I've managed to work with the basic logistic of getting the thing into the game, so that's cool!

For all of you out there who are fumbling in the dark for advice on how to do stuff in Futile, here's my (probably temporary) solution:

Code:

	//Roomtexture is just a string that's the name of the file we last loaded as a terrain graphic. 
		//If we have a graphic loaded, we unload it
		if (roomTexture != "")
			Futile.atlasManager.UnloadImage (roomTexture);

		//The graphics are located in ..\Assets\Futile\Resources\Levels, and Futile starts looking for 
		//imports in Resources, so we start our path there. Futile doesn't want file extensions for some reason.
		roomTexture = "Levels/" + newRoom.name;

		//Load it, simple enough
		Futile.atlasManager.LoadImage (roomTexture);

		//Seems like futile creates an atlas element which is in fact the entire atlas, because 
		//you can assign a sprite the element like this and it displays the entire image
		backgroundSprite.element = Futile.atlasManager.GetElementWithName(roomTexture);

Next up is trying to get this level graphic to display in a reasonable manner... And some shader stuff, perhaps. Wish me luck.

[JLJac]

Gasp, Unity limits texture sizes to 8000px. I have to do some serious re-thinking here. A thousand things going on in my head, including writing a custom compression format for 3D voxel textures...

[dancing_dead]

what, why do you need texture sizes bigger than that?

you do realize that a lot of the older/weaker/integrated gpus will probably flat out refuse and bug their way out of loading anything bigger than 4096x4096?
and that is already a seriously big-ass texture.

I think there's some hilarious misconception happening right here. what are you trying to do exactly?

[JLJac]

Hm, ok, so here's what I'm trying to do:

A standard room is about 1040*800 pixels big. I want to be able to have a level that't at least three times that size as well, or variable room size isn't really worth it.

If I'm having variable room size, I need to have a movable camera, obviously. If I'm having a movable camera, I want parallax scrolling.

Each room consists of 30 bitmap layers (with very few colors) that has previously, in the static camera build, been baked together as one image at level generation. My dream was to in this new version have all those 30 layers move about as parallax scrolling layers when the camera moved. It didn't seem so impossible - if crysis can be crysis I can have 30 pretty big 2D sprites move around, right?

Because I wanted the dynamic shadows as well, I wanted all layers to be in one texture. That way I'd be able to check in say layer 28 if it's being shaded by say layer 27 by simply asking different coordinates in the same texture for whether or not they're transparent.

So I went ahead and stacked all the layers on top of each other in a texture, and 800*30 = 24 000, so that's considerably bigger than the limit.

And now I think I have to figure out some other way to do this haha   Maybe I'll have to drop the parallax scrolling after all, and go with some pre-baked solution - can can still save a depth map for the room graphic and use that to do the dynamic shadows, so all is not lost!

Edit: Oh, and yeah, I can save each layer as its own texture, but that would make each room a 32 file, 2 megabyte monster, so I'd prefer not to. My talk about a custom file format is because most pixels actually don't change from layer to layer, so if I wrote my own compression algorithm that worked on the z-coordinate I could probably get the filesize down some, but I'd still need to unpack it for unity, so it wouldn't really solve anything.