Author Topic: A demotool  (Read 3070 times)

0 Members and 1 Guest are viewing this topic.

Offline efecto

  • C= 64
  • **
  • Posts: 90
  • Karma: 4
    • View Profile
A demotool
« on: April 01, 2011 »
First of all I would like to appoligize for not participating in the destruction competition.
I had something coming allong but then work gave shit and after that the appartment I rent gave shit so time ran out.
I really wanted to participate so I'm sorry  :-[

The thing is, like all of us, I lack time.
and I don't have a framework where I can test effects quickly
so therefor I've decided to concentrate on DX11
I've decided to write a tool in C# using SharpDX so I can at least develop some effects quickly

Now,
The thing I'm struggling with is the level of detail.
would a tool go to the level of setting rendertagets and texture inputs or just predefined effects with configurable parameters?

and how would one set all this out against a timeline?

sorry again if this post sounds silly :(


Offline hellfire

  • Sponsor
  • Pentium
  • *******
  • Posts: 1294
  • Karma: 466
    • View Profile
    • my stuff
Re: A demotool
« Reply #1 on: April 02, 2011 »
You have to find a reasonable compromise between complexity, usability and profit.
I always kept effects hardcoded but export all adjustable parameters (colors, speed, etc) by a common interface so I can change them while the effect is running.
Additionally I use a notificator for the file-system so a texture updates automatically when I save it in photoshop.
This avoids most of the rather tiresome "change some parameter in the code, recompile, watch again" sessions.
Challenge Trophies Won:

Offline Xetick

  • Atari ST
  • ***
  • Posts: 132
  • Karma: 80
    • View Profile
    • Plane9
Re: A demotool
« Reply #2 on: April 02, 2011 »
I know the feeling. Without my tool/framework I would never have been able to create my entry in time.

For starters plan ahead (as you now do) but dont set your goals too high. If you do you will just end up trying to create a tool for the next 3 years.

A good start would be to limit turn around time as much as possible, like hellfire said. Do the same for effects so as soon as you save the effect it is refreshed. I would even start with that and skip the exporting of effect parameters and building some gui around that. I found it even more useful to realtime compile effects. So whenever a change happens the effect is updated. That way you can quickly test any parameter and not just the ones you have added to you export list. Need a inbuilt text/effect editor for that though.

I would leave the rendertarget and texture setup out of it for starters. If you notice that you then often add and remove rendertargets/textures in a shader then you can add the support to dynamically add them.

Regarding timeline I would probably not add it into the tool since it would be too much work for what is the final composition. Since a bunch of effects can be time dependent (physics and such) you need to play the effect from the start anyway. So doing that final composition in code is probably good enough.

So start with something simple and after you have used that for a while you will know what's missing since we all work differently.
Plane9 - Home of the Plane9 3d screensaver/music visualizer
Challenge Trophies Won: