It just occured to me that D would be THE perfect language for the demo scene. Inline assembler, all those C libraries at hand, pointer tricks, all there.
Those guys are high school kids open to new ideas/languages, they write mostly every project from scratch, they're the guys who get hired by gaming companies (and gaming is in my opinion THE number 1 market where D has potential to become industry standard). So - I think - it would be easy to get a bunch of them to adopt D and it could have the long-lasting benefit of getting D users into gaming companies.
What do you think?
-Mike
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

On Wed, 23 Jul 2008 13:37:38 +0200, Mike wrote:
> It just occured to me that D would be THE perfect language for the demo scene. Inline assembler, all those C libraries at hand, pointer tricks, all there.
> > Those guys are high school kids open to new ideas/languages, they write mostly every project from scratch, they're the guys who get hired by gaming companies (and gaming is in my opinion THE number 1 market where D has potential to become industry standard). So - I think - it would be easy to get a bunch of them to adopt D and it could have the long-lasting benefit of getting D users into gaming companies.
> > What do you think?
> > -Mike
Would be nice thought.
But the D compilers produce quite big programs (It doesn't have to be
that way). It's often a no go for the demo scene.

On Wed, 23 Jul 2008 14:00:21 +0200, Moritz Warning <moritzwarning@web.de> wrote:
> Would be nice thought.
> But the D compilers produce quite big programs (It doesn't have to be
> that way). It's often a no go for the demo scene.
(I think) the bulk of demos is done without size limitations, the 64k limitations are seperate disciplines; in any case, the demo guys will figure out how to produce 4k programs with D anyway :)
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

> has potential to become industry standard). So - I think - it would be easy to get a bunch of them to adopt D and it could have the long-lasting benefit of getting D users into gaming companies.
What's more important, is, in MY opinion, to get more "artsy" people to use D, and
therefore to develop the equivalent of www.processing.org or of _why's Shoes ruby GUI toolkit .
I am already trying to develop dVision, a smallish embryo of a image processing, interaction and graphics D library, that is not yet mature enough to be used (though you can check some code at github.com/maelp/dvision) but would be nice to build with a small team.
What I'm aiming at is :
- A nice image processing API that must be usable enough so that (students and) newcomers can get a grab at it very quickly, even if they don't want to use intricate D programming
- can be easily extended and use all the features of generic programming that D can provide (although "regular" users do not have to know how to use them to their fullest extent)
- a small processing-like or shoes like GUI / rapid prototyping environment, featuring a lot of libraries, to do interaction and graphics, hopefully enabling the processing of videos and webcams, etc
- if we can do it, a dsss-like plugin system, where people can share repositories and do dsss net install my_extension to extend the framework
If someone has ideas / wants to help, I'm more than happy to have people join the project!

maelp wrote:
>> has potential to become industry standard). So - I think - it would be easy to get a bunch of them to adopt D and it could have the long-lasting benefit of getting D users into gaming companies.
> > What's more important, is, in MY opinion, to get more "artsy" people to use D, and
> therefore to develop the equivalent of www.processing.org or of _why's Shoes ruby GUI toolkit .
> I am already trying to develop dVision, a smallish embryo of a image processing, interaction and graphics D library, that is not yet mature enough to be used (though you can check some code at github.com/maelp/dvision) but would be nice to build with a small team.
> > What I'm aiming at is :
> - A nice image processing API that must be usable enough so that (students and) newcomers can get a grab at it very quickly, even if they don't want to use intricate D programming
> - can be easily extended and use all the features of generic programming that D can provide (although "regular" users do not have to know how to use them to their fullest extent)
> - a small processing-like or shoes like GUI / rapid prototyping environment, featuring a lot of libraries, to do interaction and graphics, hopefully enabling the processing of videos and webcams, etc
> - if we can do it, a dsss-like plugin system, where people can share repositories and do dsss net install my_extension to extend the framework
> > If someone has ideas / wants to help, I'm more than happy to have people join the project!
> >
Part of this is in the very simple qd library I wrote, which aims to provide a graphics API similar in "look&feel" to the graphics API of QBasic 1.1 for Win98, which is what I grew up on :)
So you get stuff like "line(10, 10, 100, 100, Box=White~Green)" or "paint(17, 13, Black)" or "screen(640, 480); cls; ".
Ellipses are slightly broken though - only round circles will work. The rest should be usable enough.
The whole thing is based on SDL and has a very simple SDL_ttf API as well.
It doesn't have the spiffy features a processing-rival would need, like anti-aliasing in many cases, but it does its primary job well - "get basic graphics output fast". Samples are included.
Check it out! http://svn.dsource.org/projects/scrapple/trunk/qd/
--downs

Mike wrote:
> On Wed, 23 Jul 2008 14:00:21 +0200, Moritz Warning <moritzwarning@web.de> wrote:
> >> Would be nice thought.
>> But the D compilers produce quite big programs (It doesn't have to be
>> that way). It's often a no go for the demo scene.
> > (I think) the bulk of demos is done without size limitations, the 64k limitations are seperate disciplines; in any case, the demo guys will figure out how to produce 4k programs with D anyway :)
The .exe size is mostly related to the TypeInfo data, which is used by the GC among other things. The new -lib switch in recent versions of DMD is intended to help with this issue a bit.
Sean

On Wed, 23 Jul 2008 09:04:54 -0700, Sean Kelly wrote:
> Mike wrote:
>> On Wed, 23 Jul 2008 14:00:21 +0200, Moritz Warning <moritzwarning@web.de> wrote:
>> > The .exe size is mostly related to the TypeInfo data, which is used by the GC among other things. The new -lib switch in recent versions of DMD is intended to help with this issue a bit.
> > > Sean
Is there some documentation or just some notes available that explains
how the gc is integrated and how typeinfo is related to this.
Or is there just the source?

maelp wrote:
>> has potential to become industry standard). So - I think - it would be easy to get a bunch of them to adopt D and it could have the long-lasting benefit of getting D users into gaming companies.
Doesn't the large-ish size of D binaries put it out of the running for a demo-scene language? Or are demo-sceners less adamant about that these days?
--bb

"Bill Baxter" <wbaxter@gmail.com> wrote in message news:mailman.39.1216843508.32098.digitalmars-d@puremagic.com... maelp wrote:
>> has potential to become industry standard). So - I think - it would be easy to get a bunch of them to adopt D and it could have the long-lasting benefit of getting D users into gaming companies.
Doesn't the large-ish size of D binaries put it out of the running for a demo-scene language? Or are demo-sceners less adamant about that these days?
--bb
There are size competitions (like the 64kB one), but I've seen many demos that were 20MB+ in size. In that case the media is going to far outweigh the code size.

== Quote from Moritz Warning (moritzwarning@web.de)'s article
> On Wed, 23 Jul 2008 09:04:54 -0700, Sean Kelly wrote:
> > Mike wrote:
> >> On Wed, 23 Jul 2008 14:00:21 +0200, Moritz Warning <moritzwarning@web.de> wrote:
> >>> > The .exe size is mostly related to the TypeInfo data, which is used by the GC among other things. The new -lib switch in recent versions of DMD is intended to help with this issue a bit.
> >> >> > Sean
> Is there some documentation or just some notes available that explains
> how the gc is integrated and how typeinfo is related to this.
> Or is there just the source?
Just the source. But basically, TypeInfo is passed to the runtime when allocations occur, etc. These TypeInfo objects contain a "hasPointers" flag that is in turn passed to the GC when allocations are performed.
Sean