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

Text File | 1992-11-17 | 6.6 KB | 157 lines

Nntp-Posting-Host: kolsaas.ifi.uio.no
Newsgroups: alt.sys.amiga.demos
Path: sparky!uunet!usc!zaphod.mps.ohio-state.edu!darwin.sura.net!Sirius.dfn.de!mailgzrz.TU-Berlin.DE!news.netmbx.de!Germany.EU.net!mcsun!sunic!aun.uninett.no!nuug!ifi.uio.no!larshaug
From: [e-mail] (Lars Haugseth)
Subject: Re: Writing a StarField. Which method is best?
Message-ID: <[e-mail]>
Sender: [e-mail] (Lars Haugseth)
Organization: Dept. of Informatics, University of Oslo, Norway
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Wed, 18 Nov 1992 11:51:11 GMT
Lines: 143
Originator: [e-mail]


In article <[e-mail]>, [e-mail] (Leo 'Bols Ewhac' Schwab) writes:
> 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

Because demo-coders usually use a floppy-based system when writing
programs, so it's a pain in the ass to use includes. Especially in
routines like this where the includes are used in perhaps 10 lines
of the source. I *don't* do like this when doing more "serious" stuff.


>     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.

No, this small useless code dies, I do not 8). Anyway, I agree with you
on this one. Shame on me! 8)

> >    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:

See above...

>     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...

But would I manage that many stars if I should use the system-routines
for everything? The whole point of my routine is to make it as
fast as possible.

> >    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
> :-).

I want it to run at 50 frames pr. second... 8)

>     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.

A few??? Well... 8)

Anyway, remember that I never would have posted this on
comp.sys.amiga.programmer (to avoid followups like yours 8)

> --------
>     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).

Thanks! 8) Maybe you could send the result to me, so I too can learn
something from all this? 8)

>     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.

I wouldn't say that 8)

> The demos aren't any less interesting to watch.

When I get a dh0: (Isn't it hd0: on the 4000?) , you'll never see
those offsets as numbers again.. 8)

> _-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
> 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