Copy Link
Add to Bookmark
Report
Demo News 138
______/\__________________________ __ ________________ ___ /\_______
\____ \ ________ _ _ ______ \ / \| \ ________ | \/ ______/
/ | \ _) \ \_/ \ | \ / \ \ _) \ | \______ \
/ | \ \ | \ | \/ \ \ / \ \ / \
\_____ /_______/___| /_______/\____\_____/_______/_________/________/
\_____/ |____/
Subscribers : 2646
DemoNews 138 - 12 January 1997 Archive Size : 3914M
>------------------------------------------------------------------ Contents --
Introduction
Calendar
Week In Review
Top Downloads
New Uploads
Articles
Software Design for Demos - Volume 2 .......... Kiwidog
How The Hornet Archive Works (part 3) ......... Snowman
Wired Date Changed ............................ Access
General Information
>-------------------------------------------------------------- Introduction --
Hello all, and welcome to DemoNews 138.
_____Introduction
I got good vibes about this issue.
_____Anniversary
This is going to be a very memorable year, Hornet historically-wise. This
September we will celebrate the 5th anniversary of both the Hornet Archive
and DemoNews. In addition, Music Contest will finally reach pentium
proportions. Expect some visible celebration.
_____What's Up With /incoming/music?
A few of you may have noticed that our /incoming/music directory has been
growing obscenely in the past month. Jtown (music archivist) had lost 'net
connection for about a month. Fortunately, he is now back in full force.
Expect a fist-full of /music reviews next week.
_____Changes to DemoNews
This week marks the first edition of "Week In Review". Our subarchive
maintainers finally get the chance to bust out and keep you informed like no
amount of "New Uploads" descriptions can. This week, we have /demos. Next
week we'll add /music. I'm sure the rest of the archive will follow suit one
of these days. Until then, read on.
_____Mellow-D / Hornet Alumni
This week, Mellow-D departs our group for undisclosed (unknown actually)
reasons. We wish him the best of luck in future endeavors.
_____Music Contest 5
GD, Jtown, and I are currently in preparation for MC5. Don't get excited
yet... it's still a way off. I believe we have officially set the starting
date (i.e. mc5_rules.zip release) at June 04, 1997.
_____/code and /code_review
For the most part, our /code directory has traditionally been one of the
worst maintained and organized sections of our archive. No more. It started
with Daredevil, was course corrected by Trixter, and is gradually being
polished by Kneebiter.
When we shifted our archiving software to HA4, we "upped" the standards for
our file descriptions. This meant a lot of annoying grunt work had to be
done... fixing 00_index.txt files and cleaning out cruft in preparation for
the transition. Unfortunately, /code was largely overlooked in this process
and sat dormant for the past 9 months. This is now being resolved.
As an indicator of the work being done, the "New Uploads" section for /code
this week was 104k (which I have elected to only partially print). Kneebiter
gave me another 240 file reviews this past week alone. Yesterday, the size of
our /code directory finally passed that of our /code_review directory. For
coders seeking source, good times are ahead.
_____Conclusion
Snowman / Hornet - r3cgm@hornet.org
>------------------------------------------------------------------ Calendar --
Date Event Location Contact Points
------------ ------------------- --------- ----------------------------------
09 Dec 1996 Movement Israel civax@kinneret.com
27 Dec 1996 The Party 6 Denmark theparty@vip.cybercity.dk
www.theparty.dk
* <-- YOU ARE HERE
15 Feb 1997 General Probe 3 Poland s146630@ire.pw.edu.pl
neutron.elka.pw.edu.pl/~mszklano
07 Mar 1997 Invasion Finland invasion@xuq.nullnet.fi
www.koillismaa.fi/invasion
28 Mar 1997 Mekka & Symposium Germany amable@aol.com
28 Mar 1997 SiliConvention Germany www.siliconvention.com
04 Apr 1997 X Takeover Holland x97take@freemail.nl
11 Apr 1997 The Trip Italy keyby@jnet.it
www.logicom.it/trip
12 May 1997 The Place To Be 4 France www.mygale.org/05/dadu
30 May 1997 Scream Canada scream97.educ.infinit.net
furb@total.net
22 Aug 1997 AntIQ Hungary aboy@ttk.jpte.hu
www.jpte.hu/~aboy
26 Sep 1997 Crash Canada crash@xi.ent.com
>------------------------------------------------------------- Week In Review --
-- /demos ------------------------------------------------------------------>
:: Phoenix / Hornet - phoenix@hornet.org
Welcome to the first installation of what could likely become a regular
column for me, your humble Hornet demo archive maintainer and musician. I
will comment on recently rated productions, and the scene in general.
_____New Demo Highlights
"Balance" by Pulse - won the Gravity 96 demo compo in Poland. More
incredible graphics by Lazur, and some great 3d scenes. I only wish Pulse
wouldn't keep ending their demos with still pics.
"Lasse Reinbong" re-release by Cubic Team & $een - a year old now, but this
new version is for Windows 95! Mainly just to show that it's possible.The
only main difference is the music being in MIDI format.
_____The Party 6
Well, hopefully someone will be nice enough to send us a party report :). So
for now, I can only comment on releases, which I'll do next time. Oh yeah, a
you know what goes to the guys who took over #theparty. Can we for once have
an EfNet party channel not get flooded, spammed, and just plain ruined?
Sigh..
_____Ratings Addendum
I forgot to mention two very important rating factors in my article last
issue. Date is one; a demo that is identical to another made half a year ago
will get a lower rating because of the standard at the time, plus the first
one had the effects/design first. Size is the other; a 4k intro is rated
based on what can be expected in 4kb, and the same for 64k.
_____Comments
hornet.org seems to be considered a warez bin by many lately. I keep seeing
morons trying to pack 20 disks worth into various incoming directories. Well,
we have three ways of figuring this out - if the incoming dir size goes up by
10 files and 50 megs overnight, the top daily downloads read file0001.zip,
file0002.zip, file0003.zip.., or I look around incoming and find that unused
directories suspiciously get a new date on them :). Needless to say, we plan
on winning the war on illegal uploads.
Another thing.. it's annoying me that people cannot take five seconds of
their life to read the upload rules, and use lowercase filenames and include
.txt files! Many of you are thinking, "hey, Phoenix, how hard is it for you
guys to make a script that automatically does that?" Well, it shouldn't be
my responsibility; the privilege of having your file on the archive is based
on the fact that you can put it there properly. Sorry to sound like a
badass, but it will make things much better for me. :)
OK, I've wasted too much space already.. until next time! :)
:: Trixter / Hornet - trixter@hornet.org
_____Lasse Reinbong
The W95 version of Lasse Reinbong works like a charm -- no slowdown in
comparison to the DOS version, and it runs in a window as well. (A windowed
version doesn't look correct, however, unless you're in 8-bit color.)
The music syncing is a bit off, but I guess that's to be expected. It's
MIDI, but it's a very good conversion of the original .xm. I listened to it
with OPL3 MIDI and it sucked; I then listened to it with a General MIDI board
and it was much better (duh).
In general, I'm very happy to see the first Windows 95 demo, which I consider
to be a success. Does that mean that I'll be coding W95 demos from now on?
Hell no! DirectSound is a joke, and I still have a hard time believing that
DirectX is faster than directly blitting to an LFB in DOS with interrupts
turned off. I'll still be doing the real-mode 640K-limit Mode X stuff I've
always done (this is partially due to a lack of time to learn C). But I'm
very pleased with this production and I hope that others do the same.
>------------------------------------------------------------- Top Downloads --
This represents combined ftp/http transfers for the last 7 days.
Total files downloaded : 168,575
Size of files downloaded : 26,522,879k
Times File Description
----- -------------------------------- --------------------------------------
-- /demos ------------------------------------------------------------------>
164 /1995/a/animate.zip Animate by Schwartz
144 /1993/s/symbolog.zip Symbology by Admire
107 /1993/u/unreal11.zip Unreal v1.1 by Future Crew
94 /1996/a/ai_strok.zip Stroke by Ionic of Astroidea
93 /1993/0-9/2ndreal1.lzh Second Reality by Future Crew [1/2]
92 /1995/n/nooon_st.zip Stars (bugfixed) by Nooon
89 /1993/0-9/2ndreal2.lzh Second Reality by Future Crew [2/2]
86 /1993/c/cd2_trn.lzh Crystal Dreams 2 by Triton
81 /1996/c/ctstoast.zip Toasted (final) by Cubic Team, $een
76 /1996/m/machines.a02 Machines of Madness by Dubius [3/3]
-- /music ------------------------------------------------------------------>
64 /songs/1996/s3m/i/im_empir.zip The Hidden Empire by Karsten Koch
61 /songs/1996/s3m/i/im_chron.zip Chronologie Part 4 (remix) by Karsten
59 /songs/1996/xm/r/raf-bost.zip
59 /songs/1996/s3m/a/athought.zip Another Night of Thought by Zastar
49 /songs/1996/s3m/f/fm-mech8.zip Mechanism Eight by Necros
48 /songs/1995/s3m/a/aryx.zip Aryx by K. Koch
42 /songs/1995/s3m/n/noface.zip He Has No Face by Skaven
38 /songs/1996/xm/a/anthem.zip Anthem by Soundmaster
38 /songs/1996/s3m/f/fa-bung.zip Animated Bunghole Power by Future Assa
36 /songs/1996/xm/r/raf-miss.zip Missing by Zovirax
-- /graphics --------------------------------------------------------------->
17 /images/1994/i/incest5.zip Incest by Pentalysion
14 /programs/vector/akm-mm10.zip Master Modeler 1.0 by Arkham
11 /programs/convert/alch162.zip Image Alchemy v1.62 by Handmade Softwa
11 /images/1996/h/hardcore.zip ??? by Boss
10 /images/1996/m/myth.zip ??? by Boss
10 /images/1996/d/de-anima.zip De-Anima by Made
10 /images/1996/d/dawn.zip Dawn by Lorper
10 /images/1996/0-9/3dots.zip Three Dots by Shape
9 /programs/vector/veced300.zip 3D Vector Editor by Grey Cat
9 /images/1996/v/virgin.zip Virgin Witch by Pad
-- /code ------------------------------------------------------------------->
64 /effects/3d/3dtext.arj Textmode Texture Mapping,Plasma, and 3
60 /effects/wormhole/stargate.zip Texture Mapped Wormhole by Death Star
59 /effects/rotozoom/pasroto.zip Cache Optimized Roto-Zoomer by Pascal
55 /tutor/tut21.zip
53 /effects/vector/rn_vect.zip Vector Tutorial by Richard Nichols
53 /effects/3d/fh-3dt18.zip 3D Tutorial v1.8 by fh of GODS
50 /effects/tunnel/araidsrc.zip Source for Tunnel Effect by Plastiikki
49 /effects/blobs/blobs.zip Dancing Blobs Effect by TH
48 /3ds/3dsrdr12.zip 3D Studio .3DS File Reader v1.2 by Jar
44 /effects/feedback/dunesrc.zip Feedback Effect
-- /incoming --------------------------------------------------------------->
342 /TP96/demo/alto.zip
251 /TP96/demo/megademo.zip
235 /TP96/in64/u8-daze.zip
234 /TP96/misc/tp96res.zip
192 /TP96/demo/compost.zip
183 /TP96/in64/deesbab.zip
163 /TP96/in4k/e9-fett.zip
161 /TP96/in4k/marsvoya.zip
159 /TP96/in64/adrift.zip
151 /TP96/demo/emp_fnal.zip
>--------------------------------------------------------------- New Uploads --
All ratings are subjective.
Filename Size Rated Description
------------------------------- ---- ----- ----------------------------------
-- /demos ------------------------------------------------------------------>
/1995/j/jff-bed.zip 939 *+ Bedtime For Claudia by Just For
| Fun
/1996/0-9/1stoff.zip 152 ** First Offense by Saw Tooth
| Distortion - NAID96:i128:??:
/1996/0-9/3dstuff2.zip 774 **+ 3D Stuff by Ecstasy
/1996/a/ages.zip 1182 ***+ Ages by Happo - ASM96:demo:09:
/1996/a/an_rastr.zip 9 *+ Rastro by Guild
/1996/a/arise-f.zip 1373 ***+ Arise (final) by Beyond -
| NAID96:demo:04:
/1996/b/b666_fin.zip 3709 ***+ Vitamin B666 by Exmortis -
| GRV96:demo:02:
/1996/b/badhabit.zip 104 *+ Bad Habit by Light Blue
/1996/b/bor_seit.zip 62 ***+ Seita by Borealis -
| DML96B:in64:01:
/1996/b/bros.zip 50 **+ Blue Robot of Sea by
| Seikkailupahkina -
| ABD96:in64:11:
/1996/c/c_void.zip 1274 **+ Chaotic Void by Brainstorm
| Productions
/1996/c/cmatuhka.zip 73 **** Tuhka by COMA - DML96B:in64:03:
/1996/c/coco-nuz.zip 1359 ***+ Coc'O Nuts by Cobra Creations -
| DML96B:demo:03:
/1996/c/cosmlamu.zip 20 * Cosmo Lamu by PWP -
| DML96B:in64:05:
/1996/c/crawford.zip 60 ***+ Station Crawford by Paragon -
| ASM96:in64:07:
/1996/d/devotion.a01 1166 **** Devotion by Waterlogic [2/2] -
| TS96:demo:01:
/1996/d/devotion.arj 1422 **** Devotion by Waterlogic [1/2] -
| TS96:demo:01:
/1996/d/dlp_late.zip 525 *+ Too Late by Dead Line
/1996/e/elf-drmf.zip 1869 **+ Dream War by Elfsong
/1996/f/facedemo.zip 327 *+ Wobbly Face Demo by Electric Wig
/1996/f/faith.zip 13 ***+ Faith by Vertigo
/1996/f/flod.zip 301 *** Flo by ?? - DML96B:demo:06:
/1996/f/fsk_pit.zip 204 *+ The Pit of Dhoom by Forsaken -
| DML96B:demo:09:
/1996/g/gd.zip 3 ** BBS Global Domination by Brains
| Don't Bounce
/1996/g/goo.zip 781 *** Goo by Mooze - DML96B:demo:07:
/1996/h/huilmee.zip 596 * Huilt Mee by Hema
/1996/i/ina1200.zip 65 *** Nokia 1200 by Interamnia -
| DML96B:in64:04:
/1996/l/lbalazy.zip 54 * Lazy by LBA
/1996/m/megagukf.zip 597 + Megagukk by Logical, ELQ
/1996/m/mrt-bld.zip 518 *+ Best Lame Demo by Red Power -
| GAR96:demo:EE:
/1996/n/none.zip 50 *** None by Fuse - GRV96:in64:02:
/1996/o/o_solex.zip 280 ***+ Solex by Oxygene
/1996/p/planet.zip 52 **+ Planet Damones by Damones -
| DML96B:in64:07:
/1996/p/pls_blc.zip 2333 **** Balance by Pulse - GRV96:demo:01:
/1996/p/pls_est.zip 1664 ***+ Eyesight by Pulse
/1996/p/pms_peac.zip 1235 ** Peace by Promise - RAGE96:demo:02:
/1996/p/prelude.zip 50 *** Prelude by Amorphous -
| ASM96:in64:11:
/1996/p/ps-fire.zip 0 ** Wildfire by Perigee Software
/1996/s/scar.zip 53 **+ Scar by Fuse - GRV96:in64:03:
/1996/s/scdemo.zip 178 * School Demo by Theta
/1996/s/stc_xtr.zip 38 **+ Extermination by Substance -
| GRV96:in64:01:
/1996/t/taivas.zip 1706 [n/a] Taivas by Aurinkovoodoomandariini
| - DML96B:demo:02:
/1996/t/theywill.zip 920 *** They Will Pay by Borealis -
| ASM96:demo:14:
/1996/t/torsofix.zip 48 *** Torso Preview (SB patch) by Mode
| XIX
/1996/x/xd-btl.zip 36 **+ Beyond the Limit by Xeed
-- /music ------------------------------------------------------------------>
/disks/1996/0-9/1mandog.zip 4854 **** One Man Dog by Kinetic PC
/programs/compress/mmcmp134.zip 44 Music File Compressor v1.34 by
| Zirconia : compress/decompress
| songs, load compressed modules
| into any tracker/player with TSR
| loaded
/programs/convert/mod2xm10.zip 39 Mod2XM v1.0 : MOD/S3M to XM
/programs/educate/scaleit4.zip 488 ScaleIt v4.0 : shows you all the
| chords and scales with all roots
| and all inversions, editable
| database, play the chord/scale,
| save the chord/scale as MIDI
| file or as Fasttracker pattern,
| English and German
/programs/frontend/lynchmod.zip 26 GutMOD v2.10 : Small, and HQ mod
| file playing system. Under 25k!
/programs/mixers/dj-mixer.zip 37 Digital Disk Jockey v1.00 by PcMax
| : SB16, mixes 2 wavs together
/programs/mixers/pnpmix02.zip 7 PNPMIX v0.2 by Nima Ghasseminejad
| : Gravis UltraSound PnP dos
| mixer
/programs/players/amod030.zip 76 Adrenalin Module Player v0.30 by
| Beta of Adrenalin : Assembly '95
| Edition
/programs/players/amp201.zip 53 AMP v2.01 : Module player for SB
| AWE32
/programs/players/cheese12.zip 17 Cheese Player v1.2
/programs/players/cp20a.zip 383 Cubic Player v2.0a by Cubic Team :
| The Party 6 Version
/programs/players/e_diamn1.zip 94 Diamond Player v3.00a
/programs/players/flimp12b.zip 46 FLI & Module Player v1.2b : Play
| FLI and MOD/S3M at the same
| time.
/programs/players/ld-pbp11.zip 321 PBP-Player v1.15a by Legend Design
/programs/players/mikit001.zip 49 MikIT v0.01b by MikMak : IT player
| for Win95/NT w/full NNA and DCT
| support
/programs/players/mld215.zip 47 The Unchained Melody v2.15 :
| MOD/S3M player for GUS
/programs/players/mmp4072.zip 97 The Multi Module Player v4.072 :
| SB only
/programs/players/realmp.zip 186 RealTech Module Player v1.20 by
| RealTech
/programs/players/xtcp070c.arj 130 Xtc-Play v0.70 : Now supports GUS
| Interwave
/programs/rippers/sgpro27.zip 40 Sample Grabber Pro v2.7
/programs/samplers/rubdk086.zip 812 Rubber Duck v0.86b by D-Lusion :
| realtime resonant filters, 4
| basic waveforms, 224 note
| sequencer, digital delay, drum
| section, 16-bit, 44khz, Win95
/programs/trackers/akm-mt24.zip 144 Master Tracker v2.4
/programs/trackers/it210.zip 266 Impulse Tracker v2.10 by Pulse
/programs/trackers/itpr102.zip 10 Impulse Tracker Pattern Re-
| arranger v1.02a by Cygnes :
| Kills unused patterns
/programs/trackers/itwss.zip 18 Impulse Tracker Sound Drivers :
| for Windows Sound System
/programs/trackers/itxt201.zip 6 Impulse Tracker Text Importer
| v2.01 : Import messages into IT
| from ASCII text file
/programs/unusual/gusdrvpt.zip 1 GusDrive v2.0 (patch) : fixes
| problem with GUS at address 260
/songs/1996/s3m/u/upthline.zip 114 **+ Up The Line by Daedalus
/songs/1996/s3m/w/wshl.zip 120 **+ When Silence Has Lease by Daedalus
-- /code ------------------------------------------------------------------->
/3d/docs/zed3d060.zip 349 **** Zed 3D by Zed : A comprehensive
| doc on many aspects of 3d math
| and programming - Designed for
| those comfortable with math. It
| spells out the math concepts
| needed and shows their
| application, but by no means
| spoon feeds the information to
| you. C/C++, Text
/audio/docs/fmoddoc.zip 81 **** F. mod docs by Firelight :
| Firelight's mod format
| description - The perfect text
| file for someone who is writing
| a mod player especially first
| timers. Assumes knowledge of
| programming and doesn't cover
| details of sound card specific
| issues, like setting up a DMA
| transfer or initializing the
| sound card. Assembler, C/C++,
| Text, real-mode
/audio/docs/fmoddoc2.zip 381 **** F. mod docs by Firelight :
| Firelight's mod format
| description - The perfect text
| file for someone who is writing
| a mod player especially first
| timers. Assumes knowledge of
| programming and doesn't cover
| details of sound card specific
| issues, like setting up a DMA
| transfer or initializing the
| sound card. Assembler, C/C++,
| Text, real-mode
/audio/docs/gusdk222.zip 923 **** GUS SDK by Gravis, FORTE : GUS SDK
| - Everything you've ever wanted
| to know about the GUS but were
| afraid to ask. C/C++, Text
/audio/players/mdss040a.zip 1367 **** Midas v.040a by Petteri
| Kangaslampi, Jarno Paananen :
| Midas music system - A full
| music system (almost) with
| support for compiling with tasm,
| BP, BC, and Watcom. Assembler,
| C/C++, real-mode, protected-mode
/demosrc/bbsintro/vga-vul1.zip 11 **** Boardz source by Vulture : Source
| for a BBS loader with a star
| field and scrollie - I never
| thought I'd give this high a
| rating for source to a BBS
| loader, but I figure there's got
| to be some way for people to
| know what to look for. The
| source is beautiful and there
| are more comments than there are
| lines of source! *Perfect* for
| the beginner, though not a
| tutorial. Assembler, real-mode
/demosrc/demos/fakedemo.zip 327 **** Fake demo source by Pelusa :
| Sources for a demo with a sinus
| waver, wormhole, rotating
| landscape, fire, scrollie,
| shadebobs, lens, mandelbrot set
| zoomer - Comments for
| proceedures, many parts, lots to
| look over. Clean code too.
| (old cheesy necros music. :)
| Assembler, real-mode
/effects/morph/wgttut5.zip 218 **** WGT Graphics Tut #5 by Gooroo :
| Morphing - Gooroo describes the
| ideas and code behind morphing
| in alot of detail. C/C++,
| protected-mode
/effects/water/hq_water.zip 361 **** Heart Quake's water source by ARM
| of Iguana : The authoratative
| source on the water effect -
| Includes a description of the
| physics behind the effect and
| the simplifications done to make
| the routine run quickly.
| Assembler, real-mode
-- /info ------------------------------------------------------------------->
/cds/anthoman.zip 194 Mods Anthology Manager : DataBase
| of Mods Anthology files
/demonews/demonews.136 53 DemoNews 136 - 08 Dec 1996 by
| Hornet
/demonews/demonews.137 46 DemoNews 137 - 21 Dec 1996 by
| Hornet
/dn_other/dnr144.zip 81 DemoNews Reader v1.43 by Phoenix
| of Hornet
/traxw/traxweek.080 61 TraxWeekly 080 - 11 Dec 1996
/traxw/traxweek.081 58 TraxWeekly 081 - 19 Dec 1996
/traxw/traxweek.082 22 TraxWeekly 082 - 25 Dec 1996
/traxw/traxweek.083 18 TraxWeekly 083 - 02 Jan 1997
/traxw/traxweek.084 31 TraxWeekly 084 - 09 Jan 1997
/traxw/traxweek.let 24 TraxWeekly Letters - 07 Dec 1996
-- /party ------------------------------------------------------------------>
/reports/1996/asm96sc.a01 1422 ***+ Assembly '96 Special Coverage by
| Abduction Organizing [2/3] -
| ASM96:::
/reports/1996/asm96sc.a02 481 ***+ Assembly '96 Special Coverage by
| Abduction Organizing [3/3] -
| ASM96:::
/reports/1996/asm96sc.arj 1422 ***+ Assembly '96 Special Coverage by
| Abduction Organizing [1/3] -
| ASM96:::
/reports/1996/hrn-nr96.zip 1854 NAID '96 Report by Hornet -
| NAID96:::
/results/1996/dml2-res.zip 3 Demolition 2 '96 Results -
| DML96B:::
/results/1996/grv96.res 0 Gravity '96 Results - GRV96:::
/results/packs/ai_res41.zip 152 Party Results/Previews/Charts v4.1
| by Astroidea
>------------------------------------------------------------------ Articles --
---------------------------------------------------------------------------->
:: "Software Design for Demos - Volume 2"
:: Kiwidog - chargrove@mail.ravensoft.com
_____Introduction
Welcome back. :)
Since I just got back from a break in Virginia for the holidays and I haven't
unpacked the code I wrote on vacation (yes I code on vacation too, call me
pathetic but hey :) I thought I'd take this time to write the next article.
This week, we'll be going over naming conventions and why you should have one
(if it isn't already obvious :) plus some C++ basics for you C folks to get
us going, as we start off making a screen class.
Before we begin though, I thought I'd mention a couple things... there's been
a lot of feedback to me about the first article, the vast majority of it
quite positive, and I want to thank all of you who took the time to email me
or mention on IRC that you liked the article and will read the series; it
helps a lot towards my motivation. :) But, of course where there's good
feedback there must also be a little bit of criticism (which is good in its
own right), and I got a bit for this as well.
The biggest criticism was centered on why the hell I'm writing a series about
software design for demos when I haven't released a real demo of my own to
"justify" what I'm talking about. Well, the reason is this: the biggest
stumbling block to me getting a demo done over the past couple years has been
my lack of knowledge in how to get something "big" working.
I mean, I've had my share of tiny effects and smallish 3D systems etc, but
nothing large enough to where it would work well in a demo. I simply never
figured out how, and I know lots of other people in the same boat. So after
I finally started learning some effective principles and other things, I
began my code base over again, and in 5 months it's exceeded by over 200%
what I had done cumulatively in the previous 2 1/2 years. So even though I
may not be totally justified in "preaching" this stuff, I know at least that
it's helped me dramatically... and if at least one other person out there
benefits from what I write, that's all the justification I need. :)
The second thing is about the 3D series; I've had a few people ask if I
finished it, and if I did, where to find the articles beyond #5. Since I
can't reply to everyone at this point I'll just say that A) No I didn't
finish the series completely, BUT, B) I have written several more articles
for it at least, yes, just no example source. SO, at this point I'm taking
suggestions... do you guys who followed the 3D series want me just to release
those extra articles in a single zip, or wait until I write some example
source, or try to integrate the 3D stuff into this series, or... ? I honestly
can't decide what to do, and since the articles are for you all, feel free to
give me your votes with how to handle the 3D series fiasco. Just drop me an
email, my address is at the end of the article. :)
Ok enough of my usual opening ramblings; time to jump on in. :D
_____Naming Conventions - Huh?
If you find yourself asking what I mean by naming conventions, you probably
don't have one.
That can be a bad thing.
Not that it would necessarily matter in small things or test programs, but in
larger things like full demos (especially when more than one coder is
involved), naming conventions are crucial if you want your stuff to be
compatible with each other. Not having some kind of standard can at least be
frustrating trying to find other people's code or understand its purpose, and
at its worst, it can totally stop coders' material from linking with each
other. So this is very crucial indeed.
Coding conventions altogether involve naming conventions, commenting style,
tab spacing, and stuff like that. Commenting style and tab spacing are
mostly cosmetic so you can argue amongst yourselves how you want to approach
the issue. :) But naming conventions actually affect how your code works, so
that's going to be our focus.
Naming conventions broil to only two things: Naming stuff so that you can
identify its purpose and location easily, and making it so linking multiple
persons' code won't break the project.
_____Purpose and Location
When you create a structure, function, or variable, you want its use to be
intuitive. Not just in its purpose (what it is and what it's used for), but
also in its location. Location isn't a concern in small projects, but big
ones with lots of files can get extremely unruly if you can't find stuff
(especially if you don't see it to know it's there and end up naming
something identically, blowing a link to pieces). Fortunately you can end up
solving both without too much effort. Lets start out with structures.
_____Structures (and Classes)
Structure location isn't as much of a problem usually as with functions and
variables, because structures and classes end up being used so often during a
project that its location becomes inherently obvious by what it is (vector
structures go in the 3D code, screen structures in video code, etc). But
identifying structures and classes over variable names is still an issue.
There are two philosophies I've seen that can work equally well depending on
your situation. 1) Using a prefix or suffix (like _t for structures or a T
or C prefix for classes) for all of these, or 2) Naming the structures and
classes the most natural names possible (like "screen" "palette" "vector"
"matrix" and so forth) to the point that there's no way you'd EVER name a
variable with the same name.
Personally I recommend _t for structs; after a while it feels natural. As
for classes, this depends on your scenario... for projects with an "average"
number of classes, a prefix-suffix-less system can work well for you (as a
matter of fact I use one), plus it makes your code very simple to read. The
down side of this comes in projects with a HUGE number of classes. You'll
know when this threshold is hit because your classes will start being named
like you'd name your variables (names that are on average 15 characters or
more, with some upper and lowercase). Once this is hit, you'd be best off
adopting a prefix suffix, like an _c suffix, or C or T prefix. (i.e.
vector_t, screen_c, CMatrix, TWindow, etc).
Now, once you have classes or structures that get very module-specific, it
might be time to add on a convention used for variables and functions...
_____Variables and Functions - Prefixes Are Our Friends
If there's one thing we probably agree on, it's that global variables, while
convenient, can be nasty to find. Naming a global variable and finding out
somebody else already has one with the same name and both of you use them
extensively is NOT a good thing to have happen. So when you're writing your
code, and you have globals, give them some kind of "hook" to your module.
This goes for both variables and functions.
Say you're writing some system code for your library. You want to add a
"SafeMalloc" function that calls malloc() and verifies that the pointer
returned is non-null, otherwise it quits with an "out of memory" error. Now
you _could_ just start writing
void *SafeMalloc(int size) { /* body */ }
and go on from there, OR you could name it properly. Say your module is
called SYS_MISC.C for miscellaneous system stuff. Then why not name the
function so that you know where it is?
void *SYS_SafeMalloc(int size) { /* body */ }
Now, having that SYS_ in front of it automatically lets you know it's a core
system function, plus it makes you look at SYS_*.C files first when changing
it or wondering who's responsible for the code.
With variables, you want to have something similar, but able to distinguish
it's a variable and not a function. Since C/C++ is case sensitive, how about
lowercase? Say you had some kind of standard error message list...
char **sys_ErrorMessages;
These may seem like super-anal things as far as coding goes, but just try
naming your modules with EXTENSION_DESCRIPTION.C (like SYS_MISC.C,
VID_MAIN.C, VEC_FILL.C, etc) and using corresponding prefixes, or something
similar to this... you'll notice linker errors among the coders in your group
will diminish massively if not disappear _completely_ (at least in the
clashing sense :)
On the other end of the spectrum, if you have global variables that are local
to your module and are not intended for other people to access, make SURE to
use the "static" keyword in front of the declaration.
static int tempvariable;
static void LocalFunction();
It's an easy thing to forget, but if you don't the compiler will default to
an extern declaration and you've just made your variable global across the
whole project. Using "static" from the outset when declaring stuff for your
use only not only mentally tells you "it's not public", but also keeps the
link from blowing.
There are other types of conventions out there (everyone has their own style
after all), such as Hungarian Notation (often used in windows programs) which
starts off variable names with abbreviations of their types, plus some other
ways to represent variables and functions in a standard way. Personally I
don't like Hungarian Notation (feels too bulky), but I know a few programmers
that do, and there are lots of other options to choose from as well. The
point is, find some kind of standard and stick with it. :) As for the system
I've been describing, I don't know if it has any name like Hungarian Notation
explicitly attached to it... but whatever it is, it seems to work really well
for projects of demo/game size.
_____Application - Main Chaining
If multiple people are involved in a project, one of the cheapest ways to
hack up a quick demo with various effects is what I've heard called "main
chaining" which is when you take all the independent effect test programs and
replace their main() functions with different names, then sequence all those
functions in an overall demo main().
Main Chaining is one of the most obvious areas where good naming conventions
come into play... because if you don't use them from the outset in each of
the effect test programs, your overall demo link won't be as simple as you'd
like it to be. By sticking to your standards even in tiny little programs
which often (serendipitously) turn out later to be useful effects, you won't
find yourself saying "sh*t, I've got a bunch of variables in here that clash
with yours, and it'll take hours to find and change them all, this sucks."
Okay, so that's the long and short (no pun intended :) of naming conventions.
There's not much to it as you can see, but it's amazing how much a small
change like this will make as your projects get bigger and bigger and get
shared among more and more people. Just try it; it's a good habit to get
into :)
Anyway, time to shift gears. Since I'll be using C++ for the stuff we
develop in this series (because object-oriented programming is more handy
than you might realize), I'm gonna take a bit and go over some C++ basics for
you C coders. Not the really deep stuff, just the simple stuff that's easy
to learn and use but helpful enough to benefit your code almost immediately.
_____C++ Overview - Structures On A Mission
The whole basis of object oriented programming is on (you guessed it)
objects. Theory pundits can argue with you forever about the conceptual
differences between structured and object-oriented programming, but as for
me, I don't really care. I'm looking for practical differences, and in
practice, object-oriented doesn't "feel" any less natural than structured
programming... because it's just as structured.
Objects are often said to be a "totally different" way of handling things...
and to some people they may be... but when it boils down it, objects (which
in C++ are called classes) are just structures on a mission. Regular structs
(or records for you Pascal folks) are just big fat sets of data with a common
name, like records in a database. But other than that, they're butt lazy;
you have to remember what they're supposed to do, how they interact with your
program, how to initialize them, how to clear any memory you allocated when
you used pointers under them, etc. In effect, they're nice, they're
convenient... but they're stupid.
Objects are structures that aren't so dumb, because along with holding data,
they also hold code that is specific (or at least, intended to be specific)
for use with that data. In other words, they totally encapsulate all the
data of something and the code that works with that something (and for you
sticklers, no the code is not actually stored in the class structure, that's
only for compiling purposes... if you actually did a sizeof() on a class, it
would have the same size as a struct holding only the data from the class;
the code is really stored outside but compiled like it's inside).
Let's give an example. How about, say, an apple? Data-wise, an apple can
have many values, like color, size, weight, texture, stuff like that. Under
normal C you could just slap all those fields into a "struct apple_t" and be
done with it. But with objects, we can think about the code as well. Beyond
just what an apple _is_, what does an apple _do_? Well it can grow, it can
fall from a tree, it can rot, etc. You could also put in stuff like it can
be eaten or whatever, but since those aren't really things the apple does but
rather thing it has done _to it_, those belong to a separate object (like a
person class :)
The declaration of our apple class might look like this...
class apple
{
private:
int size;
int weight;
char color;
char *texture;
public:
// Constructors & Destructor; I'll explain these in a bit
apple();
~apple();
// Operators - None needed for this class
// Functions
void Grow(int sizeinc);
int Fall(); // returns 1 if survived, 0 if shattered into teeny bits :)
void Rot(int level_of_disgust);
// Friend functions - None needed yet
};
In C++ the actual functions in the class (called "methods") go outside the
class declaration and are headed by classname::function(params), like so:
void apple::Grow(int sizeinc)
{
size += sizeinc;
}
You can actually have method functions with the same name but different
parameters and have them be treated differently (at compile time it'll
determine which function you wanted by the params you passed), along with the
ability to overload operators like + and - to your advantage, along with a
whole bunch of other goodies. I can't get into nearly as much detail as a
good book on the subject, but you'll end up picking these goodies up easily
as we progress through the series if you don't want to bother with getting a
book beforehand. :)
One other thing though that I'll explain now before we go on is the concept
of constructors and destructors (there was one of each in the apple example
above).
_____Build Me Baby
I'll start off by saying that constructors and destructors are cool.
Damn cool. To sum up what they are, they're basically functions that are
called automatically, just by creating an class object, or when that object
is deleted when it goes out of scope. Effectively it lets you put built-in
Init and DeInit functions, where you don't have to call them yourself, it'll
do it for you during the variable declaration/termination. Plus, you can
have constructors.... get this... with parameters. Like in the case above,
In addition to apple() and ~apple(), we can have apple(int startcolor),
meaning if we declare an apple variable with an int param like
apple yummyapple(4);
and we had a function
apple::apple(int startcolor)
{
color = startcolor;
}
it would automatically call that function right at the start. In C++,
constructors have the same function name as the class name, and they don't
have any "void" or anything in front of them (no return type). Destructors
look the same but with a ~ starting the function name, and there's generally
only one, with no parameters. Beyond just setting start variables during
initialization, constructors are totally awesome for initial memory
allocations and stuff (like in the screen class that we'll start writing
next, the constructor can automatically allocate the required memory for you
and deallocate it upon destruction so you don't have to malloc or free
anything).
Once again, there's a whole bunch of other stuff we'll be introducing as time
goes on, but this should at least give you an overview of what we'll need for
the time being. If you're super-interested though, pick up any C++ book and
read to your heart's content. :)
Ok, now to try and put some of this material to use...
_____The Screen Class - Putpixel Redux
If you were going to start writing all your demo code all over again, what's
one of the first things you'd end up writing? Probably a putpixel. I think
for many of us it's almost a subliminal "must hack out putpixel" urge by now.
:) Well, before we fall guilty to the putpixel sin AGAIN (I mean, how often
do you use it anyway except for old starfields and other older and generally
crappier effects? :) we should think about the whole video thing in a
practical... and "object"ive... manner.
We write a putpixel routine to draw a dot to the screen... and while we don't
use that putpixel much after that, the screen we drew on is certainly still
being used in full force. Since a video screen is such a major thing, would
it fit well as a class? Well let's see... a screen IS (a big fat buffer to
draw to, a palette, some mode info and maybe a dirty rectangle list, some
other stuff), and it DOES (clear, blit, set a video mode for itself so it
blits right, etc)... so yeah, it'd fit well. :)
Before we start hacking anything out though, we should think about this for
the long term. One of the biggest things about good design is trying to
think more ahead than you might otherwise want to, because trying to re-use
code whose API changes sucks. What's one of the things beyond Mode 13h
putpixel-ing issues that we want to address?
How about non-mode-specific graphics. Two big reasons for this, one that
hi-res stuff is getting more and more common and it'd be nice not to have to
rework everything you write just to change the video mode... and two, because
if you want to port to another platform/API (like say win95's DirectDraw),
you only need to change this one class, and the code will work.
Also, how about allowing screens to not be bound to a specific video mode at
all, but rather having them support arbitrarily sized buffers, and just
giving "extra" support if those buffers happen to be the same size as a
supported resolution? That way dirty rectangles, fonts, bitmaps, etc can all
be screens and you won't need to clutter your code with other data types that
(beyond the blitting and mode setting) have the same functionality.
And how about support for a dirty rectangle mode flag where only the dirty
rectangles you have queued will be updated onscreen, instead of the whole
screen? This could be handy in many scenarios.
There's also the issue of 8-bit vs. 16 and 24 bit support, but that's a bit
more advanced and we've got enough to deal with for now... I'll let you
figure out how to support higher-bit-depth modes on your own. For now, we've
got all we need to get going.
Actually I'm already hitting the 20k barrier on this article, so to avoid it
getting possibly double the size I'm gonna cut it short now and let you guys
mill over the screen class idea for a bit... we'll be implementing it in the
next volume.
Until then, :)
Chris Hargrove
a.k.a. Kiwidog/Terraformer,Hornet alumni
Technology Programmer, Raven Software
email: <chargrove@mail.ravensoft.com>
Disclaimer: These articles are in no way affiliated with Raven Software,
and represent the views and opinions of the author solely.
---------------------------------------------------------------------------->
:: "How The Hornet Archive Works (part 3)"
:: Snowman / Hornet - r3cgm@hornet.org
_____Introduction
Musicians have samples, graphicians pixels, and programmers code. Hornet
Archive maintainers have... ? If you shouted "SDD!", count yourself a
winner. SDD's are the fundamental unit of data on the Hornet Archive.
Whenever a script is running, chances are that an SDD or two is involved. So
what the heck is an SDD?
A "Semicolon Delimited Data" (SDD) is simply a line of text containing
several pieces of data, separated by semicolons. Each SDD contains
information such as: title, author, size, etc. There is exactly one SDD for
every cataloged file on the Hornet Archive.
To the casual scener, the knowledge that SDD's exist may seem trivial -- even
boring -- but no! SDD's are exciting! Each SDD is a bubble of database
love, a button of bouncing ASCII happiness skittering to and fro, making
_your_ archive experience a better one. SDD's provide a totally consistent
data format for the Hornet Archive. I for one am quite fond of them.
_____Anatomy Of An SDD
Remember, there is exactly one SDD for every file on our site. Now stop for
a second and ask yourself, "If I were an SDD, what kind of information would
I want to know about my file?" For starters, how about title? I mean, every
file has a title, right? clx_dope.zip is "Dope", it209.zip is "Impulse
Tracker v2.09", etc.
FILE;TITLE;
Now how about we keep track of who made the file? Hell is by "Tran". Inside
is by "CNCD". But wait a minute! Tran is a person and CNCD is a group.
Does the distinction really matter? Well, let's be on the safe side and keep
track of "author" and "group" as two separate fields.
FILE;TITLE;author;group;
Since we're a "progressive" archive, we also want the ability to write
extended descriptions for our files. See what a difference they make:
GUS Environment by Patch (/code/audio/detection/gusenv.zip)
| Grabs the Ultrasnd environment for you - Good for those who don't know how
| to find an environment variable, but it doesn't tell you much. It may give
| you a place to start. <-- extended description
FILE;TITLE;AUTHOR;GROUP;desc;
Should we track file size? Yip, must know how big a file is. Oh, and while
we're at it we might as well go ahead and keep track of when the file was
cataloged. Oh, and we can't forget about those wonderful *** ratings we like
to use.
FILE;date;size;TITLE;AUTHOR;GROUP;DESC;rating;
That should just about do it, right? Wrong! Right now we have a very
mediocre SDD. I mean, he's got all the basic info, but the boy ain't got no
style, ain't got no class. [note: SDD's are male]
How about we make a special field for programming language (like for coding
tutorials and stuff). Then we could actually have a description like this:
GUS Environment by Patch (/code/audio/detection/gusenv.zip)
| "Assembler, real-mode" <-- language
FILE;DATE;SIZE;TITLE;AUTHOR;GROUP;DESC;RATING;lang;
Don't stop there. How about a field showing what party a file came from
(Assembly, Juhla, etc.), a field for what category it competed in (Demo,
Multi-channel Music, Graphics, etc.), and a field for how it actually placed
(1st, 2nd, Disqualified, Exhibition, etc.).
FILE;DATE;SIZE;TITLE;AUTHOR;GROUP;DESC;RATING;pname;ptype;prank;LANG;
And maybe even a field for multi-part files (like if someone uploaded
demo.arj, demo.a01, and demo.a02).
FILE;DATE;SIZE;TITLE;AUTHOR;GROUP;DESC;RATING;PNAME;PTYPE;PRANK;LANG;x/y;
Boom! That's an SDD.
_____Putting Meat On The Bones
Now I'll bet you want to see a few SDD's, right? Here 'ya go:
/demos/1993/0-9/2ndreal2.lzh;836095591;802958;Second Reality;;Future Crew;
;*****;ASM93;demo;01;;2/2;*
/code/audio/players/mdss040a.zip;852969453;1400325;Midas v.040a;Petteri
Kangaslampi+Jarno Paananen;;Midas music system - A full music system
(almost) with support for compiling with tasm, BP, BC, and Watcom.;
****;;;;CAPpr;;*
/music/songs/1995/s3m/f/fm-riff.zip;843018872;359939;Search For The Lost
Riff;Necros+Basehead;;;****+;;;;;;*
/music/songs/1996/s3m/s/sxpr50.zip;843438148;100924;Sound Expression 5;
Lord Shakath Jei;;#-1;*+;;;;;;*
For the astute reader, you'll note that four things seem out of place:
1. The DATEs listed are : 836095591, 852969453, 843018872, 843438148.
What kind of sense does that make?
2. The second example has a language of 'CAPpr'. What the heck?
3. Each SDD ends in an '*'.
4. There seems to be an odd little '#-1' string in the forth example.
Oh ho! Not quite as simple as you thought, eh?
_____Conclusion
Next week we'll take a look at advanced SDD parsing and exception handling.
After reading that, you'll posses an amazing amount of totally useless
knowledge. Woohoo!
---------------------------------------------------------------------------->
:: "Wired Date Changed"
:: Access / Pulp - francois.baligant@ping.be
Hi to the DemoNews team!
#include keep_up_the_good_job.inc ;)
This a kind of response to Trixter's post about parties competing for
date...
We proudly announce that Wired'97 will be held during the month of July. Yes,
date change. That's why we want to announce it widely so other people can
invade the month of November. :) It will be probably at the end of July but
we aren't sure yet.. we still need to check with the Hall owner etc.. (around
20-21 July to be precise).
So only state it will be in July.. People that want to organize another party
in july only need to get in touch with us.. We let them know about our
intentions..
Why July?
- because many more people are in vacation for a longer time so it's easier
to organize bustrip
- people _might_ enjoy a little the Belgian sun ;)
- we, organizers, don't want to fuck up our studies like we have done for
the 3 previous years.. :)
Contact information:
email: wired@pctrading.be
Thanks for your attention.
>------------------------------------------------------- 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 - /incoming/info
Old issues - /info/demonews
Supplemental files - /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
