delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1998/01/19/01:32:51

From: George Foot <mert0407 AT sable DOT ox DOT ac DOT uk>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: DJGPP
Date: 15 Jan 1998 17:53:05 GMT
Organization: Oxford University, England
Lines: 76
Message-ID: <69lie1$p4u$2@news.ox.ac.uk>
References: <19980102185455 DOT 22437 DOT rocketmail AT send1a DOT yahoomail DOT com> <34AD7973 DOT 11B7 AT primenet DOT com> <34b488f2 DOT 661780 AT news DOT dlc DOT fi>
NNTP-Posting-Host: sable.ox.ac.uk
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp

On Thu, 08 Jan 1998 08:30:42 GMT in comp.os.msdos.djgpp yorka AT dlc DOT fi wrote:

:    Yeah right, that's all most DJGPP "game programmers" seem to do
: nowadays. Looks like nobody can even find their socks without Allegro.
: I suggest learning everything "the hard way" (a lot of
: experimenting/practicing) and using fancy-pants libs ONLY AFTER you
: would be quite capable of writing similar libs by yourself. I'm
: getting really sick'n'tired of people asking for stuff such as Allegro
: tutorials. God dammit, there's a complete function list in the zip
: which is quite enough if you've picked up the very elementary basics
: of game progging.

But what if you haven't a clue where to start?  The function list
tells you what functions are available, but how can you know what
order to put them in?  Sure, you can derive the whole theory of game
programming from first principles (the function list), but it's far
simpler to learn roughly the sort of things you might want to do from
other peope.  Then you have some building blocks with which to make
your first games.  Once you've mastered that, you figure out new ways
to combine the functions to do more things.

: Sure you could/would get quick results by starting
: out with a lib but then you wouldn't really learn anything. Besides,
: the wonderful little example programs only introduce you to the
: Allegro lib, they won't teach you shit. 

That's not true -- as you said, they show you how to use the library.
Game programming isn't about knowing how to set up a linear
framebuffer by hand.  That's low-level graphics programming.  Game
programming is about programming *games* -- not library functions.
Sure, if your game needs hyperoptimised specialist functions, such as
a first-person perspective game would, you'll probably need to write
those functions especially for the game -- but no one in their right
mind would learn game programming by writing Quake-alikes.  At first a
newcomer should stick to the functions the library provides.  When
they get more competent they can look at the source code for the
functions they've been using, and if they need special functions they
can adapt the library's functions, or write their own from scratch.

: the lineto/moveto stuff yourself, it's quite simple really. But if
: you're just too lazy or impatient to code something yourself, then I
: can only say that you will never get beyond the basics in game
: programming. Game programming is _hard_ and learning it takes a lot of
: time, patience and motivation. Don't get discouraged if things don't
: work like you expect them to, just try again and type 'till your
: fingertips are bleeding. Unless you're ready to go through all this,
: you will never become a game programmer. Period.

Game programming does not have to be hard.  It's only as hard as you
make it.  The same is true of programming in general -- you can do
things in the easiest way, or you can make your task more difficult.
When you write programs, do you #include any standard headers, or do
you write everything from scratch?  Sure, reinventing wheels can be a
good experience, and you *might* make a better wheel, but when you're
just starting out you don't want to have to do that all the time.
When you have more experience you are in a better position to decide
whether you want to go on using other people's code (so generously
donated) or roll your own.

If you only use libraries that you wrote yourself, your games will be
limited by the capabilities of those libraries.  You won't know
whether or not your graphics drivers work on a wide range of cards,
you won't have sound drivers for any card you don't own, etc; if you
use an off-the-shelf library like Allegro, you know that all the
graphics drivers work on various cards, that it supports various
different sound cards and can make the best of whatever it finds, and
that the library code itself has been thoroughly tested by people all
around the world.  Which is more likely to go wrong, your library or
Allegro?  Whichever one does go wrong, you have the source code so you
can fix it, and let the library maintainer know, so that it's fixed
for other people too.

-- 
Regards,

george DOT foot AT merton DOT oxford DOT ac DOT uk

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019