What is the sense of fantasy computers?
category: general [glöplog]
A while ago I noticed that demosceners have started coding for fantasy computers such as the TIC 80. But I seriously wonder what's the sense of this. It's a computer that doesn't exist, that can only be emulated. Why develop for something that can be run only in an emulator? I mean, if you want to artificially restrict yourself to a resolution of something like 200x100 pixels or if you want to use a strange and akward programming language to develop your demos, you can do so if you develop your demo for Windows, too. If you develop your demo for Windows, you will probably even reach a broader audience.
Cause it’s fun
Is it though?
You get the "retro" look and feel without actually having the restrictions and steep learning curves of those old machines.
Quote:
A while ago I noticed that demosceners have started coding for fantasy computers such as the TIC 80. But I seriously wonder what's the sense of this. It's a computer that doesn't exist, that can only be emulated. Why develop for something that can be run only in an emulator? I mean, if you want to artificially restrict yourself to a resolution of something like 200x100 pixels or if you want to use a strange and akward programming language to develop your demos, you can do so if you develop your demo for Windows, too. If you develop your demo for Windows, you will probably even reach a broader audience.
Javascript/browser can also be considered as some kind of fantasy computer.
Just wait, it will soon feel nostalgic. Oh the good old TIC 80 we used to play with, when we were still middle-aged!
This might be more due to practical considerations than emotions (e.g. a desire for retro looking stuff).
These simulated computers offer very quick development cycles, suit the sizecoding needs quite well, and are still kind of some capability limited (for pushing boundaries) common base to compare eachothers prods.
They have a good cost/benefit ratio.
I would never do fantasy console stuff if doing an effect would be as hard as with x86 asm.
These simulated computers offer very quick development cycles, suit the sizecoding needs quite well, and are still kind of some capability limited (for pushing boundaries) common base to compare eachothers prods.
They have a good cost/benefit ratio.
I would never do fantasy console stuff if doing an effect would be as hard as with x86 asm.
do not feed the troll. the "decay of twitter" is visible here on this thread....
also what neon said.
also what neon said.
Quote:
you will probably even reach a broader audience
it's basic trolling, but let's go with it... who cares about broader audience while doing things like that? it's called a hobby, a pointless activity you do for "your own" enjoyment in "your own" spare time
what okkie, krill and dresdenboy said.
also anyone can just see your prod if they want to, not needing to have that specific vintage old hardware in their home in a working state.
also anyone can just see your prod if they want to, not needing to have that specific vintage old hardware in their home in a working state.
that being said - its time to release a real tic-80 pocket computer
Because it's dead easy to get started.
Both the PICO-8 and the TIC-80 have built in IDEs. I don't think you'd ever use the built in code editor for any larger project, but I still think it's important that it's there. I think something was lost when the world moved on from computers that boot straight into a BASIC interpreter and the barrier of entry to creating your first program was virtually non-existent, and I think these fantasy platforms are a nice throwback to that era.
And while it's easy to get started, they still provide a challenge. The PICO-8 has somewhat strict code size and virtual CPU cycle limits, and it's definitely not a trivial task to cram a full demo that runs in 60 FPS into all of that. Trust me, I know. And while the TIC-80 has far more lenient limitations and no virtual CPU cycle limit, on the TIC-80 you're likely to be sizecoding anyway, since that's the main demoscene activity on the TIC-80.
Both the PICO-8 and the TIC-80 have built in IDEs. I don't think you'd ever use the built in code editor for any larger project, but I still think it's important that it's there. I think something was lost when the world moved on from computers that boot straight into a BASIC interpreter and the barrier of entry to creating your first program was virtually non-existent, and I think these fantasy platforms are a nice throwback to that era.
And while it's easy to get started, they still provide a challenge. The PICO-8 has somewhat strict code size and virtual CPU cycle limits, and it's definitely not a trivial task to cram a full demo that runs in 60 FPS into all of that. Trust me, I know. And while the TIC-80 has far more lenient limitations and no virtual CPU cycle limit, on the TIC-80 you're likely to be sizecoding anyway, since that's the main demoscene activity on the TIC-80.
Quote:
likely to be sizecoding anyway, since that's the main demoscene activity on the TIC-80
Prove me wrong, but that sizecoding seems to be restricted to counting source code letters.
Somewhat sensible given the platform, but an entirely different thing than counting bytecode tokens, and with nothing like using the side-effects of various opcodes to your advantage.
It seems to encourage people to do just what an ECMAScript minimiser does, which is somemwhat disappointing. :)
Krill: TIC-80 has built-in ZLIB compression for your "binaries". So you might even get an advantage over other platforms such as DOS in the range from roughly 128 to 512 bytes where ZLIB starts to really kick in whereas on DOS and other platforms you won't get very far with compression due to the overhead of having to include a decompressor in your binary.
Quote:
Ah, comparing tinydemos across different platforms isn't so sensible anyways.TIC-80 has built-in ZLIB compression for your "binaries". So you might even get an advantage over other platforms
I was commenting on the nature of sizecoding itself being very different on virtual platforms vs. brick-and-mortar platforms.
Somewhat like having div operations be no more expensive than add. =)
I think fantasy computers and fantasy consoles simply show what can theoretically be developed as hardware - or as emulation - for devices (computers and consoles); or could have been possible.
So I see it next to the point of planning and feasibility as hobby & learning projects; as well as fun projects at the same time, which depending on the scope can be very attractive and a lot of fun to use.
Projects such as pico-8 should certainly be mentioned here, which in my opinion is a very interesting project in which, in addition to the end user; possible programmers - also thanks to a large community and many examples - can see and learn the first steps in programming quite quickly and easily.
There are certainly other areas where one could ask about their purpose and usability. There are just things / projects that just show a possible feasibility; or can sometimes develop from small (hobby) projects into big and great things.
Personally, I find it very interesting and welcome any such ideas and projects.
So I see it next to the point of planning and feasibility as hobby & learning projects; as well as fun projects at the same time, which depending on the scope can be very attractive and a lot of fun to use.
Projects such as pico-8 should certainly be mentioned here, which in my opinion is a very interesting project in which, in addition to the end user; possible programmers - also thanks to a large community and many examples - can see and learn the first steps in programming quite quickly and easily.
There are certainly other areas where one could ask about their purpose and usability. There are just things / projects that just show a possible feasibility; or can sometimes develop from small (hobby) projects into big and great things.
Personally, I find it very interesting and welcome any such ideas and projects.
I think more positively of these micro platforms than negatively as they helped new people get into gamedev and it's easy and fun. But feels odd when tiny compos are combined in the recent years and most entries comes from these platforms and not real hardware. I prefer coding intros for the real thing in assembly, even if I jokingly say I hate x86 many times while doing it and would have a nicer time with some of these platforms. But it wouldn't feel real.
There is also the "permacomputing" aspect at play here: If you write code for a fantasy console, you know that it will alays be possible to run it on future computers, because emulators will exist for them. No matter in what weird direction technology may develop next, you'll probably be able to run a TIC-80 emulator on it.
In a certain sense, the C64 and Amiga have achieved the same situation, although it happened more by accident then by design.
The same is *not* true for some platforms like webbrowser demos (which, for many years, suffered from what I call "This week's javascript syndrome"), where you might have difficulties running your own code only half a year after you wrote it. Likewise most linux demos and anything developed for game consoles with copy protection mechanisms.
In a certain sense, the C64 and Amiga have achieved the same situation, although it happened more by accident then by design.
The same is *not* true for some platforms like webbrowser demos (which, for many years, suffered from what I call "This week's javascript syndrome"), where you might have difficulties running your own code only half a year after you wrote it. Likewise most linux demos and anything developed for game consoles with copy protection mechanisms.
Quote:
There is also the "permacomputing" aspect at play here: If you write code for a fantasy console, you know that it will alays be possible to run it on future computers, because emulators will exist for them. No matter in what weird direction technology may develop next, you'll probably be able to run a TIC-80 emulator on it.
That's partially true. However, you won't be able to run Rock for Metal on any recent version of PICO-8 :) Still, to be fair, I don't think Zep expected anyone to push PICO-8 in the ways I did, and as far as I know, my demos are among the very few carts that require older versions of PICO-8 to run. Perhaps newer versions of PICO-8 are more future proof, and of course, if you have that older version of PICO-8, you'll probably be able to make an emulator for it.
Quote:
you might have difficulties running your own code only half a year after you wrote it [...] for game consoles with copy protection mechanisms.
Why wouldn't code for e.g. Playstation work after a few months?
I completely understand the appeal, but kind of I wish there would be a "virtual console" that would also basically be a framework for developing for some actual older hardware. I guess in that case the language would need to be something that could be easily converted to perhaps C.
Quote:
After a quick glance, the primary objective of "permacomputing" seems to be sustainability, as in resource-efficiency, and not so much software preservation.There is also the "permacomputing" aspect at play here: If you write code for a fantasy console, you know that it will alays be possible to run it on future computers
Countering bit rot may help environmental concerns in some way, but running software in layers upon layers of virtual machines is pretty much the opposite of efficient, both in computing itself and in consuming real-world resources for the task.
For comparison: GLSL is scripting language targeting an abstract computer. It's compiled during the runtime, just like TIC-80 LUA-scripts. If we consider an average 4k intro which is essentially a gigantic GLSL script with added music, how big really is the difference to writing LUA scripts for TIC-80? It's not like either has a "dodemo()" function; some things are easier in GLSL while others in TIC-80.
Oh, while we are at it, since mid-90s, x86 computers are essentially virtual machines, emulating the old x86 opcode with microcode. So, do real x86 machines still exist? Or are they all just software emulators? Does anyone care that they are actually "emulators"? Most DOS stuff nowadays is actually developed on DOSBox, and good chunk cannot run properly on any real DOS machine, e.g. because they need insane amount of cycles or use MIDI music designed for Windows MIDI driver.
TIC-80 can be ran on bare metal raspberry pi (that boots to TIC-80 without any OS). Does that change your opinion of fantasy consoles?
Oh, while we are at it, since mid-90s, x86 computers are essentially virtual machines, emulating the old x86 opcode with microcode. So, do real x86 machines still exist? Or are they all just software emulators? Does anyone care that they are actually "emulators"? Most DOS stuff nowadays is actually developed on DOSBox, and good chunk cannot run properly on any real DOS machine, e.g. because they need insane amount of cycles or use MIDI music designed for Windows MIDI driver.
TIC-80 can be ran on bare metal raspberry pi (that boots to TIC-80 without any OS). Does that change your opinion of fantasy consoles?
Quote:
TIC-80 can be ran on bare metal raspberry pi (that boots to TIC-80 without any OS). Does that change your opinion of fantasy consoles?
Not at all. OS or not, it's a certain version of Lua script that you are targeting. And that's an excellent idea. I'm a big fan of prototyping effects in Lua, and I did this long before any fantasy console existed. I also see the aspect of preservation (of algorithmic ideas), however using a closed-source Lua incarnation (i.e. Pico-8) runs counter to that idea.
Quote:
emulating the old x86 opcode with microcode
Even the first x86 CPU used microcode, so it's not a recent trend. Whether you'd call that "virtual" or "emulation" is a different kettle of fish, but there has always been some disconnect between the machine code and what the CPU actually does. The same is true for many other architectures, like 68k.