Doom on Playdate(devforum.play.date)
devforum.play.date
Doom on Playdate
https://devforum.play.date/t/doom-on-playdate/852
42 comments
Needs to use an Atkinson dither to minimise the dither error/distraction, this would produce clearer black and whites at the expense of a little colour/shade accuracy.
For a rapidly moving scene, an ordered dither is probably more appropriate than an error diffusion based dither. Faster to render as well.
Dunno what Return of the Obra Dinn used as dithering but these videos of Doom running naive 1-bit clamping immediately makes me beg for it having the aesthetic of RotOD.
Obra Dinn took a lot of experimentation to get right. The devlog for it on TigSource[1] has some big parts just related to dithering. For instance this post[2] and this post[3]. A user called Koloth also helped provide an Atkinson-like effect that works in a shader.
[1]https://forums.tigsource.com/index.php?topic=40832.0
[2]https://forums.tigsource.com/index.php?topic=40832.msg121719...
[3]https://forums.tigsource.com/index.php?topic=40832.msg136374...
[1]https://forums.tigsource.com/index.php?topic=40832.0
[2]https://forums.tigsource.com/index.php?topic=40832.msg121719...
[3]https://forums.tigsource.com/index.php?topic=40832.msg136374...
FastDoom has a beautifully dithered 1bit (Hercules) renderer since at least two years now https://www.youtube.com/watch?v=EEumutuyBBo
The dithering would work better if it also displayed an outline around each object (walls and enemy sprites). I don't know how much work it is to add it to the game, but I think it would be an improvement.
The examples of dithering that look low-contrast and overly bright are due to incorrect gamma.
The diffusion algorithms don't inherently make images brighter. They require working in the right color space, linear light in this case.
This color space error is less visible when dithering to many colors, because the difference between the most similar color and dithered color is small, so the (incorrectly) diffused error is small. But dithering to 1 bit is the worst case.
The diffusion algorithms don't inherently make images brighter. They require working in the right color space, linear light in this case.
This color space error is less visible when dithering to many colors, because the difference between the most similar color and dithered color is small, so the (incorrectly) diffused error is small. But dithering to 1 bit is the worst case.
Being able to use the crank for the Gatling gun is just delightful.
[deleted]
"... complaining about some missing references in libc. After spending two evenings ..."
This is such a chronic problem with compiling any existing C or C++ code. I'm paranoid about touching any new 3rd party software in those languages because of the inevitable frustrating fragility of it all.
This is such a chronic problem with compiling any existing C or C++ code. I'm paranoid about touching any new 3rd party software in those languages because of the inevitable frustrating fragility of it all.
I do not understand your complaint. Any program, regardless of the language in which it had been written can be problematic to use when it depends on external libraries that you do not have.
Python programs are many orders of magnitude more fragile than C/C++ programs, because I have seen plenty of such programs that require a certain Python 3.x version and they refuse to run with Python 3.(x-1) or 3.(x+1), making it difficult to install simultaneously many such programs, each desiring a different value of x.
Python programs are many orders of magnitude more fragile than C/C++ programs, because I have seen plenty of such programs that require a certain Python 3.x version and they refuse to run with Python 3.(x-1) or 3.(x+1), making it difficult to install simultaneously many such programs, each desiring a different value of x.
Not saying Python's any better. Though how do you make a Python program work on 3.x but not 3.x+1? I thought they had ended backward-incompatibility with the 2 to 3 update?
My experience with C/C+=/Fortran problems is not just versions of dependencies but version of compilers, platforms (they're non very portable), and mostly the extreme unhelpfulness of the error messages. It's always some undefined symbol that seems like it should be fine but turns out you're supposed to use all sorts of special command line parameters on the compiler and linker to make it work just right.
My experience with C/C+=/Fortran problems is not just versions of dependencies but version of compilers, platforms (they're non very portable), and mostly the extreme unhelpfulness of the error messages. It's always some undefined symbol that seems like it should be fine but turns out you're supposed to use all sorts of special command line parameters on the compiler and linker to make it work just right.
More and more programmers are used to a language which gets this right.
Yes, you're correct that neither Python not C++ get this right, it's pretty sad that your conclusion is that therefore it's impossible.
Yes, you're correct that neither Python not C++ get this right, it's pretty sad that your conclusion is that therefore it's impossible.
Don’t be coy, out with it! Legions of programmers are dying to know which language has solved versioning and dependencies.
No, I'd imagine most of them are comfortably using a language like Rust which got this right out of the box, or are like OP grumpily insisting that it's impossible and so nothing better can be done.
One of the perverse things about human nature is that many people would rather believe nothing better is possible than go to any effort at all to improve things.
One of the perverse things about human nature is that many people would rather believe nothing better is possible than go to any effort at all to improve things.
What rust is that? Nightly?
Golang, for one. If you have a diamond dependency problem where two libraries want to use a common ancestors that's incompatible, you're screwed, but otherwise you've got a nice merkle tree of dependency versions built into the tooling.
Do people use fast doom as the basis for ports on lower end hardware now? I was looking into it earlier and impressed how many improvements it brings.
Playdate is much more powerful than the original platforms Doom targeted. There’s a nice port for GameBoy Advance which is slower by an order of magnitude.
Ooh, custom linkscripts! Nice.
the Playdate is the Mastodon of handhelds.
This is going to be great when they come out with the Playdate Color(tm) !
Oops
The software powering this discussion forum encountered an unexpected problem. We apologize for the inconvenience.
The software powering this discussion forum encountered an unexpected problem. We apologize for the inconvenience.
Here’s a snapshot to read the thread while the original link is unavailable https://archive.ph/t8Wkn
[deleted]
[deleted]
I would have gotten the Playdate if it had a color e-ink display, hoping the next one would have one if there are plans for Panic to do this.
The benefits of color and also the benefits of low powered, long battery life with possibly the chance to change the color to black and white like original playdates shipped with.
Doom on Playdate looks awesome though!
The benefits of color and also the benefits of low powered, long battery life with possibly the chance to change the color to black and white like original playdates shipped with.
Doom on Playdate looks awesome though!
Unfortunately I assume it’s pretty cost prohibitive for an e ink display with a decent refresh rate. At least one good enough to play games on.
Isn't the whole point of the playdate to create a distinct format which removes a lot of noise from indie game dev? In my experience with game dev it was very easy to slip into fixating on pixel art color schemes, shading, etc
If you want colour it's already there in everything else
If you want colour it's already there in everything else
How does e eink screen work on a game console? The playdate screen is at least 30fps (and can actually refresh faster), even the fastest eink screens can't work at this speed without ghosting, and I don't want slower full refreshes while I'm playing a game.
It’s not E ink, it’s a Sharp Memory LCD https://sharpdevices.com/memory-lcd/
Memory LCDs have fast refresh rates while also being persistent like E ink. They’re also more expensive.
Memory LCDs have fast refresh rates while also being persistent like E ink. They’re also more expensive.
Exactly, they're not asking how the playdate works with an eInk screen (because it doesn't have one). They're asking how colesantiago expects to use a game console with a 5hz screen.
It plays the following games
- Crossword
- Chess
- Crossword
- Chess
they aren't really bistable like epaper; the playdate display requires 50 microwatts to maintain the display. when i unplug mine from the breadboard it retains its image for about 30 seconds before fading just on the screen capacitance
a broken epaper screen, by contrast, retains its image for at least several years
a broken epaper screen, by contrast, retains its image for at least several years
Have you seen the Playdate IRL? Its screen is very nice.
The screen is amazing. Backlight would be nice but the screen itself is great.
I would love a backlight in my play date. The main thing stopping me playing it as much is whenever I pick it up, I feel I have to move to get light to see the screen at least 50% of the time.
Backlight is not possible on this type of display. Frontlit screens exist, but are substantially thicker and require a new front plate.
the sharp memory-in-pixel display on the playdate uses roughly 1000 times less power than epaper displays do, assuming at least a few screen updates per minute. epaper only uses less power in applications like electronic pricetags