Blue Dragon - XBox 360

Well, that was fun. Learned a few things too.

1. Mesh data stored in the XBox 360 is identical to all other formats that you expect in a high end graphics application; Specifically, large VA/IA arrays and a nicely formed VAO with a geometry shader system for handling matrix weighting/radial basis. No surprises.

2. Textures are still DXT1-5 style blocking, but arranged differently in memory. Uncompressed normal maps.

3. Meshes seemed to average ~10k polygons, and have ~170 bones apiece. Level of complexity requires on-GPU processing; may have special hardware for this, like OpenGL 3.0 or DX 11.

I like the style for this game. Internally, it's fun and NPR; high enough resolution to some really cool animations. It was hard to find a lot of information about it though.

Also, I found out my older ripping technology had a bug; and now all of my models are 100% spot on with weights, which means it's identical to the in game data for just about everything else I have. Which is really neat, now I can learn a whole lot about how Monster Hunter 3 animated their creatures so well, and how poorly some other games did the same thing

It's like having the coolest action figure collection ever!


-Z

Zoning

It has been a long time since I posted.

I've become far more proficient at modeling in blender.

Also, I've improved the DXML format to the point where it writes C/C++ code automatically, and is far more stable, fast and simple. In fact, DXML seems to be my new "does everything" format, because unlike XML or other bullshit standards, it's lexically simple and forces you to write better file formats. Which, it turns out, are directly C-struct translatable. Also, it has less possibility of confusion or errors due to it's very strict nature; and as a result, makes you far more intelligent.
The downside is slightly larger files, but when you are dealing with a text file, you want it to be comprehensible, not efficient. DXML files are built for comprehension and logical structure. They're perfect!

Also, the TED format has been getting a lot of attention and improving, I've added scripting to animations, so now attack animations can contain code (lua) so that punch animation can mean something.

Also, I embedded Lua into my programs, now I can script (safely, mind you) so extensibility is fast simple and external; allows for a lot of flexibility, and as all you truly experience programmers know, a script is only as powerful as the core that drives it. In this case, core handles a lot of things normal engines like Unity, Blender, Torque, and many others do NOT handle. No surprise; you're supposed to extend those engines in C/C++ code anyways. Most of them are also not built for magnitude/scaling either.

So, with all these improvements, the focus has been on scene management; ted files provide a vast array of graphical and animation data; they also now provide zoning information, which is used to reduce collision requirements and provide an effective scene graph that can be non-spatial (a critical requirement for adventure clone!)

Here's a rough idea of what "zones" and "zplanes" mean, in terms of blender; In text, a zone is a axis aligned bounding box (AABB) that contains a list of objects that intersect it, and a list of other zones that intersect it. A Zplane contains a reference to two Zones, and a position and matrix, used for culling.

Until next update! Maybe we'll get a video of some in-game action.

-Z

Game Physics - We got balls

Summary: Game physics works per frame, and is discretely accurate. Normal physics engines simulate real physical principals, and do integrate. Design is what keeps your game from having errors, not the engine integrating better / more accurately.

Game Physcis. The long debated quitnessential problem with most all games. Do you take an existing physics engine and force it to work the way you want? Or do you roll your own collision system for perfect accuracy at the cost of far greater development time?

Obviously, I chose to roll my own since I've never seen a "game" physics engine. I've seen bullet, novodex, Aegia PhysX, ODE, tokamak, Newton, ect... and they all attempt to be "physics" engines, not game physics engines.

What is the difference between a physics engine and a game physics engine?

• 1. Game physics do not model reality; they model fixed frame impulse systems; IE they are not time based.
• 2. Game physics generally have multiple levels of physical objects, static objects are handled vastly differently than dynamic objects, and objects that have one way interactions are handled differently still.
• 3. Game physics trades accuracy for quantity & speed. Also, their accuracy has no real physical model to use, other than the most basic physical principles (ray reflection, momentum, mass)

So, the worst part about rolling your own (maybe 500~ lines of code if you're good) is the geometry. The nastiest part about any collision engine is simply generating all the 'trivial' geometry intersection and distance functions you will need. I've consulted more than 3 PhD mathematicians on this subject, and none of them were able to solve these "trivial" problems. And these guys are seriously brilliant professors! So don't arrogantly think that these are ever trivial questions to ask; they only appear trivial because the solution seems so logically simple. Much like, if you asked what the arc length is on an ellipse. Seems innocent enough at first, go research it.

Also, game physics use special models of collision, specifically the ray-bounce-slide model, so you character will slither along corridors and walls with great clarity and smoothness, and essentially have perfectly inelastic collisions with just about everything. Lots of optimizations present themselves for broad phase testing, especially when you break up the static / dynamic environments.

So for my purposes, I made a simple little game physics engine that lets me run objects like I would expect them, it's discrete time stepping, fully consistent, but it does allow something I have always hated, which is possible penetrations. I'll have to think more to figure out how to integrate that type of dynamic into a system like this, but the truth is, if you have dynamic/dynamic object collisions, there are very few ways to solve them (refer to the classic 3 body problem, and enjoy your porkchop with cyclic coordinate descent.) So, stepping your dynamics works against dynamic objects, but you can make much more accurate collision assessments against the level. But wait! if you set your steps and velocities right, guess what? You can just completely ignore that problem all together. 

Game physics doesn't rely on correct simulation. It relies on correct DESIGN.

Your levels, collision areas, rooms, whatever; If they are designed right, you can make it so they can't mess up on the even inaccurate stepped integrations. So, it's never been a question of 'physics engine', it's only been a question of how smart you really are when it comes to designing the actual game. This would be called 'cheating'.

The difference here, is all of this is a beautiful, easy to plug into anything C/C++ class relying on the core components I have made.

Here's some balls moving around in the physical simulation. Note the time in the upper left (milliseconds / FPS) and the quantities of object in the upper right. The broadphase method used is taking a bounding sphere for each object, then calculating the best axis based on the minimum position along x,y,z axes (O(N)) using the in-line variance sum ( 3*O(N) ), then taking that axis, and making a vector with all the minimum positions and pointer back to the object, sorting (O( log2(N)*N )), then running along that sorted interval list, and testing all unique overlapping interval pairs (O( N * m ), m is far less than N). This methods worst case is N^2, as in all broadphase systems, and it's best case is O( log2(N)*N ) because of the sorting. It performs very well and has no physical size restrictions, and it can use AABB's instead of spheres for greater reduction to m.

Data & Geordi - Shuttle Rave YTP

 IN CASE YOU DIDN'T NOTICE:



This is actually my first Vegas Project ever. So it's not that great.

(WILL FIX TOMORROW; Apparently codec was broken...)

A preview of things to come. Some (very bad) Editing, this is still 100% raw footage.

Star Trek : The Next Generation Season 3 Episode 08 - " The Price"

Music: http://www.youtube.com/watch?v=Nl4opbNt8_E

Dream - Flying n' Dragons n Stuff'

Dream 2010-06-12

There was some buildup; apparently something like a generic medieval fantasy plot; some random magical overlord type creature was taking over the generic kingdom and enveloping it in generic darkness and distributing generic dark villains over the generic lands. Generically.
Well, me, mike, reed and zach were armored up to fight these things (These cool black-obsidian armor suits with colored light beams), and went about doing so. Running around the countryside, slaying doom-like demons and monsters with powerful weapons; well eventually we got into a castle, and ran through it mario galaxy style, eventually finding the end boss and kicking his ass easily. As a reward, it dropped this strange silver hang-glider looking apparatus; which, allowed you to glide-fly.
So, you don the thing, and it spreads out like a pair of batwings/batman style. At that point, if you get a good running start, you generate enough lift (somehow) to go airborne, then you hand glide to gather height and momentum. I believe it had some sort of futuristic scram-jet on the back of the unit, because you were propelled quite fast, fast enough you would actually fly (airspeed) even in real life.
Since I happened to be the plane guy, I tried it first. It was amazing.
No dream about generic flying could beat this; I could run, jump and take off into the air, gliding with minimal effort, flapping my wings if necessary for a quick change in course. It was like being a bird, you could soar over landscapes, dive down through rings and even shoot your enemies down while flying. With practice you could gain altitude in any condition as well, so there were no gliding limitations.
Well, we had to go onto level two, so I was designated "dragon-man" because I could fly + shoot plasma via plasma rifle. Level two was much harder, and required some tricky aerial switch throwing, IE dropping bridges and the like to allow the companions time to maneuver over. At this point, things got difficult, and we were forced to split up, I solo, and the other three as a strike force on the ground. I flew on ahead, taking out defenses and barriers from above, fighting some of the larger sky-predators as well. The ground team pressed down into the caverns to destroy the generators powering the evil machines that created force fields and creatures.
Eventually, I got bored of being a human with a flying suit, so I typed in a cheat code and just became a dragon instead. A big red cartoony looking one, was pretty strange. (Kinda, I have a model I made of the exact creature) Technically, no abilities changed, except that shooting plasma/fire was much more powerful and much faster, although I had a shot-cap, so I couldn't fire more than 8 fireballs at a time, like old arcade games.
Being the dragon, I could maneuver in the air way easier, and hover if I needed to, plus gain a free attack bonus on everything I did, and intimidation for lesser enemies. After assaulting the tower, I flew down into the caverns to rejoin my team; turned out they were doing just fine even without flying ability, so when I met up with them they kinda freaked a little, but figured out it was me pretty quickly. (cue mustache gesture)
Then, we tag teamed moving up this complex twisted tower, full of odd gravity puzzles like super mario galaxy, moving blocks, fighting vastly upgraded iron knuckles, hitting switches, fending off mobs, solving puzzles... It had just about everything you like to do in video games, but a flexibility in approach that was unmatched by any. You could kill all the enemies, use the environment to your advantage, negotiate, threaten, or even just slip by unnoticed. There was no set "objective" to complete except the main one, although every decision had consequences. Eventually, after winding up this long tower, we came to an impasse; The only way to go was up, and I couldn't carry anyone thanks to load restrictions (wasn't THAT great of a dragon).
So I grabbed an extra gun, and went upward to fight the boss myself. Turns out, it was some generic lich demon that had no real purpose in taking over the world. I'm sure it explained some crap to me, but I just shot at it instead of wasting time talking. It ran around like the end boss (The Campaigner I think) in the N64 Turok game; Was very hard to hit. Eventually he went down, but then morphed into this giant darkness form; And began the generic projectile-pause-claw swipe-pause-vortex loop of attacking. However I was privy to physical knowledge, it never was able to even hit me in that form, and eventually gave up on it and morphed into it's TRUE form, which was some weird looking alien-dinosaur skeleton with rotted flesh dripping off it (think Odin Sphere's King Gallon). That made the fight hard, since I had trouble determining the weak spot without an obvious bright red heart to pummel. Eventually I gave up because plasma and fire was useless, and just physically tackled the thing and tore it's head off; instantly killing it but making me lose dragon powers and flight wing just like mario when he collides with an enemy.
So there I was, atop the tower splattered with rotted blood, rifle scattered on the ground, darkness turning to light again, and no friends nearby (they can;t get up the tower, lol). I just looked off into the distance wishing I could fly again, because that was freakin awesome.


I was *about* to re-don the flight suit, but then, horror of horrors:

The cat woke me up. I took every measure to prevent this from happening. But it still meowed and woke me up anyways.

$@#^*(#$& Data.

-Z

GHOST, Mingl, XCore, Core, XGFX

Continually working on improving all the above components;

Here is a quick overview of what all this garbage is:

ghost - Lets you make programs for X11, Windows, Mac
mingl - Draws stuff in hardware lingo
core - Does everything you don't want to write yourself
xcore - Does things you should be doing anyways
xgfx - Makes everything look pretty + move around

In more details:

GHOST - Made primarily by the Blender.org guys; this is their generic host operating system toolkit; In other words, this is the code that allows you to receive low level input events and a OpenGL context; And the ability to create windows and draw to them/receive messages from them. I've heavily modified it to include some more game-friendly features, timing looks, multithreading and some specialized input event abstractions, joysticks support and other goodies. It's at least as good as SDL, and in many ways, far superior. Hard to find something better than code that has been attacked by many people.

Mingl - "Minimum Graphics Library"; essentially a wrapper around OpenGL; but, it's designed to specifically mimic OpenGL 3.0 specifications, and does an insanely good job of managing more annoying aspects of OpenGL programming; It makes writing graphical routines trivial, where you may spend hours trying to orient yourself in 3D space using any other toolkit (that includes you, blender. F*** your armature space conventions!). However, it's also interface abstracted just like GHOST, so it can use OpenGL, DirectX, software... it doesn't care. But it is primarily designed to expose low level hardware techniques to force you to write more efficient graphics code; and does a ton of things internally (like managing VBO/IBO/RC, states, transformations, ect...). It is still missing FBO operations, but those are trivial if you have a GL 2.0 + system (just need to sit down and do this)

XCore -  Operating system and hacking level tools. A quite extensive library I made of tools I use frequently, such as texture conversions from DXT to / from anything, mathematical algorithms, VA/IA generation algorithms, numerical methods, statistics, even some unique IK algorithms and other tools. IT also contains agressive memory management and a slew of commonly used structures.

Core - The heart of everything; Based on the std C++ library; core contains separate components that should not rely on any one other component, like vec3 vec4, matrix3x3, matrix4x4, index_array, geo, and a lot of other commonly used, but often not needed tools. Chances are if you need any one of these tools, you need all of them.

XGFX - My rendering system built ontop of using mingl as the renderer interface. IS still under construction for the resource abstraction and management of massive resources.

No good screenshots; Just the city level again after implementing multithreaded loading + mingl improvements.

TED Exporting + Mingl

"Walk the Walk"

I talk a lot of smack about things that I do. It's really nice when I visit artists that I can actually pop open their files and show them how to export them so I can load them in game.

It's much easier to convince people you aren't just blowing smoke when you can show them what you are doing in real time. Hard to dispute that kind of presentation.

So, more improvements on the TED file's; the exporter is more robust, and I'm in the process of verifying the data output is correct. So far this seems to be true, I've seen textures, models, scenes, and just about everything in the file working perfectly, especially animations. It's wonderful to just be able to load in a file directly exported from blender, and import it, then see your work immediately and accurately duplicated in a realtime game.

So here are some example shots; the next long haul is building the xgfx resource management system so I can maintain a logical coherence for all of these vastly different resources + files. Resources are essentially reference counted, but are not cleared until flagged to do so. Instance objects exist physically, so once they terminate they just dump all data. Plenty of re-use optimizations, tons of weird paradigms like "resource-source-instance" ideas with meshes; But this will be demonstrated eventually.

In order from top left clockwise;

Rayne from BloodRayne on PC with a static keyframe applied,
two of my custom levels,
Charizard from Super Smash Brothers Brawl on Wii with standard_wobble applied and hacked texture
another custom level,
The first boss from Dragon Blade on Wii, with wobble, note the material colors are showing now; easily removed.
Bowser Trophy from Super Smash Brothers Brawl on Wii
Rayquaza Boss from Super Smash Brothers Brawl on Wii with wobble.

Looks like I need a damn artist.

-Z

Fencing - Problem Solved

4 days of brain bashing of a very complex error to track it down and slay it.

At first, the program would crash if run outside of debug mode.

"Okay, so it must be a memory overrun, and I'm writing past the end of the array, because the debugger puts padding for detection against clobbering memory"; which looks like this:

uchar myarray[ 10 ];
myarray[ 10 ] = 60; //WHOA, myarray holds 10 ELEMENTS, so position 10 is the 11th element.

Often called a fence, I couldn't find it. What was weirder, std::string was throwing errors. std::map was having kittens. and ntdll seemed to vomit all over the floor at this party from hell.

As I burrowed into the code, seething rage ignited; was I being burned by out of date compilers? Was my code wrong? What had I done? What had THEY done wrong?

This project had it all, nested complex templates, deep inheritance heirarchies, large blocks of data and nasty C algorithms. Luckly, most of my (good) code has __debug_regression defined, so I was able to quickly rule out very large segments of code against error with a single look back at passed test dates.

But my mind was going, Dave.

I ignored the fact that if my code worked in debugging, then only the heap allocation method would cause 0xc0000005 errors thanks to ntdll 's nice memory bounding protection (mainly protects it from 0xBAADFOOD but yeah)

So, I eventually upgraded my compiler, my debugger, brought in the help of my custom designed memory heap manager (igtl_MMHeapSystem; I love you, I LOVE YOU! OH GOD YOU'RE SO SEXY MMMMM*codepronz*) and tracked down the offending bug. Hours of poking and prodding landed me with a really surprisingly simple conclusion.

I was off by one.

I'd been accused of being off kilter, off base, and not even on this world, but one? Off by one causes these insanely weird errors? Why did the debugger not detect the stack corruption? Why did the heap manager skip telling me I was writing one integer past my array? Why did absolutely none of the tools find this till I made my own?

Here's why:

When my array was writing past the end of it's detection, it wrote (coincidentally) over the bad food word. But, in the running of the program, that error PROPOGATED until some time later, when the error detection actually scanned memory; because no one in their right mind scans every single memory allocation (super slowness). By the time a scan actually occured, it was too late and bizzaro values had multiplied. But only in a small well contained region. That is, inside of a system dll I don;t have debug points in. Ironically, since the error affected nothing else in MY code, it really screwed up ntdll, and cause it to throw weird errors all over the place.. So, my code was just missing a +1, but the stack was being blow to pieces thanks to trying to protect itself.

Moral of the story?

Make sure to take a nice drink if you run into a hard problem. Usually, it's just something stupid. I use High Gravity Steel Reserve.

-Z

Here's some preliminary results with a nifty 3 instruction toon shader I made: (<3 Mecha Dragon)