pouët.net

Demo engine design

category: general [glöplog]
 
First of all, all respect to guys who do ad-hoc code for a single demo. I don't have time to custom code for every entry and i'd like to do some code which isn't obsolete in half a year.. And the word "engine" in this case is a studip word anyway, but..

I'm planning to do one more engine for the group, that may well be the last one I do. Easier the better. For pipeline I'm thinking to use FBX for intermediate format, and then maybe the directx sdk conversion tool (which seems to be designed for xbox mainly) and then through custom conversion to dump the binary.

Our previous dx9 engine was very lightweight with configurable by xml. Demo timeline, shaders, materials, animation curves and all. Worked pretty well, but most of the time went to fiddle with the xml (by artists)..

For my next engine attempt, I guess it should be dx11 with feature levels down to 9. The core should again be very ligweight but flexible. So I must have scripting support, which I dont have that much of experience. I know this generic shit is slap on the face of demoscene, but the core should be flexible enough to do shit without always hacking shit. Meaning I'd rather have focus on easy iteration on effects than some 3d engine..

So my questions are:

--

What scripting language is used now and would be good to support? I'm thinking of LUA or Python.

Is there some tool for artists to create spline curves? Not hard to do such editor but haven't found some or wouldnt want to do excessive work..

We have had archived all the data in to a single data file. Would it be better for all to see our sources? I dont mind others to see, but We've had one to rip our scene from one another demo..

If and when it's done, should I just give the source code, executables and pipeline tools for everyone? I don't see the harm in that.



added on the 2010-06-25 01:52:13 by Codarki Codarki
I think i came short about the talk of real desing of the engine. I think i'll just go with raw GPU power. I might have not time to do all the optimization tricks like frustum culling in cpu or hull shader..

I'm going for deferred renderer, seems lika a safe bet. Light pre-pass renderer is cool and an option but maybe somewhat limiting.

Maybe going to try mutithreading but CPU hasn't really been an issue at demoscene.. If I do, I'll subdivide the scene graph to independent cores without any data dependencies..

Anyways, I'd like to hear more from other coders around here.
added on the 2010-06-25 02:20:11 by Codarki Codarki
use werkzeug.
My advise: only create a generic engine if you have people willing to actually use it. You might think you'll save time in the long run, but most likely you won't.

I would recommend you to rather just write your first demo, use GNU Rocket to control it (which is what you would use for scripting anyway, if this was 2002), and when the time comes for your next demo, re-use what you did for the first demo and just add on new stuff when needed.

You'll save time, energy, and you'll end up making more demos.
added on the 2010-06-25 09:45:42 by gloom gloom
I kindof agree with gloom in that engine/tool development should be organic.
It's probably only the hardcore/foolish who actually throw away all of their code each time and start from scratch, and we certainly have a massive toolset and engine that have evolved through refactoring and reorganisation iteratively since .. 2002?
However, the main thing to remember is that 3d engines, renderers, scripting and multithreaded scenegraphs don't make demos. Not anymore anyway I hope. :) You should add that stuff if/when you need it, not because you think you might one day. Don't spend a lot of time with your 3d asset pipeline if you don't have anyone making graphics for you. Don't bother writing a multicore scenegraph if you only have 100 nodes per scene.
That might sound like dirty democoders hacking stuff together, but actually it's the best old fashioned software engineering principles at work: do your requirements analysis, then write what you actually need.



added on the 2010-06-25 10:23:07 by smash smash
And btw - I rate the quality of my own engine and toolset not by the number of features etc they have, but by how flexible it is - much work / pain it is to add the new things I want to add, how easy it is to grow it and experiment.
added on the 2010-06-25 10:25:31 by smash smash
what gloom said.
added on the 2010-06-25 11:11:04 by psenough psenough
I am testing your engine.. let me know when it is ready to use!
added on the 2010-06-25 11:22:47 by omg omg
Reusable, reliable components have been a useful thing. At some point it was apparently fashionable to write a huge demoengine that the artists were supposed to use by scripting. I tend to think you'll end up with substandard results anyway unless there is a coder involved in the productions. To make scripting really work one would need to reveal a lot of functionality to the scripts and that's in a sense just extra work if you end up writing the same things in the scripts that you would have done in C/C++. Some people really like crafting their engines for years, but engines are not demos - at least for me the only interesting thing about demo coding is creating new effects.
added on the 2010-06-25 11:47:15 by Marq Marq
my approach is to write a core of stuff you always need (math primitives, render context for easy/easier rendering/setup, integration for audio stuff you need, specific allocators, some standard shader, file i/o)

then, i have a utility layer with stuff like particle renderers (generic, so input->screen), demo resource loaders (with possible loadfrom/storeto archive file), perhaps some cool blitters, 2d postprocessing shaders/rendertarget management etc

and then on the third 'line' i build my demo using components of the aforementioned two (and the contents i named for them is just a ballpark of course)
added on the 2010-06-25 17:07:38 by superplek superplek

login