5 ms·
Rendering Doom with Emojis
- xhrpost 4y agoI didn't know about doomgeneric. Sounds like it might be an easy way to hack on doom without having to get a whole DOS environment set up.
- pizza234 4y ago> Sounds like it might be an easy way to hack on doom without having to get a whole DOS environment set up. I don't know doomgeneric, however before it, Chocolate Doom has been for long a common modern port (while respecting the original code as much as possible), allowing running on modern O/Ss.
- quadcore 4y agoNitpick: this is fushia, not magenta.
- Eduard 4y agoNitpick: it is written fuchsia, not fushia.
- jsd1982 4y agoMight be faster to work in palette space instead of RGB space. Instead of computing the RGB average value from a block, just pick the most representative palette index for that block and reverse lookup the best emoji for that palette index. All you need is an emoji lookup per each unique palette; there's only a few dozen unique palettes used in vanilla DOOM.
- Eduard 4y agoI love it. Can you provide higher resolution pictures? E.g. the three "approach" images are just a stamp-size pixel mush, at least in mobile view. And zooming in on the YouTube videos is limited. Also, pausing them shows advertisements/suggestions on top of it. Additional self-hosted high-res videos would be great to see the full beauty !
- bscphil 4y ago> Another approach I thought initially was to treat colors as 3d points and check the distance between them. Granted, it doesn't matter much at all because they're just looking for the closest color, but it might be nice to do a transform into a perceptually uniform space (Oklab is both nice and computationally cheap) before calculating the distance, rather than just taking the euclidean distance of the raw pixel values like they do here. If you combine that with caching the best matching emoji for each palette instead of calculating everything on the fly for each new color, there wouldn't even be a performance penalty for this.
- yarg 4y agoOklab - https://bottosson.github.io/posts/oklab/ https://bottosson.github.io/posts/oklab/ The dude's blog has a few more posts about colour in software: https://bottosson.github.io/ https://bottosson.github.io/ The gamut clipping post is quite interesting - https://bottosson.github.io/posts/gamutclipping/ https://bottosson.github.io/posts/gamutclipping/
- bscphil 4y agoYes, also some discussions here previously. Oklab: A perceptual color space for image processing https://news.ycombinator.com/item?id=25525726 https://news.ycombinator.com/item?id=25525726 An interactive review of the Oklab perceptual color space https://news.ycombinator.com/item?id=25830327 https://news.ycombinator.com/item?id=25830327
- cyclotron3k 4y agoSome dithering would probably improve things too
- Exuma 4y agoThis took me forever to understand the first example because that is not saturation, that is the proportion of red/green/blue. Saturation would be something different. This isn't a nitpick, its a very cool article
- justinator 4y agoUrge to make a Perl, "image to emoji art" module rising...
- tym0 4y agoWonder if they could have solved their resolution problem by doing "sub-emoji" rendering.
- deleted 4y ago[deleted]
- glandium 4y agoUsing emojis would be a nice addition to libcaca. It heavily depends on the font, though, so it would be difficult to handle as a simple text thing...
- dylan604 4y agoSo, is there a stable diffusion model so you say "made from emojis"?
- dmitrygr 4y agoDoesn’t Doom use indexed color? And thus all this hash stuff isn’t needed, just map index to emoji when CLUT changes.
- gnicholas 4y agoNext: Rendering Doom with Emojis on a graphing calculator/smart fridge/etc.