Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
Programming Books Media Book Reviews IT Technology

Linux Graphics Programming with SVGAlib 42

Posted by timothy from the racy-title dept.
A technical book with personality? Chromatic claims just that in his review of Linux Graphics Programming with SVGAlib. If you're a graphics guru, or are looking for a book that describes a lot of the low level functions that put pretty pictures on your screen, this one sounds like one you should at least consider.

Linux Graphics Programming with SVGAlib
author Jay Link
pages 513
publisher Coriolis Open Press
rating 7.5
reviewer chromatic
ISBN 1-57610-524-5
summary A tour of the SVGAlib library, designed to help you create new Linux applications or port existing applications to Linux.

*

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

  1. Getting Started
  2. Graphics Basics
  3. First Programs
  4. Complex Shapes, Formulas, And Functions
  5. Color
  6. Shades, Fills, And Patterns
  7. Fonts
  8. Fractals
  9. Graphic Files
  10. Basic Animation
  11. Polygons
  12. 3D Images
  13. Raytracing And Photorealism
  14. Game Basics
  15. Using The Mouse And Joystick
  16. Landscapes
  17. A Look At Existing SVGAlib Applications
  18. Simple Paint Program
  19. Thoughts On A GUI
  20. Video Card Drivers
  1. GNU General Public License
  2. Libvga Functions
  3. Libvgagl Functions
  4. ASCII Character Codes
  5. Chipsets Supported By SVGAlib
  6. A Brief History of SVGAlib
  7. FAQs And Troubleshooting

Purchase this book at ThinkGeek.
This discussion has been archived. No new comments can be posted.

Linux Graphics Programming with SVGAlib More

Linux Graphics Programming with SVGAlib

Comments Filter:
  • I've always known that SVGAlib is way better than X ;-)
    -----
  • What would be useful would be to have a program that would force a really high graphics mode with the tiny font and then exit. That would permit a greater screen space.

  • Why would I code directly to SVGAlib instead of using GGI?

    I would assume that there's an SVGAlib target for GGI, so what's the point?


    --
  • 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..."
  • Seems most of the development of things such as windowing systems have been restricted to X and it's interface.
  • Is it entertaining? Aggresive? Any specifics?

  • Plus you don't need one extra library that clutters up the system.

  • But you can run it under X if you need/want to, which is a huge advantage especially for development...


    --
  • Ok I admit it I like to have a nice small font (I do have 20/20 or better after all) but I do remember once when I was running some fractal generator which utilized SVGAlib to interface and somehow it crashed without restoring the video mode and made for a nice effect.

    I already tried to get something that small with SVGATextMode but didn't get as fine a resolution.
  • It's somewhat offtopic, but what you're looking for is covered by the Framebuffer HOWTO, avalible here [linuxdoc.org]. Your console resolution should be reasonably easy to change in most situations, and some distros (like Linux PPC) even ship with a higher resolution enabled by default.
  • Just try playing original Quake on a Linux box sometime; squake is much faster than xquake. Unfortunately, Q3 only runs inside X; however, that doesn't matter at all if you're running a server.

    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.

  • The problems people cite with X are bloatedness (RAM) and slowness. If you look at QNX's GUI, it has none of these problems.... in fact, you can fit it on a floppy....

    Now, SVGAlib sucks for speed too, but at least it's not RAM-hungry.
    -----
  • Linux Specific?

    I know for a fact there's a BSD port of SVGALib.

    For portability, though, GGI might be a better bet.
    --
  • I use fbcon with 1600x1200x32 res for that.
    Works great!
    And you get a packed pixel framebuffer to play with :)

    I wrote a little program a while ago that showed
    a starfield behind the console text.
  • Oh... memories of my own SVGAlib stuff for DOS ...
    I thing that programing svgalib for linux have similarities to old DOS svga programming, don't you think ?
    Hope SVGAlib never dies, 'couse X is not always the answer, you know.

  • really high graphics mode with the tiny font and then exit.

    so what's the use? look at it with magnifying glass or what?

  • No actually I can read text fine at between 4-6pt easily I just want a console that reflects that. I even seen to recall (a very long time ago) that there were some assembly calls for dos that would do something similar but I don't recall the details.

  • Re:SVGAlib is better than X. (Score:3)

    by Emil Brink ( 69213 ) on Thursday October 26, 2000 @06:31AM (#674293) Homepage
    Sounds to me like OpenGL [opengl.org] using the DRI [sourceforge.net] stuff with XFRee86 4.0 [xfree86.org] should be pretty low-latency, since that makes your app talk directly to the hardware. Oh, and modern 3D hardware sure beats (S)VGA when it comes to doing stuff on screen. (And no, I'm not karma-whoring with those links) ;^)
  • Moderators: sory for the reply...
    SVGALib isn't interesting only for GFX gurus, it can be a good place to start for beginers too. At least learn how to draw lines before you switch to OpenGl right ?
  • There are two ways of doing this. You can use SVGATextMode if you're using a normal console (and have a supported graphics card), or you can use fbset if you're using a framebuffer console. Works nicely for me.

    "I want to use software that doesn't suck." - ESR
    "All software that isn't free sucks." - RMS

  • Try SDL. It works through direct X in windows. Its cross platform portable library. www.libsdl.org

  • Umm, wrong level.

    OpenGL -> GGI -> SVGALib
    OpenGL -> GGI -> X
    OpenGL -> GGI -> Network
    OpenGL -> GGI -> DRI (Windows)
    OpenGL -> GGI -> Console [slashdot.org]

    etc, etc...


    --

  • Re:Ok (Score:1)

    by MatanZ ( 4571 )
    Yes. Somebody is still supporting svgalib, which you could find out if you followed the link to www.svgalib.org.
    What video card do you have? many new cards are supported.
  • Check out GGI [ggi-project.org]. I think this is what you you are looking for.

    -matthew

  • One of the major complaints about svgalib is that if a program does nasty things and doesn't clean up properly, or crashes, it can leave your display hosed. What I thought about doing is creating an svgalibd that would link to svgalib, and a replacement svgalib that impliments all the functions as calls to svgalibd through sockets or shared memory. Therefore, svgalibd can act as a traffic cop, and the individual user programs wouldn't need to be suid root.

    Does anyone see any reason why this wouldn't be practicle?

  • Use SDL and forget about X, GGI, SVGAlib, etc. (Score:4)

    by ianezz ( 31449 ) on Thursday October 26, 2000 @07:32AM (#674301) Homepage
    SDL at http://libsdl.org [libsdl.org] is a LGPL library implementing a layer that can use X, SVGAlib, GGI, the Linux kernel framebuffer, and Windows and BeOS graphics systems as a backend. It is well documented, easy to use, provides a nice framework to manage input events and sound, and it is here to stay for a looong time. There are Free (as in speech) extensions to manage even more types of audio files and images, MPEG video, TrueType font rendering. There are also a couple of nice toolkits providing buttons, textfields, lists, checkboxes, etc.

    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.

  • Why not go one further and use SDL. That also has a target of SVGALIB (as well as GGI actually), but it's more cross platform also, having support on win32, mac, beos (iirc)

    The good thing about writing for something like SDL also is that the SDL programmers have spent ages doing little optimisations and extra performance improvements for specific targets that someone writing something from scratch might not be bothered with, so in practive it's often no slower than programming for the specific target directly. For example, for X11 target, it looks to see if it has DGA authority, if not, it might try MIT-SHM extensions before resorting to Xlib otherwise.

    I have to admit though, if you have the time to optimize your code and you want the fastest code possible you should code for your specific target directly.

    Personally though, I would prefer fbdev over svgalib, but thats just me.

    Incidentally, IIRC, someone has done a plug in replacement for svgalib that redirects access via GGI so stuff written for svgalib works on X11, fbdev, aalib etc. cool stuff and it's fast (according to the author)
  • 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.
  • 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.
  • How much does this book help if you're familiar with DirectX programming? -----------------------------------------------
  • For another library that allows easy porting of programs look at Allegro at http://www.talula.demon.co.uk/allegro/ Its a great package and with the next release supporting a wide range of enviroments.

  • Hmm... (Score:2)

    by cr0sh ( 43134 )
    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 [eff.org] - do you?

  • Re:Utterly useless (Score:3)

    by Anonymous Coward on Thursday October 26, 2000 @09:56AM (#674308)
    I don't understand how some people here have the audacity to put down a project that doesn't quite fit their idea of something that is worth doing.

    Please, no more comments such as:
    do we really NEED that

    or

    why don't you spend YOUR spare time coding this OTHER project, which I, in my not-so-humble-opinion, think is much more interesting than the one you are working on?

    These posts are rude, and very unproductive.

    Regarding this book:

    • Nobody is making you read it.
    • Your opinion of a worthwhile book will differ from another's opinion of a worthwhile book.
    • If you think SVGALIB is a waste of the author's time, then you need definately need to shut up and write your own book on what IS important (to you).


      This book promotes learning, some people will find it useful, so STFU.
  • from http://www.ggi-project.com/ [ggi-project.com]

    2000-10-15

    XGGI 1.6.2 [stacken.kth.se] has been released. Summary of changes:
    • Now uses XFree 3.3.6 as it's base.
    • Don't try to open a new VT by default when running on a console-based target. This used to cause problems when running XGGI without any root privileges.
    • Italian, Polish and Norwegian keymaps added.
    • Save and restore all screens in a multihead configuration upon VT switching.

    Yeah, it's not the most current, but i wouldn't say stagnating...
    --

  • I realize this, I was commenting on speed only. For sure, I use networked X quite a bit myself. However, there are times when you don't care about networked graphics and just want speed, e.g. games.
    -----
  • It would work really well, but why not just make an X server that uses SVGALIB as the display driver? That would amount to the same thing, PLUS you could run all your X apps through the thing.

  • 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 [arava.co.il].
  • Well, hopefully OpenAL will become more mainstreamed and it can be a companion to OpenGL. Then the code will be more portable too. OpenGL is making some big jumps lately, hopefully it will take over Direct3D. That doesn't really address DirectDraw.... but I'd say that if you're looking into serious developement, 2-d is sort of dying out. Maybe it'll be revived in a better form on graphics cards later... but for now...
  • SDL supports full screen X, GGI, framebuffer consoles, and SVGALib for display, among all of its other cross-platform support.
    =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
  • CrystalSpace crystal.sourceforge.net [sourceforge.net] is another cross platform graphical environment. It is intended for 3d, and runs on Amiga, *nix (x), Linux(X, svgalib, ?fb?) BeOS, Windows, Mac, etc,etc. However, a friend of mine has written a limited 2d graphics library. It runs on more hardware, and has acceleration.

    btw, SDL looks very good.

  • Now, I haven't tried SDL on GNU/linux or Windows, but I got the SDL copy of The Black Lotus's iXalance demoloader [libsdl.org] and fired up Jizz - a demo that used to run just great from Windows on my old P133. Using libSDL under BeOS on my brand spankin' new P3/700, Jizz sucks up the whole damn processor and still wants more.

Slashdot Top Deals

Get hold of portable property. -- Charles Dickens, "Great Expectations"

Close