Slashdot Mirror
Linux Graphics Programming with SVGAlib
The Scoop XFree86 isn't the be-all end-all of Linux graphics. Consider the embedded space, or dedicated turnkey apps, or console games, or... Jay Link introduces readers to SVGAlib in a flawed, but entertaining and useful tutorial. (If you've never heard of SVGAlib, it's a Linux-specific graphics library providing fast functions for full-screen use, joystick and keyboard input, and even 3D. It's undergone development and refinement for a few years, and it's easy to use but still powerful.) What's to Like? More than a listing of SVGAlib functions and their uses, the author covers a wide scope of graphics topics. They're all explored in the context of SVGAlib, but the basic principles apply to other libraries. Monitors display information the same way, polygons and primitives have the same algorithms, and something has to save the background before you draw something over top of it. The first three chapters cover libraries, competing tools, graphics modes, hardware fundamentals, and the primitive primitives. It's a good introduction to graphics in general.
Starting simply, SVGAlib functions obviously build on each other. For the most part, so do the chapters. Once you've mastered setting pixels and drawing lines, it's time to draw circles and arcs or fill in your shapes. You'll want fonts after that, and then animation. Basically, this is a book you can read straight through with little trouble. Link travels a lot of ground -- input devices, 3D development, raytracing, animation, and user interfaces. Appendices B and C list and describe the vga and vgagl functions of SVGAlib. Though usually short, the descriptions have information enough to be useful to a casual programmer, often listing caveats and gotchas.
The most enjoyable part of the book, though, is the author's enthusiasm. It's obvious he had great fun in writing the book, and that shines through his prose. It's infectious -- he's found something cool and wants to share that with the world. There's room to grow, too. The last two code chapters build a simple paint utility and discuss ways it could be improved. If you've done your homework up 'til that point, you should be able to complete it and add more whizbang features at will.
What's to Consider? The author's pretty casual. It's refreshing to read a technical book with personality. If you're a big X fan, though, or a closet Microsoft sympathizer, you might disagree with Link's rhetoric in a couple of spots. Of course, those aren't the people likely to pick up the book, leaving the rest of us free to chuckle along with the personable prose.
Two things might put you off if you're considering the purchase. First, it's not precisely a tutorial. Some chapters have pages of source code with little actual commentary. If your C-reading skills are low, be prepared to do a lot of homework to figure out what's going on. Second, there's also not a lot of explanation of the math involved. In places (geometric shapes, advanced primitive drawing, ray tracing) either dig up those old trigonometry notes or a battered copy of Michael Abrash's Zen of Graphics Programming (recommended in the text). This isn't an exploration of specific graphics theory as much as an exploration of the library.
The only thing I really disliked was the book's formatting. As is usual with techie books, warnings and notes are interspersed throughout the text. In a few spots, there also are glossary-like definitions mingled with notes, text, and figures in a hard-to-read mess of words, lines, and icons. More consistency would improve the readibility. Having additional explanations would have helped, but most of the code is clear enough that the a-ha factor comes into play. (Moderately experienced programmers can read the accompanying code and description and things will click the first or second time through). The overall tone says, "Here are the tools, now go explore and play and have fun."
The Summary Somewhat experienced programmers with a decent math background will get the most out of this book. It's an entertaining look at a library I'd overlooked for quite some time. For a good introduction to SVGAlib (and a healthy dose of fun programming), check it out. Table of Contents
- Getting Started
- Graphics Basics
- First Programs
- Complex Shapes, Formulas, And Functions
- Color
- Shades, Fills, And Patterns
- Fonts
- Fractals
- Graphic Files
- Basic Animation
- Polygons
- 3D Images
- Raytracing And Photorealism
- Game Basics
- Using The Mouse And Joystick
- Landscapes
- A Look At Existing SVGAlib Applications
- Simple Paint Program
- Thoughts On A GUI
- Video Card Drivers
- GNU General Public License
- Libvga Functions
- Libvgagl Functions
- ASCII Character Codes
- Chipsets Supported By SVGAlib
- A Brief History of SVGAlib
- FAQs And Troubleshooting
Purchase this book at ThinkGeek.
great. Ive always wanted a book on svgalib, but that was like 4 years ago. Is anybody even supporting svgalib? I dont use it because only X supports my graphics card. If the guy wanted to make a decent effort to write a book, I think a GTK or QT manual would be much more timely.
I can see where this would be useful though, maybe coding apps for older machines, and possibly make some cheap embedded stuff (kiosks, etc etc.). But does any applications still rely upon svgalib ?
"sex on tv is bad, you might fall off..."
I lost my concept of community when my community lost all concept of me.
I wish that there was a graphics and sound API for Linux that had the low-latency properties that DirectDraw and DirectSound do under Windows. From what I've seen, SVGAlib and OSS are the only comparable ones, and they still need work.
"Ancillary does not mean you get to rule the world." --U.S. Circuit Judge Harry Edwards, speaking to the FCC's lawyer
Linux Specific?
I know for a fact there's a BSD port of SVGALib.
For portability, though, GGI might be a better bet.
--
Does anyone see any reason why this wouldn't be practicle?
On the ohter hand, SVGAlib is SVGAlib, and as of today, I'm more inclined to trust an XFree86 X server running as root than whichever app running as root and messing around with SVGAlib. But your mileage may vary, of course.
I learned a bit about GGI and thought it was pretty neat. Later, I had to write a graphics program so I looked them up again--no new release in over a year. Ummmm....yeah. I see activity on the mailing list, but they don't appear to be putting anything out (or updating the docs on the website).
I used it anyway because I wanted something right away, but I agree with another poster that OpenGL is probably the way to go now.
--
An abstained vote is a vote for Bush and Gore.
Non-meta-modded "Overrated" mods are killing Slashdot
(Hey Ryan! Here's your proof!)
Just something everyone has been waiting for: as if X isn't enough hassle to set up right (OK, so modern distro's have solved this problem for the most of it), add in another, seperate library that does about the same things!
:-)
I mean, what can SVGALib do that X can't? If you find something, implement it in X, tadah, it supports many SVGA cards at once!
I used to play the SVGALib version of Koules, that game sure was a lot of fun
However, it was quite hard to get SVGALib to work at all.
Every expression is true, for a given value of 'true'
While I haven't had time to implement anything yet in my homebrew VR pursuit, I have spent time trying to decide on what I want to use for the display.
So far, my choice has settled on some sort of full-screen X window interface (maybe using SDL or GGI). The driver hardware for my HMD is a VGA->TV converter, and I need a 640x480 screen @ 60 Hz refresh to get the converter working. I once got X doing it on an old Redhat box, but I lost the config settings. So, I know it is possible.
I am not sure what it would take to go "full screen" with X, or if I could use something else to drop into that mode. I like SDL for its cross platform use, plus the fact that it can work console or in X. IIRC, it also supports OpenGL, which I will need for my work.
The one thing I didn't like about SVGAlib was the root access issue. Has this been corrected yet, or is it just because it needs to access the hardware in such a direct manner, that it does this? SVGAlib, otherwise, would probably be fine for me to use...
I support the EFF - do you?
Reason is the Path to God - Anon
With the current development version of svgalib, 1.9.6, you no longer need root access. Instead, it uses svgalib_helper, a linux kernel module, along with /dev/svga[0-9]. The only thing you would need root for is the mouse, unless you chmod 666 it. This version of svgalib can be gotten from here.
-- kapheine