Thread overview | ||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
July 23, 2008 D and the demo scene | ||||
---|---|---|---|---|
| ||||
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/
|
July 23, 2008 Re: D and the demo scene | ||||
---|---|---|---|---|
| ||||
Posted in reply to Mike | 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.
|
July 23, 2008 Re: D and the demo scene | ||||
---|---|---|---|---|
| ||||
Posted in reply to Moritz Warning | 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/ |
July 23, 2008 Re: D and the demo scene | ||||
---|---|---|---|---|
| ||||
Posted in reply to Mike | > 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!
|
July 23, 2008 Re: D and the demo scene - qd | ||||
---|---|---|---|---|
| ||||
Posted in reply to maelp | 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 |
July 23, 2008 Re: D and the demo scene | ||||
---|---|---|---|---|
| ||||
Posted in reply to Mike | 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
|
July 23, 2008 Re: D and the demo scene | ||||
---|---|---|---|---|
| ||||
Posted in reply to Sean Kelly | 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?
|
July 23, 2008 Re: D and the demo scene - qd | ||||
---|---|---|---|---|
| ||||
Posted in reply to downs Attachments:
| 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
|
July 23, 2008 Re: D and the demo scene - qd | ||||
---|---|---|---|---|
| ||||
Posted in reply to Bill Baxter | "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. |
July 23, 2008 Re: D and the demo scene | ||||
---|---|---|---|---|
| ||||
Posted in reply to Moritz Warning | == 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
|
Copyright © 1999-2021 by the D Language Foundation