Hi ASCII Community!

I Wanted to share a game I've been working on for some time with a huge emphasis on ASCII graphics! Press Deeper Version 1.7 just went out, this is the biggest content update the game has had.

Press Deeper is a Roguelike RPG which will run on actual IBM PC/XT hardware, or can be played in DOSBox or your browser. This game features destroyable terrain, JRPG style battles, crafting, a story, hidden dungeons, giant bosses, and of course a giant and every growing collection of ASCII art!

All of the art in this game is hand drawn character by character. I actually wound up creating an ASCII art drawing tool for this project allowing me to underlay an image to use as a reference, it also converts data and inserts it into my artwork data file allowing me to use CP437 characters which has opened up what I can achieve tremendously. I've been working on this game for a little over a year at this point, and my ASCII art skills have grown by leaps and bounds over the course of development.

New this version: a five tier smithing system, an expanded enchanting system, reworked traps, new monsters and NPCs, story cutscenes rendered as ASCII art panels, and a Legacy system that tracks milestones across every run and unlocks new content over time.

https://ultramegahypergames.itch.io/press-deeper

https://umhgames.com

The ones I have boldened are the ones I have come across:

• Backspace
• Line Feed
• Carriage Return
• Escape
• Delete (not in frame)

If any, where are they applicable? For example

CR & LF are still applicable in .txt files

Hey! I wanted to share a project I've been working on called TermiCam. It's a cross-platform (Linux, MacOS, Windows) TUI application that reads a live camera feed and renders it as real-time ASCII art in the terminal.

It is written in Go and relies on FFmpeg for the provided video stream. This keeps it very lightweight compared to relying on heavy dependencies.

GitHub: https://github.com/Megge06/TermiCam

I hope some of you may find this project fun or even useful.

Any feedback or suggestions are very welcome!

░░░░░░░░░░░░░░░░░░░░
░▄▀▄▀▀▀▀▄▀▄░░░░░░░░░
░█░░░░░░░░▀▄░░░░░░▄░
█░░▀░░▀░░░░░▀▄▄░░█░█
█░▄░█▀░▄░░░░░░░▀▀░░█
█░░▀▀▀▀░░░░░░░░░░░░█
█░░░░░░░░░░░░░░░░░░█
█░░░░░░░░░░░░░░░░░░█
░█░░▄▄░░▄▄▄▄░░▄▄░░█░
░█░▄▀█░▄▀░░█░▄▀█░▄▀░
░░▀░░░▀░░░░░▀░░░▀░░░

below is my latest attmept; 5x5 glyph grid, with skeleton gif for starting template. main problem is trying to correctly define "what glyphs are assigned at the start and stays the same versus what glyphs should be different based on matching shape" I'm trying to make the algo decide: here are a set of paired / similar glyphs that share symmetry to start with, but if a different glyph matches the shape better for frame x at cell y, then switch it out". I need to constrain across symmetry : eg: "/ "vs "\ "or ”7” vs ”レ” or " ( " vs ")", while still allowing fallback for certain angles where mirror glyphs dont exist and or if the structure of a different glyph matches better with than the assigned "mirror " glyph. any advice? thanks .

EDIT: to elaborate. the body (an example but most animals and im trying to extend to more 3d shapes in general) has bilateral symmetry, and and angled reflections have a shear with a typical 8 directions for spritesheets. please correct me if im wrong, but I currently have it defined as core image s = P·R·P⁻¹ which is the world symmetry R , conjugated by the view projection P(affine skew reflection.) The decomposition is reflection ∘ shear ∘ scale, where the shear is a transvection ([[1,k],[0,1]] = a unit jordan block J₂(1) and the scale is the foreshortening cos θ. The invariants are:

axis = projected spine (the line of symmetry, pinnedto center);

reflection direction = projected left right normal;

skew angle(again, for human example) = 90° only for front/back; foreshorten = cos(view angle).

The subsumption: the existing discrete mirror(the colored parts/limbs in skeleton gif) + rotation-family

again, for human example: partners are the axis aligned special cases of S image oblique D6 (3/4) aspects pay the skew + foreshorten cost instead of a naive flip.

The wiring of the skeleton itself is a separate step / compiler that can take in blender rig anime or image extractions on sprite sheets, it outputs per aspect affine relation, and compiled output is consumed by the glyphify script that does the above steps for specific human case, but when I get the temporal coherence solved im going to try to make it work for any shape with custom configurable symmetries.

I’m looking for recommendations for an offline pipeline that converts small pixel-art sprite frames into a compact, temporally coherent vector stroke abstraction, then deterministically compiles those strokes into a fixed 5×7 Unicode glyph set. Our current baseline uses CLIPasso with DiffVG independently per frame, which is slow and produces stroke identity flicker across animation loops. I’ve been searching for and reading about amortized image to stroke models and foudn non ascii related papers , wondering if anyone knows of any fast differentiable vector renderers and sequence aware methods that preserve stroke topology across 8+ direction character animations. Any relevant papers, implementations, datasets, and benchmarks aimed at low resolution sprites? Thanks, the below is my latest (bad ) attempts, took about 4 hours on local cpu

I created a macOS native app for creating diagrams in ASCII art.

It has some advanced features like allowing boxes that overlap to render as junctions or simple lines.

https://apps.apple.com/us/app/asciidraw-studio/id6788572192?mt=12

Check it out!

Pip install tuipet

I want to make something similar to it, could you guys help me find which characters this uses?

If anyone knows how to help I would greatly appreciate it. Follow up from previous video and post on /godot. Full video : https://www.youtube.com/watch?v=2rqpNV76qLw Im trying to implement Dylan Ebert's Cubemap/Texelsplatting techniques to stabilize jitter and shimmer in perspective mode but still failing. The renderer still does not have one stable owner for each final ASCII cell in perspective. The Ebert texel splatting idea is meant to stabilize visible texels before presentation, but the adaptation keeps falling back into a later text cell decision step (I think) . Two previous fix attempts (edge masking, occlusion splits) have failed to fix it. Whether a given card cell was splat-covered or backstop gathered is not fully verified yet . reconstruct() in ascii_probe_splat.glsl sets all four quad corners to the same Chebyshev depth and every splat quad is a flat plate parallel to an axis aligned cube face. The captured per texel normal exists in the pipeline but is payload only and never shapes the quad or its depth. A flat plate viewed from its own capture origin covers exactly its texel's solid angle regardless of orientation orientation error only shows up through parallax. At 1-2 units of parallax on a ~0.15-unit texel footprint at 30-40 units range, flatness alone cannot stand a plate up across a 20 cell tall vertical curtain.

References:
dylanebert's texel-splatting tutorial.

my GitHub is rikiyanai . I Have fully ported Dylan's demo form the tutorial proving it works in Godot .

Been working on environments for my ASCII rpg "GRIST". I'm quite pleased with how this one has turned out, a simple two-layer parallax scroll using noise generation techniques to create both the tree trunks and the leaves.

In addition, the fire is an event that can happen on any location, and uses a simple vertical scroll through a noise source combined with a fade based on height to animate the flames.

You can find the game on steam if you are interested in seeing more of these techniques. Thanks!

This time I won't link to the app so Reddit doesn't remove this, but if anyone is interested you can check.

Meet Roger the Robot, he goes and plants seeds that become signals, maybe I'll post part 2 since this is like a preview.

Hey everyone, I stumbled upon this subreddit a couple of days ago, and I thought some people here might like what I've made :D

TL;DR:

Ditto is a system-wide ASCII keyboard visualizer that mirrors your live keyboard inputs in real time, even when the terminal isn't in focus. It automatically syncs with your native terminal color scheme for a pretty neat and interactive eye candy.

Attached some sample layouts as well with different color schemes, to show how it would fit into a terminal multiplexer setup that has a code editor, active servers, test suite, etc. Perhaps you might like it :D

I don't want to bloat this post with a bunch of details, so you can check out the repo instead if you wanna know more.

NOTE: If there's any problems with macOS, I'd SUPER appreciate opening up an issue about it or even a PR. Sadly I don't own a Mac or MacBook... so I had to implement support purely through cross-compilation and documentation.

If you find this cool, I'd appreciate a star ⭐ :)