From: larshaug@ifi.uio.no (Lars Haugseth)
Subject: Re: Writing a StarField. Which method is best?
Organization: Dept. of Informatics, University of Oslo, Norway
Date: Wed, 18 Nov 1992 11:51:11 GMT
Originator: larshaug@kolsaas.ifi.uio.no


In article <1992Nov17.211753.11335@ntg.com>, ewhac@ntg.com (Leo 'Bols Ewhac' Schwab) writes:
> In article <1992Nov11.131803.1276@ifi.uio.no> larshaug@ifi.uio.no (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                    ewhac@ntg.com
>  \_ -_          Recumbent Bikes:                ..or..  ewhac@well.sf.ca.us
> 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