Re: Programming Linux Games - code updated and available

From: Paul F. Johnson (paul_at_all-the-johnsons.co.uk)
Date: 08/03/04 

Date: Tue, 03 Aug 2004 11:32:20 GMT

Hi,

Jon Dowland did utter the following words of wisdom:

> Paul <paul@all-the-johnsons.co.uk> wrote in
> news:pan.2004.08.02.15.22.42.190270@all-the-johnsons.co.uk:
>
>> For those who have enjoyed the NoStarch / Loki Games book -
>> "Programming Linux Games" (not to be confused with "Linux Games
>> Programming" by Mark Collins), you may be interested to know that I've
>> updated the code so that it now compiles properly with a modern
>> distro.
>
> Just out of curiosity, what needed changing? I'd have thought if it were
> written in a standards-compliant way it would be forward compatible till
> the end of time.

It's not so much the pure C, more the calls to external functions (such as
OpenAL, OpenGL and sndfile)

Sound code was in need of some repair (change of API in libsndfile and
OpenAL), the network code needs fixing (basically, needs updating -
again, changes in the likes of bind()), some of the code was not good (see
below) and a few other problems which meant that things would not compile
"out of the box". The engine.wav file is also dead on the original archive.

For instance, the makefiles used in the tcl examples look specifically for
-ltcl8.3. This doesn't exist on any of my machines (Fedora 2, 3t1 and
Slackware 10), but the correct library is symlinked so -ltcl does work.
IIRC, that is the recommended way of doing things for forward
compatibility.

An example of either bad style or bad code (IMO at least) is the use of
goto when an error is returned as a clean up method. goto is just bad! A
simpler (and cleaner) way was to add in a small static void function to
clean up the error, call that routine and when control is passed back to
the caller function, exit from the caller cleanly. A far better way than
using goto - sure, goto is quick - but it isn't a good idea to use it.

Another one which is more a niggle than an error is the use of exit(1) and
return 1; as methods to exit the program rather than exit(EXIT_FAILURE).
exit(EXIT_FAILURE) - this is more a portability issue than anything [yes,
return 1 and exit(1) are portable, but exit(EXIT_FAILURE) is a clearer
indication that you're getting out due to a failure somewhere].

TTFN

Paul 

-- 
"There are four stages to any war
First they ignore you, then they laugh at you
Then they fight you, then YOU win."
Ghandi

Relevant Pages

  • Re: Is David Fenton right about error handling? (re-post?)
    ... > Error Goto 0 a proper termination. ... after the Exit Function. ... Clears all property settings of the Err object. ... Exit Sub, Exit Function, Exit Property ...
    (comp.databases.ms-access)
  • Re: On Local Error Goto Somewhere
    ... an EXIT DO or EXIT FOR. ... going if there is no label to show you the destination. ... IMO the GoTo statement has never been "THE" problem. ... ON ERROR GOTO MySubErr Dim lFNbr as long ...
    (microsoft.public.vb.general.discussion)
  • Re: COBOL aint quite dead - yet !
    ... The point about goto is that there is nothing at all wrong with a goto ... For example the use of an exit paragraph signals ... loops - which was all about replacing a GOTO with something that did the ...
    (comp.lang.cobol)
  • [patch 06/10] Introduce path_put()
    ... goto fail; ... return err; ... * Given a path decrement the reference count to the dentry and the vfsmount. ...
    (Linux-Kernel)
  • [patch 1/4] Introduce pathput
    ... if (!ret) { ... goto fail; ... return err; ...
    (Linux-Kernel)