Serpentime: September Update #2


Just a quick update still on the rendering part of the game.  I found this wonderful blog post which covers implementing bilinear filtering on the CPU.  This was exactly what I needed.  I had to adapt it to be compatible with a Texture Atlas but other than that, much of what was covered was applicable and 4 times faster than the code I had originally written.   

As you can see from the example screenshot below, the Bilinear filtering takes out some of the noisiness of the Nearest Neighbour sampling by smoothing out some of the highs and lows.  But, it does cause the texture to be slightly blurry which can be seen in the foreground texture of the wood on the wharf.  

However, Bilinear filtering interpolates 4 pixels together, so it retains more of the details in the texture when the texture is being shrunk.  You can see this in the cracks in the plaster of the house walls.  The Nearest filtering is just grabbing one pixel at a time from the texture and can sometimes lose details when samples are farther apart in the texture.  By sampling more pixels, it can represent the texture more accurately.

Comments

Log in with itch.io to leave a comment.

zoomed out I can hardly see the difference, zoomed in I feel like bilinear embankment is muddled as if I'm seeing it through the veil (or a stretching of mismatched display resolution), walls are damp mudbrick and windows have curtains, whilst nearest neighbour has a crisp crunchy pixel-art look with bars on the windows and cracks on the dry plaster walls.

seeing you working on these subtle changes so early in the project, I hope it's not a kind of scope creep time sink cart before the horse thing.

is it to early to ask you about a timed roadmap of some kind? some devs are playtesting-driven from the earliest stages, others won't share a draft encounter with placeholder graphics even if their life would depend on it.

Bilinear filtering was something planned.  I experimented with it a few months ago but I couldn't get it fast enough and so I never demoed  it in one of the videos.  It's also something that can be disabled in the game options.  It helps cut down on the flickering in the walking and turning animations but it is at the cost of some crispness.

As for planning, I have a game design document which mostly focuses on the story aspect of the game and I use Trello for keeping track of implementation work.  Because both of these have some of the story information in them, I wont open them up to the public because it would give away the story.  However, the majority of what is in Trello deals with the rendering engine.  Until I get that performing well, there isn't much of a game and that's why I'm focusing on it.  There are some optimizations that I have tabled for later (even updates for after the game is released) which Bilinear filtering was one of them and then there are some that are going to be such a critical part of the pipeline that I have to implement them now or it will cause a dangerous refactor.

However, the Bilinear filtering basically fell into my lap when I stumbled on that article.  To quote Bob Ross, a "happy accident", if you will.  I was just striking while the iron was hot for a quick achievement.  It only affected one line of code in the pipeline.  So not a serious impact.

On the other hand, my current work is on the dynamic map loading mechanism. That's designed to make the world appear seamless by loading the world in chunks as the player moves around.  No loading screens except in some rare cases.  This has triggered an intensive refactor -- one of those optimizations that needs to be done now rather than later because it is going to gut my whole graphics pipeline.

As for demo releases, I hadn't thought about those just yet.  I didn't think anyone would want to toy with such primitive demos.  Maybe when I get the map collision implemented so that the player can't just walk through walls, then I'll start releasing some tech demos and see if I can get some feedback on render performance and quality from everyone.  It's just too early for anything else.

cool, looks like you've got this!

So it's a first solo videogame dev for you, but you are not a stranger to code