🚀 go-pugleaf

Newsgroups: rec.games.programmer
Subject: Re: Game Library? Fact or Fiction.(cont)
Summary: 
Expires: 
References: <76060@ut-emx.uucp> <1992Jul19.061540.20112@mintaka.lcs.mit.edu> <1992Jul19.145047.29656@wam.umd.edu>
Sender: 
Followup-To: 
Distribution: 
Organization: /etc/organization
Keywords: 

In article <1992Jul19.145047.29656@wam.umd.edu> dmb@wam.umd.edu (David M. Baggett) writes:
>In article <1992Jul19.061540.20112@mintaka.lcs.mit.edu> psteffn@hal.gnu.ai.mit.edu (Paul Steffen) writes:
>
>Sure it is, but why does that mean that using a library is ridiculous?
>Some people like to program "with their faces pressed right against the
>bare metal of the machine" (my favorite quote from Warwick Allison)
>while others are more intersted in *designing games*.  I'd venture that
>most people don't have the patience to work out 8-directional fine
>scrolling on their PC or ST, but they'd be more than happy to sit down
>with a sprite editor, make some shapes, and write a little pacman or
>robotron game for fun.

Well, to me, programming is a learning experience where I not only learn
how to code increasingly efficient algorithms, but whatever tricks
(software/hardware, orthodox/unorthodox, etc) I can use to get the task
down faster.  This may include using register save opcodes for block
moving memory, delaying video DMA for smooth scrolling, or writing
fully background interrupt-driven disk routines.  I gauge my success
in machine cycles.


>
>It's all a mater of whether you want the majority of your time to
>be spent on *design* or *programming*.

*design* is what I do whenever I'm not at my computer.

>This has *always* been a big thing.  Remember the 2600?  James Hague
>just sent me the programming specs for it (thanks, James) so they're
>fresh in my mind.  You wanna talk "faces pressed to the bare metal" --
>sheesh!  The 2600 had no DMA for the screen, so the CPU had to control
>the screen D/A registers directly itself.  I.e., you, the programmer,
>control the screen timing *by counting cycles*.  You misplace an
>instruction, your screen is completely hosed.

I have to admit that the thought of seeing some actual 2600 code is 
mildly erotic.  The difference being is that the non-professionals
I talk of are programming code  many levels above the norm for 
professionals.  About the only 'standard' that has come of this
into the mainstream is the MOD music format [who do you think Mahoney&
Kaktus were!?]  The quality of even the artists and musicians
who work with the programmers far exceed the norm.  
[ftp to wuarchive.wustl.edu in /systems/amiga/incoming/demos and download
party91.lzh which is 3 IFF pictures and 3 MOD files, for example.]

>This is a all neat stuff.  If you had a game library that had things
>like that in it, then everyone could write games like Wolf 3D on their
>ST's without having to do all the tedious work your friends did.  I.e.,
>the world only has to code these things *once* if we all use a shared
>library of routines.  Then those of us who have *no interest* in
>writing real-time texture mapping routines can still write games with
>that technology.
>

Don't get me wrong.  I don't have anything against game libraries as
long as the programmer is supplied with source and the right to 
make improvements on them [and an incentive to make them available
as updates].
 
>>Yet, check out ACF's Just Buggin Demo which has a built in 'game' with
>>graphics to put Bitmap Brothers 'GODS' to shame...
>
>Demos are not games.  Much more severe requirements are imposed on
>games because they have to run on all "100% compatible" hardware and
>they have to include code to make the thing -- get this -- fun.  You
>can't, for example, precompute gigantic tables for games unless you're
>willing to devote almost all your memory to the fancy graphics and
>ignore gameplay.

But, the argument for game libraries is that people want to do just the
fun stuff [*-i.e. design-*] and none of the hard stuff [*-programming-*]
where-as, here are demos where the programmer[s] did all the hard
programming and very little game design.  Do you think people would go to
all this work if hardware programming wasn't fun?  esp. for no pay?

>
>Gods is a fully-functional and fairly complex game.  A demo is just
>that -- a demo.  If it uses undocumented tricks or relies on hardware
>bugs, who cares?  You, the customer, didn't pay anything for it.  If
>you buy a game, on the other hand, and it doesn't work on your
>computer, you're going to return it and be wary of other titles from
>the company.  The company will lose money.  They will go out of
>business.  The owners will have to do something else to feed their
>families.  (How's that for the real world getting in the way of hacking?)
>

Quite true, and since demos are free, the programmers are not obligated to
test run their work on machines they most likely have no access to.
Actually, the game Pinball Dreams was done by a demo group called Silents
and is a HIGHLY rated pinball game [when it runs...].

>Since you program on the ST, here's an example:  Thalion's Enchanted
>Lands was written by a demo coding group, and it's basically a pretty
>good game.  The graphics are excellent and the scrolling is almost
>magically smooth.  In fact, it *is* magically smooth, because they rely
>on certain undocumented video shifter behavior to achieve it.  Consequently
>it works on my STe but not on any of several circa 1986 ST's I've tried
>it on.  If it were a demo, no one would care, but since it's a game
>*people care*.

I'm not aware of that game but I am aware of Thalion.  They were a very early
demo group and the first to use that technique in a Neochrome slideshow
[which had people at Atari boggled].


>
>>Game libraries are perfectly fine, I'm sure, but it good to think for
>>yourself once in a while, too.
>
>No argument there, but this seems to contradict your opening statement.
>

How does it contradict my opening statement?  I'm confused.

>Dave Baggett
>dmb@wam.umd.edu

Paul Steffen
STratoHAK
psteffn@gnu.ai.mit.edu