hello. I've been programming using Textpad in Windows XP for a couple of months using Java. However, Java would probably make the crappiest game ever.

So, I did some research and came up with an idea. I prefer Linux to Windows, and I currently use PCLinuxOS and Gentoo Linux. I've found a good programming language called "Digital Mars D" ( http://www.digitalmars.com/ ) and a good IDE called LEDS ( http://sourceforge.net/projects/leds/ ). D is a C-like language. I'd like to know where to start if I was to make a game. a simple game, like an STG (not as advanced as Touhou or anything, something simple) or something.

I know for graphics and sound I can use SDL. I also know that 3D is a total pain in the arse, and takes lots of work. I also know that I can't draw for crap, and that if I were to make sprites I'd have to make one for each and every frame, which also sounds like a pain. My question is: which way is easier?

So is D still kind of braindead with regard to string literals? I.e. no immutable string type?

http://www.digitalmars.com/d/lex.html

Looks like there are string literals there.

>>14-15

What, is there some sort of rule that D libraries have to have super-dorky names like "DedicateD" and "Derelict"? The whole thing sounds very teenagers-in-basements.

>>17
Sure, but their type is char[]. Which is silly, because there are no immutable arrays in D. Meaning that the following would pass the compiler but produce a segfault or astonishing behaviour depending on whether text segments are read-only on the target platform:

char[] foo(int x, char c) {
    char[] poit = "hurble burble";
    if(x < poit.length) poit[x] = c;
    return poit;
}

I.e. the string literal would be modified through the array access. Which isn't so good.

>>15
It looks promising. Thanks.

>>19
that only looks like a problem if you assume that

char[] poit = "hurble burble";

is the equivalent of

char *poit = "hurble burble";

which it would be, more or less, in C (but may not necessarily be in D, which I know nothing about).

If, on the other hand, in D,

char[] poit = "hurble burble";

is the equivalent of

char *poit = strdup ("hurble burble");

then when you change the value of poit[x] you aren't modifying the string literal, you're modifying the array, which is completely sane.

>>21

That would, instead, be horribly ineffecient. It would incur a memory allocation and copy each time you used a string literal.

>>21
Huh, that's odd. Well, allocating memory willy-nilly when a string literal occurs in a certain context isn't exactly strange (Java anc C# do it too), and the array syntax is certainly dissimilar to C's pointer syntax to not make this entirely weird.

Depends on a fast allocator though.

>>22
Oh certainly. But a language in which there are "no immutable arrays" sounds more like it's oriented towards efficiency at the coding/debugging level, rather than the run-time level. Like Java and C#, which as >>23 mentions, act similarly.

But again: I know nothing about D; I was just suggesting a possible alternate interpretation of that code snippet from a few posts up, since at a guess, most people on this board know as little about D as I do.

>>24
Yes, that's why I posed the question -- last time I tried the GCC variant of D it didn't copy the string literal but merely wrapped it up in the D array handle gar. In any case, the D developers seem to have an unreasonable bug up their collective arses about efficiency, which would suggest they'd like to rely on some sort of "make transparent copy of read-only array on modification" semantic rather than making a straight copy.

Which seems reasonable given that most string literals aren't used in a "this, but then put this here" context, but breaks down real soon when you consider that writing to char[] can be a really common operation. Perhaps some sort of static analysis of code to determine when a character array will never be written to is what they're planning; the language is in its early formative stages still after all.

Quake 2 has been ported to Java. With OpenGL.

Some people are masochists.

>>26

Allow me a completely unbidden segue into outraged ranting about the Java OpenGL library.

Why on Earth does it keep the "gl" prefixes for all functions? It's already put all functions into their own namespace as methods of an object! C adds "gl" to the start of all OpenGL functions to avoid namespace conflicts! The fucking specs don't include the prefix! Yet still we have to suffer code like "gl.glBegin(GL.GL_TRIANGLES);" in Java. What the fuck?

>>28
lol java