www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Tango conference 2008 - Tomasz Stachowiak DDL talk

reply Peter Modzelewski <peter.modzelewski gmail.com> writes:
I believe DDL is a project I don't need to introduce. Tom gave a great 
talk about it and his branch of the project showing the power of DDL and 
D. Video can be found here: 
http://petermodzelewski.blogspot.com/2008/11/tango-conference-2008-ddl-talk.html
slides: http://team0xf.com/conference/DDL.pdf

more videos to come soon! :D

Other videos:
Teaching D:
http://petermodzelewski.blogspot.com/2008/11/tango-conference-2008-
eaching-d-talk.html 


Gamedev:
http://petermodzelewski.blogspot.com/2008/11/tango-conference-2008-team0xf-talk.html

DReactor:
http://petermodzelewski.blogspot.com/2008/11/tango-conference-2008-dreactor-talk.html

DWT:
http://petermodzelewski.blogspot.com/2008/11/tango-conference-2008-dwt-talk-video.html

MiniD:
http://petermodzelewski.blogspot.com/2008/10/tango-conference-2008-minid-talk-video.html

Fibers:
http://petermodzelewski.blogspot.com/2008/10/tango-conference-2008-fibers-talk-video.html

Compiler workshop:
http://petermodzelewski.blogspot.com/2008/10/tango-conference-2008-compiler-and.html
Nov 18 2008
next sibling parent reply Tom S <h3r3tic remove.mat.uni.torun.pl> writes:
As an added bonus, I've described the basics of DDL && xf.linker for 
those who might want to play around with it: 
http://h3.team0xf.com/devlog/?p=12 Please keep in mind that it only 
works with DMD+Windows at the moment.


-- 
Tomasz Stachowiak
http://h3.team0xf.com/
h3/h3r3tic on #D freenode
Nov 18 2008
parent reply "Bill Baxter" <wbaxter gmail.com> writes:
Excellent talk!  Now I finally understand what the buzz about DDL is about.
My vague understanding was that it was basically a workaround for
current D compilers support of dynamic libs.  So I was content to just
wait for D to get the kinks worked out eventually. But from your talk
it seems much more like DDL is a better long term solution for dynamic
linking of D code regardless.

--bb

On Wed, Nov 19, 2008 at 5:40 AM, Tom S <h3r3tic remove.mat.uni.torun.pl> wrote:
 As an added bonus, I've described the basics of DDL && xf.linker for those
 who might want to play around with it: http://h3.team0xf.com/devlog/?p=12
 Please keep in mind that it only works with DMD+Windows at the moment.

Nov 18 2008
parent Tom S <h3r3tic remove.mat.uni.torun.pl> writes:
Bill Baxter wrote:
 Excellent talk!  Now I finally understand what the buzz about DDL is about.
 My vague understanding was that it was basically a workaround for
 current D compilers support of dynamic libs.  So I was content to just
 wait for D to get the kinks worked out eventually. But from your talk
 it seems much more like DDL is a better long term solution for dynamic
 linking of D code regardless.

Thanks! DDL is indeed something more :) In case of Windows, the issue is actually with DLLs, so no matter how awesome D's support of these gets, they still won't provide all that DDL can. I'm not yet sure to what extent SO could be abused to do what DDL does, but it would probably need some crazy runtime- and kernel-level programming skillz ;) Anyway, I believe that this is just the beginning of what DDL might be able to provide. Once it matures, we'll probably see more cool stuff done with it - perhaps having the same code/plugin run on multiple OSes as long as the processor architecture is the same? -- Tomasz Stachowiak http://h3.team0xf.com/ h3/h3r3tic on #D freenode
Nov 19 2008
prev sibling next sibling parent reply Christopher Wright <dhasenan gmail.com> writes:
Peter Modzelewski wrote:
 I believe DDL is a project I don't need to introduce. Tom gave a great 
 talk about it and his branch of the project showing the power of DDL and 
 D. Video can be found here: 
 http://petermodzelewski.blogspot.com/2008/11/tango-conferenc
-2008-ddl-talk.html 

That looks like it has amazing implications for runtime reflection, even if you aren't using dynamic libraries. (I'd prefer it if the language and runtime supported runtime reflection, but DDL should be a lot better than nothing.)
Nov 18 2008
parent Tom S <h3r3tic remove.mat.uni.torun.pl> writes:
Christopher Wright wrote:
 Peter Modzelewski wrote:
 I believe DDL is a project I don't need to introduce. Tom gave a great 
 talk about it and his branch of the project showing the power of DDL 
 and D. Video can be found here: 
 http://petermodzelewski.blogspot.com/2008/11/tango-conferenc
-2008-ddl-talk.html 

That looks like it has amazing implications for runtime reflection, even if you aren't using dynamic libraries. (I'd prefer it if the language and runtime supported runtime reflection, but DDL should be a lot better than nothing.)

True. Eric wrote some ramblings about it a few whiles ago: http://www.dsource.org/projects/ddl/wiki/DevNotes/Reflection Another cool idea: http://www.dsource.org/projects/ddl/wiki/DevNotes/HLA -- Tomasz Stachowiak http://h3.team0xf.com/ h3/h3r3tic on #D freenode
Nov 19 2008
prev sibling next sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Peter Modzelewski wrote:
 I believe DDL is a project I don't need to introduce. Tom gave a great 
 talk about it and his branch of the project showing the power of DDL and 
 D. Video can be found here: 
 http://petermodzelewski.blogspot.com/2008/11/tango-conferenc
-2008-ddl-talk.html 
 
 slides: http://team0xf.com/conference/DDL.pdf

The one I was most looking forward to... and it definitely didn't dissapoint. Runtime recompilation/reloading? CRAZY!
Nov 18 2008
parent Tom S <h3r3tic remove.mat.uni.torun.pl> writes:
Robert Fraser wrote:
 Peter Modzelewski wrote:
 I believe DDL is a project I don't need to introduce. Tom gave a great 
 talk about it and his branch of the project showing the power of DDL 
 and D. Video can be found here: 
 http://petermodzelewski.blogspot.com/2008/11/tango-conferenc
-2008-ddl-talk.html 

 slides: http://team0xf.com/conference/DDL.pdf

The one I was most looking forward to... and it definitely didn't dissapoint. Runtime recompilation/reloading? CRAZY!

Hehehe thanks, I actually think it's crazy too :D In case you haven't seen it, my Nucleus/Nucled project uses this system on a wider scale. A smallish demo can be seen in http://vimeo.com/2164813 starting at about 35:12 -- Tomasz Stachowiak http://h3.team0xf.com/ h3/h3r3tic on #D freenode
Nov 19 2008
prev sibling parent reply "Saaa" <empty needmail.com> writes:
That is some amazing game dev framework!
How is everything licensed?

I totally agree with what is said about programming with D:
You just implement it, even if you understand only a subset of the language 
(like me :)
And after a while the code becomes cleaner/better by itself.
For instance, I started out with loads of global variables and like almost 
no knowledge
about oop and now I better understand modules and oop, things get nicely 
packaged and
the global variable list is slinking.

Everything I made can not do much beyond what it should be doing (opposite 
the teamh0xf framework)
but that is what you get from being a one man show and try to focus half of 
my attention to
AI research :D

Why Cg? I used Cg for a bit but went back to GLSL because of its simplicity.

One last simple thing: In the Molly Rocket talk about immediate-mode guis a 
comment is made
about some games not holding true to the convention that releasing the mouse 
away from the
clicked button will not result in button click.
I think that in-game guis should not hold to this convention because of 
three things:
1. it is faster and holding to the convention could become quit annoying
2. highlighting the hot buttons is more elaborate in games (well most of the 
times of course)
3. faulty clicks are not that damaging 
Nov 18 2008
next sibling parent reply "Jarrett Billingsley" <jarrett.billingsley gmail.com> writes:
On Tue, Nov 18, 2008 at 11:32 PM, Saaa <empty needmail.com> wrote:
 One last simple thing: In the Molly Rocket talk about immediate-mode guis a
 comment is made
 about some games not holding true to the convention that releasing the mouse
 away from the
 clicked button will not result in button click.
 ...
 3. faulty clicks are not that damaging

Oops, I just used my one-time super awesome buff trinket that I was saving for Kil'jaeden _when I was fighting a trash mob_. It might not be damaging to your computer or data, but it can sure be frustrating in the game ;)
Nov 18 2008
next sibling parent "Saaa" <empty needmail.com> writes:
 One last simple thing: In the Molly Rocket talk about immediate-mode guis 
 a
 comment is made
 about some games not holding true to the convention that releasing the 
 mouse
 away from the
 clicked button will not result in button click.
 ...
 3. faulty clicks are not that damaging

Oops, I just used my one-time super awesome buff trinket that I was saving for Kil'jaeden _when I was fighting a trash mob_. It might not be damaging to your computer or data, but it can sure be frustrating in the game ;)

Well, I mentioned it as an indirect poll :) So, you'd rather have the conventional buttons ingame? And, which were the games in which the unconventional way was actually frustrating you?
Nov 18 2008
prev sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Jarrett Billingsley escribió:
 On Tue, Nov 18, 2008 at 11:32 PM, Saaa <empty needmail.com> wrote:
 One last simple thing: In the Molly Rocket talk about immediate-mode guis a
 comment is made
 about some games not holding true to the convention that releasing the mouse
 away from the
 clicked button will not result in button click.
 ...
 3. faulty clicks are not that damaging

Oops, I just used my one-time super awesome buff trinket that I was saving for Kil'jaeden _when I was fighting a trash mob_.

Bah, you know you were going to save that super awesome buff trinket until the very last big boss. But you don't know which one is it, and then the game suddenly ends and you never used that super awesome buff trinket. Better is at least using it with a trash mob.
Nov 19 2008
parent "Saaa" <empty needmail.com> writes:
 Bah, you know you were going to save that super awesome buff trinket until 
 the very last big boss. But you don't know which one is it, and then the 
 game suddenly ends and you never used that super awesome buff trinket. 
 Better is at least using it with a trash mob.

Yeah, don't let the consciousness regain power and undo that click by dragging away from the button!
Nov 19 2008
prev sibling next sibling parent "Saaa" <empty needmail.com> writes:
Erm, my comments relate to the Damedev video :/ 
Nov 19 2008
prev sibling next sibling parent reply "Bill Baxter" <wbaxter gmail.com> writes:
On Wed, Nov 19, 2008 at 3:58 PM, Saaa <empty needmail.com> wrote:
 One last simple thing: In the Molly Rocket talk about immediate-mode guis
 a
 comment is made
 about some games not holding true to the convention that releasing the
 mouse
 away from the
 clicked button will not result in button click.
 ...
 3. faulty clicks are not that damaging

Oops, I just used my one-time super awesome buff trinket that I was saving for Kil'jaeden _when I was fighting a trash mob_. It might not be damaging to your computer or data, but it can sure be frustrating in the game ;)

Well, I mentioned it as an indirect poll :) So, you'd rather have the conventional buttons ingame? And, which were the games in which the unconventional way was actually frustrating you?

I strongly disagree with the notion that good usability principles in a "game UI" somehow differ from usability principles that apply to "regular UI". UI principles are universal. It doesn't suddenly become ok to throw UI principles out the window because the interface happens to be used for shooting little digital green space aliens. It's still an interface, and a human still has to use it. And, really, gamers are some of the most sensitive people in the world when it comes to UI. Ever heard gamers griping about how the graphics of some game are nice but they threw it in the dustbin after a day because the controls are too sloppy? --bb
Nov 19 2008
parent "Saaa" <empty needmail.com> writes:
"Bill Baxter" <wbaxter gmail.com> wrote in message 
news:mailman.14.1227086510.22690.digitalmars-d-announce puremagic.com...
 On Wed, Nov 19, 2008 at 3:58 PM, Saaa <empty needmail.com> wrote:
 One last simple thing: In the Molly Rocket talk about immediate-mode 
 guis
 a
 comment is made
 about some games not holding true to the convention that releasing the
 mouse
 away from the
 clicked button will not result in button click.
 ...
 3. faulty clicks are not that damaging

Oops, I just used my one-time super awesome buff trinket that I was saving for Kil'jaeden _when I was fighting a trash mob_. It might not be damaging to your computer or data, but it can sure be frustrating in the game ;)

Well, I mentioned it as an indirect poll :) So, you'd rather have the conventional buttons ingame? And, which were the games in which the unconventional way was actually frustrating you?

I strongly disagree with the notion that good usability principles in a "game UI" somehow differ from usability principles that apply to "regular UI". UI principles are universal. It doesn't suddenly become ok to throw UI principles out the window because the interface happens to be used for shooting little digital green space aliens. It's still an interface, and a human still has to use it. And, really, gamers are some of the most sensitive people in the world when it comes to UI. Ever heard gamers griping about how the graphics of some game are nice but they threw it in the dustbin after a day because the controls are too sloppy? --bb

I strongly agree with the notion that good usability principles in a "game UI" somehow differ from usability principles that apply to "regular UI". UI principles are not universal. It doesn't suddenly become ok to not think about UI priciples because the interface happens to be used for shooting little digital green space aliens. It's still an interface, and a human still has to use it. And, really, gamers are some of the most sensitive people in the world when it comes to UI. Ever heard gamers griping about how the graphics of some game are nice but they threw it in the dustbin after a day because the controls are too sloppy? :) Seriously, I just asked whether you'd always want that kind of button behaviour or that some situations (like certain games for instance) require a different principle. I said that speed might be a reason to do this. I think you vote no :) -- Saa
Nov 19 2008
prev sibling next sibling parent reply "Bill Baxter" <wbaxter gmail.com> writes:
On Wed, Nov 19, 2008 at 7:10 PM, Saaa <empty needmail.com> wrote:
 "Bill Baxter" <wbaxter gmail.com> wrote in message
 news:mailman.14.1227086510.22690.digitalmars-d-announce puremagic.com...
 On Wed, Nov 19, 2008 at 3:58 PM, Saaa <empty needmail.com> wrote:
 One last simple thing: In the Molly Rocket talk about immediate-mode
 guis
 a
 comment is made
 about some games not holding true to the convention that releasing the
 mouse
 away from the
 clicked button will not result in button click.
 ...
 3. faulty clicks are not that damaging

Oops, I just used my one-time super awesome buff trinket that I was saving for Kil'jaeden _when I was fighting a trash mob_. It might not be damaging to your computer or data, but it can sure be frustrating in the game ;)

Well, I mentioned it as an indirect poll :) So, you'd rather have the conventional buttons ingame? And, which were the games in which the unconventional way was actually frustrating you?

I strongly disagree with the notion that good usability principles in a "game UI" somehow differ from usability principles that apply to "regular UI". UI principles are universal. It doesn't suddenly become ok to throw UI principles out the window because the interface happens to be used for shooting little digital green space aliens. It's still an interface, and a human still has to use it. And, really, gamers are some of the most sensitive people in the world when it comes to UI. Ever heard gamers griping about how the graphics of some game are nice but they threw it in the dustbin after a day because the controls are too sloppy? --bb

I strongly agree with the notion that good usability principles in a "game UI" somehow differ from usability principles that apply to "regular UI". UI principles are not universal. It doesn't suddenly become ok to not think about UI priciples because the interface happens to be used for shooting little digital green space aliens. It's still an interface, and a human still has to use it. And, really, gamers are some of the most sensitive people in the world when it comes to UI. Ever heard gamers griping about how the graphics of some game are nice but they threw it in the dustbin after a day because the controls are too sloppy? :) Seriously, I just asked whether you'd always want that kind of button behaviour or that some situations (like certain games for instance) require a different principle. I said that speed might be a reason to do this. I think you vote no :)

Uh, yeh. You guessed right. I vote no. :-) --bb
Nov 19 2008
parent "Saaa" <empty needmail.com> writes:
Are you going to freak out if I tell you about my plan to have a few buttons 
behave like the following:
if you click on one of them it is possible to select more of them by not 
releasing your button and moving over them.
Or should I just not call them buttons anymore ? :D

 Uh, yeh.  You guessed right.  I vote no.   :-)

 --bb 

Nov 19 2008
prev sibling next sibling parent "Bill Baxter" <wbaxter gmail.com> writes:
On Wed, Nov 19, 2008 at 7:25 PM, Saaa <empty needmail.com> wrote:
 Are you going to freak out if I tell you about my plan to have a few buttons
 behave like the following:
 if you click on one of them it is possible to select more of them by not
 releasing your button and moving over them.
 Or should I just not call them buttons anymore ? :D

Sounds ok as long as you give them give them a different appearance from normal buttons. About the original comment, it sounded to me like you were going to change the behavior just because it was a pain to program the "normal" way, and then you were rationalizing that it was ok because it's just a game. Sorry if I misinterpreted. If you have an actual reason to think some behavior will make for a better user experience then great. Go for it. I certainly don't mean to say that every UI has to act like standard WIMP to be usable. But if you're going to deviate for from the norm there should be a good reason to. I do agree that games are an interesting place to experiment with alternative UIs since people don't necessarily expect them to look and feel just like Windows. Whereas if you start getting creative with the UI in, say, a data entry app, users will probably want to throw things at you. --bb
Nov 19 2008
prev sibling parent reply Tom S <h3r3tic remove.mat.uni.torun.pl> writes:
Saaa wrote:
 That is some amazing game dev framework!
 How is everything licensed?

Thanks! MIT/BSD. There are licenses in a few spots, but we were too lazy to add them everywhere :P
 For instance, I started out with loads of global variables and like almost 
 no knowledge
 about oop and now I better understand modules and oop, things get nicely 
 packaged and
 the global variable list is slinking.

Cool :) I hope you haven't exchanged them for singletons, which are for the most part excuses for having globals and pretending not to have them :P I usually shoot these on sight (unless they are justified) or replace them with thread-local stuff. This said, a few spots in the 'xf' stuff uses singletons, mostly because we didn't have the time/will to refactor them out ;)
 Everything I made can not do much beyond what it should be doing (opposite 
 the teamh0xf framework)
 but that is what you get from being a one man show and try to focus half of 
 my attention to
 AI research :D

Oh, sweet! Perhaps we'll have someone to bug about AI for Deadlock when something is working again ;)
 Why Cg? I used Cg for a bit but went back to GLSL because of its simplicity.

* access to the hot and latest NVidia extensions * easy porting to DirectX ... just in case * CgFX * NVidia tools * some support for pre-shader NVidia hardware, like the GeForce3
 One last simple thing: In the Molly Rocket talk about immediate-mode guis a 
 comment is made
 about some games not holding true to the convention that releasing the mouse 
 away from the
 clicked button will not result in button click.
 I think that in-game guis should not hold to this convention because of 
 three things:
 1. it is faster and holding to the convention could become quit annoying
 2. highlighting the hot buttons is more elaborate in games (well most of the 
 times of course)
 3. faulty clicks are not that damaging 

Depends ;P I'd take an adaptive approach. Start with the 'normal' behavior, release it to testers and ask if they felt that any particular widgets/types of buttons should have a different behavior. Then just subclass the Button widget and be done with it. -- Tomasz Stachowiak http://h3.team0xf.com/ h3/h3r3tic on #D freenode
Nov 19 2008
parent "Saaa" <empty needmail.com> writes:
 That is some amazing game dev framework!
 How is everything licensed?

Thanks! MIT/BSD. There are licenses in a few spots, but we were too lazy to add them everywhere :P

You need to publish the license if you use the software. something like: license.txt derived software license .. .. This software made use of team0xf software framework MIT license .. .. ?
 For instance, I started out with loads of global variables and like 
 almost no knowledge
 about oop and now I better understand modules and oop, things get nicely 
 packaged and
 the global variable list is slinking.

Cool :) I hope you haven't exchanged them for singletons, which are for the most part excuses for having globals and pretending not to have them :P I usually shoot these on sight (unless they are justified) or replace them with thread-local stuff. This said, a few spots in the 'xf' stuff uses singletons, mostly because we didn't have the time/will to refactor them out ;)

doesn't permit a second object derived from it. I think I have no classes which only have one object :) I have a globals.d which used to contain a lot of variables (and arrays). But now most arrays have become arrays of object and are declared in the class description module. The template I use a lot is like this: module project.xclass.d enum X{ NAME1, NAM2} x xs[X.max+1]; //or keep it dynamic and init with ~ void init() { xs[X.NAME1] = new Xchild1( 1,2,3); xs[X.NAME2] = new Xchild2( 1,2,3); } void iterate() { // do stuff which need the xs } abstract class x { }
 Everything I made can not do much beyond what it should be doing 
 (opposite the teamh0xf framework)
 but that is what you get from being a one man show and try to focus half 
 of my attention to
 AI research :D

Oh, sweet! Perhaps we'll have someone to bug about AI for Deadlock when something is working again ;)

I'd love to research a 'equal knowledge' problem which might even lead to a publication ; ) ( meaning: bug me anytime you want)
 Why Cg? I used Cg for a bit but went back to GLSL because of its 
 simplicity.

* access to the hot and latest NVidia extensions * easy porting to DirectX ... just in case * CgFX * NVidia tools * some support for pre-shader NVidia hardware, like the GeForce3

website/resources) For me it would be too much work, I don't really have the time to write videocard specific shaders.
 One last simple thing: In the Molly Rocket talk about immediate-mode guis 
 a comment is made
 about some games not holding true to the convention that releasing the 
 mouse away from the
 clicked button will not result in button click.
 I think that in-game guis should not hold to this convention because of 
 three things:
 1. it is faster and holding to the convention could become quit annoying
 2. highlighting the hot buttons is more elaborate in games (well most of 
 the times of course)
 3. faulty clicks are not that damaging

Depends ;P I'd take an adaptive approach. Start with the 'normal' behavior, release it to testers and ask if they felt that any particular widgets/types of buttons should have a different behavior. Then just subclass the Button widget and be done with it.

anything and just keep quiet and watch them play.
 -- 
 Tomasz Stachowiak
 http://h3.team0xf.com/
 h3/h3r3tic on #D freenode 

Nov 20 2008