Slashdot Mirror
Graphics for Beginners (Using SDL)
Jari Komppa writes "Looking at how learning programming these days is much harder than when I was starting, I decided to write a tutorial on how to make graphics at pixel level. The aim for the tutorial is to show that programming can actually be fun."
I used it for a game I wrote. It makes Threading, CDRoms, Joysticks, Keyboards, and graphics sooooo easy.
If you're using SDL for games, you should also look into:
NET2 - Fast Networking for SDLNet for multiplayer game programming. It basically has a separate thread that polls for Network traffic on your sockets and pushes events to your event queue. He even extends SDL events to be thread safe and FASTER.
SDL rocks.
More than enough BS
I bet this tutorial will be on the next Hugi. ;)
Programming is easier than ever. Back in the day we had punch cards and assembly language.
You're just lazy is all it is.
Another great tutorial is the book called:
g
http://www.nostarch.com/frameset.php?startat=pl
One of the few programming books I've purchased that I didn't feel like I got ripped off in purchasing.
Written by an Ex-Loki associated person John R. Hall
And now you tell me programming was easier in my day? You, with your fancy SDL and OpenGL? I'd like to see you code once you've ploughed 300 fields in one day with your bare hands.
...on RubyForge, including Magic Maze (which was inspired by Gauntlet) and Tadpoles.
The Army reading list
It's an approximation, and there's some things which each set of software does markedly better than the other, but SDL+OpenGL is considerably easier to extend (e.g. the NET2 library mentioned above) so I'd expect to see it get better faster (cheaper
The big advantages are:
These advantages are usually enough to handsomely compensate for any peripheral shortcomings (e.g. no force-feedback API, slightly smaller texturing envelope).
Got time? Spend some of it coding or testing
I'm 100% serious. All this Copeland guy does is plug his rubyforge site or InfoEther.
Do you actually do any work on Ruby or do you just spend your time trolling message boards and mailing lists?
PS, I know where you live and work. Ever been to the theatre at Worldgate? I bet you have. You don't want some albino storming into your life and fucking up your shit.
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
I've taken a quick glance at the tutorial, and it looks pretty good! As a Flash programmer, I've long been meaning to branch off into something more, um, sophisticated, and maybe this is the simple introduction that I've been waiting for!
Many thanks, Jari Komppa!
"Yeah, well, Dracula called and he's coming over tonight for you and I said okay."
SDL has a couple of things going in its favor:
1. It works.
2. It's cross-platform.
3. It's not trying to do too much.
That said, SDL isn't particularly well-designed otherwise. It's awkward. There's too much underlying info exposed to the user. The "surface" abstraction is muddy, in that you can accidentally run without hardware acceleration too easily, and you do easily do other things that hurt performance simply because you didn't pay attention to barely documented flags.
Maybe he should talk to a psychiatrist.
I wonder if anyone has ported LIZA to Ruby?
I had a friend who did 2-player "TANKS" in HTML, Javascript and CSS, simply by having tons of 1 pixel divs. Quite impressive ...
> Why [...] plug Ruby?
Don't know... just seemed appropriate in this case...
The Army reading list
Put "Ayanami Rei albino" in google.
Check out some of the winners from the last 5k compo. Really cool stuff.
Dr Superlove 300ml. I use my powers for awesome
why would you use a library that doesn't even have a decent putpixel() ? try using allegro.
What sig?
You don't have to give away any rights before you start using it.
Wrong. It is under the LGPL, so you lose some rights. Like for example you have to make all the object files used to compile your code available. That is not really a big deal, but it is an inconvenience.
There are some alternate libraries that do the same thing as SDL, like Allegro, that are under BSD or freer licenses.
CreateDIBSection() allows blitting a raster to the screen. I call a raster a memory array of pixels where you can control all of the pixel values. OK, CreateDIBSection() creates a bitmap object along with a corresponding raster memory allocation, you have to create a memory graphics context (Windows HDC) and load the bitmap object into that graphics context, and you have to blit from the memory graphics context into the display graphics context, but apart from the complicated dance step, you are essentially blitting a raster into the display -- something that TinyPTC does with a simple, clean interface.
What Windows allows and TinyPTC along with many other systems does not support is blitting a subrectangle of the raster into the display. Why this is important to me is that I scroll the display with ScrollWindowEx() (which takes advantage of hardware acceleration, and I don't find that call outside of Windows), and I scroll my in-memory raster representation of the display by shifting a circular-buffer pointer, and once I scroll the raster in that way, I need to blit in piecemeal into the display in response to paint messages.
Finally, IDirectDraw::WaitForVerticalBlank() allows doing the scrolls in step with the display refresh to get absolutely smooth scrolls without tear or flicker. Is there anything like this call under other "platforms"?
That these three calls exist under Windows is an outgrowth of the WinG and later DirectDraw/DirectX initiatives. There was a vast supply of largely 2-D DOS games and His Billness decided they needed to move to Windows, and Windows got a lot of game-specific support for the 2-D games of that generation.
It seems that the game world has moved on from 2-D games and on to 3-D games and the 2-D game API's are deprecated, even in the Windows world. If I understand the 3-D graphics world, this business of background scrolls with sprites on top has all gone out the window as a tool for getting a high-performance pseudo-depth game display. You are supposed to recreate each frame in its entirety with each frame refresh, although you describe the scene in terms of those shader triangles and get hardware assist to draw them and sort out the depth.
Maybe I am living in the past and unnecessarily tied to the kinds of 2-D performance optimizations just described. Maybe I should switch from 8-bit palette-mapped rasters to 32-bit RGB rasters, memory usage be damned, I should scroll those rasters by copying the pixels in memory, and I should blit the entire raster wholesale using the TinyPTC-style API with each frame update. Its just that what I have is high performance across a broad range of hardware speeds and works quite well.
sol.. ltns.. mm i have been away from irc too long. i bet nothing has changed on #coders in 5+ years...
no sig for you
I noticed there's a slight delay (1 second or two) in the audio on SDL/OpenBSD. It's weird, and only SDL seeems to have this problem. For example, if I compile a straight X11 (non-SDL) version of Xmame, the sound is normal.
This problem happens on every app I've compile with SDL. It's pretty disconcerting. Anybody know what's up, and if there's a fix or workaround?
... there is a Perl SDL game called Frozen Bubble. It's pretty fun, you should try it sometime. Admitedtly, it's not 100% Perl, there's also some C in some places too. Y'know for optimization, kinda like back in the day you'd optimize your C or Turbo Pascal code with some inline ASM. Well at least I used to do that, for my putpixel algorithm and other low-level gfx functions. ;)
Anyway check it out: http://www.frozen-bubble.org/
One problem IMHO, is that SDL tries to be kind-of-good at too many things, but isn't superbly good at anything. Of course it's good at being Open Source, cross-platform, easy-to-learn, yada yada, but fails in so many other areas. A general problem is that, in many cases, it abstracts the various hardware capabilities at a way too high level. For instance when it comes to the audio part: relying on the application programmer to do all mixing, etc, is probably nice seen from the "simplicity" point of view, but it hides 99% of the features of modern sound hardware entirely; don't you think the reason why people buys nifty Audigy-sound cards, is because they want to listen to cool environmental effects, 3D sounds, etc? The same could be said about the SDL_net project (I know it isn't officially (or is it?) part of SDL)... the lack of multicasting capabilities might not be a general problem, but I really don't like too much functionality to be hidden for me -- don't ask why ;)
From my point of view, SDL is simply a nifty way of initializing OpenGL, managing household threading needs, and retreiving simple user input in a cross-platform way. What about CD-ROM audio? Sure, it's easy, but has anyone used it since the nineties? If you want to do 2D pixel graphics it's cool too, way easier than plain DirectDraw, and just as powerful. But again, almost no (serious) games today use such a thing as non-3D graphics (even for 2D).
DirectX might be bloated, but at least you can access all the features of your hardware. I'd really like to see something similar but cross-platform - then we would probably also see some more serious games able of running on linux.
Okay, enough ranting :) As the title of the thread somehow states, SDL is ideal for people who want an easy way to write some cool graphical stuff that runs on many platforms.
I just wanted to mention that there is also Allegro. It's a multi-platform gaming library:
http://www.talula.demon.co.uk/allegro/
also see http://www.allegro.cc/
Coder's Stone: The programming language quick ref for iPad