i don't... hate... this?

[eniko@mastodon.gamedev.place]

@swetland dosbox staging has a variety of crt filters. I should load one into a qbasic program and see what it looks like!

[aeva@mastodon.gamedev.place]

@eniko holy smokes that looks really good actually

[eniko@mastodon.gamedev.place]

@aeva !! :D thanks aeva!

[eniko@mastodon.gamedev.place]

And now that I have a structured palette I know what bits are red, green, and blue, and so I can easily do cool effects using PUTs binary operations, OR, AND, and XOR

Fuck yeah this is going so well!

[mcc@mastodon.social]

@eniko could you maybe make it *crunchier*? like by varying your dithering method. that might make it look more stylized and less like a tech limitation. it's a really good idea

[neia@zoner.work]

@eniko@mastodon.gamedev.place It's good crunchy!

[eniko@mastodon.gamedev.place]

@mcc hmm varying it in what way?

[tomf@mastodon.gamedev.place]

@eniko If you wanted a more even quality, a 666 palette would help a lot with the blue channel. 4 shades, even dithered, is really pushing it.

[eniko@mastodon.gamedev.place]

@TomF oh yeah I guess you could do it that way

Would make bit trick effects harder to impossible, though?

[darkuncle@infosec.exchange]

@eniko FWIW, agree -- the left image looks a little better to my eyes

[tomf@mastodon.gamedev.place]

@eniko hmmm... another thing to try would be:
Even pixels are 4 bits of red, 3 bits of green, no blue.
Odd pixels are 4 bits of blue, 3 bits of green, no red.
But you dither the green channel, which gets you an extra bit. So you actually have a 444 framebuffer :)

[mcc@mastodon.social]

@eniko well i meant trying different dither algorithms. but also it might be interesting in adjacent bigpixels to alternate the alignment of the dither algorithm. like ranodmize which one is left side and which is right side to break up the rigid curtain feeling it has currently

[eniko@mastodon.gamedev.place]

@mcc oh thats an interesting idea

For just, like, artistic control, going in and manually tweaking things is always an option. Or creating assets with more flat color areas known to be undeterred values

[mcc@mastodon.social]

@eniko i think there are some dither algorithms that follow rules similar to this one

[eniko@mastodon.gamedev.place]

@mcc I guess I could weight towards the pure colors? Might try that tomorrow and see how that works

[disorderlyf@todon.eu]

@eniko both look nice, but there's subtle differences with having both I prefer

[eniko@mastodon.gamedev.place]

@disorderlyf having both creates vertical streaking artifacts though

[disorderlyf@todon.eu]

@eniko Could be they're less visible at the pixel density I'm viewing from

[cobbpg@mastodon.gamedev.place]

@TomF @eniko On the other hand, in the 286-386 era you’d still be able to use LUTs for such effects (e.g. fading towards a given colour in up to 64 steps), so the layout of the palette is not necessarily as critical as its contents.

[eniko@mastodon.gamedev.place]

@cobbpg @TomF yes, but part of the challenge is that I'm using qbasic 1.1, the interpreted one without a compiler, without adding assembly. So doing my own per pixel operations is very slow

Meanwhile PUT is fast and lets me do bitwise operations. So that's much more viable