Joined: 4/17/2010
Posts: 11486
Location: Lake Chargoggagoggmanchauggagoggchaubunagungamaugg
As you guys already know, Hourglass and libTAS are technically-not-an-emulator's. The same is known about Wine.
We have at least 3 such programs, and PC TASing apparently fully depends on this approach, so it will be getting more and more attention. Because after Hourglass's death, Linux TASing (with or without Wine) is our only hope.
But there is one problem. We can't constantly hear regular people call such tools emulators, and constantly yell at them that it's technically-not-an-emulator!!!!!!!1. We need to come up with some simple name that will stick, while also being accurate.
As we know, the very word "emulator" was made up semi-arbitrarily. Then it completely changed its meaning, and now it stuck as software simulation of hardware device logic.
Well I guess it's time to semi-arbitrarily invent a new word! We have some definitive words to base on, and they are pretty accurate and are approved by the authors of those programs.
Wine's actual self definition is that it's an API translation layer:
Wine (originally an acronym for "Wine Is Not an Emulator") is a compatibility layer capable of running Windows applications on several POSIX-compliant operating systems, such as Linux, macOS, & BSD. Instead of simulating internal Windows logic like a virtual machine or emulator, Wine translates Windows API calls into POSIX calls on-the-fly, eliminating the performance and memory penalties of other methods and allowing you to cleanly integrate Windows applications into your desktop.
The same was said by ais523 about TAS frameworks using the same principles. So I shortened it to just "translayer". And so far, people I asked seem to like the word.
If anyone has better ideas, or just concerns, please post! Maybe we'll come up with a better word. But the plan in any case is to start enforcing this new term so it eventually becomes the standard.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
The word "translayer" is really catchy and I like it. Somewhat unfortunate to say it loud...
edit: just some research for the word in other software:
QEMU also defines this translationing as the core feature (for emulation purposes):
"QEMU is a [..] processor emulator using dynamic translation to achieve good emulation speed".
QEMU calls his dynamic translation backend as TCG --> Tiny Code Generator.
(linky for QEMU wiki)
PhD in TASing 🎓 speedrun enthusiast ❤🚷🔥 white hat hacker ▓ black box tester ░ censorships and rules...
Joined: 4/17/2010
Posts: 11486
Location: Lake Chargoggagoggmanchauggagoggchaubunagungamaugg
MESHUGGAH wrote:
QEMU also defines this translationing as the core feature (for emulation purposes):
"QEMU is a [..] processor emulator using dynamic translation to achieve good emulation speed".
QEMU calls his dynamic translation backend as TCG --> Tiny Code Generator.
(linky for QEMU wiki)
That's code translation, not translation of API calls. Full on emulation is still happening for them, they just optimize the code n a special way to run faster. In translayers, nothing is emulated at all.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Thanks for that. I just spat coffee all over my desk.
Not trans layers, tran slayers!
Anyways, I like "API wrapper" which makes it clear that only the API is converted (and not the actual game code as with an emulator).
The pronunciation of "trans slayer" can be rather unfortunate and is probably worth avoiding the term altogether for. Something to do with API is probably better all around.
[16:36:31] <Mothrayas> I have to say this argument about robot drug usage is a lot more fun than whatever else we have been doing in the past two+ hours
[16:08:10] <BenLubar> a TAS is just the limit of a segmented speedrun as the segment length approaches zero
Joined: 4/17/2010
Posts: 11486
Location: Lake Chargoggagoggmanchauggagoggchaubunagungamaugg
I'd also state that I really want the term we come up with to be a single word, because otherwise it'd be avoided altogether or boiled down to something silly (like, emulator -> emu). It can be compound if needed too.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
[16:36:31] <Mothrayas> I have to say this argument about robot drug usage is a lot more fun than whatever else we have been doing in the past two+ hours
[16:08:10] <BenLubar> a TAS is just the limit of a segmented speedrun as the segment length approaches zero
Joined: 4/17/2010
Posts: 11486
Location: Lake Chargoggagoggmanchauggagoggchaubunagungamaugg
This one doesn't tell anything about what's going on on the technical side. Not descriptive/accurate.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
I would prefer not inventing a term that we have to explain to people first. Translation Layer (unabbreviated) or API Wrapper sound fine to me.
This is a fairly good point. We should be focusing on what is most clear to the reader first and easily abbreviated second. Good abbreviations are nice but I think trying to force an abbreviation might come off unnatural compared to say emu.
[16:36:31] <Mothrayas> I have to say this argument about robot drug usage is a lot more fun than whatever else we have been doing in the past two+ hours
[16:08:10] <BenLubar> a TAS is just the limit of a segmented speedrun as the segment length approaches zero
Joined: 4/7/2015
Posts: 331
Location: Porto Alegre, RS, Brazil
This term will be used only for these TASing tools (and others that might be created in the future) or it will be a broader denomination?
Games are basically math with a visual representation of this math, that's why I make the scripts, to re-see games as math.
My things:
YouTube, GitHub, Pastebin, Twitter
Joined: 4/17/2010
Posts: 11486
Location: Lake Chargoggagoggmanchauggagoggchaubunagungamaugg
brunovalads wrote:
This term will be used only for these TASing tools (and others that might be created in the future) or it will be a broader denomination?
Can it be broader than Wine is?
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Tools like Hourglass and WINE are translating at the API level, not the ABI level. The ABI basically just says "if you have a function which takes X arguments and produces Y return value, here are the registers you use, here's how you have to set up the stack, etc.". Most notably, the ABI doesn't define anything about what individual functions do. An ABI translation would thus allow you to connect together programs and libraries which were compiled using different compilers (the best-known such incompatibility being MSVC versus mingw).
The API is a list of functions and what those functions actually do; it's relevant both for programmers, and for compiled programs. (Sometimes the details differ, but normally not by much, in order to keep compilers simple.) Hourglass, WINE, and libTAS work at this level of abstraction; they know, e.g., which functions are timer functions, which is information included in the API but not the ABI. Then those functions (only) get replaced.
There are other possible techniques, e.g. I (have been working / do not currently have the time to work on) a layer that translates at the system call level rather than the library level (on Linux, these are distinguished by which chapter of the manual they're in, system calls in chapter 2, library calls in chapter 3). The benefit of that is that there's only a few hundred system calls (as opposed to too many library functions, across all the libraries in existence, to easily count), so in theory it should be possible to consider all of them individually and ensure that they're all 100% reproducible.
Joined: 3/2/2010
Posts: 2178
Location: A little to the left of nowhere (Sweden)
ais523 wrote:
Tools like Hourglass and WINE are translating at the API level, not the ABI level. The ABI basically just says "if you have a function which takes X arguments and produces Y return value, here are the registers you use, here's how you have to set up the stack, etc.". Most notably, the ABI doesn't define anything about what individual functions do. An ABI translation would thus allow you to connect together programs and libraries which were compiled using different compilers (the best-known such incompatibility being MSVC versus mingw).
I stand corrected, I must have understood the API vs ABI differences when it was first explained to me.
As we know, the very word "emulator" was made up semi-arbitrarily. Then it completely changed its meaning, and now it stuck as software simulation of hardware device logic.
Well I guess it's time to semi-arbitrarily invent a new word! We have some definitive words to base on, and they are pretty accurate and are approved by the authors of those programs.
Okay, so we need a semi-arbitrary, easy-to-use, catchy and spreadable word that captures the way these tools function?
WINE itself is an API translation layer, but neither libTAS nor Hourglass did any sort of translation. What all three of these tools have in common, however, is their interception and moderation of API calls. So I want to suggest
Interceptor
or
Mediator
as the the word we use to refer to this class of program.
How fleeting are all human passions compared with the massive continuity of ducks.
Joined: 4/17/2010
Posts: 11486
Location: Lake Chargoggagoggmanchauggagoggchaubunagungamaugg
I noticed that there's no verb that can be made out of "translayer" other than even more ominous "translay".
- What does your tool do?
- It translays!
- Translays whom? O_o
So what about "translaytor"? It "translaytes" - serves as a layer that translates API calls.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Joined: 4/17/2010
Posts: 11486
Location: Lake Chargoggagoggmanchauggagoggchaubunagungamaugg
That's the least of evils imo.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
My own opinions for the new terms:
- Translaytor is overkill: hard to say and read (Trans + lay + t(e)or??)
- Translays is acceptable: easy to say and read (Trans + lays)
- Translayer is acceptable: easy to say and read (Trans + layer)
While as I said it's unforunate to say it loud (because of the current dramas in real life world regarding sexual identfication and the way the word could be mocked, maked fun of by writing it mispelled as trans slayer), it shouldn't be a real factor for considering the name of the term. This wouldn't be the first case in the world of neologism.
PhD in TASing 🎓 speedrun enthusiast ❤🚷🔥 white hat hacker ▓ black box tester ░ censorships and rules...
For me, it's not "technically-not-an-emulator", it's more like black and white picture is not colored one. Just because we want to call colored ones to be those with something other than gray.
I just want to mention that Wine doesn't only "translate" API, it also implements windows components like registry, edit box, combo box and etc.
It's more like windows API implementation - which is basically simulation (or pick any word you like) of windows API.
So, "API translator" is only partial truth.
Edit: something wrong below. I just don't know how win32 works under wine. Also some old wine can run 16 bit code, like 32 bit XP can.
Also, it has x86 x32 implementation for x86 x64 machines.
Isn't it then "technically-not-an-emulator-with-an-emulator-inside" then?
Joined: 4/17/2010
Posts: 11486
Location: Lake Chargoggagoggmanchauggagoggchaubunagungamaugg
Right, Nach said it's environment implementation, not just API translation.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
