I wanted the village to feel more lively and somewhat chaotic. I'm starting to add some people to create a sense of being in a crowd.
One very subtle parallaxing is in the weapons shop background behind the guy at the counter. I was testing this out as the buildings felt a bit too static to me.
Can't have a Beat 'em up without some proper punching.
More people. A few twins, random walking/idling, random facing away or towards the camera.
Got lazy with the walk... so if you look closely, they have similar arms for now, no swinging arms, and they actually only step with one leg.
As I said on Twitter, looks legendary!
Thanks so much! I hope it turns out well!
Some new game mechanics including slopes!
https://x.com/lumiPD/status/1741187215181729891?s=20
Little sneak peek into a new scenery.
What the Crow opening title and first few seconds of gameplay.
Charge bow and... is that a six legged rhino triceratops beetle?!
It very much looks like it might be!
These titles both look so good.
Iâm blown away by what youâre doing with this game. Canât wait. Hopefully youâre making some dope music to go along with it haha
These look really good! Have you come up with creature names? How about Rhinotlops?
Thanks Adam and your help on the forum for flickering and quantizing. Do you have any tips on how to do this while following a player? Seems that because i'm quantizing the objects that parallax, the camera following the player on a easing function is causing stuttering. Trying to figure out a way around that and tried removing the .5 to round down, but that doesn't help.
Thanks for your interest! I could try making some music, but with just being myself for programming and designing the game, I might have to just use free music to save time.
Thanks! No names at the moment. Nice name!
Do you have a GIF showing the problem?
Generally the best way to quantize for anti-flicker is to do the rounding at the last moment before rendering, never storing the rounded values. Tracking the UNrounded values internally. That way rounding never accumulates to cause stutters or wrong speeds.
And also, round each object independently of others. Some may round up, some down, some may not change.
EDIT: yes, it looks like youâre rounding the camera, not the individual objects. One rounding for everything wonât work.
I donât know in your case how easy it would be to do that. Can you track and update positions for everything un-quantized, but donât draw using those directlyâquantize them all at render time?
(Also FWIW horizontal stripes wonât ever flicker for horizontal movement... but I know you have some vertical too, and stripes really only get you one gray level.)
Another possible issue I see: quantizing to 2px increments solves flicker for 2x2 dither patterns, but only REDUCES it for larger patterns. Some of your patterns like the undersides of the big background rocks look to be 4x4âand in a configuration that quantizing wonât even reduce.
I know it would be a lighter tone, but if you used instead a 2x2 pattern with one light pixel, it shouldnât flicker art all. (But I also donât see a big problem with a little flicker on certain things youâre not looking directly at often.)
Alternatively, how would that 4x4 dark gray look if the 2 white dots were aligned horizontally in a single row? A stripey look? Then quantizing would stop ALL horizontal flicker. (I would suggest not quantizing the vertical on the rocks then... except that would make the 2x2 checkered parts of the rocks flicker.)
These little mountains in the background and even the player (when running) actually stutter back and forthâespecially at slower speeds. You can't see it quite in the player, but can see it in the biking animation as well as if I slow the player down to a walk speed.
I think this is less of a flicker and more that they are moving to the left, then to the right, then left again.
I'll take some time to chew through what you just mentioned. I think I tried doing it with individual objects, but will take a look again.
The 4x4 pattern I custom made as it seemed to flicker the least. I think in your previous tips, you mentioned the number can be changed from 2 to 4 depending on the dither. I'll give that a try as well.
Thanks for your help!
Yes, you can use a larger numberâbut then the objects will âjump" in increments of that many pixels... so unless things are moving fast, that could look jerky.
Itâs like a grid-snap in a graphics program essentially.
Jerking back and forth does sound like cumulative rounding errors of some kind, so thatâs what Iâd investigate: I see those most distant rocks in the background doing that. (Viewing a GIF in Mac Preview is how I step frame-by-frame.) If their internally tracked position is moving smoothly (fractional pixels ideally) and then that is rounded JUST to render, there should be no back-and-forth.
Good luck! It looks great as is! But I know what itâs like to want to fine tune some little glitch Iâve noticed...
