Great video, I would like to implement some of these Ideas in my own code
http://vimeo.com/36579366
Great video, I would like to implement some of these Ideas in my own code
http://vimeo.com/36579366
Last edited by WILL; 26-02-2012 at 02:10 AM. Reason: Embed, embed, embed! :)
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.
Tried something simple in the same vein for fun:
http://delphitools.info/2012/03/02/l...-for-dwscript/
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.
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?
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.).
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...
Bookmarks