x2mdo.exe (d3drm.dll)

#11
I will help you out when I get back tomorrow night ;)

Dont worry its a pain to figure out the first time, but it will be easy once you get all the right tools and junk.

The tutorial unfortunately is not to that step yet to cover custom graphics, however if you need info before tomorrow night, John has a great little document he sent me that he wrote about the different file types and programs needed to make custom graphics.
- Todd DuFore (DMPDesign)
Site Founder
Reply

#12
Have any luck with your custom graphic creation yet?

I wanted to know if the new tutorial section was useful or not.
- Todd DuFore (DMPDesign)
Site Founder
Reply

#13
^A little late but better than never...

I've actually been focusing my time on this in a round about way pretty much this whole time... at this point I'm less interested in making new graphics than getting the existing graphics out of SoM. Because basically I need them (or at least one) for reference to make sure everything looks right.

I was going to write a little custom tool to help decipher the files (or actually add a few routines to my usual homebrew graphics suite) ...but I decided I should be making good on that promise to remake SoM some, so I decided I will start working on that, and use it to visually decipher the graphics files...

So in a round about way I'm now working on finally getting this new virtual reality (development) environment to draw stuff (yes it technically does not even draw stuff yet)

The reason it doesn't draw, is because the system is supposed to be fully modular, and I'm taking my sweet time to make sure the thinking behind the module system is very sound. The trouble is, I want the system to have zero limitations. So in other words, if someone is willing to program a module (if necessary) there should be nothing the system can not be made to achieve. So the module interface is very wide open.

The environment is very complex supporting multiple "games" (or networks) and computing environments spread out across multiple machines and clusters of machines performing the same distributed tasks.

But basically the library that does all the drawing is also a module. I've already programmed the interface long ago for the first rendering module, called opengl-core, and defined how the low-level graphics server interacts with it (or technically does not interact - directly that is)

I tend to work in reverse from the more complex down to the more simple stuff, or in other words from the interface end down the implementation chain. But in short routing the modules through the library that handles them is pretty much the last step, and I'm making headway, and will hopefully have something to show after a little while. Patience is the key when it comes to designing/implementing very flexible (really futuristic) systems. It's really the opposite of what I did as a kid, just wanting to sit down and make some graphics popup. I did ground breaking stuff that way, but it's hardwired stuff more or less. Now I want to build (am building) wide open systems without limits.

So in short, I've given myself a very simple objective and have chosen the least direct way to go about achieving it Doh

I'm also doing this though, because I felt like SoM was subtracting too much from more substantial work lately.
Reply

#14
Dazed

Did you eat lead paint as a child?

If so, I want some!
- Todd DuFore (DMPDesign)
Site Founder
Reply

#15
^Is that what lead paint does?? Sweatdrop

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.


Attached Files
.png   prometheus-demo.png (Size: 117.2 KB / Downloads: 347)
Reply

#16
^Just because I said some crap, here is an old screenshot of the Overman gui (default) sort of at it's prime (it's a little stripped down these days as it's being rebuilt back up)

For some reason for a while the root hub (directory) name was being printed in the command prompt. I think now the root hub is named after the machine, but it isn't printed by default...

The crap in the background is just a window into my homebrew graphics suite which is actually a lot more sophisticated than most commercial suites in many ways... or at least I'm constantly running into brick walls with commercial suites, so I have to use my homebrew suite to achieve stuff they simply can't do (sometimes complicated most time really stupid stuff) ...plus I like rolling my own cause I like to use a flight simulator joystick for modeling, and for some reason that is a feature not really supported by any Maya/3Dmax suite I've ever worked with. I've never understood why people would rather break their wrists trying to rotate a model around with a mouse than fly around it with a joystick driven camera...

Anyway, first off, I said it looks better than anything out there... but in my defense I'm a hardcore minimalist. It definitely handles better, but whether it looks better (by default) is up to the eye of the beholder. It does a lot of technically amazing stuff no other OS gui does (Vista, Gnome, KDE, I'm guessing whatever OSX looks like)

Edited: The colour scheme is based on the background app. In this case the dominant colours are like the red to blue 3D glasses spectrum. On the other monitor would run a system graphing (debugging) application in the background and had a mintgreen/white scheme with red-orange selection hilight... very Ghost in the Shell if you've ever seen that movie... I'm sure there are plenty of screens of that as well.


Attached Files
.jpg   overman-2.1.06-lr.jpg (Size: 233.31 KB / Downloads: 381)
Reply

#17
From an early "PhysX" hardware evaluation project...

PS: I produced the models from scratch in two evenings Cool

Edited: Plays better than an Armored Core game in many ways. Tank handles better and the arms aim more realistically. The tank had a full physics simulation (could be flipped etc.) ...not so much luck with the biped.


Attached Files
.jpg   arcadia-ac-lores.jpg (Size: 226.03 KB / Downloads: 372)
Reply

#18
I must say, everything you do here is certainly impressive...

I wish I was on your level of thinking, I can't comprehend how an individual can just toy with all these programs and have that kind of talent to just pick up something and be able to figure out how it all works in a matter of days.

I don't think anyone here is questioning your devotion to your projects, and I doubt anyone is in a major hurry for your rework.

I can tell you from working on my game now, even with a tool as limited as SoM may be, it has taken me nearly a year to make my game. ‎  A combination of not having enough free time or concentration has a lot to do with it, but I can definitely say it will be a while before I am willing to start another game..so I would prefer the long wait for a better tool to do it with.

- Todd DuFore (DMPDesign)
Site Founder
Reply

#19
That's ok.... in the meantime then you can help with the "Maunstraut Redux" project Smug

I have been slowly trying to wrap my head around monster defense. But it takes a lot longer than offense because the game must be restarted every time you need to change the defense stat.

I also want to take another stab at locating the exe memory segments from the ddraw proxy I have. I didn't expect that to be so tricky. There must be a practical way of going about it...
Reply

#20
I've been going back and forth about how to do Sonellion's (hope I got the spelling right, been a while since I worked with DoM) armor. On one hand I'd like something interesting, but on the other I kinda feel like it would be more appropriate to just take the helmet and repeat it's elements until there is a suit of armor.

I kinda like the idea of making DoM out to be a monster world. I don't know how to explain that, but it's a kind of Japanese type genre that really focuses on the monsters as characters. And I sort of would like to make the armor a monster armor. But at the same time the designs I churn out, though good seem in retrospect over the top. It's sort of a good idea, hard to apply in theory.

Anyway, the last armor I designed is sort of obviously Cthullu-inspired, and I rather sort of think this design could make it off the drawing board if I can tone it down enough. The Sonellion set is basically the dark armor set. That is it's main strength is protection from the dark affinity, which as you can guess is not uncommon. There is a more dark set that is more traditional, but the Sonellion set is better well rounded, designed for end-game wear.

Anyway, long story short.... the body armor part of this full body equip set with this design reminds me of the "dark armor" from KFII (w/Melenat) ....So like, I figured might as well kill two birds with one stone, if I go this route, and just remake that armor for SoM. I had found a Japanese website with screenshots of all the KFII equips (I think it had all) via Google Images, but I can't find it now. I sort of wish I had bookmarked it. In general it was the most complete Japanese KFII guide I've ever stumbled across, so maybe someone has a link. But anyway I wanted to find an image of that armor, but I will just describe it to make sure we are on the same page. Basically it's the upper body piece only armor you find in one of the caves later in the game. In the US game I think it was just called "Dark Armor" ...possibly found in the "Dark Cave". If my memory serves me at least the design is very similar to what I have in mind, so I was hoping Todd could maybe somehow give me more info and one of his model rips from KFII for it.
Reply





Users browsing this thread:
2 Guest(s)