www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - D and the demo scene

reply Mike <vertex gmx.at> writes:
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/
Jul 23 2008
next sibling parent reply Moritz Warning <moritzwarning web.de> writes:
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.
Jul 23 2008
parent reply Mike <vertex gmx.at> writes:
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/
Jul 23 2008
parent reply Sean Kelly <sean invisibleduck.org> writes:
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
Jul 23 2008
parent reply Moritz Warning <moritzwarning web.de> writes:
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?
Jul 23 2008
parent Sean Kelly <sean invisibleduck.org> writes:
== 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
Jul 23 2008
prev sibling next sibling parent reply maelp <mael.primet gmail.com> writes:
 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!
Jul 23 2008
next sibling parent reply downs <default_357-line yahoo.de> writes:
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
Jul 23 2008
parent reply "Bill Baxter" <wbaxter gmail.com> writes:
Content-Disposition: inline

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
Jul 23 2008
parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"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.
Jul 23 2008
parent Moritz Warning <moritzwarning web.de> writes:
On Wed, 23 Jul 2008 16:17:42 -0400, Jarrett Billingsley wrote:


 "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.


There are 20MB size demos for sure.
But if you have any size restrictions at all,
Current D compilers would be a drawback about what you can put into the 
binary.
Embedded devices are a related issue.

Despite this, D usability is definitely a huge plus.
Jul 23 2008
prev sibling parent reply Benji Smith <dlanguage benjismith.net> writes:
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! 
 
  


If you like algorithmic art, you might also look at "Context Free" for 
sources of inspiration:

http://www.contextfreeart.org/gallery/view.php?t=rand&num=25

--benji
Jul 23 2008
parent "Nick Sabalausky" <a a.a> writes:
"Benji Smith" <dlanguage benjismith.net> wrote in message 
news:g68gr2$1b3v$1 digitalmars.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.


 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!


 If you like algorithmic art, you might also look at "Context Free" for 
 sources of inspiration:

 http://www.contextfreeart.org/gallery/view.php?t=rand&num=25

 --benji


And to think, in my day all we had was Logo ;)
Jul 24 2008
prev sibling parent "Stewart Gordon" <smjg_1998 yahoo.com> writes:
"Mike" <vertex gmx.at> wrote in message news:op.ueqs8105kgfkbn lucia...

 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.


<snip>

"The demo scene" - as in this?
http://en.wikipedia.org/wiki/Demoscene

I don't suppose I'm the only one here who at first thought of demo versions 
of commercial software products.

Stewart.

-- 
My e-mail address is valid but not my primary mailbox.  Please keep replies 
on the 'group where everybody may benefit.
Jul 25 2008