2009-08-01, 06:39 AM
^Is that what lead paint does?? 
I dunno, just felt like I should make up some sorry excuse for not appearing dedicated to the cause here lately...
I am really supposed to be working on this crap. A demo of all this work would be nice, but I really want to demo the VR platform, which is pretty separate from the operating system component which is pretty well developed at this point (and obviously I need visuals for that)
I will attach a sort of illustration I clambered together once with Inkscape to help visualize my design goals for the low-level graphics server named Prometheus (it's name is longer than the others' so I'm thinking "Promeus" for short)
FYI: Servers represent services, which are given proper/capitalized names, because they represent an entity on the network which can have all the power of a person/user. The opposite is utilities which operate on behalf of a user (they are an extension of the user)?
Anyway, basically the whole system is called Arcadia... also the name of the business I'd like to startup eventually. The operating system is separate from that though, something I basically had to develop because no existing operating system could satisfy all the requirements I felt were outside the scope of Arcadia's function. The operating system code name is Overman (named long ago after the god-planet in the Armored Trooper Voltoms manga/anime serial -- because I thought, damn if that doesn't sound like an operating system name) but anyway someone later pointed out to me Nietzsche's Ubermensch, which was undoubtedly the source for Voltoms... but anyway, it's audacious but there is a good chance Overman will be the final name of the os. It's a truly nerdy system, really designed to look like every futuristic sci-fi computer system you ever saw in the movies, but at the same time not just cosmetic... but anyway, point is it's not a domestic/your grandma's computing environment.
Anyway asides aside, the diagram is basically a mockup of what the casual game designer would see if they really want to customize their game (erhmm, virtual reality experience) ...the actual Overman gui looks way better than this, better than anything really, but I haven't added the user interface for this stuff yet. Anyway, really any high-end animation suite designed for like CGI movies has something like this builtin to it these days, but the diff here, is generally this system visualizes everything that goes into a game, makes it visual like hooking up a home entertainment system, and let's you pick and choose and customize what components you want (make new ones from combining or programming new modules if you're a programmer) ...and finally compiles it all together so your final system is not bloated, but just has the parts needed by your game. Basically it's a "game engine" "engine" so to speak.
Each block is called an effect (or fx) and each word group represents an "image", the wires connecting are "filters". Once you have all of that you get a particle (or pk) or in other words the entire environment is conceptualized as a classic "particle effects" system. The wires with the blue stripe are purely software I think. And the green represent once you get into stuff that depends on the hardware environment. Like your opengl or directx drivers. So basically a game can support different profiles which are pretty much predefined, or must at least be supported by module programmers. So like if you add an effect to your game that only supports opengl and not directx then your game can't support directx, unless maybe you can make that effect somehow optional to the game.
This is just how the graphics/sound/physics work in the VR environment. Stuff like driven animation is actually builtin to the operating system. Like the os has a concept of a "virtual device", which is also a node in the "virtual network system"... nodes are like files only way more sophisticated, that is a file is just a tiny subset of what a node can do (sounds alien to Windows users, but Linux has the basic concept of a node builtin) ...but anyway so a virtual device is a node that also has a driver and an interface that represents the sort of stuff you think of in a real device, like a telephone has buttons and inner workings, some exposed some not, some that can be exposed if you crack it open. Anyway so like the arm in a KF game that swings the sword you can think of as a virtual device, or maybe even a few devices linked together (depending on how sophisticated a simulation you're going for) ...so the device is part of the operating system, but the Prometheus server actually attaches the visuals and geometry you want to it. But anyway, like scripting like telling the arm to swing is all fully integrated into the os. And users are even a special class of nodes said to be "mobile". And the player can be thought of as a mobile node as well that a person at a physical computer logs into. So like your entire game environment can be thought of as something like a filetree. Like one level can be in one directory and another in the next. And say a door is a link into a different directory... nodes have the concept of a barrier, the simplest example is asking for a password, but a barrier can be anything like say pressing a key on your keyboard (no internet hacker could do that) ...or crossing thru a doorway in a VR game.... blah blah blah...
Anyway, I programmed the compiler that compiles this stuff like a year or two ago, but ironically haven't been able to setup a proper demo just yet due to major side tracks elsewhere...
Edited: So like making this diagram below accommodate a mdo file is just a matter of changing the value of the "specs:" image in the top left corner to read mdo (Sword of Moonlight) or whatever. Though since SoM is pretty esoteric I'd probably just make a custom effect for it that would support all the different SoM file types and replace the Import effect with that one. That's actually how I will start deciphering the files, by hacking away at that effect until it comes out the way it should.
PS: If you look at how the Import effect works, it's really modeled after a command line application. I will eventually write the same application to be used to export your som files to some other format, like that evtcat commandline app I cooked up for events.
I dunno, just felt like I should make up some sorry excuse for not appearing dedicated to the cause here lately...
I am really supposed to be working on this crap. A demo of all this work would be nice, but I really want to demo the VR platform, which is pretty separate from the operating system component which is pretty well developed at this point (and obviously I need visuals for that)
I will attach a sort of illustration I clambered together once with Inkscape to help visualize my design goals for the low-level graphics server named Prometheus (it's name is longer than the others' so I'm thinking "Promeus" for short)
FYI: Servers represent services, which are given proper/capitalized names, because they represent an entity on the network which can have all the power of a person/user. The opposite is utilities which operate on behalf of a user (they are an extension of the user)?
Anyway, basically the whole system is called Arcadia... also the name of the business I'd like to startup eventually. The operating system is separate from that though, something I basically had to develop because no existing operating system could satisfy all the requirements I felt were outside the scope of Arcadia's function. The operating system code name is Overman (named long ago after the god-planet in the Armored Trooper Voltoms manga/anime serial -- because I thought, damn if that doesn't sound like an operating system name) but anyway someone later pointed out to me Nietzsche's Ubermensch, which was undoubtedly the source for Voltoms... but anyway, it's audacious but there is a good chance Overman will be the final name of the os. It's a truly nerdy system, really designed to look like every futuristic sci-fi computer system you ever saw in the movies, but at the same time not just cosmetic... but anyway, point is it's not a domestic/your grandma's computing environment.
Anyway asides aside, the diagram is basically a mockup of what the casual game designer would see if they really want to customize their game (erhmm, virtual reality experience) ...the actual Overman gui looks way better than this, better than anything really, but I haven't added the user interface for this stuff yet. Anyway, really any high-end animation suite designed for like CGI movies has something like this builtin to it these days, but the diff here, is generally this system visualizes everything that goes into a game, makes it visual like hooking up a home entertainment system, and let's you pick and choose and customize what components you want (make new ones from combining or programming new modules if you're a programmer) ...and finally compiles it all together so your final system is not bloated, but just has the parts needed by your game. Basically it's a "game engine" "engine" so to speak.
Each block is called an effect (or fx) and each word group represents an "image", the wires connecting are "filters". Once you have all of that you get a particle (or pk) or in other words the entire environment is conceptualized as a classic "particle effects" system. The wires with the blue stripe are purely software I think. And the green represent once you get into stuff that depends on the hardware environment. Like your opengl or directx drivers. So basically a game can support different profiles which are pretty much predefined, or must at least be supported by module programmers. So like if you add an effect to your game that only supports opengl and not directx then your game can't support directx, unless maybe you can make that effect somehow optional to the game.
This is just how the graphics/sound/physics work in the VR environment. Stuff like driven animation is actually builtin to the operating system. Like the os has a concept of a "virtual device", which is also a node in the "virtual network system"... nodes are like files only way more sophisticated, that is a file is just a tiny subset of what a node can do (sounds alien to Windows users, but Linux has the basic concept of a node builtin) ...but anyway so a virtual device is a node that also has a driver and an interface that represents the sort of stuff you think of in a real device, like a telephone has buttons and inner workings, some exposed some not, some that can be exposed if you crack it open. Anyway so like the arm in a KF game that swings the sword you can think of as a virtual device, or maybe even a few devices linked together (depending on how sophisticated a simulation you're going for) ...so the device is part of the operating system, but the Prometheus server actually attaches the visuals and geometry you want to it. But anyway, like scripting like telling the arm to swing is all fully integrated into the os. And users are even a special class of nodes said to be "mobile". And the player can be thought of as a mobile node as well that a person at a physical computer logs into. So like your entire game environment can be thought of as something like a filetree. Like one level can be in one directory and another in the next. And say a door is a link into a different directory... nodes have the concept of a barrier, the simplest example is asking for a password, but a barrier can be anything like say pressing a key on your keyboard (no internet hacker could do that) ...or crossing thru a doorway in a VR game.... blah blah blah...
Anyway, I programmed the compiler that compiles this stuff like a year or two ago, but ironically haven't been able to setup a proper demo just yet due to major side tracks elsewhere...
Edited: So like making this diagram below accommodate a mdo file is just a matter of changing the value of the "specs:" image in the top left corner to read mdo (Sword of Moonlight) or whatever. Though since SoM is pretty esoteric I'd probably just make a custom effect for it that would support all the different SoM file types and replace the Import effect with that one. That's actually how I will start deciphering the files, by hacking away at that effect until it comes out the way it should.
PS: If you look at how the Import effect works, it's really modeled after a command line application. I will eventually write the same application to be used to export your som files to some other format, like that evtcat commandline app I cooked up for events.