next »

[godDLL]

NEW YEAR, NEW ARMOR

You better make that game.

[Spennerino]

NEW YEAR, NEW ARMOR

[knifeySpoonie]

NEW YEAR, NEW ARMOR

Great little promo guys :D

[exclamationmarker]

NEW YEAR, NEW ARMOR

I'm very excited to see this game come together!

[noio]

Hi again!

Today I will tell you about...
Our Pixel Rules

As always, if someone has any suggestions to improve the amount of used screen space without penalizing the "balance", I would be very keen to know about them.

Hiya!

Super interesting read, I'm dealing with the exact kind of problem you have :D. We came up with almost the same solution

Our game renders to a small "screen texture" that is then zoomed and rendered to screen. Some other games scale up pixelart by scaling up each individual sprite, which allows "bigpixels" to overlap eachother halfway. This also allows you to rotate individual pixels, which Crawl does quite effectively. This all can result in smoother motion (especially in regards to the f@!$ing paralax jiggles^[2]) but we decided against it.


Crawl's rotated bigpixels.


Rendering to a low-res texture has performance benefits, since we're actually rendering only the 512x256 pixels in our screen texture. Like you guys, we want "sharp" pixels, which means we can only upscale 1x, 2x, 3x, ... (Though there is a nuance here which gives a lot of flexibility! I'll get back to that later ^[1].)

We define a minimum region of this screen texture that we always want to see, and we zoom up to the highest integer zoom factor possible, that still shows this whole region.

 Since our game is focused very much on a horizontal playing field, we letterbox the upper and lower regions of the screen in stead of extending the view (which would just be filled with more sky / water). The whole "90° vertical screen orientation" thing is not something we even considered, haha.


Layout of the screen texture. We always show the middle part, the "extensions" are optional for wider screens.

http://imgur.com/0tym2Nf.png
Crop for a phone.

http://imgur.com/ef4d9eg.png
Crop for a 1920x1080 monitor.

This method gives a nice visual balance on most devices, some players get up to a 33% extended view field on either side, but that doesn't interfere with gameplay. It is flexible enough to never have black bars left/right. Top+bottom letterboxing is fine, but I really do want to fill the whole width of the screen. I don't think there are many devices with a 2:1 or higher aspect ratio, so I think we're good there.

We are rendering a few too many pixels (the ones outside the screen & under the letter box), but I don't think that will form a problem.

[1] @4x and up
So, there is a nuance regarding the rule that pixels can only zoom in integer amounts (1x, 2x, 3x). We all avoid non-integer zooms (like 1.5x) because it will either make bigpixels blurry (with anti-aliasing) or cause a kind of aliasing (image below). At 1.5x, without anti-aliasing, what happens is that bigpixels on a line are zoomed by a factor of 1,2,1,2,1,.... However, I was surprised to see that at zooms of 4 or higher, this is not very noticeable at all. A zoom factor of 4.2x, for example, yields bigpixels that are alternatingly 4,4,5,4,4,... pixels in size, but this is not a disturbing sight. So, at a zoom of 4 or higher, we do not cap the zoom to integer levels anymore. This allows us a little extra flexibility to fill screens that would otherwise have a bit of letterboxing.


Upscaling by a non-integer factor is not so bad at high zoom levels. It's even less noticeable ingame where the contrast is lower.

[2] Parallax Jiggles
I was gonna rant about the "jiggles" that you get when moving objects are "discretized" onto bigpixels, but I'll save it for another time.

Finally a short note on rotation. Initially we decided not to rotate objects, like you did. But rotation can be effective if used sparingly. It is important to keep the rotation fast and to mask it with effects where possible. This is exactly what we did for our falling trees. It's important to be able to break even your own rules when it's needed.

[dhontecillas]

@noio That long reply cheered me up! Thank you! We cant wait for your Kingdom release. We'll be buying it for sure.

First of all I must tell that we made our rules to try to stick to them and achieve the result that skydsgaard had in mind. But as you pointed, Crawl rotates pixels, and it looks awesome. (Last time we met, Skydsgaard and I, we played it and it was so fun that we didn't stop too much looking at the render .

Actually, we are not rendering to a small texture and then scaling it, but doing it the "bigpixels" way. First we thought that pixels should not be allowed to intersect halfway with other pixels (althought from the begining we didn't render to a smaller tecture and then scaled it, because we thought that would allow us to implement other effects, like chromatic aberrations, or blur, ....

Your aproach, not only has the advantage of beeing 'cheaper', because you render to a smaller screen, but also that when you rotate something, since it looks you are using the "nearest pixel" aproximation, you do not end with rotated squares (or romboids), nor blurred pixels on screen. When you scale your texture, you have squares and that is how they are displayed.

I must admit that it took me more time than expected to adjust scaling, to make it look good (I had several quirks due to rounding issues). And if you played the Hyper Light Drifter beta, and you stare at it, you will find they also are having some issues with pixels (they will probably have it fixed for the release, because it is pretty noticeable in some tiles with some patterns like this floor with lots of lines

, only on certain resolutions .. in that video it looks perfectly crisp, but if you have the chance to play it, do it)

<Technical stuff>
Our actual approach is that we have all positions (camera/viewport, actor and props positions, bounding boxes, etc.. ) in floating point. And we select a "Base Resolution" (that would be the ideal resolution to play the game). Then, having the viewport or screen resolution, we calculate the scale factor and the "logic viewport".
For example:

base resolution: 300 x 200
screen window: 665 x 610 (pretty weird, but is for having an example)

find the scale factor:
665.0 / 300.0 = 2.22
610.0 / 200.0 = 3.05

we select the smaller one, and round it down, so we end with a scale factor of x2
665.0 / 2 = 332.5
610.0 / 2 = 305.0

logic viewport = 332.5 x 305.0
scale = 2

and we pass that to the shader, that can make the calculations and the rounding to the pixel on the vertex shader (and we can enable / disable easily from the shader the 'big pixels can intersect' or not)
<End of technical stuff>

So, as I said, at the begining, we didn't want pixels to be halfway into other pixels, until we viewed how the parallax looked .. yeah ..  I guess that when you talk about de parallax jiggles, you talk about the effect that you have of the layers chasing each other when they are too close.

You can also find that on great games like Super Time Force: look at the botom layers how they move relative to each other, that looks like they are chasing each other:

Look at the gameplay video (put it on HD)

, or jump to this point and take a look at the trees: https://www.youtube.com/watch?v=4Eps9hRmahU#t=101 .

But once you play, that is barely noticeable, the game is fast, and so very good looking that you have to stare at it to see it. (In our case is what we do, first we play them, we enjoy them, and then ... we start looking for all the details, to find what makes that game feel so good).

For example, although we haven't been able to play Chroma: https://www.youtube.com/watch?v=mkOFy3i1Gsk by @Claw, we looked carefully at tha video, and we like how smooth feels the parallax, so we decided to allow the pixels to be intersected halfway. We hope they make a ton of money with Titan Souls, so they can come back to finish Chroma ! Looks amazing!


So I recorded our game with GifCam http://blog.bahraniapps.com/gifcam/ (direct download here: www.bahraniapps.com/apps/gifcam/gifcam.php ), with the MC moving much more slower that it would do in the game, so we can view the differences.

I have 3 variations (Neither of them have blurred pixels, because we still respect the "screen pixels"):

Hard cam, hard parallax: the camera (or viewport) starts at big pixels positions so it can not start in a half 'big pixel', and the parallax bigpixels can not intersect other layers bigpixels.

Soft cam, hard parallax: the camera can start at a fraction of a pixel, and the parallax bigpixels can not intersect other layers bigpixels

Soft cam, soft parallax: camera and parallax are allowed to intersect halfway of a big pixel.

And that last one is, for now, what we decided to have. We think it allows us to have closer layers, one to each other. At the end it is an effect that can not be completely avoided, unles you start to have blurred edges and anti-alias.

The main problem is that we want to have sharp pixels (beeing it screen pixels or 'big pixels'), so we round each layer position to the start of a pixel, so for example if we have a layer (A) moving a 1.3 pixels/frame and another one (B) at 1.4 pixels/frame, what we end having is this :

position A	1.30	2.60	3.90	5.20	6.50	7.80	9.10	10.40	11.70	13.00	14.30	15.60	16.90	18.20	19.50	20.80	22.10	23.40	24.70
position B	1.40	2.80	4.20	5.60	7.00	8.40	9.80	11.20	12.60	14.00	15.40	16.80	18.20	19.60	21.00	22.40	23.80	25.20	26.60
rounded A	1	2	3	5	6	7	9	10	11	13	14	15	16	18	19	20	22	23	24
rounded B	1	2	4	5	7	8	9	11	12	14	15	16	18	19	21	22	23	25	26
rounded Diff	0	0	1	0	1	1	0	1	1	1	1	1	2	1	2	2	1	2	2

And so we end with this unavoidable 'chasing effect' where layers are getting further-closer-further-closer ..

Sooooo ... if anyone has a solution for this, It would be great to know !


About the screen, putting or not bars, and so one .. we are not still satified, nor convinced of how to manage that. I think that once we have tested gameplay we could form a better opinion. Perhaps @Omnus is right about the main resolutions, but there will still be people playing it in some less common ones ... and at the end the point is to not have different experiences in different screen resolutions.

Thanks for all comments!

[shellbot]

I don't have any valuable input, I just want to follow this devlog

[Shackhal]

NEW YEAR, NEW ARMOR

Keep the good effort, guys!

[JobLeonard]

we want to have sharp pixels (beeing it screen pixels or 'big pixels')

Thank you. Thankyouthankyouthankyou. When pixel art games have engines that don't  respect their own resolution it irritates me to no end.

I don't really know any solutions to your chasing effect, but maybe you can implement the parallax math using Bresenham's algorithm. Yes, I'm talking about the line-drawing algorithm, except without the line-drawing part. Because the core of it is secretly "how to add fractions using only integer addition and subtraction" - it's how you do perfect embedded timers, for example. Here's a similar post how someone used it for a perfect timer in his game engine.

Then again, shaders are all about floating point math, aren't they?

[dhontecillas]

@JobLeonard Thanks for your suggestion. I've been thinking about the Bresenham's and also read the two articles. But, after thinking it carefully, what that would give us is a better rounding for the position (but that wouldn't solve the artifact).

Here you have to lines drawn using bresenham, and there is still the chasing problem:

So, the other option would be instead of position each layer 'absolutely' position it relative to the previous layer, so, the difference among two consecutive layers would not be shortening at any time. But that could lead us to other kind of artifacts like a layer poping two pixels, because the previous one was poping one, and the current one should be getting one pixel further from the previous... and with several layers that could happen more often, or more chained.

And also, if you expect to have lots of things in different depths, that becomes too difficult to mantain.

For the moment we feel pretty comfortable with what we have. It is about beeing careful to not put too close layers, and , take into account that the movement will be much faster.

[JobLeonard]

Eh.. no, that's not quite how Bresenham works... The lines would look like this:


source: http://en.wikipedia.org/wiki/Bresenham%27s_line_algorithm

No double pixels in the Y-axis. That's the whole point of better rounding. Would that solve your chasing problem btw?

[dhontecillas]

Oh, you are right, I made bad bresenhams when drawing them  , sorry. But, the result is still the same. The problems is not about having the correct 'absolute' rounding, but that each position has its own point in time when it advances one real pixel :

Those are real bresenhams and yet they have distances between them getting further-closer.

[JobLeonard]

Ah, yeah, I think I get what you mean. So let's say the horizontal axis is time, and vertical is displacement, and the two lines represent the offset of two layers. Right?

Too be honest, I don't think this can be solved if you want to avoid subpixel displacement, which you clearly do. I don't think it's a real issue though.

[dhontecillas]

@JobLeonard Exactly! thanks for the clarification, I forgot to put what each axis means.

It will be much less noticeable when we put a faster moving character (so the camera also moves faster), and distance between close 'parallax layers'. So, it is a 'good enough' solution, and we will focus on other stuff.

I guess that this is what @noio meant with parallax jiggles.

[jjhaggar]

NEW YEAR, NEW ARMOR! :D
(Sorry for the interruption, guys ^^)

[JobLeonard]

I think what's most important is that the "active" layer (the one with the player) has no chasing effects and in the same vein no weird hitbox jumps.

[oahda]

Not sure what you're trying to achieve – the third gif looks great.

[Aurel300]

(NEW YEAR, NEW ARMOR)

Hey guys, just found out about this project, saw the trailer, want it asap
Also will try to help if at all possible with programming problems and such!
Hope this ends up as successful as it deserves to be.

[noio]

I guess that this is what @noio meant with parallax jiggles.

Haha yea that's exactly what I meant with parallax jiggles. Very clear posts! Great idea to visualise the phenomenon as a 2D graph.

We don't have a real solution to the problem either, we're just trying to mitigate as well. As you noted: increasing the movement speed definitely helps to hide the problem. Everything is always positioned at whole/rounded bigpixel positions. And then we try to have the parallax ratios as "nice" fractions of each other. So 1/3 gives no problems:



But, as you mentioned, having "close" layers makes everything much worse (our closest is at 0.75). The red bars show the parallax layer "catching up" to the front layer, i.e. jiggles.



Of course, we could come up with some crazy system where the slower layers somehow "stash" or "store" their intended movement and wait until a layer in front of them moves (you mentioned something similar to this: "positioning relative to the previous layer [...] never shortening distances"). But that might cause different irregularities, as well as being a nightmare to implement.

Actually, we are [...] doing it the "bigpixels" way.

Interesting! From your first set of "rules" I thought you were really strict .  I've run Kingdom in that mode too and I must say that movement definitely looked a lot smoother (and of course it gets rid of the jiggles). It also allows you to get even more out of bigger screens, because you really gain resolution. I hope, though, that we'll get different benefits out of our low-res rendering. We should be able to have more sprites and per-pixel lights on the scene without getting in to performance troubles. At the moment we do things like having each blade of grass as a separate sprite so they can grow independently. But this might just be crazy & lazy .

[dhontecillas]

@noio it's cool to see different solutions for the same problem (and see that we all face similar issues  ).

By the way, your graphics explaining the parallax issue are much better than mine! what did you use to generate them?

Your way of using a factor for the speed of the layers looks smart. Do you have fixed layers of parallax? I mean, each 'prop' o 'thing' must be on one predefined layer that always has the same depth?

Currently we don't have predefined depths. We calculate the position offset (parallax) depending on the depth, and we try to tweek that depth value until it feels ok. But we could do the calc to find the ratio that prevents the chasing effect.

We also don't always have big images in the parallax, and we put smaller images composing the background with offsets.

Actually, we have implemented a "Prefetch 2d" system for all graphics assets. Here you have a debug render of how it works:

The white blinking square it is supposed to be the camera, the tiles are the sections with the graphicals assets ready to render. As we move the camera we can see gray squares, that are the assets that are currently beeing unloaded from memory, and new tiles (blinking) appears, that are the graphical assets that are loading into memory. These allows us to not use tiles but all the level hand painted, and have big levels without having to stop the game to load them. (At the very begining we were going to use tiles and http://www.mapeditor.org/ for the levels but we changed our minds).

Obviously, all the game logic is loaded in memory, but we can defer the loading of the graphical assets. However, this is subject to some tweaking (is about finding the balance between the used memory of preloaded assets / camera speed / fetching from disk lag). These can also bee improved by putting a cache layer before the file system resources loading. But as you can see at the end of the gif animation, the camera chases some "currently loading" tiles, and that is something we must avoid !


By the way! ... Happy New Year TIG People !!