Skip to main content

Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines

[DevLog] Stylized renderer/prototype, daily screenshots/videos (hopefully :))

A topic by Johan Helsing created Oct 01, 2020 Views: 319 Replies: 9
Viewing posts 1 to 10
(+1)

So, I’m doing this thing. My goal is pretty simple. I want to check in once a day, improve or tweak something, however trivial, and take a screenshot of it.

Today I tried some new palettes for a stylized renderer I’m working on:

screenshot

Hopefully I’ll find some use for it during Ludum Dare.

So I skipped this Ludum Dare as I failed to get properly inspired by any of my ideas. Experimenting with how characters work in Unity instead. I set up a Kenney character that I intend to use as a base/placeholder.

I got inspired for Ludum Dare after all. Making a petri dish inspired game/toy.

I submitted a game for Ludum Dare :D

Today I just played ludum dare games, and fixed a simple bug in my submission.

Rat inc is my favority ludum dare game so far: https://weeisfijn.itch.io/rat-inc

(1 edit)

Still just playing ludum dare games, and trying to catch up with lost sleep, work and physical exercise.

Also, when did this turn into my diary?

Anyways, I have two new favorite ludum dare games:

So I was quite happy with how the rendering for the loops in my Ludum Dare game turned out, so I ended up cleaning it up and making an upm package out of it. Hopefully I can continue expanding on it to create some juicy things later :)

(1 edit)

Continuing work on the 2D soft shape renderer. The plan is to make something akin to mudbun/clayxels, but for 2D.

While the shapes now seem to blend rather smoothly (pun totally intentended), today I worked on getting colors to blend as well.

I spent a lot of time botching it up.

But finally I got something I was happy with. It’s a weighted average color where the weights are the negative distance from the source shape + some offset to the power of 3.19, which is kind of weird. It probably makes sense to make it configurable per shape (right now it’s on the material).

I was also struggling to keep the number of render passes low, because I needed 3 color channels, alpha, distance, and weighted average total. Eventually, I figured out how to properly do multiple render targets in one pass, which means that for the moment I have plenty of room (4 render targets * 4 channels = 16).

In any case, I’m quite optimistic with how it works, and I think I can make something that is both very performant, author-friendly and flexible.

As intended, scaling now produces no artifacts :)

(1 edit)

So the only shape I supported up until now was the vesica, which was a bit weird. So I cleaned up some code and added support for rectangles and circles as well.

Not sure if this is a rabbit hole or not. Perhaps I should get back to making games.

I spent 3 hours trying to get GPU instancing to work for a custom sprite renderer shader with a material property block, only to figure out it’s a known bug that Unity decided not to fix and not to warn about. I mean they could at least have printed some warning in the console that setting a material property block on a sprite renderer will break instancing.

Anyways, once I found out it was their bug, I spent 15 minutes switching over to the mesh renderer and instancing is now working smoothly.

So I still get four draw calls, but at least most sprites with the same shape are now drawn in the same draw call. That’s happening because currently, each of the primitives have their own material. I guess maybe it would make sense to make them all use the same shader and just branch based on an enum value (instead of using #ifdefs like I do now). Anyways, I’m probably going to postpone that until I encounter performance issues to avoid doing too much premature optimization.