Copy Link
Add to Bookmark
Report
Demo News 137
______/\__________________________ __ ________________ ___ /\_______
\____ \ ________ _ _ ______ \ / \| \ ________ | \/ ______/
/ | \ _) \ \_/ \ | \ / \ \ _) \ | \______ \
/ | \ \ | \ | \ / \ \ / \ \ / \
\_____ /_______/___| /_______/ \____\_____/_______/_________/________/
\_____/ |____/
Subscribers : 2618
DemoNews 137 - 21 December 1996 Archive Size : 3683M
>------------------------------------------------------------------ Contents --
Introduction
Calendar
Top Downloads
New Uploads
Articles
Software Design for Demos ..................... Kiwidog
Ratings - What Does It All Mean? .............. Phoenix
NAID - Memories ............................... White Noise
Java and Demos ................................ 3NO
Hornet Archive And Jukebox Truth .............. David Greenman
A Demo Scene Survey ........................... Nick
The #trax Page ................................ b0b
General Information
>-------------------------------------------------------------- Introduction --
Ho ho ho, and welcome to DemoNews 137.
_____Introduction
[Note: I will be on vacation from 21-29 of December.]
1997 is about 10 days away. It's time to buy a new calendar and give the old
one to the packrat in the family. Everyone seems focused on Christmas and
the passage of another year. And why not? A "year" is a really nice chunk
of time. It's long enough to define an era of the demo scene, yet short
enough not to obscure memories of previous years.
So what does 1997 mean to me?
mkdir /demos/1997
mkdir /music/songs/1997
mkdir /graphics/images/1997
...
:D
I've been contributing to the scene since 1992. There are others out there
who have been around longer but their number is small and becoming more so.
However, as a result of the roles I've had in the scene I feel I have a
unique perspective on things. I'd like to share some history and future
predictions.
_____The Past
Since I wasn't in the PC scene until 1992 I can't really talk about things
before then. I do know that in 1992 things were drastically different then
they are now. A soundcard was a totally cool _optional_ component of your
system. Demos almost always outshined games in terms of technology and
innovation. There was no web. The Internet was still a buzzword to most of
the scene. In September, Dan Wright started the Hornet Archive and DemoNews.
1993 brought the scene a GUS and a new standard. People started jumping on
the 'net and sending international email without even logging onto a BBS! And
with that change a lot of localization in the scene fell to the wayside...
national scenes turned into continental ones. Connectivity brought us faster
access to new releases around the world. Second Reality came out and a new
generation of demo enthusiasts were born. I personally consider 1993 to be
the best year in modern PC demos history.
1994 was like 1993++. More people hopped online. PC hardware was finally
getting consistent. You could on people in the scene having a 486 and a SB
and/or GUS. The music scene was starting to take off and become almost
another entity. Everyone still knew how to navigate in DOS. Trying to run
demos under Windows 3.1 was laughable. People usually belonged to one group.
IRC was a very nice size and mostly cool people hung out there.
Then came 1995. You could count on almost everyone having an email address
and net connectivity. Demo parties started popping up everywhere. There was
explosive growth everywhere. Unfortunately, demos were starting to lose
their technological edge and public appeal. The masses who would have
dropped their jaw at Second Reality in 1993 were bored to tears with Dope.
The scene started to see the death of DOS in sight and were confused. What
OS to go to next? Windows 95, Linux, or something new?
Earlier this year I think the scene pretty much decided to stick with Windows
95, for better or worse. No longer could you count on people understanding
DOS or being as resourceful as they were in 1993-1994. A huge influx of
newbies appeared in the music scene. The BBS's have all but died and
everyone and their kid sister creates web pages. I used to give
presentations at local computer clubs and high schools about the demo scene.
The audience used to be captivated that such things existed. Those same
people today are more interested in Bevis and Butthead AVIs, obscene WAV
files, and Java applets that crash '95 than they are about demos. This is
sad.
_____The Future
Today the scene is thinking about moving from DOS to Java (how odd that
sounds). I see this move as having one of two different outcomes. First, we
can rekindle some of the innovation and creativity we used to have and
totally stun the world with our productions. Or second, we get lumped into a
general category: pretty cool Java applet makers. I hope for the first but
expect the second. :(
All is not lost though.
One really neat thing the scene has is the ability to earmark its members.
Even though the public has found our secret little world and invaded it, we
still know who is _really_ in the scene and who isn't. And it isn't a fuzzy
distinction. You either are in the scene or you aren't. We know no middle
ground. I'm happy that this aspect of the scene hasn't changed. It gives us
a nice, solid, protective buffer from the outside world.
Predictions? I'm really hesitant to make any strong ones. I do know that
the scene is volatile and changing dramatically. This is not a statement I
would have made at the end of any other year except for 1996. 1997 will
affect the very core of the scene... what OS we support, how we deal with the
public (or avoid them), the death of the GUS standard, the commercial
invasion, newbies who are totally lacking in basic skills, etc.
_____Conclusion
Of one thing I am certain. 1997 will define a new era of the demo scene.
Snowman / Hornet - r3cgm@hornet.org
>------------------------------------------------------------------ Calendar --
Date Event Location Contact Points
------------ ------------------- --------- ----------------------------------
CANCELED! Demobit Slovakia demobit@elf.stuba.sk
internet.sk/demobit/english.htm
CANCELED! Tesko UK party@tesko.demon.co.uk
09 Dec 1996 Movement Israel civax@kinneret.com
* <-- YOU ARE HERE
27 Dec 1996 The Party 6 Denmark theparty@vip.cybercity.dk
www.theparty.dk
15 Feb 1997 General Probe 3 Poland s146630@ire.pw.edu.pl
28 Mar 1997 Mekka & Symposium Germany amable@aol.com
04 Apr 1997 X Takeover Holland x97take@freemail.nl
12 May 1997 The Place To Be 4 France www.mygale.org/05/dadu
22 Aug 1997 AntIQ Hungary aboy@ttk.jpte.hu
www.jpte.hu/~aboy
>------------------------------------------------------------- Top Downloads --
This represents combined ftp/http transfers for the last 7 days.
Sorry, my "get description" subroutine broke and I didn't have time to fix it
before these statistics were generated.
Total files downloaded : 182,943
Size of files downloaded : 27,130,504k
Times File Description
----- -------------------------------- --------------------------------------
-- /demos ------------------------------------------------------------------>
198 /demos/1995/a/animate.zip
155 /demos/1995/n/nooon_st.zip
135 /demos/1993/u/unreal11.zip
126 /demos/1993/s/symbolog.zip
119 /demos/1996/a/ai_strok.zip
118 /demos/1993/0-9/2ndreal1.lzh
114 /demos/1996/p/paper.zip
113 /demos/1996/m/machines.arj
109 /demos/1993/0-9/2ndreal2.lzh
108 /demos/1996/m/machines.a01
-- /music ------------------------------------------------------------------>
100 /music/songs/1995/s3m/a/aryx.zip
76 /music/songs/1996/s3m/a/athought.zip
66 /music/songs/1996/s3m/i/im_chron.zip
60 /music/songs/1996/s3m/i/im_empir.zip
59 /music/songs/1996/xm/r/raf-bost.zip
56 /music/songs/1996/s3m/f/fm-mech8.zip
56 /music/songs/1995/s3m/c/ctgoblin.zip
55 /music/songs/1996/s3m/f/fa-bung.zip
51 /music/songs/1996/s3m/c/ccs-eps.zip
50 /music/songs/1996/xm/a/anthem.zip
-- /graphics --------------------------------------------------------------->
18 /graphics/images/1996/c/chantal.zip
17 /graphics/images/1994/i/incest5.zip
16 /graphics/images/1996/a/airwar.zip
13 /graphics/images/1996/a/abc_land.zip
12 /graphics/images/1996/i/impcybor.zip
12 /graphics/images/1996/a/abc_pien.zip
12 /graphics/images/1996/0-9/3dots.zip
12 /graphics/disks/1996/pls_wild.zip
11 /graphics/images/1996/v/voyeur.zip
11 /graphics/images/1996/s/scarlet.zip
-- /code ------------------------------------------------------------------->
81 /code/effects/3d/3dtext.arj
75 /code/effects/3d/fh-3dt18.zip
74 /code/tutor/tut21.zip
73 /code/effects/tunnel/araidsrc.zip
68 /code/effects/rotozoom/pasroto.zip
67 /code/effects/blobs/blobs.zip
66 /code/effects/vector/rn_vect.zip
66 /code/effects/phong/mphong.zip
65 /code/effects/voxel/voxeltut.zip
64 /code/effects/wormhole/stargate.zip
-- /incoming --------------------------------------------------------------->
64 /incoming/music/disks/fm-plast.zip
62 /incoming/music/songs/xm/t2.zip
55 /incoming/mags/sub00004.zip
53 /incoming/demos/astralf.zip
52 /incoming/code/chaossrc.zip
50 /incoming/demos/riplview.zip
49 /incoming/music/disks/u-lucid3.zip
48 /incoming/code/dos32vbe.zip
47 /incoming/demos/1k_intro.zip
>--------------------------------------------------------------- New Uploads --
All ratings are subjective.
Filename Size Rated Description
------------------------------- ---- ----- ----------------------------------
-- /demos ------------------------------------------------------------------>
/1996/0-9/1stepfix.zip 7 ** CAC96B:in4k:??: The First Step by
| Brave Lamers
/1996/a/abc_voda.zip 808 *** Voodka by Absence
/1996/a/ai_mutha.zip 936 ***+ CAC96B:demo:01: Mutha by Astroidea
/1996/a/amitro.zip 4 + Amitro by Damage PC
/1996/a/ashes.zip 65 ** Ashes by Tate
/1996/b/booth.zip 274 ** SEN96:demo:??: Booth by MFX
/1996/b/br-1st.zip 841 [n/a] CAC96B:demo:??: First by Black
| Rainbow
/1996/c/clx_nog.zip 2802 *** SEN96:demo:??: No Garden by
| Complex
/1996/c/cob.zip 67 **** SAT96B:in64:12: Cob by Nooon,
| Orange
/1996/c/comahomo.zip 567 **+ SEN96:demo:03: Homo by COMA
/1996/d/dem3sat4.zip 404 *+ SAT96B:demo:06: Tartofraise by
| Horizone
/1996/d/dny-inac.zip 70 *** CAC96B:in64:??: In Activity by
| Dinasty
/1996/e/elite.zip 274 * The Elite Demo by Intra
/1996/e/explora.zip 1509 ***+ SAT96B:demo:02: Explora by Bomb,
| Oxygene
/1996/f/fade.zip 59 *** CAC96B:in64:??: Fade by Exact
/1996/f/fastark.zip 1283 *** SAT96B:demo:03: Fast by Arkham
/1996/f/fg-porno.zip 463 + CAC96B:demo:??: Porno by Firg
/1996/f/fizzygay.zip 61 **+ SEN96:in64:??: Peter and I Like
| Fizzy Water... by TPOLM
/1996/f/frs_clue.zip 78 **+ CAC96B:in64:??: Clue by Fresh
/1996/g/grd_eqtn.zip 58 **+ Equation by The Grid
/1996/h/h_empty.zip 66 ***+ SEN96:in64:01: Empty by Halcyon
/1996/i/io3_4k.zip 15 Intel Outside 3 4k Intro Compo
| Entries
/1996/k/kala.zip 1419 [n/a] SEN96:demo:??: Kalanviljelylaitos
| by Tempest
/1996/m/mantmag.zip 2084 ***+ SAT96B:demo:01: Magma by Mentasm
/1996/m/muna.zip 1053 * SEN96:demo:01: Muna by Hirmu
/1996/n/ntl.zip 81 ** SAT96B:in64:06: Not Too Late by
| Skytech Group
/1996/p/p-statio.zip 71 *** SEN96:in64:??: Station A. Hoffman
| by Paragon
/1996/p/pastel.zip 19 **+ CAC96B:in4k:??: Pastel by
| Controlled Dreams
/1996/p/pearl.zip 60 *** Pearl by Poison
/1996/p/pierre2.zip 910 [n/a] SEN96:demo:??: Pierre Deux by Coon
/1996/p/probe.zip 602 *** CAC96B:demo:03: Probe by
| Euthanasia
/1996/r/ravetro.zip 69 **+ CAC96B:in64:??: Ravetro by Byteam
/1996/s/sat_ast.zip 223 *+ SAT96B:demo:05: Narguileh by AST
| System
/1996/s/sck-onyx.zip 1546 ***+ CAC96B:demo:02: Onyx by Shock
/1996/s/sphere.zip 76 ***+ CAC96B:in64:01: Sphere by Mortal
| Compact
/1996/s/ste-08.zip 123 *+ N0ll 8tta by Syntax Terror
/1996/s/ste-die.zip 111 * Doo by Syntax Terror
/1996/s/ste-stlf.zip 423 ** REM96:demo:04: Don't Get Stajlish
| (final) by Syntax Terror
/1996/s/super_.zip 691 **+ SEN96:demo:02: Superman's Day Out
| by TPOLM
/1996/t/talo.zip 116 * SEN96:demo:??: Talo by P33107
/1996/t/the_cube.zip 19 *** CAC96B:in4k:01: The Cube by Fishy
/1996/t/tls_time.zip 580 *** Time by The Lost Souls
/1996/u/uf_depr.zip 1295 ** CAC96B:demo:??: Depravity by
| United Force
-- /party ------------------------------------------------------------------>
/invites/1996/cache96a.zip 532 [n/a] CAC96B::: Cache '96 Autumn
| Invitation Intro by Unicorn
/invites/1996/demol2.zip 216 *** DML96B::: Demolition II '96
| Invitation Intro by Ws, Solen
/reports/1996/p2b4_myo.zip 3516 ** The Place To Be IV Slideshow by
| Myopath Crew
/results/1996/cac96a.res 0 CAC96B::: Cache '96 Autumn Results
/results/1996/cov96res.txt 3 COV96::: Coven '96 Results
/results/1996/w96res.zip 4 WIR96::: Wired '96 Results
>------------------------------------------------------------------ Articles --
---------------------------------------------------------------------------->
:: "Software Design for Demos"
:: Kiwidog - chargrove@mail.ravensoft.com
_____Introduction
Hello everyone. :)
As I wrap up the Intro to 3D series in extremely late fashion in my spare
time, I've decided to start writing another article series on a topic not
talked about very often in demo coding... software design. This has been a
somewhat touchy subject because good coding design practices are hard to
learn in an environment where ultra-rapid speed is all that counts, and where
the coders typically are self-taught individuals in their late teens to early
twenties.
From what I've seen, there are three prevalent views among demo coders I've
talked to; they either A) think good coding practices necessitate intolerably
slow code, B) think good coding practices require unnecessary effort when
writing demo code, and/or C) think taking the time to learn good coding
practices wouldn't have much benefit as far as demos go.
While B may be true depending on your situation, A and C are most definitely
myths, and I think these myths are slowly contributing to the scene's gradual
"falling behind" as far as innovations go. The times of making tiny single
routines that look super-impressive to everyone are over, and making large
demos that have impact is getting more and more difficult with time. As a
result, people are either making crappy or unoriginal demos (such as the
3D-engine-object-show rut), or even worse, not making demos at all... and the
scene is losing its edge because of it.
For the past 5 months or so, I've been employed at Raven Software, a game
company whose games you've worst case seen on the shelves, best case played
and enjoyed (I'm not going to plug the company since this is not a sponsored
article, but you knew I'd bring them up somewhere :) In these 5 months I've
ended up learning more than I could possibly fathom previously about writing
good code. Not just fast code or small code.... _good_ code. If you don't
know what that means, you haven't had to deal with the frustration of coding
a large project, and if you think you know what it means and think it's not
as "good" really because it means bloated and slow, you're wrong.
I think that if demo coders took the time to learn some good coding practices
and software design, it would not only allow them to focus more on the demos
themselves, but would also give them more power to really do in demos what
they enjoy doing the most... creating. If you're spending forever trying to
get your code to work with your teammates' code, or if you find yourself
rewriting your VGA unit every month, that's time taken away from the fun
part, the creating.
In addition, for those of you that are thinking of bringing your programming
skills into the outside world, good software design skills are a huge plus
(I'm not saying this as a prospective employer, as I'm not... I'm saying this
as a fellow coder who wishes he could have learned 2 years ago what he's
learned in the past few months, as it would have been incredibly helpful).
If the scene's going to get out of its rut and continue to move on to
bigger-better-faster things, it's also got to add one more property to the
list... smarter. Without coding smarter, coding faster won't do you any good
once the project gets intense.
So that's what this series is about. In this article series I'm going to
show you how to start creating a comprehensive demo library and development
system, which I am working on myself only shortly before these articles are
being written. We'll build this development system from the ground up, and
in the end you'll be able to take the practices used and move them over into
your own code, whatever your language or compiler may be.
This is not a rigid "cut and paste my code and you will code perfect demos"
thing by any means; at the time of this writing I'm still working on making a
full demo, so I can't speak for this stuff being gospel (actually it can most
certainly be improved). But I think it's the _principles_ that are
important, and those don't change regardless of what language you prefer or
how fast your texture mapping algo is. Think of it as a "helpful hints" type
of thing. :)
The key points I'll be going over during this whole shindig:
- Good naming conventions
- Organization for large projects
- Code Re-Use
along with a couple demo-specific things that I've found useful, such as
process queues (fake multitasking for effects) and internal consoles for
on-line development.
This is not a basic intro series like I did last time; this is a bit more
high up. Not _too_ high up, but a bit more than before. To really gain from
these articles you'll probably have had to have had frustrations in the past
with large project organization (I could name a certain person from Psychic
Monks that would fit this category from this past NAID, but he already knows
who he is :) Trust me, I've had just as much frustration, so you're not
alone.
_____Dammit Kiwi!
Here's the part where I'm sure there will be a lot of coders screaming
"DAMMIT KIWI!", and before you do, read the whole section.
The language of choice for me to write the code for this series is C++.
If you find yourself screaming "Demos using C++? What the hell is he
thinking? C++ is bloated and slow, it's what you write Windows programs
with, not demos! This sucks!", then perhaps reality will set in when you see
that C++ code overhead is.... well....
Zilch.
That's right, nothing. No overhead. The only reason C++ code can be slower
than C code is if you abuse it, and granted it is easy to abuse... but you
don't have to (BTW when I say C++ code I mean using the object-oriented
extensions of C++... in other ways C++ is really just a superset of C).
Want proof? In later articles you'll have proof yourself with the example
source (which for the people who read my 3D articles, you'll be happy to know
that this time the example source is already written). But for now, let me
give you an example.
I have a program called PROCTEST.CPP which is the main file of a project.
Inside this program there is one "routine" declared which is a function set
framework used for a repeated operation; this routine happens to be a set of
empty functions, so they do nothing. An instance of this routine is created
by declaring a "process", which is a class that takes a routine frame to tell
it what it's supposed to do, and this process is set to "spawn" on the
execution of a particular "event", a linked-list structure holding sets of
manual spawn and kill orders.
Events can be rigged to certain things like music sync points or other
process kills, but in this case, the event is executed directly. The spawned
process is now added to the process execution queue, and this queue is
executed every frame by checking all processes in the queue, getting current
timing information for each, (built-in profiling), and executing the process'
prime functions, checking for any hooked events or internal self-kills from
the process.
Another process is created from another routine frame, but this routine does
something; it quits the program if a key is pressed. This process is also
set to spawn at the initial event, so during the main process queue cycle,
both an empty process and a key-quit process are being run, as well as all
the other empty slots in the queue being checked for validity information.
Sound confusing? That's okay. Sound huge? Understandable. Sound object
oriented? Extremely. Wanna know how long it takes to execute a frame,
built-in-profiling-multi-process-execution and all?
On my P75 at work, 0.000244 seconds, under Win95 even. This is an accurate
timing, as I'm reading the PIT directly (< 900ns granularity) which is not
affected by Win95's timing quirks except to point out that normal interrupt
latency exists (i.e. without interrupts the result would be even better than
it already is!).
So if you want to complain about overhead, you're complaining about the wrong
thing. We're talking about a small fraction of a screen clear's worth of
clock cycles, for something that on the outside might appear "bloated and
slow". If you want to spend your time complaining about clock cycle loss,
optimize your polygon routines more... but don't go whining that C++ is
inherently slow; you'd be barking up the wrong tree and only doing yourself a
disservice. How you _use_ the language is what counts.
There, now that that's said...
_____So What Exactly Are We Planning To Do?
I'm planning to cover this development process piece by piece, first with how
to arrange for large projects, followed by naming conventions, and then on to
starting the library itself. Once you get the hang of how the system works,
the library's internals won't matter too much (we'll only be doing a few of
them with this series); you'll be able to use your existing knowledge to fit
the pieces together. The internals we will be building here will be the ones
you might not have dealt with, namely the process queues and internal console
mentioned before... so if you take nothing of the software design process
away with you, you'll at least take away two more techniques that one way or
another could help you in your coding.
I'll also be going over some of the nuances of using C++ for you C folks
here as we go on; there's really not as much to learn as you might think.
This series will undoubtedly spread over many articles, but unlike my 3D
series there's no rigid "this article this topic" structure or timeline
(which should make Snowman happy as far as size limits go :) I don't plan
on the series lasting forever, but there might be a few weeks between
subsequent articles to compensate for the fact that I have a job to deal
with too (still, there shouldn't be too much lag... the code's already done
this time, and the article-writing time isn't nearly as long as the code-
writing time, so we should be in good shape).
BTW, all my code will be written for Watcom C++ 10.0+, so when you see code
or makefile references, that's what I'm using. Any specific stuff to the
compiler though should be minimal, and besides as I said before, it's the
principles that matter.
Well, now that I've taken up half my article space for this opening volume,
we might as well begin... :)
_____Setting Up for Large Projects
There are several principles that come in handy when you want to move from
a small project arrangement to a large project one.
1. Multiple Directories and/or Version Control
If more than one person is working on the project, Version Control software
is a good idea, whether you make it yourself or get some kind of actual VCS
package like RCS or MS SourceSafe (BTW I highly recommend SourceSafe for you
MSVC developers out there). Version Control lets you "check out" files from
a particular project, edit them, and check them back in when you're done...
that way no two people are editing the files at the same time. It can get
nasty if two people are updating a module and one person is making additions
to an older version than another person has, and when the updates are
completed the stuff from the older version remains while other newer version
changes by other people are wiped out. Version Control prevents this from
happening.
If you're a single person, Version Control might also be helpful to you, but
if you don't have it, then you'll want something else to help structure where
your files are located (as there is no package present to manage the
locations for you like VCS will), such as multiple source directories.
Breaking down your project into multiple subdirectories for individual
components can help assist in making changes and updates, as you always know
where your code for a given type of module should be.
2. Make Use of Library Files
The .LIB extension seems all too uncommon these days, but it can be very
helpful. For one, projects using a common .LIB will not link with any dead
code from the library; only the functions used will be linked in (for you
Pascal folks, this basically means use units extensively). In addition,
the .LIB can then be a project in itself, so any of the code meant for the
library can be kept in the library project _only_ and nowhere else, allowing
you to keep track of where you should make changes. Not to mention that
if the the .LIB is a project, then when this project is updated and other
projects are meant to use the .LIB, all that's required is a relink by the
other projects, and everything is new and fresh.
3. Use IDE Projects and/or Makefiles
If you have an IDE associated with your compiler that supports projects, take
advantage of it. If you don't (or you just don't want to use it, like in the
case of Watcom's Windows IDE which I despise), and makefiles are supported,
use them. Even better, in the case of projects that use common resources
(like a common .LIB as mentioned above), you can set up a single makefile
with variables that can be changed on the command line for individual
projects. As an example, my arrangement has a subdirectory \PROJECTS, with a
single makefile PROJECTS.MAK. Each project I make goes underneath this
directory, and they all build with ..\PROJECTS.MAK, so there's only one
makefile to change if changes are required.
4. Use Generators
Generator programs, such as programs to generate a class frame with a
particular name or "buildme" batch file for a particular project, only take a
few minutes to write yet can save you an incredible amount of time and
headache. In the case of the above PROJECTS.MAK example, having a small
program called NEWPROJ that creates a project directory and writes a batch
file "BUILDME.BAT" in the dir with the line "wmake /f ..\projects.mak
TARGET=(command line param)" is quick and simple to write, but saves a nice
chunk of time in the long run.
For module frames, doing a similar program that writes an entire module
template with a specific name saves tons of grunt work cut&paste time, and by
the same token gives you a common frame to work with so your code is
consistent. I wrote my class frame generator in 15 minutes, but I'm positive
it's saved me at least 5 hours of grunt work time by now. :)
5. Have Effective Naming Conventions
This last one is a topic unto itself, which I'll get to next time. Having
some kind of standard way to name your variables, functions, and structures
may seem too "nitpicky" or "anal" at first, but it can save you phenomenal
headache over time, ESPECIALLY if there's more than one person involved in
the project. I'll get into specifics in the next volume.
_____Conclusion
Welp, my space has run out, so I'm taking off. Next time we'll discuss all
the ins and outs of good coding style and naming conventions, and why no
matter what convention you choose, you should choose one.
Until then, :)
Chris Hargrove
a.k.a. Kiwidog/Terraformer,Hornet alumni
Technology Programmer, Raven Software
Disclaimer: These articles are in no way affiliated with Raven Software, and
represent the views and opinions of the author solely.
---------------------------------------------------------------------------->
:: "Ratings - What Does It All Mean?"
:: Phoenix / Hornet - phoenix@hornet.org
_____Introduction
Ratings - What Does It All Mean?
Ever since last year, we at the Hornet Archive have been stamping a little
rating onto each demo, song, musicdisk, artwork, and sometimes even coding
util that gets uploaded. These ratings have certainly helped people in
deciding which releases are the "best" and which to not waste their time
downloading, but at the same time they've been a source of controversy and
confusion.
Assuming you've cared at all, you've probably asked yourself "what do all
these stars and other weird ratings mean?" Well, here's your humble demo
reviewer to attempt an answer to that, with my personal scale for demos.
_____The Scale
+ - Total crapola. Offensive. A bad joke. Why did you make me watch
this?
* - Ugly. Lame. An average joke.
*+ - A really poorly done serious demo. Effects from 1991, bad gabber,
no design. Or, a pretty good joke demo. :)
** - Still below par. Old/overdone effects, unfitting music, little to
no gfx.
**+ - Mediocre. May have some modern effects, but poorly used. Music
could use some improvement.
*** - Decent/slightly above par. The minimum of what I'd expect from
current demos. The music is listenable and fits with the demo. Has
modern effects, but some may be overdone. Some OK gfx.
***+ - Very good. May have a new effect or two. There's some design with
graphics and transitions. "Catchy" music. I start keeping demos on
my hard drive at this level.
**** - Excellent. These are usually the smaller party winners. A
memorable design/theme with good gfx (if any). Many interesting
effects, and high quality, well-synchronized music. I start
recommending demos to others at this level.
****+ - Outstanding. I'd only give about 5 or so demos this rating per
year. Usually the major party winners, they contain almost all new
effects, including one or two ingenious ideas. Well-fitting music
once again, and usually top-notch graphics, if not design.
***** - Godlike. I'm saving this for the mother of all demos. After
watching several hundred of them, deep inside I still believe that
there will be some that make me fall off my chair.
[rip] - Uh oh. Contains mostly code/gfx/music that obviously came from
another release, but wasn't credited. I've given a couple of these,
and deleted one intro that was a complete rip. Boo.
[n/a] - Most of the time, this means I could not get the demo to work. My
current system is: 486-DX4/75, 8MB RAM, 1MB ET4000 VLB VGA, GUS ACE
512k, and SB Pro. Not too great for recent demos (although I think
it should be), but hopefully it will soon be: 6x86/120, 16MB RAM,
2MB S3D PCI VGA. Under various software configurations I can run
about 90% of the demos, but my goal is 99% under the new system.
(blank) In my departments, party results and pictures do not get rated;
graphics programs and newsletters do not either.
_____Factors In Demo Ratings
Some of those demo ratings may seem a little more unusual than others, but I
have a logical explanation for each one. These are some of the factors that
go into the ratings.
Music + catchy, well-synchronized, style fits mood of demo
- boom chi boom chi rez boom rez chi
Code + new effects, creative combination/use of old effects
- old effects, and even worse, overused effects (e.g. 2D embossing/
bump, tunnels, polar plasma, polar ANYTHING, lens flare, circling
bobs [they may have looked pretty in Caero but they're just bobs :)]
strobing vectors, etc.)
Design + creativity gets points (e.g. Toasted, Paper). So do transitions,
well drawn logos and pictures, and good use of color.
- trying to imitate stuff done before, or just not having any design
I'm neutral on "thematic" demos (like Craw Prod. stuff). Sometimes
they work, sometimes they don't.
_____The Hitlist
If it was not made clear in DN #135, here's who rates what:
/demos, /party - Phoenix (me :)
/graphics, /mags - GD
/music - a small group of people, who should probably remain anonymous since
this directory gets the most threats from ratings. :) JTown is the
file mover, however.
/code - Gee, I don't think any of us know who rates this. :) Sometimes it's
Snowman, sometimes Trixter, it's even been Daredevil before.
_____Conclusion
Anyway, I hope I helped clear up some confusion in demo ratings. All that is
left is confusion in other ratings.. well, I'll leave that to them. :)
---------------------------------------------------------------------------->
:: "NAID - Memories"
:: White Noise - jeff@ego.psych.mcgill.ca
You were at NAID, in 95 or 96? You entered something in a competition there?
A song, a graphic, a demo, an intro? Then you can help the Ultimate NAID
collection. Have a look at naid.conceptech.qc.ca, the NAID - Memories and
help us out by sending in what you submitted.
Also, should you have pictures of the party in digital format, or artifacts
such as ticket stubs or anything that you think could be nifty to add to this
Monument to NAID, please send it over.
The ftp site is at ftp.naid.conceptech.qc.ca/incoming/naid
Thanks for your help. Long live the memories...
White Noise.
(used to be in Hornet now lost somewhere in a void between his keyboard and
his schoolbooks)
---------------------------------------------------------------------------->
:: "Java and Demos"
:: 3NO (formerly Vector) / Vinlandia, Tpolm Kanada - jnoel@public.nfld.com
Hello again. Last week, I outlined my desire to explore Java as a possible
demo platform. Since the publication in DemoNews last week I have received a
number of responses, all positive. I have decided that instead of doing a
newsletter, I will write a regular column in DemoNews on the subject, most
likely every 2 weeks or so.
Just some brief notes for this week. I noticed on cspid (C-sped? :) about a
week ago mention of a web site with some demo-effects on it. Everybody
interested should check this out - it has a number of fire effects, as well
as a little starfield, which run directly in the web browser. You can find
this at http://www.uni-koblenz.de/~cohnen. It's a good example of what can
be achieved even at this early stage.
Also, one of the best sources of general Java information is the Sun Javasoft
site, http://www.javasoft.com. This contains various tutorials and docs,
including a complete outline of the High-level Java language and the Java
virtual-machine (JVM) specification.
This brings up an important point - I would like to start keeping track of
sources of demo-oriented Java sites, and will hopefully put up an index site
at some point. If anyone knows of any good sites, please email me.
The next thing I would like to talk about is Java music-playing. I was
talking to Mikmak on irc the other day, and he seemed quite interested in the
possibilities of Java, despite some of the shortcomings. (NO unsigned types
- argh!). He is apparently working towards a Java version of mikmod, and
told me that Rao has been playing with as well. In any event, if music can
indeed be played properly in Java, we could be seeing a few basic demos being
produced in the near future.
A Java tracker could also be interesting - portability is assured, and would
be a step towards more direct, on-line co-op composition. Makes me think of
that little blurb on the Kosmic web-page. :)
The last thing I want to mention is the whole issue of Windows 95 and DirectX
demos. Part of the reason I want to start exploring Java as a demo platform
is because of Windows 95 and DirectX. I feel DOS is gradually losing it's
relevance, and I also think it would be horrible if we all started making
Win95 and DirectX demos.
As one person on cspid said, it wouldn't be about finding new tricks but
finding bugs in the OS, and from my own experiences with Windows programming
I have to concur. I think Java is a much more exciting platform for demos,
because it is virtually uncharted territory. Besides, there's no reason why
Java in the future couldn't support all the accelerated hardware that DirectX
is supposed to.
Well, this is all I have for this week, and my next column will be 2 weeks
from now, hopefully. Have a good holiday, and make sure to email me if you
have any feedback, info, or good ideas.
---------------------------------------------------------------------------->
:: "Hornet Archive and Jukebox Truth"
:: David Greenman
_____Introduction
When the Hornet Archive started running out of room, one of the suggestions
people made over and over again was to have a CD jukebox on wcarchive for
additional storage. I tried explaining why this was a bad idea, but people
wouldn't listen. Here with us today is David Greenman, official maintainer
of ftp.cdrom.com (wcarchive).
_____The Scoop
> David, could you write a 3-4 paragraph summary of why using online CDROMs
> as additional storage for wcarchive is not feasible? I've have been
> getting asked this over and over again. As much as I try to explain about
> slow seek times, bad performance in multi-user environments, etc., your
> words would carry much more weight.
Here are a few of the reasons:
1. [most important] The archives change too frequently (usually daily), and
this makes permanent storage impractical.
2. We don't have physical access to the machine without an hour's drive to
San Francisco; see #1. We don't pay CRL for micro-management of the
machine, and co-location is the only way we can afford to provide the
level of service that we do. Getting them to insert one or two CDROM's a
month is perhaps possible, but one a day (or even one a week) is not.
3. Single CDROM drives are expensive in the MB/drive area - much more
expensive than hard drives. While juke boxes bring this price down
considerably, we can't use them because they are designed for single-
reader access, not 500-reader access. I'm afraid that the little carousel
would really be a spinnin'. :-) ...and people would see about 512 byte per
10 seconds transfer rates.
You could argue that some archives don't change (like releases of software,
for instance), but even for those, we simply have no archives that are
trafficked so infrequently that #3 wouldn't kill you every time. Archives that
are so unpopular where #3 wouldn't be a problem would (should) be deleted
since they don't contribute significantly to the value of the archive.
Of course there is also the problem that, while specific software releases
don't change, new ones do come out occasionally and the sum total of all new
software releases that are put up on wcarchive each day would still make
#1/#2 a show-stopper.
David Greenman
Core-team / Principal Architect, The FreeBSD Project
---------------------------------------------------------------------------->
:: "A Demo Scene Survey"
:: Nick - stilgar@crush.wwnet.net
[Editor's note: You won't believe how much trouble I had in printing this
text. Nick emails me a survey (for a class project), I fill it out, send it
back, and promise to put a copy in DemoNews. Then I lost the survey. Then
the deadline passed. Finally, Nick decided that he'd would persue the
project outside of school and could extend the deadline. So here we go.]
_____Introduction
Note: I realize that time is limited, so if you don't feel like answering all
the questions, don't; the first two and the demographics would be nice, or
maybe just skip the first five, and head straight into the multiple choice.
_____Essay Questions
1. What does the scene mean to you?
2. In your mind, what is the best quality of the scene?
3. What is your favorite demo? Why?
4. What first interested you about the scene? Or, how did you first learn
about/get into/whatever the scene?
5. Do you see Microsoft as a necessary evil, or just evil? ;)
_____Multiple Choice
6. Do you think the scene will shed its underground? roots?
A. Yes.
B. No.
C. I hope not!
7. Do you think the scene will ever be superseded by larger (perhaps
corporate) interests?
A. Maybe.
B. No way!
C. Why are you asking this?
8. By the year 2000, do you think the scene will have:
A. Grown immensely
B. Grown, but not by an extreme margin
C. Stayed roughly the same size
D. Started to die out
E. Become a force to reckon with
9. By the year 2000, how do you see your relationship with the scene?
A. Still immersed in the wonderful world of demos.
B. Reduced role.
C. Casual Observer.
D. Moved on to other things.
10. How do you plan to use your experience in the demo scene to support
yourself later in life (or how *did* your experience..)
A. Go into business for myself.
B. Find a job in a related computer industry.
C. It has really just been a hobby.
D. I plan on using the experience to change the computing status quo.
_____Demographic Information (optional)
Age:
Country:
Group:
_____Conclusion
When you are done, please cut out this survey from DemoNews and mail it to
stilgar@crush.wwnet.net. Thank you for your time.
---------------------------------------------------------------------------->
:: "The #trax Page"
:: b0b / Chill, Ultrabeat, Mazurka - b0b@datex.ca
There's this little page out here on the www called the #trax page. It's the
semi official home of all the people who frequent the IRC channel, #trax. In
recent times, people beyond the scope of the #trax culture have also logged
onto the page and added their entries. It has become more of a demoscene
megalink page now. The page gives people the ability to edit their own
entries; most people log onto the page to modify their bio's on a regular
basis so the page stays very up to date for the most part. Or so that's the
theory. :)
Currently the page has over 340 people listed, over 150 pictures of scene
people, and about 20+ group listings (and growing). One of the newest
features of the page gives everyone the ability to add/edit and delete
'releases' to their bio's. Your releases can be hyperlinked to an FTP or
HTTP server where the file might be stored. This feature although VERY cool
has not really caught on. :( So let's see you people adding in your
releases!!!
Recent updates include:
- fixed links section (took out pictures, looks nicer now).
- fixed some source code bugs that no one else really noticed.
- added about 15 new pics and updated about 10 other pics.
- added about 4 new groups.
- shrunk the damn logo so that it doesn't take nearly as long to load now.
- fixed all the pages so that you can resize them and they don't screw up.
Some people may have noticed lately that there were a lack of updates. The
reason being that I got very busy at my "real job". Luckily things have
slowed down due to the X-mas season and I was able to reply to the 100+
messages in my mailbox regarding the page. If there anyone now who has sent
me something via e-mail and has not received a reply please resend your
message.
Lastly, there are still over 100 people who have not logged onto the page to
change their default password. On 01 February 1997, I will be deleting all
entries that have not updated your password.
The default password is: XXXXXX
Six x's. So login and change it if you havn't.
Thanx.
And remember: http://www.spaz.com/trax
>------------------------------------------------------- General Information --
_____The Hornet Archive
Master Site : USA (California) - (ftp|www).hornet.org/pub/demos
Mirrors : Portugal - ftp.telepac.pt/pub/demos
Sweden - ftp.luth.se/pub/msdos/demos
South Africa - ftp.sun.ac.za/pub/msdos/demos
USA (Wisconsin) - ftp.uwp.edu/pub/demos
USA (Pennsylvania) - ftp.co.iup.edu/code (from /demos/code)
_____DemoNews
New issues are posted to /incoming/info.
Old issues are in /info/demonews.
Supplemental files are in /info/dn_other.
How to subscribe:
Mail - listserver@unseen.aztec.co.za
Body - subscribe demuan-list FIRST_NAME LAST_NAME _or_
Body - subscribe demuan-list HANDLE
DemoNews is sent to your e-mail's "Reply-To" field.
_____Contact Address
questions@hornet.org
>------------------------------------------------------------------------------
EODN
