Had another 48hr game jam this weekend...

Manu turkeyman at gmail.com
Sat Aug 31 21:36:32 PDT 2013


On 1 September 2013 12:57, Andrej Mitrovic <andrej.mitrovich at gmail.com>wrote:

> On 9/1/13, Manu <turkeyman at gmail.com> wrote:
> > The only compiler you can realistically use productively in windows is
> > DMD-Win64 **
>
> Why? Win32 works fine for me and many others. If you run into
> Optlink-related bugs it's usually the compiler's fault. It might
> generate a bad object file and cause Optlink to crash (Unilink is
> better for diagnosing what went wrong).
>
> I'd imagine in a game-jam you won't be making a huge codebase, so you
> might as well stick with 32bit?
>

** If you want to link against any other libraries. Ie, if your eco-system
is not completely self-contained.
Libs in windows are compiled with VC. It's the de facto standard.

In our context, libs include: D3D, OpenGL, DirectSound, XAudio,
DirectInput, XInput, zlib, libpng, libjpeg, libmad, libogg, libvorbis,
AssImp, etc.

> We needed to mess with sc.ini for quite some time to get the stars aligned
> > such that it would actually compile and find the linker+libs.
> >
> > Walter: DMD needs to internally detect installations of various versions
> of
> > VisualStudio, and either 'just work', or amend sc.ini on its own.
>
> I provided a setup script once to retrieve the VC paths, which could
> then be invoked by some other process (perhaps even DMD itself when it
> reads sc.ini), but nothing seems to have come out of it yet:
>
>
> http://forum.dlang.org/thread/50DAD8BA.8030205@digitalmars.com?page=2#post-CAJ85NXCKNnKMjVKpk9wSWOrGdAhJFCWa_n:2BkjCZpjJOBC5u-bQ:40mail.gmail.com
>
> Recently Nick has been working on making release scripts which will
> package dmd.zip automatically, I hope we can work on better VC
> integration after that work is done.
>
> > I suggest:
> >  * These should be made central D community projects.
>
> Most of us are happy enough with syntax-highlighted text editors, so
> we likely wouldn't touch any IDE code. I'm not sure what the above
> political move would do. There was a period when DWT was elected as
> the "official" D GUI, but nothing came out of it. So these political
> moves don't really mean a thing.
>

Most of who? The D devs? You all reject auto-complete and debuggers? How do
you get any work done?
Most of the D developers don't seem to be like most of the commercial
software dev's I've ever worked with.
I can't explain this, but I think it's a big problem that the development
community experience has very little on common with the end-user experience.

The reason for the political move would be in the inclusion of all of their
bugs into the main bug tracker, and consequently included in any reporting
and trend data.
It would also give end-users the right to come into the D forums and
complain about the IDE integration's directly. It's a central part of the
language experience, and should be taken as first-class criticism.

>    - Deprecate DMD makefiles. Seriously! Insist that contributors use the
> > IDE bindings to work on DMD.
>
> Not gonna happen.
>

Reconsider.

>    - The fact that you all laughed at the prior point suggests clearly why
> > it needs to be done. It will cease to be a problem when all the
> > druntime/phobos contributors are suffering the end-user experience.
>
> Slowing us down won't help anyone.
>

I'd argue that it would; inflicting the pain of trying to be a productive D
user on the developers will certainly highlight the importance of the issue.
I'm sure the only reason it can remain in such a feeble state for so many
years, is because the few people that write D code every day and could be
focusing attention on it aren't exposed to it.

>  * They should receive bugs in the main github bug-tracker, so EVERY D
> > contributor can see them, and how many there are.
>
> Bugzilla is better than whatever github has to offer. It's fast and
> its very searchable. Github just seems to introduce more and more
> useless features every other day (but I can't even search the damn
> pull request section, even though there's a "global" search..).
>

Well bugzilla then, wherever.. Just in the same place.

I'm really don't like bugzilla as an end-user, but I'm not performing
searching actions.
As a reporter, I find it's needless friction between me and reporting bugs,
and I consequently report perhaps half as many bugs as I would otherwise,
because I need to open a slow website, and login with yet another account...

> This goes back to the threads where the IDE guys are writing their own
> > parsers, when really, DMD should be able to be built as a lib, with an
> API
> > designed for using DMD as a lib/plugin.
> > I think continuous code compilation for auto-completion and syntax
> > highlighting purposes should be a service offered and maintained by DMD.
> > That way it will evolve with the language, and anyone can use it without
> > reinventing the wheel.
>
> This has been said a million times, but it's a very slow evolution
> turning an application into a library, especially one like DMD. The
> C++ => D migration process of DMD could maybe help us move into this
> direction.
>

Cool. And yeah, I know, I've seen it raised loads of times.
Raise it's priority? It's clearly a critical issue, not just a 'yeah that'd
be nice'.

> There were many instances of people wasting their time chasing bugs in
> > random places when it was simply a case of the debugger lying about the
> > value of variables to them, and many more cases where the debugger simply
> > refused to produce values for some variables at all.
>
> That sucks.
>

And needs to be fixed.

> Documentation:
> >
> > Okay for the most part, but some windows dev's want a CHM that looks like
> > the typical Microsoft doc's people are used to.
>
> It's in the windows/bin folder. It's a poor place to put it, it should
> better be put in a 'doc' folder or something, and it should be noted
> somewhere on the website.
>

Oh, in bin... Never thought to look there ;)
I think most users would expect a link in the start menu.

> This code:
> >   foreach(i, item; array)
> >     if(item == itemToRemove)
> >       array = array[0..i] ~ array[i+1..$];
> > Got a rather 'negative' reaction from the audience to put it lightly...
>
> That will allocate a new array. It could have been:
>
> foreach(i, item; array)
>     if (item == itemToRemove)
>         array = array.remove(i);
>
> or even:
>
> auto idx = array.countUntil(item);
> if (idx != -1)
>     array = array.remove(idx);
>
> Although it's still not very pretty. I'm surprised you're using
> allocation like that for game development! :)
>

These are all horrible 'solutions' to remove an item from an array.
It should be one line.

It's a 48hr game jam, efficiency is not a priority. Brevity and
readability/hackability are of key importance.
Especially when cooperating with a bunch of programmers, with absolutely no
discussion about code/systems design.

> It is how quickly classes became disorganised and difficult to navigate
> > (like Java and C#).
> > We all wanted to ability to define class member functions outside the
> class
> > definition:
> >   class MyClass
> >   {
> >     void method();
> >   }
> >
> >   void MyClass.method()
> >   {
> >     //...
> >   }
> >
> > It definitely cost us time simply trying to understand the class layout
> > visually (ie, when IDE support is barely available).
> > You don't need to see the function bodies in the class definition, you
> want
> > to quickly see what a class has and does.
>
> I think Andrei mentioned once that this might be a good idea, but it
> needs a DIP and formal reviewing, not to mention a solid
> implementation. Only this time, no more back-channel introduction of
> features like UDAs, please. We ended up having a deprecation for
> syntax that never formally existed.
>

Well, it's still a good idea if you ask me, and my squad of friends at
least. ;)

> Conclusion:
> > I think this 48 hour jam approach is a good test for the language and
> it's
> > infrastructure. I encourage everybody to try it (ideally with a clean
> slate
> > computer).
>
> Clean slate means you run exactly into issues like setting up the
> compiler, which does bring these problems to light, but really in a
> game-jam full of people wanting to try D, why not come prepared?
>

Are you saying I should have told everyone to set up their machines before
coming?
The decision to use D was made on the spot, upon my insistence...
Seems I'm making myself unpopular all over the world for recommending D to
people, perhaps I should stop ;)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20130901/efa35169/attachment-0001.html>


More information about the Digitalmars-d mailing list