______/\__________________________ __ ________________ ___ /\_______ \____ \ ________ _ _ ______ \ / \| \ ________ | \/ ______/ / | \ _) \ \_/ \ | \ / \ \ _) \ | \______ \ / | \ \ | \ | \/ \ \ / \ \ / \ \_____ /_______/___| /_______/\____\_____/_______/_________/________/ \_____/ |____/ 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: 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