fnf@mcdsun.UUCP (Fred Fish) (11/11/87)
Just to keep everyone informed, I received the Badge Killer Demo Contest entry disks (thanks Tom!) a few days ago. However, it has become apparent that due to other commitments on my time, I will not be able to get them worked into the library for general distribution for at least a couple of weeks because I would like to distribute each entry with full source where provided. Tom has nicely compacted everything onto four disks, and obviously gone to a lot of work to do so, and make everything easy to use, but I'd like to include some of the additional material, spread out over more disks. Thus I will basically be building on Tom's work to get the material organized, but "fleshing out" the entries with more of the original material where appropriate. Since there are probably a lot of people that are anxious to see the demos, I'm willing to redistribute the four "release disks" that Tom sent, until I can get the material onto one of the official library disks. So for the next three weeks or so, anyone that wants copies of these four disks can order them under the same conditions as the other library disks. -Fred -- # Fred Fish hao!noao!mcdsun!fnf (602) 438-3614 # Motorola Computer Division, 2900 S. Diablo Way, Tempe, Az 85282 USA
bryce@hoser.berkeley.edu (Bryce Nesbitt) (11/12/87)
The BADGE Killer Demo Contest disks are out! It appears the first
distribution was at the monthly meeting of the First Amiga User's Group
(FAUG) on November 10. What follows is a review:
The entries have been compressed into a set of four "Best of" disks. There
are 18 total demos, 16 of which were BKDC entries. This includes the top 7
demos plus "whatever else fit". The cover letter indicates the top 8 demos
are included, however Alan Hastings "Car" demo was not represented. (Too
bad, this one is really neat, "Red?, Red? where are you Red?" :-).
The quality of the demos themselves has already been discussed here, and
anyway they are better in person (or better yet, in a large crowded room
filled with enthusiastic Amigans :-). I will just make some comments on
the disks:
1> All the demos can be executed by icon, good job. This must have
represented quite a bit of work, since most of the demos came to the
contest without icons.
2> The demos are categorized by the amount of memory needed, nice touch.
The drawers have "comments" made from an invisible icon, interesting.
3> The bootable disks said "Boot Me!" and the non-bootable ones did not.
Finally someone does that right!
And now some negative comments:
1> The icon execution was not foolproof. For example "RotAmiga" looks for
the copy command at an absolute location instead of "c:".
2> Far too many of the demos were not very robust. For example,
"Kahnakas", "RotAmiga" and "Rocker" could be crashed by just hitting C= N
and C= N a few times.
Looking at the results, I propose some rule changes for next time:
1> All demos will be executed by double-clicking the supplied icon. If
special fonts or libraries not on the standard workbench disk are needed,
this must be clearly stated.
2> Eliminate the "Amiga specifics" category, or at least tabulate the score
by group consensus at the time of juding.
3> Technical score starts at 30 points and goes down based on certain
factors. If your demo is submitted X days early you will be given your
technical score and a chance to fix any problems BEFORE the contest. Fixes
after the contest, but before disk distribution, will be accepted but will
not affect judging. The factors are:
a> Not executable from an icon. -10 points.
b> Does not work properly with extra memory? -300 points (ouch!).
c> Does not work on a 68010 machine? -5 points. All you have to do is
avoid the MOVE SR,<EA> instructions, it is not tough!
d> Does not work properly on a 68020 machine? No penalty. -2 if it
fails to tell the user this when the demo is started on a '020 machine.
Again, your program has to be weird to have any chance of failing.
e> Fails to returns control to user after exit. -5. If there is no
warning this is going to happen or no way to abort after the icon is
clicked, -20.
f> Can all the icons be selected from the supplied disk, moved to
another arbitrary drawer, and have the demo still work? -5 if not.
g> Could our bug bashers crash your demo? -1 to -15 depending on
circumstances.
h> Did it work if the system font was set to Topaz 60? -2 if not.
i> Did all memory come back after the program exits (After the any
libraries and/or resident fonts are flushed back out)? -10 if not.
j> If deprived of memory, libraries, fonts or hardware sprite
allocation was the error response reasonable? -5 if not.
k> Does it work with interlaced and/or oversized Workbenches? -8 if
not. An additional -2 if the demo has a window that is arbitrarily
restricted to 640*200 pixels. Hardware sprite based demos are exempt
from the appearance of sprites due to overscan conditions.
l> If the user tries to interact while your demo is running (dragging
screens, clicking the mouse, C= N and C= M) is your response at least
benign? -5 if not.
Yup, negative scores are possible, but unlikely.
This should ensure that the demos are of high quality and will help the
Amiga's good reputation when placed in the hands of novices.
GOOD LUCK NEXT YEAR!
|\ /| . Ack! (NAK, SOH, EOT)
{o O} . bryce@hoser.berkeley.EDU -or- ucbvax!hoser!bryce
(")
Ukeithd@cadovax.UUCP (Keith Doyle) (11/13/87)
In article <21732@ucbvax.BERKELEY.EDU> bryce@hoser.berkeley.edu (Bryce Nesbitt) writes: > e> Fails to returns control to user after exit. -5. If there is no > warning this is going to happen or no way to abort after the icon is > clicked, -20. I have a comment about this. I don't think it should be required that the demo should run once and then quit. Dealers like to see demos that loop forever so they can leave them running on the machine. RGB was set up to run once and then quit (because it was in the contest rules) but now we are trying to get everyone a version that loops because that's what the stores want. Having two versions out there is a pain. However I agree there should be some way to cause it to abort without rebooting. > k> Does it work with interlaced and/or oversized Workbenches? -8 if > not. An additional -2 if the demo has a window that is arbitrarily > restricted to 640*200 pixels. What's the definition of "arbitrarily" here? Keith Doyle # {ucbvax,decvax}!trwrb!cadovax!keithd Contel Business Systems 213-323-8170
bryce@hoser.berkeley.edu (Bryce Nesbitt) (11/14/87)
In article <1869@cadovax.UUCP> keithd@cadovax.UUCP (Keith Doyle) writes: >In article <21732@> bryce@hoser.berkeley.edu (Bryce Nesbitt) writes: > >> k> Does it work with interlaced and/or oversized Workbenches? -8 if >> not. An additional -2 if the demo has a window that is arbitrarily >> restricted to 640*200 pixels. > >What's the definition of "arbitrarily" here? Arbitrary means that, the application supports a larger window size than the Window's "maximums" are set to. Case in point: (Some of the) Infocom games support word-wrapping to your current window size, make the window smaller and it adjusts. The maximums are set to 640*200. This is 255% smaller than my 704*464 display allows. Merely by filezaping the constants in the program code I can modify the progam to use the space... it works. Remember programmers... set the window maximums to whatever the maxium *your* application can support, even if it is larger than the current screen you own. To specify "no limits", set the size fields to ~0 (or -1, same thing). The Intuition manual example is *wrong* in encouraging 640*200. >I have a comment about this. I don't think it should be required that >the demo should run once and then quit... Yes, I agree. An advanced user could set up a script, naturally. Infinite loops are desirable for dealer demos. A slideshow of all the demos on the disk would be even better, but then each demo would need to automatically exit. >Dealers like to see demos that >loop forever so they can leave them running on the machine. RGB was >set up to run once and then quit (because it was in the contest rules) >but now we are trying to get everyone a version that loops because that's >what the stores want. Having two versions out there is a pain. I suggest using "LOOP=ON/OFF" in the tooltypes. *One* version would serve both. Also it needs to be easily abortable, the invisible gadget in the upper left seems to be a workable de-faco standard. |\ /| . Ack! (NAK, SOH, EOT) {o O} . bryce@hoser.berkeley.EDU -or- ucbvax!hoser!bryce (") U
ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) (11/15/87)
In article <1869@cadovax.UUCP> keithd@cadovax.UUCP (Keith Doyle) writes: >In article <21732@ucbvax.BERKELEY.EDU> bryce@hoser.berkeley.edu (Bryce Nesbitt) writes: >I have a comment about this. I don't think it should be required that >the demo should run once and then quit. Dealers like to see demos that >loop forever so they can leave them running on the machine. RGB was >set up to run once and then quit (because it was in the contest rules) [ ... ] Memory fault: I quote from the rules: "Each demo shall have five minutes to load, and 60 seconds to run. If it does not terminate of its own accord by this time, it should have clearly indicated a method of termination, and it will be ended." I interpreted this to mean that loops are permitted, as long as there's an obvious way to break out back to a working WorkBench or CLI. Hence, Marketroid loops, with a message in the main title screen telling you how to exit. Just a clarification. _-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ Leo L. Schwab -- The Guy in The Cape ihnp4!ptsfa -\ \_ -_ Recumbent Bikes: dual ---> !{well,unicom}!ewhac O----^o The Only Way To Fly. hplabs / (pronounced "AE-wack") "Work FOR? I don't work FOR anybody! I'm just having fun." -- The Doctor