pouët.net

jar: attempts stay attempts !
i´m just drunk again,but...
...read again what chaos posted and you should be able to do it on your own easily !

not that i wouldn´t have tried to avoid WinAPI myself for a long time and still dont know shit about it...but i started to code PCs in January 2008 and now i´m at a point considering to try to just do it !

and: if its running once it´ll run forever....if smash´s right...and i dont think the API will change that lot anymore as in the last 7 years :P

man,i´m drunk!

bonzaj: i saw your tool was released.. really good work! will it be possible in future for users to extend it with their own fx etc?

smash: yes, there's tons of stuff to be done. I hope in a month or two we'll have a shader designer/render monkey clone. In the future I target to release SDK for it. And after that I'll be able to open it entirely. Still we don't have an adobe after FX/premiere front end to edit the scenes together :(. That's why I'm delaying the official scene release. In other words - currently you are able to compose a demo just from one big scene - and I guess only MFX and ASD can do it with really good final effect :).

this could get the scene where it belongs again...
...a demo-editor for everyone with easy management would be totally rad !
i also know of other shit going public soon...can´t tell yet tho !
will get good times for the scene soon as it seems !

use windows forms????????????

thec: very nice screenshots and ill check that site out. doesnt look like windows, how did you make that window look so nice?
is it a skin thing maybe?

smash: i've been into mfc before and it wasnt that bad at all except for the macrostuff that i didnt like. i wonder if it can be overcome some way. ill still research on the win32 api as long as i can handle before moving to mfc, if that's my last chance.
and no, im not into cross-platforming.

rydi, as i said earlier, just avoid the autogeneration of classes and Mfc will be quite ok.

rudi: UI-coding gets ugly no matter what, so don't worry too much about macro-hacks etc :)

We're using Windows Forms since 2003 for our demotool. It's really easy and intuitive to get some GUIs working with that and C#. Mind that doing it *right* might not be that straightforward as one will otherwise get in deep troubles with more complex components/subsystems such as generic curve editors when not clearly separating user interface and business logic.
Our tool is communicating with our C++ Dx9 engine using TCP/IP. This greatly simplifies final steps such as packing it all together for a release as we're able to use the exact same engine executable for in-tool display and ultimately demo playback.

kusma: sure its ugly, but fucking great to use if one gets it done.

rudi: I think you missed my point. I was saying that the macro-stuff in MFC shouldn't be a too big worry, since GUI code will end up as a huge horrible pile of shit no matter what :)

i didnt miss your point. the point is to remove as much shit as one possibly can, even macros and stuff...

rudi: Right, sure. Yeah, GUI-coding can be usefull as long as you spend your time at making user interfaces that improve the part of the process that is problematic. This is pretty much the reason why I don't believe in The One Demotool that solves every problem - instead I believe in making specific tools to solve specific problems. I already have C++ to write my demo-logic in, and it's a good enough tool for me at that. But I did make GNU Rocket to be able to decrease the turn-around time for tweaking parameters, since that was a big problem in my old way of working. Of course, these choices might not apply to other people - it's just how I see it.

kusma: you're right in a way. one demotool doesnt fit everybody.
if you're a coder and you make a demotool to animate all your properties in graphically, it might very well not help you - because you forgot you suck at animation which is why you turned to coding in the first place.
i cant help but think a lot of people start making a demo tool "because farbrausch have one" without actually thinking about why they want one. the biggest mistake is to think that once you have the tool, thats it - demomaking is now easy.

our demotool has been fantastically useful for me, though. it meant that a) other people could be more involved in the process of making the demo; b) my own fx development was accelerated massively just because i have an environment i can move stuff around in and change parameters etc on the fly; and c) it was possible to apply it to various different projects - our demos and 64ks, even zine and some 4k development were all done using the same tool but with different plugins - reusing the common tool.

awful lot of 'tool' in this thread.

smash: Sure, but making that tool must have been a really big job in the first place. I don't have that kind of time to spend on demo development. It's surprising how little "enigne code" you can get away with if you just accept to hardcode most scenes. Of course, I assume that you guys built your tool incrementally, so at least you can develop demos at the same time as the tool, but it's still lots and lots of work :)

And yeah, by making a demo-editor you can involve more people in the process - but for me that's not a clear win - I prefer keeping the ultimate control myself (Yeah, I'm a big ego - but we all knew that already). I'm still able to include people in the process - overlay images can be added by adding a datafile, meshes and shaders can be replaced, and concept work can still be done outside of the engine. Don't get me wrong; I'm not saying that my way is any better than your way, I just think it fits me and the people I work with better. There's at least as many ways of making demos as there are demo coders.

Anyway, I guess this is another discussion - and highly subjective. After all, we're just trying to enable ourselves to make better demos with less pain - at least that's what I'm doing :)

kusma : actually, flt's coders are so leet that it only took 2 weeks.*





*not really

ive been coding like a madman for years now, i think its about time to make something that can be used on demodesign than unnecessary time like coding the same shit over and over again.

though making a tool is a big job indeed and may take some time, but its worth the effort i think.

i buyed this big fat book called windows cia c/c++ coding. i got a little dissapointed, because it seems like it was not directed towards gui programming, i mixed up api and gui. although api should cover gui this book seems to do not, if i am not mistaken, i havent read it through. Topics covered include processes, thread pooling, virtual memory, DLLs, file I/O, and message crackers. have anyone read this book?, do they feel that they had use for this knowledge in any way, and can someone give me a example of what they did have the use for, if they've have it. anyway, i think maybe some of this can be handy.

Probably more even. :)

Who needs books if the documentation is right there, complete with samples and everything? Of course everybody may learn differently but those topics are (or where) big all over the net.

Paralax: yeah, but if i could get all that in a book i would be glad. i like to read books in old style :)

* Windows via C/C++ (Pro - Developer) (Hardcover) by Jeffrey M. Richter (Author), Christophe Nasarre (Author)
(this is what i buyed)

* Programming Windows®, Fifth Edition (Microsoft Programming Series) (Hardcover) by Charles Petzold
(this is what i should have buyed?)

the only fucking thing i want to do now is to buy the Petzold one as well, but the sum of these books will be a lot of reading and little time for coding :/

rudi: "bought", not "buyed". I'm mentioning it since you misspelled it three times in two posts :)

you're right kusma. i fucked up.

now what I think would be best (not that I ever followed this practice myself, always been a dumb hardcoding man) is to develop a demo and schedule some time to make tools that make immediately obvious tasks needed to meet your conceptual (design) goals easier

after a few iterations of this you might have a better idea of what your exact needs are, have a lot of tool *and* other code around and if need be you can craft this stuff into a pipeline if that didnt happen along the way already

i think it'll just kill most people if they have to sit, think out a spec, code a tool for a long while and then find out that it's just not as flexible as they wanted it to be. if it ever gets finished at all.