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?
Take a look at the Arc library (http://www.dsource.org/projects/arcgames). It is nicer than plain SDL and has the advantage of hardware accelerated graphics.
The server with the Asteroids tutorial is currently down but commented source is available from http://svn.dsource.org/projects/arcgames/downloads/zipfiles/games/asteroidspkg.zip.
That should give you an idea of where to start.
In general: as long as you are doing a simple top-down or side view plain, software 2D (what SDL gives you) is sufficient. In that case you won't need alot of animations either.
If you want a lot of effects (rotation, zooming, smoke, lights, particles, etc) you will have to learn OpenGL.
For everything else that falls under "uses perspective view and has animations" I would use 3D or at least prerendered 3D-models. This isn't necessarily less work or "easier", but the result will look better.
> has the advantage of hardware accelerated graphics.
In what sense?
SDL makes what use it can of 2D hardware.
Arc uses SDL as one of two backends.
If you're referring to the OpenGL backend, some 2D operations are slower in a 3D context.
>>In what sense?
Mainly speed. Drawing textured quads and a OpenGL buffer swap vs SDL's blit/flip. The latter can take quite toll even on modern systems, especially if you want to do a shooter with loads of effects at 60fps.
This might not be an immediate advantage to the OP, but it is something one is going to notice sooner or later.
>>SDL makes what use it can of 2D hardware.
Hardware surfaces might be slower than software surfaces in the first place, and they are only available in fullscreen mode.
>>If you're referring to the OpenGL backend
I was.
>>some 2D operations are slower in a 3D context.
But said 3D context makes use of modern hardware and not some 2D accelerator that hasn't seen any significant improvement for nearly a decade.
>>2
That's what I'm trying to avoid, I want to make something from scratch, and even if it totally sucks I can at least say that I made it myself, and I can use it to learn from my mistakes and make a new one that's better.
Arc looks pretty sweet.
>>3
I want to do a strait top-down STG, but I'd like it to be good to look at. What I want to know is whether 3D is worth the effort if the game is going to be on a top-down 2D perspective. Even if it's not, I'd still want to at least try it, just to see what it's like.
If I were to do 3D stuff, would Blender be a good choice for a 3D application or do you have a better program?
I'm not sure what you mean with "3D" here:
-you can do "true" 3D and lock the action to the x-y plane and the view to overhead. I would not recommend this for a first attempt.
-you can do 2D (i.e. sprites) via OpenGL. This is what Arc does. If you want do it yourself you'll need to learn some basic OpenGL commands. This can serve as good introduction to OpenGL if you really want to go 3D later on.
-you can use images of prerendered 3d-models as your sprites, depending on wether you find it easier to learn how to draw or how to model and texture.
>>If I were to do 3D stuff, would Blender be a good choice for a 3D application
Blender is fine, though personally I prefer Wings (http://wings3d.com/) for modeling.
> But said 3D context makes use of modern hardware and not some 2D accelerator that hasn't seen any significant improvement for nearly a decade.
You misunderstand me: some operations are faster even despite a modern 3D accelerator. Uploading textures and/or scene setup isn't cheap, and depending on what you do in a 2D context, this can cut out any benefit you might have seen.
Unless you're blending or parallaxing like no tomorrow, I just don't see any real advantage of using OpenGL as a backend. If Arc is a nicer or more portable library, right on, but performance?
Of course, hardware changes, and maybe I'm behind the times. I'd love to hear something more substantial regarding this issue.
>>8
I'd like to do the first one, but I know it would take a veeeeery long time to do, lots of hard work, practice, learning and headaches.
I'd do the second choice, just to learn OGL, and then move into 3D with a 2D movement plane later. (although I wouldn't have thought of using sprites with OGL, I never thought people used sprites with Direct3D either. :P )
I heard about wings a couple of years ago and completely forgot about it. Thanks for reminding me about it.
I can't draw for crap. That is definitely my major setback.
>Unless you're blending or parallaxing like no tomorrow,
As I wrote:
"especially if you want to do a shooter with loads of effects at 60fps"
So let's say: particles and smoke, pseudo-3d explosions (scale some fragments), colour tinting for light effects.
In my experience doing 100-200 blits per frame (just blitting a non-alpha image to random point on the screen) can already bring you into the 30-60 fps region on semi-recent hardware (depending on resolution and size of the image). You can reach that with only tiles, enemies, and bullets.
Sure, with the exception of particle effects none of the above is in Arc (yet). For a lot of things the speed difference between using OpenGL or an SDL/software hybrid is irrelevant. But the capability is there if you want to make use of it.
>I'd like to do the first one, but I know it would take a veeeeery long time to do, lots of hard work, practice, learning and headaches.
Yes and no. You'll have to learn basic 3D OpenGL anyway or you wont know what you are doing in 2D, but staying 2D for the beginning gets you going faster. You dont have to worry about (or make) models yet, effects and gamelogic are somewhat easier to do.
An example that uses OpenGL/2D: http://www.reptilelabour.com/software/chromium/download.htm
Chromium is awesome. I had it on my old computer before the mobo blew up... quite literally. smoke and everything.
On the topic of D and OpenGL, are there any decent gl*.h ports? The only version I found are the DedicateD ones. They're kind of old, and don't have glut or ext.
~10 minutes in google got me this:
http://www.dsource.org/projects/derelict
Is this what you're looking for?
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.
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.
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.
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