NetNews Usenet Archive 1992 #27/NN_1992_27.iso/spool/alt/sys/amiga/demos/1707

Text File | 1992-11-17 | 5.2 KB | 123 lines

Newsgroups: alt.sys.amiga.demos
Path: sparky!uunet!utcsri!newsflash.concordia.ca!IRO.UMontreal.CA!CC.UMontreal.CA!sifon!charnel!rat!usc!wupost!csus.edu!netcom.com!netcomsv!ntg!ewhac
From: [e-mail] (Leo 'Bols Ewhac' Schwab)
Subject: Re: Writing a StarField. Which method is best?
Message-ID: <[e-mail]>
Summary: Critique
Organization: Politically Incorrect Software, Ltd.
References: <[e-mail]> <[e-mail]>
Date: Tue, 17 Nov 1992 21:17:53 GMT
Lines: 111

In article <[e-mail]> [e-mail] (Lars Haugseth) writes:
>Here is a small 3D-stars routine, with sine-table and all...

    Not to denigrate Lars' contribution to the community, but I thought
I'd try to make a few (hopefully constructive) comments on the coding style.
I've noticed a variety of practices in this and other pieces of demo code
which cause me to sit back and go, "Why?"

>No flames about coding-technique, please. After all, this is
>alt.sys.amiga.DEMOS ;-)
>
    Well, okay, but my philosophy in writing demos and hacks was to
learn how the system worked, and then be able to make constructive use of
that knowledge later, without getting bitten in the future.  Although some
of my *old* stuff made some invalid assumptions and looks ugly in some
configurations, they all still work (even "Viacom," the most brutal of the
lot).

    Part of this was following the programming standards.  Another was
writing code I felt was readable by myself and others.  Both of these are
religious issues to be sure, but what I'd like to point out below are just a
few simple things that I believe would help make demo code much easier to
write, *read*, maintain, and share.  (I like to share my stuff, you see;
that's why I believe it's important.)

>START    move.l    4.w,a6
>    move.l    156(a6),a1
        ^^^
    Okay.  Why isn't this a symbolic offset?  That is, why didn't you
say:

    move.l    IntVects+6*IV_SIZE+IV_DATA(a6),a1

    Granted, this is more verbose, but it tells me exactly what you're
fetching; the iv_Data field from the seventh interrupt vector in ExecBase.
However, the real weirdness comes in with:

>    move.l    38(a1),OLDCP

    Translated, this is:

    move.l    gb_copinit(a1),OLDCP

    Basically, what the programmer has done is dive into the Exec
interrupt tables, pull out the iv_Data field from the "Blitter finished"
interrupt structure, made the *assumption* that this pointer is maintained
by Graphics and points to GfxBase, then fetches the copinit pointer from
GfxBase and saves it for later restoration.

    Excuse me but:        Ack!

    Why didn't you just open graphics.library?  Yes, it takes slightly
more code and is slower, but it gets executed only once, and you are
guaranteed that you will always get a pointer to GfxBase.  Future versions
of Graphics may (and probably will) put a completely different pointer in
the interrupt vector.  What if some other program in the system has made use
of that vector (which is perfectly legal)?  Poof! you die.

>    bsr    SBUFFER
>    bsr    VBLANK
>    move.l    #COPPER,$DFF080
            ^^^^^^^
    Again, why not a symbolic offset?  I don't have the custom hardware
addresses memorized (sorry).  On the other hand, if you had said:

    move.l    #COPPER,_cop1lc

    I'd know what you were doing without hunting through my RKM.

    I'm also the kinda guy who would suggest using Graphics to create
three Views rather than using a custom hard-coded copper list.

    [Actually, I have a theory about how one might incorporate such
copper lists into Intuition displays, but I haven't actually tried it out
yet...]

>    move.w    #$7FFF,$DFF09A        [ Disable all interrupts ]

    ARGH!  Why?  It's a STARFIELD!  It's not like you're modifying
system lists or trying to DMA hard disk data at breakneck speeds.  So why
put the system at risk?  Besides, I might be trying to download more demos
:-).

    Example:  CDTV's CD-ROM device driver (cdtv.device) is written in
such a way that multitasking and interrupts *must* remain alive.  The CD-ROM
drive communicates with CDTV via interrupts.  If they are turned off for any
great length of time, cdtv.device will either DIE completely, or lose sync
with the CD-ROM drive and force it to reset (which takes *4* seconds).

    Speaking entirely personally, I'd really prefer not to kill the
system for a few extra stars.

--------
    However, lest you think I'm only here to bash Euro coders to a pulp,
I think the core algorithm is interesting, and I'll probably spend a fair
amount of time studying it.  Also, there's nothing preventing a persnickety
compatibility freak (like me :-) ) from diving in and making it live more
peacefully with the system (at the cost of some stars).

    While I realize these are merely demos and not intended to be
paragons of Perfect Programming Practice, I personally believe there are
acceptable tradeoffs between RAW UNADULTERATED SPEED and "nice" code.

    These are, of course, suggestions, and are completely ignorable.
The demos aren't any less interesting to watch.

_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
Leo L. Schwab -- The Guy in The Cape                    [e-mail]
 \_ -_          Recumbent Bikes:                ..or..  [e-mail]
O----^o       The Only Way To Fly.                     (pronounced "EH-wack")
 "Work FOR?  I don't work FOR anybody!  I'm just having fun."  -- The Doctor