next »

[noio]

We don't want to put the coordinate exactly in the limit between one tile and the other (the red dot). Because when we use the "nearest" sample we could get the neighbor pixel. We neither want it to be in the center of the first pixel (yellow dot)

Is that for the same reason you need the half-texel offset on DirectX ?

[dhontecillas]

@noio Well, is not exactly like that. What is described there happens because is using biliniar interpolation for texture sampling. In OpenGL (that is what I'm using) would be like having this setting on textures:

glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR);
glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR);

But we are actually are using the nearest, that does not makes the interpolation stuff, but gives you the plain color of the texture at the sampled point (there must be something like this in DirectX and other engines):

glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_NEAREST);
glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_NEAREST);


But if one of our coordinates falls exactly in one "pixel frontier" we can not be sure which of the two neighbor texels will give us. So we must avoid texture coordinates 0.0, 0.25, 0.5,0.75 and 1.0.

Obviously, rounding down doesn't work, because we hit the 0.0 and 1.0:

We can try to 'hit' the texel in its center on the uv coordinates, and offset the size of half texek inside. In this case, 1.0 / 4.0 (the number of texels) leads us to a texel size of 0.25, and we halve it to 0.125 offset in each coordinate:

It look like it works. But, since our viewport will have "zoom", are going to sample the texture more times (x2, x3 ...).

For example when we double the resolution, the pixel shader will sample the texture 8 times, and we will end with a texel sampled just at 0.5  , a point we want to avoid:

If we offset inside the texture coordinates a small amount (in this case a 4% the size of a pixel -> 1 pixel = 0.25 then offset = 0.01).

This way our pixels are sampled at :
0.01 ,0.15, 0.29, 0.43, 0.57, 0.71, 0.85, 0.99

And obviously, this does not only apply to the big images, but to all the sprites.

Hope it clarifies why we need the offset.

Offtopic: To those of you who participate in the Global Game Jam this weekend... Have Fun! .

[noio]

But if one of our coordinates falls exactly in one "pixel frontier" we can not be sure which of the two neighbor texels will give us. So we must avoid texture coordinates 0.0, 0.25, 0.5,0.75 and 1.0.

I understand! We use GL_NEAREST too (well, I assume that Unity does internally when "Point filtering" is selected) I wonder why we don't have the problem .

[TheWing]

Woah, amazing pixelart! Great setting for a game, can't wait for something playable !

I come to wonder, though, you don't seem to have audio-stuff planned out yet, is either of you doing that too or is the place open/not planned yet?

[ehaykal]

This is sheer brilliance. I love the whole feel of the game.

[dhontecillas]

@noio Mmm, don't know, maybe because of your "1pixel-to-1screenpixel" and the scaling at a later pass?

@TheWing we are not working on audio / music yet. 

@eheykal Thanks!

For today, I would like to explain a little bit how we put together all the images that @Skydsgaard creates. You already know how we export the animation from photoshop from a previous post. But, once we have that, we import it in our "sprite library tool" .. and that is what I want to show you in a "new format" :

As you will notice, English is not my main language, and also I could not manage to reduce the background noise.

Well, tell us if you like this kind of videos

[wzl]

Wow, impressive tool. Must have been quite a lot of work on its own.
I find it very interesting to see how you are approaching animations handling. Especially since you use different layers for basically everything. the use of attachment points is quite interesting, and nothing i'd ever personally bother with, but i can see that it would offer a lot of freedom for a game like irkalla.
And boy that approach looks much more workable than going back into the code, finding that specific frame of animation and tweak the time until it seems right. (or timing it through the paint tool and translating it).

One thing i'm wondering is if there is a full animation preview. you have an animation and sprite specific preview, but can you for instance select the mc, and choose any of its animation sets to see the complete sprite preview, with all attached sub-sprites (gun arm for instance). I'd imagine it would help a lot getting the animations straight, and also for testing the transitions to different animations.

Finally, are you keeping this tool in-house, or can we expect to get our hands on it at some point? It certainly seems like a very mighty tool, but still generalized enough to benefit a lot of artists and programmers alike.

Hats off 

wzl

[TheWing]

Well, tell us if you like this kind of videos

I love videos like this, so I'll be eager to watch more!

On the other hand, I do like those longer posts that might have the same things written out separately, they're a bit better to grasp in the long run, since the text is staying there and it doesn't fly past, like in a video.

Some parts of software do need video/gif/movement to show how a thing works, and in that case (like your video now), it's very well in place

[dhontecillas]

@wzl Thanks!   It has some work, but I think in the long term it will pay the effort to code it. There is room for much improvements. You are right, the next step should be to have a way to see the "composed sprites", and all the animation cycle with different parts. I write it down into my TODO list. I don't know when, but at some point I will put that feature.

At this stage we do not plan to release it. Perhaps in the future we can think about it. Would someone pay something for it? (could it be some kind of income to support our game dev?) Shall we release it for free ? Don't know! 

@TheWing We will keep doing both. As you said, I though that explaining the editor with a long post would be too much, and with a video, people can skip parts, or hear it in the background.

[Deftoneish]

Wow this is simply gorgeous, I love the art direction!

[wzl]

At this stage we do not plan to release it. Perhaps in the future we can think about it. Would someone pay something for it? (could it be some kind of income to support our game dev?) Shall we release it for free ? Don't know! 

I could imagine people paying for it. Would it generate enough to support your gamedev? doubtful.
I'd likely spend a couple bucks on it, since it seems like a really good tool that would enable a bunch of functionalities that otherwise were really difficult to implement manually.

Honestly, the available toolsets to create 2d games at this point is really low. We have general purpose pixel and tilemap tools, but they all do just what you would expect. There are barely any tools that go beyond that (like your sprite library for instance). Compared to the huge scope of 3d dev tools (meshing, scultping, material painters, context sensitive mesh generation etc etc) it is really lacking. Admittedly 2d dev doesn't require any fancy stuff most of the time, but if you want to do something slightly out of the box you're stuck to writing it yourself, distracting you from the actual game dev.

The lack of tools may be a reason for 2d games being stuck with mostly simple mechanics and gameplay. It feels like they barely progressed from the 90ies.

I'm working on a tilemap editor myself to get more artist friendly features in, since i feel basic tile placing doesn't cut it anymore in this day. But the last two weeks i mostly worked on that, so my game doesn't progress at all right now.

[ENDESGA]

Love this so much. I've been following development for a long time, and I honest to god cannot die until this is finished.

[dhontecillas]

@Deftoneish Glad you like it!

@wzl Well, once it is more polished, we'll see what we do with the tool. (If I'm not too ashamed of the code, perhaps open source it?)

@ENDESGA Thanks! We do not post very often because we are busy working on it 

The past weekend I re-wrote the code for the main character jump. We found that what we had didn't have too much room for tweaking with what we had, so we had to change it a little bit.

This is how the MC Jump Model works now:

For the game, although we think the best experience would be a gamepad, we do not plan to use analog input (so the experiencie remains the same when playing in a keyboard).

On the horizontal movement: we have the walk speed, the running speed, and in-between a small time (that we can modify easily) about how much time it takes to get from min to max speed, and a different time for stopping. Running will be acomplished with a button/key.

On the vertical part, we want to set a min jump height, and a maximum height, but also to give the player the control of the jump.

So we have 2 different stages of jump:
- preparation: we actually have an animation for this part, that is when the MC prepares to perform the actual jump.
- afterburner: (i've put that name, if you have a better/adequate name, please tell me ) that is the part of the jump when the MC has already taken off, but, if still pressing the jump button, it can make it jump higher.

So, the complete velocity for a jump is composed of 3 parts: min jump velocity + preparation velocity + afterburner velocity.

Since we know the min/max height we want we have fixed the min/max velocity.  We split the difference between the preparation velocity (proportional to the time it takes to play the prepare jump animation), and the afterburner velocity (that is proportional to the afterburner time -> a param we can tweak). 

Lets say for example the animation takes 0.25 seconds, and we put an afterburner time of 0.25 (the maximum time to control the jump height would be 0.5 seconds).

Every row in this figure represents a different proportion of "velocity weight" on each stage of the jump: The first row, all velocity is gained in the preparation jump, on the second one there is on part of the velocity jump that is gained in the 'afterburner stage', and in each row, the contribution proportion of that part grows.

Then we have the boxes:
- The red one : the width represents the time the player keeps pressing the jump button, the height the proportion of the maximum velocity is getting by pressing the button until that time.
- The green one: the width marks the point where the preparation animation ends, and the height the proportion of the max velocity you get at that point.
- The yellow one: the same , but for the last part of the jump.
- The cyan one: is there to mark the minimum velocity threshold

And then we have the parabola, that is the height the MC versus time.



Or, looking at it in another way, here we have two rows:
- the first row is the vertical velocity the MC gets versus the time it keeps pressing the button. And in each column we have a different proportion of the importance of the (prepare/after) stage of the jump.
- on the second row how it maps to the height.



So this way we have these params to tweak:
- min height
- max height
- time after the MC has taken off that can still boost the jump
- ratio of importance of the preparation part of the jump versus the part where it is already on air.

I've been playing with those params and I think that this model is good enough to get a jump that "feels good".

[ENDESGA]

That seems so bloody intricate! But very interesting to read :D

I personally just have (basically) a horizontal variable, gravity, air and ground friction. I find for a good platformer, high acceleration and deceleration are key. As well as the fluidity and speed of the control reaction.

From the odd videos and .gifs you shown off, the running looks pretty darn good. Though, I'd love to see some more gifs!

Awesome work man! I'm definitely gonna follow this DevLog

[dhontecillas]

@ENDESGA Thanks!

At the end, the two most important params are how much time of pressing the jump button you take into account, and the shape of the "height" curve. And then tweak that. The problem with the jump is that I can show one thousand .gif's but until you don't press the button you won't feel it.

More gifs will be revealed ... but I can not tell you when Stay tuned !!

I'm going back to work! have a nice weekend

[ENDESGA]

The problem with the jump is that I can show one thousand .gif's but until you don't press the button you won't feel it.

Yeah, true. In the older version of NIKRA, the player had a slight delay before he jumped. It gave it depth because he crouched when doing so; no one can just jump instantly and quickly without going down and pushing up.
Though it made the game feel slower, and less progressing. Which is the same idea behind attacking; you have to make it cinematic and dynamic, while preserving speed and fluidity.
Complicated stuff. But good stuff.

Can't wait bro! I've heard of this game for a while and I absolutely love it.

While I'm here, would you be keen for a CameoSwap? I'd love for the main protagonist in NIKRA, Tae, to meet this chick from IRKALLA (I forgot her name for a second )

[Janeator]

Hey, popping up here for a bit. What did I miss? Seems like there hasn't been news for a while

[ramenators]

Been a while since I checked this, I hope to see some updates soon, keep it up guys!

[quan]

posting to follow, like main character design it is cool this looks cool

[shellbot]

I'm throwing in a bump here. Because I also want to see some progress 

Or at least a sign this isn't dead