Development Libraries of Choice?

[Temia Eszteri]

Hey there. I'm a hobbyist coder, amateur shmup fan, new poster, etc. etc. and I've come to ask a couple questions.

You see, I'm of the opinion that a shmup can only be as good as the developer can code it, and that extends to the people behind the programming libraries underneath - the problem is that my language of choice (Python) is very sorely lacking in any decent game development libraries on almost all fronts - graphics, audio, controls, and even timing (the biggest problem I've had) are all difficult in finding something satisfactory.

While I've found something decent (if a bit spaghetti-like in its code) for graphics in Rabbyt, and audio is unfortunately low-priority (as much as I love the music that goes into shmups as much as the shmups themselves), I have yet to find something satisfactory for controls and timing, especially the latter as I've had constant issues with mistiming, inability to control whether vsync is used (tied into graphic library issues), or altogether choppiness.

So I'd like to ask - what are some development libraries you've found that are good enough for shmups? If you know of something that is good for Python, even better, but I'm willing to work with C at this point, whether through ctypes, C/Python integration, or just biting the bullet and changing languages.

I'd like to note that I'm unsatisfied with SDL/Pygame at this current time, so please do not suggest that.

[BPzeBanshee]

Well I can't comment on the more advanced languages but Game Maker (while having issues of its own once you get more complex) allows for getting shit to display on the screen real easily, and has options like vertical sync available. Time in regards to frames seem for my uses quite precise. Certainly it allows for some pretty excellent titles to be made on it, and if you don't like anything with the default functions external DLLs are readily available for things like music support.

[Temia Eszteri]

Ah, unfortunately, that won't serve my purposes. Game Maker has its own set of troubles for sure, many of which I've seen in games developed under it.

There has got to be someone who has developed in a lower-level language that has some insight... anyone?

[nasty_wolverine]

Go with c++/DirectX, with sdl to handle win32 code...
the ideal world for me would have been c++/opengl with sdl for cross-platform coding. But the horror...
opengl implementation is buggy on windows And possibly linux because drivers which are buggy themselves. And there is no way u can ever get timing right on windows, its a nightmare. I have been debugging code and rewritting parts of my code till I figured out timing is awful on windows and opengl suffers micro stutter because of bad drivers...
so bottom line, u need a language with power and flexibility and since u already Know a language picking up c++ will be quite easy. If ur not creating a graphic card eating monster, sdl software rendering should be enough, or else use directx, it will solve timing issues once u vsync lock. If u really.want to.walk the cross-platform road, be prepared, here they be dragons....
Or if you can live with managed code.unlike me, c#/XNA is the way to go, it can possibly run on linux with MONO...
edit: don't discount gamemaker, its a great piece of software, very good for proto-typing. And if you are a genius like some of.our forum members, u can create arcade quality shmups just browse some of the most viewed posts on the development section, u will know what I mean... Special mention to gmosse and flying v(this has flying tanks)

[XYX]

Java+Libgdx+Eclipse covers all the bases, win, linux, android and soon iOs

[Udderdude]

If you're determined to use C++, Allegro is pretty good and also cross-platform.

[Ex-Cyber]

You might also look into SFML.

Timing is just a hassle on modern desktop systems. There's no easy solution. You more or less have to assume that an arbitrary amount of time might pass between iterations of your game loop, and deal with whatever amount of time passed.

[nasty_wolverine]

Timing is just a hassle on modern desktop systems. There's no easy solution. You more or less have to assume that an arbitrary amount of time might pass between iterations of your game loop, and deal with whatever amount of time passed.

Since i work on windows i can only comment on that, i hear linux timing is almost flawless. On windows, timegettime(your basic time function) gets you 10ms resolution, unless you call timebeginperiod which gets you ~2ms. Considering at 60FPS a frame takes 16.6 recurring, you will always be +/-12% off.
try queryperformancecounter/frequency, it jumps, you cant measure more than few microseconds accurately. Bottom line, time is irrelevant on windows. Microsoft Windows makes Einstein sad.

[Temia Eszteri]

You might also look into SFML.

Timing is just a hassle on modern desktop systems. There's no easy solution. You more or less have to assume that an arbitrary amount of time might pass between iterations of your game loop, and deal with whatever amount of time passed.

I'll be honest - from what I've read and researched, implementing delta timing in shmups is a terrible idea, especially if you want to support replays.

Anyway, Udderdude, I've experimented some with Allegro 5 (it was 5 you were suggesting, right? not 4?), and it does seem to be a nice library. The independent timers and event catchers work together to create a very robust and mutable system, and they seem rather accurate to boot. I'll play around with this one some more - the Python bindings are VERY un-Pythonic, so I might end up having to write my own, hahaha... oogh.

In the meantime I guess I can shut up and let people freely discuss and debate the qualities of their favorite development tools and libraries. General library choice thread ahoy! :D

[Ex-Cyber]

I'll be honest - from what I've read and researched, implementing delta timing in shmups is a terrible idea, especially if you want to support replays.

You can and should base the internal game logic on a fixed time step; I'm just saying that the OS won't enforce any coupling of that step to real time (in terms of e.g. when your process is scheduled for execution), so you need some policy for bridging that gap.

[Udderdude]

Anyway, Udderdude, I've experimented some with Allegro 5 (it was 5 you were suggesting, right? not 4?), and it does seem to be a nice library. The independent timers and event catchers work together to create a very robust and mutable system, and they seem rather accurate to boot.

I used Allegro 4 for XOP, but Allegro 5 should be just as good, if not better.

Allegro has some really nice hardware timer support that lets you easily change the game speed or drop frames.

[relminator]

You might also look into SFML.

Timing is just a hassle on modern desktop systems. There's no easy solution. You more or less have to assume that an arbitrary amount of time might pass between iterations of your game loop, and deal with whatever amount of time passed.

I'll be honest - from what I've read and researched, implementing delta timing in shmups is a terrible idea, especially if you want to support replays.

Anyway, Udderdude, I've experimented some with Allegro 5 (it was 5 you were suggesting, right? not 4?), and it does seem to be a nice library. The independent timers and event catchers work together to create a very robust and mutable system, and they seem rather accurate to boot. I'll play around with this one some more - the Python bindings are VERY un-Pythonic, so I might end up having to write my own, hahaha... oogh.

In the meantime I guess I can shut up and let people freely discuss and debate the qualities of their favorite development tools and libraries. General library choice thread ahoy!

Technically, you could implement some sort of pure delta timing in shmups but from my experience, it's not quite good if you want replays (I've done it on an asteroid clone and my replays are quite big).

You could however do some sort of hybrid by using a fixed timestep. I made an article about the subject recently in Freebasic:

http://games.freebasic.net/BASICGaming/ ... #tutorial1

A bullet pattern test in C++, GLFW and OpenGL with source can be downloaded here:
http://rel.phatcode.net/junk.php?id=129

The article(I wrote) speaks of "decoupling" but I'm doing a platform game right now and found out that you could sync your render to the gameloop just as well.

You could also alternately try threading which could do away with delta timing altogether. Render on main thread and a thread for a game loop that will do a wait of 1/60 per frame. But threading in SHMUPS is kind of overkill.

As for devtools I use, Just GLFW, OpenGL and C++/FreeBASIC/x86ASM.