next »

[tobru]

Great to see your progress! It must have been hard to undo so much of what you had made.

SVO Fates

At some point I standardized all the fates to use a Subject-Verb-Object format. So instead of saying [Person A] [was killed by] [Person B] [with a gun], it's now [Person A] [was shot by] [Person B]. This makes matching fates easier and is friendlier to localization, where sentence structure can be shuffled.

FWIW (unless I'm confusing things completely) Subject-Verb-Object would be [Person B] [shot] [Person A]. The phrase [Person A] [was shot by] [Person B] is passive voice (Object-Verb-Subject). It's usually considered to be weaker, but it seems completely appropriate when the purpose is to put emphasis on the fate of Person A.

[Scorpile]

I'd like to eventually release this code as open source. It still needs some more production testing, and I want to figure out a license that prevents people from trying to just resell it on the asset store, but it's modular enough that someone else may get some use out of it.

Please, i need this desesperatelly...  i need to make a huge city and Unity Lightmapper takes ages (literally)

[dukope]

FWIW (unless I'm confusing things completely) Subject-Verb-Object would be [Person B] [shot] [Person A]. The phrase [Person A] [was shot by] [Person B] is passive voice (Object-Verb-Subject).

You're right and it's actually worse than that, as I've got both "[Person A] [was shot by] [Person B]" and "[Person A] [shot] [himself]" as fate options for the same guy. So I guess it's less "subject" and more like the "topic" you see in, at least, Japanese grammar. I don't want to think about it too much or I'll go changing things again.

Please, i need this desesperatelly...  i need to make a huge city and Unity Lightmapper takes ages (literally)

I touched on this a bit via Twitter, but the Lightcaster isn't production-ready for any case but mine right now. For one it's Mac-only. The shaders don't work on Windows for some totally great reason and I won't have time to figure that out until the game has shipped. For another, it's probably not ideal for huge levels. In any case it will eventually be released but I suggest finding another solution for your situation. Even for Obra Dinn I'm using a dynamic shadow-casting directional light for the moon/sun light so maybe you can try something like that for sharp cartoony shadows.


Schedule

Coming off PAX West, there was a scenario brewing in my mind where I could finish the game this year. It would've been a struggle but doable. Unfortunately there's not really a good time to release it between now and the end of the year, and I've got a few things on my plate that would really suffer from a dive into crunch. So I've decided to push any potential release until 2018 at the earliest. The less exact I keep it, the happier we'll all be I'm sure.


Currently

My next big post should be about the script-finalizing and voice-casting process. You know, gettin close to the end - show some progress. There's a few interesting tidbits in there even though it's not mesmerizing. But no, let me instead talk about some endless tweaking and wheel spinning. Stay tuned.

[dukope]

PAX West 2017

Booth shot (thanks to Chris Kohler)

Showing the game at the IMB Minibooth went great. My goal was to test out the new book and game flow and it seems the changes worked well. Some players embraced the book and some players ignored it but just about everyone was able to proceed through the game without getting stuck. Visually, the presentation was helped by the small-ish monitor mounted away from players' faces. Small physical pixels means the dithering works as it should and the low resolution isn't a distraction. As far as I was concerned, everything was hunky dory.

Having finished the script and sent out character audition scripts before PAX, the moment I got back home there were hundreds of voice actor auditions. That kept me busy for a while but I was able to stop by TGS in mid September to chat with a few fellow indies. One of those indies was Justin from Gattai Games. They're making a black & white horror VR game, "Stifled", which at first glance looks similar to Obra Dinn. I played their demo at PAX and it was great fun. They were showing the same build at TGS and I had a chance to ask Justin what he thought of the Obra Dinn build he played at PAX. His main comment was that it gave him a headache after a few minutes so suit up b/c there's nothing I love more than a problem that needs solving. 

Shark Jumping

This is the point where, as I put this post together, I wonder wtf I'm doing and why I don't just finish the damn game already. Moving on.


Fullscreen Still Looks Bad

Nothing if not predictable

A few months Three years ago I made a long post about how the game looks bad in fullscreen. I addressed this problem in a few ways (better dither, optional soft filter, etc) but resisted actually increasing the resolution, the obvious choice. The main reason for that is that I'm leaning heavily into the grungy dither-punk presentation through all levels of the art direction. Everything was designed with a minimum size for details and adding extra fidelity makes the game look worse.

Still though, it's a valid complaint that the game is all-day headaches and I really wanted to spend a little more time on that.


Shades and Lines

Broadly, the game's visuals are split into two separate elements: 1) Dithered texture, and 2) Wireframe lines.

The basic visual components

Zoomed

The game renders natively at 640x360. Doubling to 1280x720 gets finer geometry, more effective dithering, and thinner wireframe lines:

Rendered at double resolution (click for big)

As mentioned I don't like the extra detail, but I also don't like the thinner wireframe lines. The chunkiness is almost totally gone and that's just no good. You can also just start to see how low-poly the geometry is, which I'd rather avoid.

Now's a good time to reiterate that the visuals are really only a problem at fullscreen, large physical sizes. It's hard to communicate it clearly in little screenshots like this so just take my word for it. You can get a slightly better sense by seeing the swimming, flickering pixels in motion while zoomed.

Flickering dither and swimming lines

After thinking about this, it seemed to me that it should be possible to make the visuals more comfortable without adding actual detail, and without giving up the 1-bit limitation. My previous attempts were limited to upscaling the final buffer. That didn't give great results so I expected to try a little harder this time. It occurred to me that I could upscale each visual element (texture, lines) separately and combine them afterwards. Sounds harder already; good start.


Upscaling Dithered Texture

At 640x360, the game uses three separate dithering techniques: error diffusion, bayer pattern, and blue noise pattern:

The three dither techniques at 640x360

Each dithering technique is appropriate for different circumstances and their selection is important at these super low resolutions. With low res and bigger individual pixels, the eye has a harder time merging the dot patterns into shades of gray and I expect this is a major cause of eye strain. Doubling the resolution of the dithering (but not the underlying render) gives a much easier time of combining the dots into shades of gray:

Nearest-neighbor scaled from 640x360 to 1280x720, then dithered

Face closeup

.. Easier to see the grays, RIP chunkiness. It all looks a bit soft and the contrast between small dither pixels and thick line pixels clashes. Now that we've decided it's ok to cheat with mixed resolutions, and we've got all these extra pixels, why not try a coarser and more stylish dither pattern?

WB, chunk.

Looks rough but still captures the texture well, even without error diffusion

Rotating the dither pattern. Bad printer, classic newsprint, or tasteful woodcut? Choices.

Ok well that looks great and was a lot easier than I expected. Job half done.


Upscaling Lines

The wireframe lines were a little trickier. The goal was to upscale the lines into something that looks better and A) is still 1-bit (no blending) and B) doesn't add any information (no higher-res rendering). Since I played around with pixel-based scalers before I started by trying those again:

Upscaling the wireframes with pixel-scalers

There's a lot more algorithms than Scale2x and xBR but the others I tried end up with pretty similar results. Scale2x has the benefit of being fast and simple, xBR is slow and complex. Scale2x doesn't look good here, xBR is promising. After some research I found that xBR is a rule-based technique, designed for general color content. A significant amount of the work is spent on color separation and edge detection. 1-bit wireframes should be faster to handle, and if you're willing to write a custom pixel scaler, indeed they are.

Custom Line Scaler

I made a brief stab at simplifying the xBR algorithm but quickly decided there was too much going on there and it'd be better to just design something new from scratch. Without going into too many details, the algorithm I came up with does a case-by-case matching of the 3x3 pixel neighborhood to determine what the 4 new subpixels would be if the line was rendered at x2 with the same endpoints.

Pixels that match a left-hand pattern are expanded into the right-hand subpixels

I wrote a small Python tool to work this out and there are 24 possible left-hand patterns to match, which is perfectly manageable in shader code. The game takes the x1 wireframe render (640x360) and expands it to x2 (1280x720) in one shader pass. After this initial match-and-expand pass a little more cleanup is required. Line endpoints can be a lot more varied than just the 3x3 square neighborhood, and the border between matched patterns in these lines can leave out subpixels here and there. These missing subpixels can be hack-patched in a following pass that compares new and old pixel positions.

Original x1 line on the left, upscaled x2 on the right

The algorithm handles short lines well and long lines less-well. It rounds corners and when summing all possible matches in each 3x3 neighborhood, adds a satisfying "bleed" around joints:

Custom line scaler result

Comparison with nearest neighbor and xBR

If we just wanted a higher resolution line we'd be done but in Obra Dinn's case pixels carry information about wireframe color (inDarkness or not) separate from the wireframe on/off channel. This means that the changes to the wireframe channel need to be back-applied to the other channels. That's again a fairly simple pass that updates the subpixel colors based on neighboring wireframe values.

All told, the custom method is much faster than xBR and looks better for this special case. I have a hunch the technique could be modified to handle full color data and used as a general-purpose pixel scaler. Maybe I'll play around with that after the game is done. So, never.


Putting It All Together

Combining the higher resolution dither pattern with the custom line scaler makes a big difference. There's still swimming during motion due to the low resolution input data but it's way more comfortable to look at. The old display mode will remain as a selectable option and this new business will probably be the default.

I'm gonna gently close the book on this again. The final result:

640x360 render with custom x2 upscaler (click for big)

Old/new comparison

Moving

[Bennett]

Lucas I always love your dev posts, and this as always was an education. But... this looks a lot less beautiful to me, both on the lines and the dither, and it's not even really an improvement on the motion crawl... now it just reveals way too much of the algorithm and breaks suspension of disbelief. For me, anyway. I hope you make this an optional setting.

/edit: I guess I'm also not at all convinced by your hypothesis that the fat pixels are what's to blame for the headaches.  Did you get anyone who was affected by headaches to test at a higher resolution? Even if that did resolve the problem, I wouldn't be convinced that it's the real root cause of the headache problem. It seems plausible that your game causes involuntary eye saccades due to the high contrast and flickering, but this is not really addressed by your tech solution here. The thing I would try first is some simple frame blending to simulate phosphors which are slower to respond than modern LCD pixels.

[io3 creations]

I agree with Bennett regarding the new visuals and the headache.  While the new lines look quite good for close or far away objects with less details, the person sitting farther looked worse.   There could be many reasons for the headache especially if only one or few people experienced it but most didn't. So, it'd best to have a few of the options available in game for players to select.

Oh, don't think I mentioned it before but when I was playing the demo, the first time an "R-rated cutscene" started and there was nothing on screen, I wondered if it was a glitch.  Also happen to see a murder investigation on TV recently where they used a similar blackout during the recreation of the murder but there it was more obvious why they didn't want to show it.  In your game's case, even after the cutscene the game continued fine, I was probably wondering because computer games can have glitches.  On that note, I'm wondering if others mentioned similar things.  Also, in a general, I'm wondering what would be ways to indicate that the game is working as intended and the player isn't supposed to see something.

[sam_suite]

Yeah I gotta say I far prefer the chunky pixels to the smoother woodcut. Maybe it'll grow on me, but this feels like a big departure from your original art style.

[JobLeonard]

I actually like the WB dither quite a lot, especially when used diagonally. It feels like it is in the same "spirit" as the original aesthetic.

But I do agree that flickering is the more likely cause of head-aches. That's what makes the most physiological sense to me. Either way we need more solid data.

I just took that original gif, converted it to mp4 with ffmpeg and then ran it through butterflow to get some interpolated blending. It might give a better hint as to where the problems lie:





So, here's my hunch: when moving, you often move so fast that outlines (and dithered pixels) start "moving" more than one pixel per frame - look at the cupboard in the back, for a clear example. For smaller screens this is not too bad, but on bigger screens, those square pixels become a "visual unit" of its own, which actually is in conflict interpreting them as a group. Motion biases this even more in favour of individual unconnected pixels, and when motion moves pixels more than one pixel per frame it's the worst.

And although I normally loathe CRT shaders, they might work here. Another option might be motion blur, oddly enough. What if you try a motion blur filter (I guess you need one for texture and wireframes separately) and then apply dithering to the texture that comes out of that?

[JeroenDStout]

At the risk of taking this far out of the your "why don't I just finish it already" perspective... some sort of frame-to-frame persistence can be useful. A lot of "make video look hand-drawn" neural nets suffer from not knowing the previous frames and thereby ending up with very heavy noise results.

Something like feeding the current ditherer the previous final frame and favouring the result towards that of the previous frame might be something to consider. (Even if that sounds like a huge bloating of the original idea.)

[kinnas]

I don't know man. The original had a careful and considered feeling to it. The new one feels a lot like an overlay layer. Like somehow psychologically the old style feels natural and intrinsic while the new one has a tinge of that postFX filter effect feeling to it.

However holy fuck that dithered no lines look of the very first image is amazing. How does that look like when moving around? There's a certain cartoony videogamey feeling that the wireframes bring. The no wireframes look feels more serious somehow, like it's going for evocative psychological drama. It's gonna tell you a story, it's gonna transpose you to a different world! Long serious nights behind an old Mac computer. On the other hand the wireframes bring some of that 80s "3d is awesome!" Elite feel. I mean both are cool, the wireframe videogame warmness probably makes it easier to play longer stretches without getting opressive but it's super interesting to see just what a difference it makes.

[tobru]

The woodcut look kind of fits thematically, but with that and the greenish color palette I feel like we're getting pretty far from the "black & white look of old Mac games" that you talked about originally! But I can see how the flickering/shimmering dither patterns when moving would be a problem for a lot of people.

Two thoughts about how you might address the issue without ditching the pixelated dithering (I'm sure you've considered these ideas already):

1. The demo GIF shows a panning camera. Is this the most problematic motion? If so, wouldn't it be possible to pan the dither patterns too? So if the camera is panned 1 pixel to the left, the bayer/noise patterns are also moved 1 px to the left. I get that due to perspective etc it would never be a perfect match, but it should be possible to get more visual persistence in the image as a whole. For the blue noise it could at least theoretically be possible to distort it to follow the movement of different parts of the image. Maybe use a noise texture directly on the geometry, filter the output, and use as pattern for the dithering?

2. This is maybe an odd one, but if camera motion is a problem in general, wouldn't it be possible to modify the controls to reduce motion? Maybe a sort of Myst-like control scheme, where the camera doesn't move continuously, but jumps between individual still images. Maybe the game mechanics depend too much on the controls for this to work out.

[Bennett]

For me the new line interpolation evokes, way too strongly, 1990s emulator SNES9x aesthetics. It handles the detailed parts of the screen terribly, skipping between one inference about the line angle and another from frame to frame, and it makes straight edges look like they're wobbling or swimming. With the fat pixels, my brain can fill in the detail and those lines still look straight, but these new interpolated lines are very distracting. To my brain it says — third-party hi-def upscale.

The new dither shading isn't as bad, but it is culturally very strongly associated with emphasis effects in cheesy early-90s anime. It looks like a mid-90s photoshop filter has been applied to every frame. The worst thing about it is that the hatches stay still in screen space as the camera moves, which makes me acutely aware of the screen. I guess it's supposed to evoke a woodcut, but it doesn't get there for me, it looks like a quick photoshop mockup of a woodcut. Real woodcuts do not have anything like such regular hatching patterns. And a woodcut would never have that weird stepping on the straight lines.

My two cents: either go full-bore on a realistic woodcut style, which will take a lot more work and study, or commit to the 80s mac monochrome style, and find a better way to solve the headache problem. Sorry Lucas for being so vehement on this, but I have always thought this game was particularly beautiful, and this is kind of a catastrophe for how it looks, at least to my eyes.

[Pretzel Bros Studios]

Hi,

maybe you can reduce the flickering in the old version by minimizing the number of isolated pixels. A filter searching and replacing isolated pixels each frame might reduce the flickering to a more tolerable level without killing the visual aesthetics. Or calculating the distance to and the frequency of directly neighbouring pixels of the same colour might even be better? Maybe you can even eliminate 'isolated pixel nests' that fall below a certain threshold that way.

[dukope]

I'm over here jumping hammerheads but apparently you guys came for great whites. Not even sure they're native to this area.

This unpainted corner is all my own fault. I've made a game where recognizing details is important and the visuals work directly against that. Another way to put it is that the chunky pixels affect a great visual style but I need players to see past the individual pixels and into the scenes, characters, faces, and details being represented.

Bennet I'm not an inherent fan of upscaling either but there's an objective reality that the game is hard to play for long periods in fullscreen. Without changing the visuals I can either force large borders and hear players rightfully complain about "black bars", or I can allow fullscreen and have them give up out of discomfort. Think of it like bad VR, where an uncomfortable experience trumps everything else.

There are two possible compromises:
  1. Add more pixels
  2. Add more bits

I've internally decided that adding more pixels is better because it preserves the 1-bit moniker. I'm not totally calcified yet though so I'll play around with adding more bits instead. As JobLeonard noted, maintaining persistence of vision is made harder with large high-contrast pixels. A phosphor or motion-blur effect could help with that. Then the question will circle back to which compromise looks and works better to me. I'll post any results here, hopefully in a few days.

In any case, the original display mode will be an option in the menus, so you can reflect on my stunningly clinical wisdom in not making it the default.

[Sporkaganza]

Honestly, my main problem isn't with the texture, although it is definitely not the same aesthetic as the old Mac stuff you were going for. It's the line upscaling. For me the only way to enlarge pixel art is to just blow it up to twice (or 4x, etc.) its normal size. No other way of doing it has ever looked good in the entire history of video games. This does create an aesthetic mismatch with the woodcut vibe but at that point you're throwing the original aesthetics away anyway.

Hopefully the other option will be better so you can just trash this wonky-looking solution. I think it's okay if you can't find anything better as long as it's optional though. (And preferably off by default.)

[Bennett]

>objective reality that the game is hard to play for long periods in fullscreen.

Still not convinced that lack of pixels/bits is the actual root cause, rather than some of the other hypotheses (such as: isolated regions of individual pixels flickering on and off, causing eye saccades)

I feel like you should do some actual multi-hour user testing with a sensitive person and various different configurations. If isolated pixels are the problem, it's plausible that all you need to do is modify the tone curve, so that there are fewer areas with almost-white and almost-black brightness. I wouldn't rule that out at all until I'd tried it on an actual human.

If there is another issue with recognizing details, I'd say... increase the resolution by a smaller amount. Personally, I don't feel like 1280x720 native looks anywhere near as bad as your upscaling solution, but I'd bet a bilinear upscale on 960x540 would look great on almost everyone's monitor.

/edit it's really hard for me to overstate how bad the final image looks to me, compared to the naive 1280x720 upscale. I broke a 3-year streak of not posting on TIGsource just to try and dissuade you from committing to this look.

[JobLeonard]

on bigger screens, those square pixels become a "visual unit" of its own, which actually is in conflict interpreting them as a group.

So I just re-read dukope's post again and noticed he also realised this:

With low res and bigger individual pixels, the eye has a harder time merging the dot patterns into shades of gray and I expect this is a major cause of eye strain.

So I just want to emphasize: yes, this definitely is one part of the problem. It's basic physiology. Or psychology, I'm not sure where gestalt theory falls these days. Anyway, it's this:



The above image, but applied to pixels vs groups of pixels. Except the problem here it's not two conflicting interpretations of a still image, but of whether pixels turning on or off represent flickering or movement.

Here's yet another way to look at the problem:

- the "real" signal of our image is the original pixel resolution
- the signal our eyes receive is the screen resolution
- messing with the signal to reduced it back to the original might help with the problem

So here's a dumb thing I just tried to test that out for the texture part of the problem: apply the GIMP spread filter on each layer of the original gif. GIMP claims this filter swaps pixels randomly in a certain area. This is a lie, because sometimes a 2x2 white pixel is reduced to a 1x1 pixel, so there's definitely a loss of pixels in some form. But either way, it's basically a blur that retains hard pixel contrasts.

Here's the result of 3x2 (so more horizontal spread) alongside the original:





EDIT: Added space between them because the lack of synchronisation gives me motion sickness.





I have a small (unlisted) gallery with 2x2, 3x3, 4x2 and 2x4 as well. Not embedding them directly because big gifs: https://imgur.com/a/5y4Ty

(I missed what the issue would be with just using the high-res wireframes but with thicker lines though - maybe that was explained in an earlier post?)

[BottledBacon]

So I agree with what is being done in general here by Lucas. I think it's better that the game fits the '1-bit' look without needing to be held back by everything else that came with it. I mean we're already fully 3D so it's not an exact recreation. The diagonal pencil look I think goes some way to making it more pleasing on the eye... but that really only holds up in stills. As soon as the camera moves and it the brush strokes slide across models and the world, it looks kind of worse.  You at least expect pixels to act like that, but when a hand drawn style morphs and slides like that it's quite weird.

I'm a little confused why people are resistant to making it higher resolution or making the style super sharp and contrasty without so much dithering muddying up the details. I get it's currently more like the older games but as someone who is nearly 30 andhas  never played the old apple games this is styled after, making the game more painful to play for such specific nostalgia seems like something the game needs to get over to be playable by the vast majority.

A cool 1 bit art style is enough to stand out, and sticking to lower screen resolutions to avoid people seeing simple geometry sounds like the worst of both worlds. I'm sure players would prefer sharp low poly environments than blurry or dithery flickery ones that COULD be high detail underneath. If the gameplay is fun people will not mind seeing  low poly assets.

[Bennett]

Even if you commit to the thicker lines, this method — render at half resolution and then upscale hq2x — is insanity. None of the line angles are preserved and there is a complete mess in high frequency areas. It makes much more sense to me to render the lines at your output resolution and then add a pass to the line shader to fatten them up - that'll preserve the straight lines and the angles of the geometry, and it won't produce these strange artefacts when the camera moves.

To me the upscale doesn't even count as 'adding more pixels', you're just changing how the same number of pixels is presented. And it defeats the whole purpose of the line overlay on the image, which (for me, anyway) is to add some elements which are invariant between frames.

[Fuzzy Branch]

Man, what a tricky problem! Hard to tell just from gifs, but it seems like the most glaring issue is the intense pixel flickering during camera movement (which is still problematic even for the upscaled versions). It's a real shame that upscaling loses the low-fi 1-bit mac aesthetic you're targeting.
I'm curious if it might be possible to preserve the blockiness by upscaling with nearest-neighbor (so keeping fat-pixel look), but using a custom variant of Temporal Anti-Aliasing, and/or Screenspace dithering constraints, in order to preserve dithering patterns over time as they move around.

For example, look at the pattern of the foreground character's coat & head during your camera pan:

original:

Just spitballing here, but if you used a similar method to motion-blur, to store the previous frame's data to keep track of pixel movements, it might be possible to add an influence that tries to color the pixel the same value as its corresponding pixel of the previous frame. The pattern would still need to morph over time (especially due to perspective and rotations), so there would still be some flickering, but it might prevent the rapid frame1:on, frame2:off, frame3:on problem, and visually look more like the dither pattern is primarily just sliding around the screen, with only minimal flickering. Alternatively, maybe you could accomplish the same effect by constraining the dither patterns to stay relatively fixed in screen-space coordinates, or using stretched anisotropic dither patterns (with a visual direction of flow) that match the camera movements?

I know you probably have enough opinions to sort through already, and I'm sure there are a number of edge-cases and reasons why it wouldn't work, but it would be great if there was still a way to preserve your original intended aesthetic at fullscreen resolutions!

Also, just wanted to say great job on the devlog -- the amount of detail and insights in your posts are always interesting, been following along for awhile.