Re: Developing Games under Linux

[Norihide Kise <s100234@example.com>]

On Thu, 11 Jan 1996, Stephen J. Turnbull wrote:
 
> > One possibility for games under Linux is to use the LIBGRX package
> > that comes with DJGPP (DJ Delorie's port of GCC to DOS; uses the GO32
> > DOS extender that he wrote).  LIBGRX is an excellent fast graphics
> > package for use with DJGPP, and supposedly is being ported to the
> > Linux environment.  DJGPP is not as good for writing games as some of
> > the DOS environments (in particular Watcom and Turbo C both usually
> > produce smaller and faster executables), but it usually is close in
> > both size and speed to the best that the commercial compilers can do.

OK. The program sounds great, but often I have to go down to deep 
assembly level to gain more control and speed. My question is that is the 
graphic package you mentioned good enough for high-speed graphics? Also, 
is there an assembler for Linux? I have programmed in MASM. 

> >>>>> and "Kise" == Norihide Kise <s100234@example.com> replies:
> 
>     Kise> Thank you much for telling me very valuable information. Is
>     Kise> there any dedicated book which describes how to develop
>     Kise> games under Linux? In the U.S. there are more than a dozen
>     Kise> of books which explain how to program computer games under
>     Kise> DOS and Windows 3.1/95, but I've never seen similar books
>     Kise> for Linux. If anyone knows such a book, please let me know.
> 
> I would guess that techniques for Windows would work fairly well under
> X, but the functions you need to call are different, and that basic
> techniques for DOS using grphics libraries such as Zortech/Symantec
> FlashGraphics or Borland's BGI should work with libsvga under Linux.

How about the new API, "Win G?" I think that it is designed specially for 
writing games under Windows 95 if my memory is correct. Also, is there 
any book which describes all the major APIs for Linux? 

> But remember that under DOS or Windows you can grab direct access to
> the screen (yes, you can address the screen directly under most
> implementations of DPMI 0.9; AFAIK only Linux DOSemu's DPMI does not
> permit this).  I don't know how you would go about getting direct
> access to the graphics screen or card accelerator functions under
> Linux.

I don't know much about direct access to the screen, but should I avoid 
accessing the screen directly if it's possible? Doesn't the program become 
so portable?

> I've looked at several graphics (not games) programming books for DOS,
> and the quality is extremely uneven.  I would imagine that the games
> literature is the same.  In general, my feeling is that "how to" books
> are generally best used for kindling or toilet paper.  They can't help
> you with design, not very much anyway, and beyond the basic principles
> of implementation, a lot of what makes a good game great is going to
> be hardware-specific: the closer you can get to the common hardware,
> the faster and slicker those implementations are going to be.  But
> most of the books don't go beyond very basic cookbook approaches to
> direct screen writes.

I don't know much about you, perhaps you might be a programming guru??, but 
I find some 'how-to' books quite useful. I'm basically a software guy 
when it comes to hardware stuff, it's quite difficult to understand. This 
is one of the reasons why I think some of the 'how-to' books are useful. 
By the way, have you seen the computer game programming book, "Computer 
Game Programming Gurus?" It's quite extensive. It contains more than 900 
pages! 

> Probably the best place to start is to look at the implementation of
> libsvga; the source is available.  The implementation of the XFree86
> servers for the various cards would be an even better source for
> learning about graphics programming, but this is going to be a huge
> piece of code, and I don't know how easy it will be to find the
> games-relevant portions.  Note that font-handling code is likely to be
> somewhat similar to sprite-handling code; similar analogies probably
> abound.  DOSemu might also have some useful techniques; I don't know.
> 
> If I were going to book up on game techniques, I would probably get
> whatever book was recommended as best across all the systems (Mac,
> Windowze, Linux, DOS, X); the techniques aren't that different so it
> doesn't matter if it's not the one I'm actually going to use.  

Are you sure? I find that programming on the Mac is quite different from 
programming under DOS. The Mac is a *very easy* to use, but when it comes 
to programming, it's very difficult since it uses "event-driven" 
programming. Have you seen the books, "Inside Macintosh" from Apple? I find 
these books are difficult to read. Also, one more important programming 
aspects on the Mac is every Mac has its built-in-graphics routines, 
"QuickDraw." I think that the routines like that is quite Mac specific. 

> Then I would look at industrial-strength graphics code, such as an X 
> server, to learn the graphics techniques relevant to my hardware/OS
> environment.  Then (to the extent that code was public domain) I would
> specialize it to my application.
> 
> Note that if you want to write commercial games, you need to be
> careful about this approach; you may not legally be able to keep your
> source code private if you are using GPL code as an example.

Finally, there is one serious question I have to ask. Learnig these 
hardware/software stuff takes *a lot of time*, but do you consider that 
learning those stuff is going to get me a job in the near future? What 
I'd like to know is that am I wasting my time to learn not so marketable 
programming skillsor knowledge? For instance, if I learn some programming 
skills under Linux, and if I'm able to use that knowledge for other 
environments, it would be great, but if it doesn't, I'll have a serious 
problem. Before I invest lots of time, I have to know about this point.

Sincerely,