Inventing on Principle

[Carver413]

Great video, I would like to implement some of these Ideas in my own code
http://vimeo.com/36579366



http://vimeo.com/36579366

[WILL]

He has some interesting ideas. I would be nice to have game development tools that act and behave much more like this than the completely separated code vs. concept approach that we usually start with.

[Carver413]

the framework I'm building has scripting built into the core so you can bet I'll be playing around with a few of these Ideas.

[WILL]

If you could create a game using a sort of 'Hypercard' type of design work for scenes, that would be awesome. :)

[Eric]

Tried something simple in the same vein for fun:
http://delphitools.info/2012/03/02/live-ide-scripting-for-dwscript/

[Carver413]

Nice work Eric

[Mirage]

The video is a nice demonstration of an extremely good implementation of data driven approach. Where the data is the code.
When I worked on particle effects for one of my games, the particles were driven by a script and I was able to change the behaviour in real time modifying the script within the game editor. This way I got very nice effects in very short time.
This is the reason why I think that a game engine should be built with a data-driven architecture an should have an editor with WYSIWYG capabilities.

[WILL]

Hey great proof of concept Eric!

I'm still wondering however if this can be applied to an OpenGL or DirectX environment. Mistakes, as you've mentioned in the post on your site, can happen and with an environment such as 3D/2D graphics processing could cause your system to suddenly slow to a crawl. Especially if it's an older or lower spec system.

I still like where this is going and would love to se more pick-up of the idea. Maybe a serious game engine or design tool of some kind?

[Eric]

Mistakes, as you've mentioned in the post on your site, can happen and with an environment such as 3D/2D graphics processing could cause your system to suddenly slow to a crawl. Especially if it's an older or lower spec system.

Indeed, all parts of the application you're testing have to be fault-tolerant (not to mention capable of getting restored from a known state in a quick and reliable fashion).

DirectX & OpenGL are not very tolerant indeed, if you mess up you can quickly end up in a crawl, using all memory or cause a system crash.

On the other end, this is an issue that is currently being worked on for the web-based 3D standards, because well, that's the main issue of WebGL (do a shader wrong, and the system will crawl/crash). So I guess it's only a matter of times before things evolve, there is a massive push in that direction from Apple & Google, and they arguably got a portion of 3D acceleration stable enough to be used in browser compositing (and the basic 3D stuff through CSS 3D).

The most problematic stuff is the lack in DirectX/OpenGL of constraints, such as memory limits, fill-rate limits or shader execution time limits, but that's something that could technically be introduced in drivers.

Another option could be a revival of fixed-functionality pipelines, but much richer than before, and where you would have all the common lighting and rendering techniques exposed.

That's somewhat the direction taken by CSS, and it has merit as it shoves the low-level hardware-specific complexity back in the hands of the drivers and composition engines, which is certainly more future-proof than all of the existing shader approaches (a bump mapped phong lighting will always be a bump-mapped phong lighting, rather than the optimized-for-special-cases-of-bump-mapped-phong shaders you see these days, that f.i. don't scale with an arbitrary number of lights, handle only point lights or parallel lights, etc.).

[WILL]

I was thinking that perhaps if there was a way to omit executing the potentially crashing/dangerous code and maybe highlight it in red or something until it meets up with a safe set of parameters. How restrictive those would need to be and what to restrict and what is safe could be a cause for debate.

I think in terms of OpenGL vs. DirectX some functions work well for this concept and some are more tricky to execute code in real-time. Perhaps for those tricky bits having some kind of special code block that won't execute until you close it would come in handy? This would prevent major mayhem when tweaking code that if done improperly or executed on the fly as you type would normally cause a ton of memory errors, etc...

But perhaps we are taking the Inventing on Principle concept too literally by going right down to API level...

[Eric]

How restrictive those would need to be and what to restrict and what is safe could be a cause for debate.
Well the other risk is that if you end up having to manually qualify and safeguard what is risky & what isn't, you could just as well end up spending more time doing that than designing, or end up with design tools that are too restrictive/specific to be more useful than a "classic" IDE or game level editor...

I'm thinking that this approach can only blossom if all the hard, low-level aspects are taken care of already.


But perhaps we are taking the Inventing on Principle concept too literally by going right down to API level...
I'm not sure: if you're using this approach to design a shader f.i., you'll have a few sample scenes ready, and will want to preview/tweak the shader interactively.

At that point, either you're only tweaking the shader parameters (and doing no better than what already exists), or you're editing the shader code itself, and seeing the results interactively, but that assumes your hardware can handle buggy shaders without crashing or locking up.

Even without interactivity, there is nothing more annoying when you're trying to tweak a shader than having the driver fold up and having to reboot. That has happened to me for all 3D APIs at some point or another, and it's not just frustrating from a design POV, it's also frustrating from a deployment POV, because it makes you wonder "ok, if this shader can crash my PC, what will it do on users machines with their outdated drivers?"

[WILL]

Well you could write a middle-layer for graphics that kept you from messing with breakable API code. Then just stick to that layer and you won't crash during development. You'd lose some low level control, but you do gain that added feel towards the creative hands in your code real-time effect that is what you are going for. I personally think that that's the only way. Until the hardware starts putting in safeties that will prevent hurting the drivers.

[LP]

Even without interactivity, there is nothing more annoying when you're trying to tweak a shader than having the driver fold up and having to reboot. That has happened to me for all 3D APIs at some point or another, and it's not just frustrating from a design POV, it's also frustrating from a deployment POV, because it makes you wonder "ok, if this shader can crash my PC, what will it do on users machines with their outdated drivers?"
Would you please share the shader code that managed to crash your PC? What operating system and API did you use?

[Eric]

Well you could write a middle-layer for graphics that kept you from messing with breakable API code.
Well, that's what ANGLE is trying to achieve (http://code.google.com/p/angleproject/ and http://blog.chromium.org/2010/03/introducing-angle-project.html), but they're not quite there just yet, and they still have to exclude a variety of graphics cards and hardware drivers for stability reasons.

I don't remember if FireFox also uses ANGLE, but I've read that both Chrome & FireFox perform extra checks on the shaders to try and detect errors the HLSL compiler and drivers don't handle very well (like http://www.gamedev.net/topic/579554-hlsl-shader-crash-in-dx9/).

But anyway, I'm hoping the push for stable 3D graphics in web apps will ensure that stability will happen, from the hardware vendors down, ANGLE & other middle-layers will (and already) have trouble keeping up with all the new hardware and driver revisions.


Would you please share the shader code that managed to crash your PC? What operating system and API did you use?

It was definitely nVidia, and crashing with either Cg & HLSL, I don't have the code available anymore, but it might have been a similar issue to the DX9 one I linked above, ie. an error in the shader code that wasn't reported correctly.

[LP]

It was definitely nVidia, and crashing with either Cg & HLSL, I don't have the code available anymore, but it might have been a similar issue to the DX9 one I linked above, ie. an error in the shader code that wasn't reported correctly.
It is weird since in 6 years working with shaders (both in FX Composer and directly) I've never had a video driver crash, let alone BSOD (I don't even know how it looks like now). Maybe I've been using a wrong operating system?

Seriously though, Cg, HLSL and GLSL are restrictive enough, there is little you can do to force the crash. Sure, there are ways to mess up with the API, but I don't think using badly written shaders is one of them.

[Eric]

but I don't think using badly written shaders is one of them.
Think again, just check the ANGLE issues tracker (f.i. http://code.google.com/p/angleproject/issues/detail?id=198). You can also have a look at the detailed driver release notes from nVidia, AMD & Intel. And if Google takes the trouble of maintaining hardware and driver compatibility lists for Chrome, believe me, that's not for the fun of it either ;-)

[LP]

Think again, just check the ANGLE issues tracker (f.i. http://code.google.com/p/angleproject/issues/detail?id=198). You can also have a look at the detailed driver release notes from nVidia, AMD & Intel. And if Google takes the trouble of maintaining hardware and driver compatibility lists for Chrome, believe me, that's not for the fun of it either ;-)
Then you should have stated that buggy software that tries to use shaders among other things, can crash PC, not shaders themselves. The link you have provided redirects to ANGLE issue tracking support. The only thing you prove by this is that ANGLE has issues but you did not address any of my shader questions.

In any case, ANGLE is just an application of Adapter (http://en.wikipedia.org/wiki/Wrapper_pattern) (or "wrapper" in some literature) software pattern. In no way it will help to resolve API issues as you are just redirecting OpenGL ES API, on top of which WebGL is based on, into Direct3D API. I think this will create more issues than it will solve.