Asciicker – an online 3D game demo rendering to ASCII text
asciicker.com
asciicker.com
Edit: the reflection in the water is a nice touch.
Very nice.
Some commenters are asking how it gets such good performance and whether it would work on retro hardware. It seems it uses WebGL (and fails without it), so likely it depends on a 3D engine for at least some of the rendering process. Still, WebGL seems to be used for only a small part of the rendering pipeline.
If you want to play with arbitrary rotations instead of being locked to 60-degree increments, punch this into the developer console:
document.onkeydown = function(e) { if(e.key == '[') { dest_angle -= 1; } else if(e.key == ']') { dest_angle += 1; } else return true; }
Then use [ and ] keys to rotate by 1 degree increments. (Tested to work on Firefox).(having said that, such optimizations would still have helped in the hypothetical case one might have wanted to implement this on old hardware)
Also, on a desktop you can use the browser zoom (via the menu) to get it to increase the font size. I managed to get my HD screen to show 96 x 54 characters, which comes close to the resolutions on old DOS terminals I think. Now if only it came with a CRT shader, like this one by Timothy Lottes:
Also I noticed some websocket netcode up front. Is a multiplayer classic RTS in the works? ;)
Tip: in Firefox you can zoom out by opening the hamburger menu and changing the zoom level e.g. down to 30%.
https://www.reddit.com/r/asciicker/comments/d3ca43/whats_goi...
You can take a look at the ressources to get an idea of how it was done: http://asciicker.com/x13/images/
Very impressive demo otherwise!
I'll let you know if I reach new vistas.
(joking, joking. There is no Windowlicker 8-bit cover as far as I can tell. Somewhat surprising, actually)
Currently this is the closest approximation I can find: https://youtu.be/hfr1ddGM6Rk
Pretty phonetically sound, no?
Also keep in mind that games like Zarch[0][1] (aka Virus[2]) already existed in 1987. The ASCII actually hides the fact that we have a low rendering resolution, which may help a lot here.
So I think the main limitation might be the tricks required to render to ASCII, and time it takes to display those ASCII characters. Assuming the implementation tries to make a pure text-based renderer instead of a bitmapped one.
Searching on pouet.net for "ASCII" doesn't reveal many demos[3], but the few that exist look pretty cool[4][5]. They lack separate foreground/background colors though, which bring up one important point: what terminal are you targeting?
Anyway, I'm pretty sure there are more demos out there that basically render to the console but I don't remember the names right now so can't find them.
[0] https://www.youtube.com/watch?v=xrN2soK60bA
[1] https://www.youtube.com/watch?v=L7J5_5GZzeg
[2] https://www.youtube.com/watch?v=V1sYsOm-y8w
[3] http://www.pouet.net/search.php?what=ascii&type=prod
http://asciicker.com/x13/images/
As you can see it makes use of (I suspect paletted) PNGs
If you mean "uses WebGL to render 3D polygons", then there are other possible solutions, like the isometric approach I mentioned before. Given that the developer wants to target linux terminals[0] he is likely to come up with his own rendering scheme, probably not unlike the old software 3D engines of the late eighties/early nineties (like the aforementioned Zarch, or later Bullfrog games like Powermonger and Syndicate 2)
[0] https://old.reddit.com/r/asciicker/comments/d64sys/has_anyon...
Invoke "mplayer --vo=caca ((a video file))"
Love the backwash on the waves, that's the kind of detail that creates realism -- much more than subpixel texture perfection.
The sprites would have to be hardcoded, instead of being interpreted from images. You would also have to be extra smart about what you're calculating/rendering, but keep in mind that your screen is probably only 40 characters wide, so the amount to render is exponentially smaller.
You'd be amazed what can be done on those older computers when the developer understands how the processors work on the ground level.
At the very least it'd be an impressive tech demo for something like the Commander X16[0], a new 6502 based computer running at 8mhz.
Well, I was programming on C64 way back, and am pretty much aware what the system can and can't do. Sprite crunchers, xor filled vector fillers, etc. are familiar to me.
Cc65 would only hurt the effort. You need a full spectrum of assembler tricks to get any kind of performance out of C64.
C64 (PAL) has just 19k clock cycles available per 50 Hz frame. Since fastest instructions are 2 cycles, that's at most 9.5k instructions. Realistically closer to 5-7k. No multiply (hello table lookups!), no divide and not even 16-bit add.
Or in other words, it takes maybe 10k+ cycles for C64 to just "memcpy" 1000 bytes of characters!
You could implement something like Asciicker in a limited demo... but it'd be more like a souped up video player. Which, sadly, is a rather common technique in recent C64 demos, but understandable due to the limitations.
I think it could be done, with reasonable sacrifices.
Yeah, like dropping rotation. I think it'd be easier to do 80x50 rendering than ASCII.
> The framerates were atrocious...
That's the sacrifice you'd need to make.
Geoff Crammond (author of The Sentinel) wrote another game that's graphically way more impressive in this context: C64 Stunt Car Racer. https://www.youtube.com/watch?v=KMgjmIW8fd8
This is not to say The Sentinel wasn't an amazing game in all aspects, including graphically. It certainly was.