.Start.of.DemoNews.119..............................................Size:49,755 ______/\___________________________ __ ________________ ___ /\_______ \____ \ ________ _ _ ______ \ / \| \ ________ | \/ ______/ / | \ _) \ \_/ \ | \ / \ \ _) \ | \______ \ / | \ \ | \ | \ / \ \ /~\ \ / \ \_____ /_______/___| /________/ \____\_____/_______/_________/________/ \_____/ |____/ | Subscribers : 2058 DemoNews Issue #119 - March 13, 1996 | Last Week : 2014 ------------- | Change : +44 DemoNews is a newsletter for the demo scene. | Archive Size : 2218M It is produced by Hornet at the site ftp.cdrom.com. | Last Week : 2169M Our demo archive is located under /pub/demos. | Remaining : 733M | =-[Contents]=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Line Section ------ ------------------------------------------------------------------- 31 Calendar 53 Top Downloads 76 Uploads 363 Articles 365 Introduction................................Snowman 422 Demoscene Music WWW Pages...................GD 515 Intro to 3D Graphics - Volume 04............Kiwidog 927 Subscribing 942 Closing =-[Calendar]=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Date Event Location Concact Points --------- ------------------- --------- ------------------------------------- 29 Mar 96 Mekka Germany PV80090@PH80090.HH.eunet.de http://www.xs4all.nl/~blahh/RAW/Parties/Invitations/Mekka.html 02 Apr 96 The Gathering Norway mikaels@powertech.no http://www.ifi.uio.no/~uwek/Crusaders/TG 05 Apr 96 Symposium Germany gandalf@blackbox.shnet.org http://134.28.37.10/~frank/bbx-sym96/bbx96.html 06 Apr 96 X Netherlnd cba@xs4all.nl http://www.xs4all.nl/~herkel 31 May 96 Naid Canada naid@autoroute.net http://www.autoroute.net/~naid More information is at http://hagar.arts.kuleuven.ac.be/~sdog/party.html =-[Top Downloads]-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= NOTE: Statistics are sometimes slightly off due to symbolic links, mirrors, renamed files, and other things that affect the log files. Pc Times FileName.Ext Pc Times FileName.Ext Pc Times FileName.Ext -- ----- --------.--- -- ----- --------.--- -- ----- --------.--- 1 00356 acdu0396.zip 1 00182 animate.zip 1 00027 dst_frac.zip 2 00239 cp16.zip 2 00169 nooon_st.zip 2 00024 vamp10.zip 3 00213 cp1666.zip 3 00159 mfx_tgr2.zip 3 00024 airwar.zip 4 00194 ft206.zip 4 00153 ftj_ymca.zip 4 00021 veced300.zip 5 00186 scrmt321.zip 5 00127 unreal11.zip 5 00019 icekngdm.zip 6 00182 animate.zip 7 00169 nooon_st.zip 1 00238 cp16.zip 1 00089 dn116_3d.zip 8 00159 mfx_tgr2.zip 2 00213 cp1666.zip 2 00083 onesrc.zip 9 00153 ftj_ymca.zip 3 00194 ft206.zip 3 00068 dos32v33.zip 10 00139 ft204.zip 4 00186 scrmt321.zip 4 00056 dcc_3de.zip 5 00139 ft204.zip 5 00053 ggouro2.zip =-[Uploads]-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= =----------------------------------------------------------[File Information]-= All files listed below are on ftp.cdrom.com under /pub/demos. Please keep in mind that all ratings are subjective. If your file transfers are too slow, there are several alternatives: Our code mirror is ftp.co.iup.edu/code. ftpadmin@ftp.co.iup.edu for help. Try getting files from the web at http://www.cdrom.com/pub/demos See /hornet/demonews/demonews.102 for details about ftpmail. You may also wish to check out a couple of other good demo sites: ftp://ftp.arosnet.se/e:\demo maintained by Zodiak / Cascada ftp://hagar.arts.kuleuven.ac.be/demos maintained by Sleeping Dog / Natives Here are also a few good WWW links to try out (under construction): http://www.th-zwickau.de/~maz/sound.html for music and sound utils =-------------------------------------------------------------[Demos:General]-= Location /demos/alpha Size Rated Description =-------------------------------- ---- ----- ---------------------------------= /1994/u/utopia.zip 969 *+ Utopia by Vertex /1995/p/poliisi.zip 775 ***+ Poliisi by Coma /1995/s/supnova3.zip 218 *+ BBS: Super Nova by Palpatine /1996/m/minidemo.zip 35 **+ Minidemo by Crucial /1996/r/ringnes.zip 254 *** Ringens Motion by The Joker /1996/r/rush_pkl.zip 283 ** Rushed by Pankakeland /1996/s/simplesl.zip 1458 *** Simple by Spanish Lords /1996/s/sl_fake.zip 88 ***+ Fake by Sublogic /1996/s/slr-s599.zip 1 *** Simple Scroller by Solar Designer /1996/s/snowfire.zip 9 *+ Snowfire by Anaconda Assembly 1995 4k Intros (ASM95:in4k:) /1995/h/havoc.zip 7 **** 05: Havoc by Extreme /1995/c/clxfinal.zip 10 ***+ 07: Complexity by Byteam /1995/s/strictly.zip 4 ***+ 14: Strictly 4kb by Olppa /1995/0-9/165plasm.zip 2 ***+ XX: 165b Raster Plasma by Project /1995/0-9/4kg.zip 5 ***+ XX: 4kg by Lopez,Firehawk /1995/0-9/4magic.zip 2 *** XX: Four Magic Kaas by The Natives /1995/a/acidrain.zip 4 ** XX: Acid Rain by ??? /1995/a/act.zip 8 **+ XX: Act by Placidia /1995/a/aivopesu.zip 3 *+ XX: Aivopesu by Cannibal /1995/a/alifemem.zip 3 ** XX: Alife by Mriq /1995/a/asm95zea.zip 4 ** XX: 0.5 Weeks by ??? /1995/b/bbuumi.zip 5 *** XX: Bittibuumi by Rubicon /1995/b/bug.zip 3 ** XX: Bug by ??? /1995/c/chaos95r.zip 3 ** XX: Bestial Chaos /1995/c/crystal.zip 4 *** XX: Crystal by Juho Ahonen /1995/e/elements.zip 3 **** XX: Elements by ??? /1995/f/finland.zip 3 ***+ XX: Finland by ??? /1995/f/fucko.zip 2 *+ XX: F. The Optimizing by Astute /1995/h/hellfire.zip 6 * XX: Hellfire by Illumination /1995/k/kakka.zip 1 *+ XX: Kakka by Mov,Inzu /1995/m/math.zip 4 *** XX: Math by Interamni /1995/m/mp!hiloi.zip 3 *+ XX: Hiloi by Masa,Pena /1995/n/nunna.zip 6 + XX: Nunna by Akesoft /1995/o/ortni.zip 4 ** XX: Ortni by Voxel /1995/p/pamppu.zip 7 * XX: Pamppu by Akesoft /1995/r/riuku.zip 7 + XX: Riuku by Akesoft /1995/s/shapes.zip 3 ** XX: Shapes by Petman /1995/s/smooth.zip 4 **** XX: Smooth by Pulp /1995/s/starlit.zip 6 **+ XX: Star Light by XoR /1995/t/tan.zip 4 *** XX: Tan by Marlon Berlin /1995/t/taxintro.zip 6 *+ XX: Taksi by Brainlez Coders /1995/t/tight.zip 3 ** XX: Tight by Pyre /1995/w/wiswatch.zip 7 **+ XX: Wise Watcher by Acid Pixhell Movement 1995 Demos (MOV95:demo:) /1996/u/ulc_star.zip 1677 *** 03: Star Reach by Unl. Creations The Party 1995 Demos (TP95:demo:) /1996/a/ancircs3.zip 1446 **** 17: Circuit (S3 pre) by Analogue The Party 1995 4k Intros (TP95:in4k:) /1995/t/tc_par.zip 15 ****+ EE: 4k Intro by The Coexistence General Probe 1996 4k Intros (GP96:in4k:) /1996/s/stc_4078.zip 4 *** ??: 4078 by Substance Volcanic 1996 Demos (VOL96:demo:) /1996/e/e_magic.zip 446 ***+ ??: Magic by Eclipse /1996/e/exine.zip 1313 ***+ ??: Exine by Anarchy =-------------------------------------------------------------[Music:General]-= Location /demos/music Size Rated Description =-------------------------------- ---- ----- ---------------------------------= /songs/1995/xm/v/vg-sunri.zip 219 ** Sunrise Experience by vildauget /songs/1996/it/j/jasmine.zip 125 *** Jasmine Tea by Lord Blanka /songs/1996/it/k/kanamon.zip 254 ***+ Kanamon Worms by Lord Blanka /songs/1996/it/l/lizlevit.zip 155 **+ Leviathan 2010 by Lizard /songs/1996/s3m/f/fdn-ffg.zip 188 **+ Fall from Grace by Ender /songs/1996/s3m/f/fm-energ.zip 274 **** Energia (Planar Remix) by Necros /songs/1996/s3m/w/wppeals.zip 25 *** West Point Peals by Paul Watkins /songs/1996/xm/e/el-alsom.zip 134 **+ Always Somet. by Electric Lucidity /songs/1996/xm/e/el-scorp.zip 384 *** Scorpion Win. by Electric Lucidity /songs/1996/xm/e/el-shiom.zip 82 *** She Is Once.. by Electric Lucidity /songs/1996/xm/e/el-subtl.zip 157 **+ Error of Sub. by Electric Lucidity /songs/1996/xm/e/el-toeac.zip 16 ** To Each Thei. by Electric Lucidity /songs/1996/xm/e/exjungle.zip 81 * 1st Try Jungle by Stefan Trischler /songs/1996/xm/g/glory.zip 95 *+ Glory by Pix /songs/1996/xm/g/gwattack.zip 0 ** Global World Att. by Eye of Hurr. /songs/1996/xm/h/happy.zip 61 ** Happy Land by Pix /songs/1996/xm/h/herelies.zip 1081 + Here Lies One by Noiseman /songs/1996/xm/i/icu.zip 312 **+ I See You by Pix /songs/1996/xm/u/undefeel.zip 289 ****+ Undetermined Feelng by Ryan Cramer /songs/1996/xm/u/use-chin.zip 147 ** Cyber China by Dustbin /songs/1996/xm/u/use-hypn.zip 195 **+ Hypnosis by Nabo /songs/1996/xm/u/use-icy.zip 88 *** Icy Flower by Nabo /songs/1996/xm/u/use-trib.zip 475 *** Tribal Steps by Dustbin =--------------------------------------------------------[Music:Non-Reviewed]-= Location /demos/music Size Description =-------------------------------- ---- ---------------------------------------= /programs/convert/amf2mod.zip 23 AMF to FastTracker 1.0 MOD converter /programs/convert/amf2s3m.zip 8 AMF to ScreamTracker 3 Module Converter /programs/misc/ask.zip 4 Font changer for ST3 + ImpulseTracker /programs/players/amp121.zip 40 AMP AWE32 Module Player v1.21 /programs/players/awemp145.zip 59 AWEMP AWE32 Module Player v1.45 /programs/players/cmod305.zip 107 CapaMod player v3.05 /programs/players/cp1666.zip 495 Cubic Player v1.666 /programs/players/cwd_ppp.zip 19 Pervo Player v1.0 /programs/players/genmod.zip 433 Generic Module Player v1.3 /programs/players/juicy17.zip 38 Juicy Player MOD player v1.7 /programs/players/mod.zip 12 MASSOUND Player v9 /programs/players/starp225.zip 34 StarPlayer v2.25 /programs/players/timidity.zip 219 TiMIDIty Player+Source v0.90 /programs/players/wemp96.zip 37 Wavefront Extended Module Player v0.96 /programs/rippers/burp100.zip 31 BURP Ripper v1.00 /programs/rippers/rippr495.zip 181 Ripper v4.95 /programs/samplers/wav_2_xi.zip 14 WAV2XI sample converter v0.72 /programs/samplers/wavetoxi.zip 20 Wave to XI sample converter /programs/trackers/amusic11.zip 81 Amusic AdLib tracker v1.1 /programs/trackers/digitr30.zip 168 DigiTracker v3.0 /programs/trackers/ft206.zip 345 FastTracker v2.06 /programs/trackers/it105.zip 362 ImpulseTracker v1.05 /programs/trackers/radpas13.zip 11 Reality AdLib -> TP Libraries v1.3 =----------------------------------------------------------[Graphics:General]-= Location /demos/graphics Size Rated Description =-------------------------------- ---- ----- ---------------------------------= /disks/1994/cyrout.zip 34 + Anti Lord Cyrix by Various Artists /disks/1996/lt-psych.zip 661 ** Psychedelia by Light /disks/1996/lt-x9.zip 434 **+ A Journey Through X9 by Light Abduction 1995 Graphics (ABD95:grfx:) /images/1995/j/jmagic.zip 33 **** 01: Jmagician by Der Piipo /images/1995/m/madsanta.zip 32 ***+ 02: Mad Santa by Dice /images/1995/e/escape.zip 113 ***+ 03: Escape by Slimy Devil /images/1995/m/melody.zip 34 ** 05: Melody by Cross /images/1995/k/k_picas.zip 26 **+ 06: 45 Minute Picasso by Kowtow /images/1995/b/brown_ey.zip 56 **+ 07: Brown Eyed Girl by Tohe /images/1995/b/babyface.zip 54 **+ 08: Babyface by Gnome /images/1995/b/bathtime.zip 28 *+ 10: Bathtime by Damac /images/1995/s/squid.zip 58 ***+ 11: Squid by Exeter /images/1995/k/kiesus.zip 34 **+ 12: Kiesus by Prager /images/1995/p/prayer.zip 132 *** 13: Prayer by Captain Drago /images/1995/c/centurio.zip 49 ***+ ??: Centurion by ??? /images/1995/e/ernest.zip 43 *+ ??: Ernest by ??? /images/1995/g/grn_sig.zip 6 **+ ??: ??? by ??? /images/1995/k/kapy_fin.zip 20 **+ ??: ??? by ??? /images/1995/k/kissa62.zip 34 ***+ ??: ??? by ??? /images/1995/n/nosigne.zip 138 [n/a] ??: ??? by ??? /images/1995/s/shqsign.zip 5 + ??: ??? by ??? /images/1995/s/sunset.zip 19 ** ??: Sunset by ??? Assembly 1995 Graphics (ASM95:grfx:) /images/1995/f/fiction2.zip 38 ****+ 01: Fiction by Visualize /images/1995/m/mystery.zip 43 **** 02: Mystery by Artifec /images/1995/a/agony.zip 36 *** 03: Agony by Jogi /images/1995/v/valk31.zip 163 **** 04: Valkyria by Visigoth /images/1995/a/an_axe.zip 55 **** 07: An Axe by Yoga /images/1995/p/phobic.zip 65 **** 08: Phobic by Ironman /images/1995/b/baby.zip 45 **+ 10: Baby by Facet & Super /images/1995/g/grandma.zip 35 *** 12: Grandma by Tyshdomolo /images/1995/n/nrtzrkbl.zip 104 ** 14: Blend by Netesten /images/1995/a/after_li.zip 43 ** ??: ??? by ??? /images/1995/b/battlewa.zip 75 ** ??: ??? by ??? /images/1995/c/cowboy.zip 13 + ??: Cowboy by ??? /images/1995/d/dasboot6.zip 22 + ??: Das Boot by Hazard /images/1995/d/deespalf.zip 35 ***+ ??: ??? by ??? /images/1995/d/dragon.zip 92 *** ??: ??? by ??? /images/1995/d/ducepic.zip 64 **+ ??: ??? by Duce /images/1995/f/firedray.zip 30 ***+ ??: ??? by ??? /images/1995/f/frost.zip 14 + ??: Frost by Nagath /images/1995/h/hcosmic.zip 21 *** ??: ??? by ??? /images/1995/h/hellview.zip 63 * ??: ??? by ??? /images/1995/h/huma2.zip 131 *** ??: Huma by Dreamer /images/1995/i/imp_wolf.zip 77 *** ??: ??? by Wolf /images/1995/i/indian.zip 118 **+ ??: Indian by M-Stone /images/1995/i/ingas.zip 88 ***+ ??: Ingas by Louie /images/1995/l/ladywar2.zip 45 *+ ??: Lady at War by Mindeye /images/1995/o/outspace.zip 33 **** ??: Outer Space by Toxic /images/1995/p/pad-newb.zip 30 *+ ??: ??? by Pad /images/1995/p/pilvii.zip 27 **+ ??: ??? by Saffron /images/1995/r/rabbits.zip 31 ***+ ??: Rabbits by ??? /images/1995/r/rosie.zip 39 *** ??: Rosie by ??? /images/1995/s/sami2.zip 131 ** ??: Sami by Cork /images/1995/s/si-nrn.zip 47 **+ ??: ??? by ??? /images/1995/s/sld-domi.zip 52 *** ??: Domination by Slimy Devil /images/1995/t/tb_ass95.zip 102 *** ??: ??? by Treabeard /images/1995/w/warrior.zip 47 ** ??: Warrior by Menace /images/1995/w/whoisit.zip 16 **+ ??: Who Is It by ??? Assembly 1995 Raytracing (ASM95:grtc:) /images/1995/s/sld-ftch.zip 223 ** ??: Fetch by Slimy Devil Juhla 2 1995 Graphics (JUH95B:grfx:) /images/1995/m/mistydrm.zip 27 ****+ 01: Misty Dream by Prayer /images/1995/d/dpclock.zip 35 **** 02: Clock Tower by Der Piipo /images/1995/p/portrait.zip 27 **** 03: Man's Portrait by Nik /images/1995/b/boymansk.zip 60 **** 04: Boy Man Skull by Slimy Devil /images/1995/t/temple.zip 31 **+ 05: Temple by Ember /images/1995/d/demon.zip 21 * 06: Demon by Gnome /images/1995/s/sadflash.zip 28 * 07: Sad Flasher by Primon /images/1995/0-9/2oddity.zip 34 *+ 08: The Two Oddity by Mazor /images/1995/f/fright.zip 31 *+ 09: Fright by Cork /images/1995/m/mvmadman.zip 17 *+ 10: Man Man by Mov /images/1995/n/nitghoul.zip 25 * 11: Ghoul by Nitric /images/1995/t/theslob.zip 23 **+ 12: The Slob by Duke /images/1995/l/lizard.zip 28 *+ 13: Lizard by Damac /images/1995/v/valley.zip 8 + 14: Valley by Mithrandir /images/1995/g/graffiti.zip 18 ** 15: Graffiti by Manticore /images/1995/s/steelfac.zip 50 * 16: Steel Face by Emetic The Gathering 1994 Graphics (TG94:grfx:) /images/1994/z/zzmadman.zip 48 **** 01: ZZ Madman by Fairfax /images/1994/t/tonyofra.zip 56 **** 02: Tony of Razor by Tony /images/1994/i/inyourfa.zip 42 ****+ 03: In Your Face by Archmage /images/1994/s/spacegua.zip 48 **** 04: Space Guardian by BCR /images/1994/j/julia.zip 33 ***+ 05: Julia by Decker /images/1994/c/conan.zip 53 *** 06: Conan by Blue Devil /images/1994/d/dentist.zip 164 ***+ 07: Dentist by Tiedye /images/1994/i/illusion.zip 69 **+ 08: Illusionia by Bridgeclaw /images/1994/b/badtrip.zip 57 ***+ 09: Bad Trip by Pal The Party 1993 Graphics (TP93:grfx:) /images/1993/y/yell.zip 7 ****+ 01: Yell by Lithium /images/1993/s/skyr_pxl.zip 66 **** 02: ??? by Pixel /images/1993/w/watery.zip 10 **** 03: Watery by Arachnatron /images/1993/w/windows.zip 2 + 04: Windows Sucks by Gore /images/1993/a/alita.zip 29 ***+ 05: Alita by Sigfrid /images/1993/a/air.zip 31 **** 06: Air by Marvel /images/1993/h/horror.zip 20 *** 07: Horror by Lord Something /images/1993/a/arnial.zip 14 **** 08: Arnold by Joachim /images/1993/w/womanru1.zip 21 *** 09: Woman by Trau /images/1993/a/aghev02.zip 20 *** 10: Aghev by Havoe /images/1993/s/sti_ephr.zip 31 **+ 11: ??? by Sti /images/1993/m/mulkero.zip 2 * 12: Mulkero by Phontom /images/1993/v/vis16.zip 9 **+ 13: Vis 16 by Zeb /images/1993/s/sul_comp.zip 17 ** 14: Sul by Barti /images/1993/a/alex.zip 13 **+ 15: ??? by Alex /images/1993/m/max_comp.zip 47 **+ 16: Max by Zebig /images/1993/i/inteli.zip 13 * 17: Intel by Jeskola Productions /images/1993/s/sonic_ca.zip 14 ** 18: Sonic by Consel /images/1993/a/apple.zip 17 *+ 19: Apple by Neuronik /images/1993/c/chaos.zip 13 ** 20: Chaos by Maestro /images/1993/s/strawbry.zip 21 ** 21: Strawberry by PL Wired 1994 Graphics (WIR94:grfx:) /images/1994/u/ukko39.zip 66 **** 01: Ukko by Zuul Design /images/1994/n/nadia.zip 39 [n/a] 02: Nadia by Moebius /images/1994/r/robot.zip 73 ***+ 03: Robot by Youfi /images/1994/h/hn-ranma.zip 20 ** ??: Ranma by Hypernova /images/1994/s/sunsweat.zip 59 ** ??: Sunsweath by Balex-T /images/1994/t/tarzan.zip 44 * ??: Tarzan by Fred =-----------------------------------------------------[Graphics:Non-Reviewed]-= Location /demos/graphics Size Description =-------------------------------- ---- ---------------------------------------= /party/1993/a/a93-pics.zip 360 Photos from ASM93 taken by Extreme =------------------------------------------------[Miscellaneous:Non-Reviewed]-= Location /demos Size Description =-------------------------------- ---- ---------------------------------------= /hornet/demonews/demonews.116 55 DemoNews 116 /hornet/demonews/demonews.117 38 DemoNews 117 /hornet/demonews/demonews.118 45 DemoNews 118 /info/traxw/traxweek.048 29 TraxWeekly 48 /info/traxw/traxweek.049 42 TraxWeekly 49 /info/traxw/traxweek.050 65 TraxWeekly 50 =-[Articles]=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= =---------------------------------------------------[Introduction]--[Snowman]-= Hello all, and welcome to DemoNews issue 119. CELEBRATION. Our mirror at ftp.luth.se has been restored. I made a note to myself to check the exact directory where the mirror resided on their site. Unfortunately, when it came time to write this introduction I could not access the site. But I have faith... the mirror is there and Europeans should experience a speed gain when downloading. I highly encourage you all check out that #trax people picture web page that GD mentions in his article below. You never know who or what you might find there. Many of you may wonder why this issue is out so late. This week I actually have two somewhat legitimate excuses. First, I couldn't release the issue yesterday because our entire company had to change IP addresses after an ISP change. All of the servers in our department were offline at one point or another. The upside to this is that we now have a direct T1 connection to wcarchive here and I'm getting 177k/s transfer rates. This makes me very happy. :) Second, and more importantly, I've found a kindred spirit. Those of you in the music scene can hop on #trax. Those who code can read comp.sys.ibm.pc.demos. But what is a demo maintainer to do? There just aren't that many forums where open discussion about archive management take place. One of the three Simtel archive maintainers is Michigan native Christopher Gavula. He also happens to be affiliated with Walnut Creek CDROM and is a Novell NetWare expert. He flew here to California two days ago to assist us with network upgrades. The two of us started talking about archive maintenance. Then we _really_ started to talk about archive maintenance. It turns out, oddly enough, that the Simtel and Hornet Archives are very closely related. We spent a great deal of time with a whiteboard and markers, drawing diagrams of how we handle files and update descriptions. I spotted several intriguing ways to improve performance on our site. It was amazing. Here was someone in an unrelated field talking about how he moves files out of /incoming and keeps the base directory tightly arranged. After hours of discussion, I came to the conclusion that the Hornet Archive and Simtel were at similar stages of development, but that both archives were years ahead of almost all other ftp.cdrom.com-based archives. So why am I telling you all of this? Consider it a precursor to a more organized and efficient demo archive. One that will be tailored to meet _your_ specific needs. One that is searchable, user-correctable, modifiable, and easily maintainable. One that is not only functional but also aesthetically appealing. There's a real-time raytraced golden light in our near future. Snowman / Hornet - r3cgm@cdrom.com =-------------------------------------------[Demoscene Music WWW Pages]--[GD]-= Back in demonews 102, I reviewed a couple demoscene-related worldwide web pages. I had hoped to make it a regular demonews feature, but this didn't happen. Recently, a number of web pages have surfaced on the Internet which are focused on computer music. I would like to direct your attention to three such webpages of interest to the music scene. _____Virtual Music The Virtual Music page is designed as a central point for gathering information on computer music or for contacting other musicians. One of the links offered on this page is a frequently asked questions guide for the alt.binaries.sound.modules newsgroup. User links are sorted alphabetically and a click on the letter of the user's choice will go to that section of the alphabetic listing. This would be a good place to use html frames, and put the alphabetic selector in another window, but the author of this page stresses his desire to make it compatible with as many browsers as possible. Webpage URL : http://www2.gvsu.edu/~behrensm/vmp/index.html Maintainer : Matt Behrens (Zigg) Send email to: behrensm@river.it.gvsu.edu _____#trax Homepage This page serves as a home for the IRC channel #trax which is frequented by novice and expert demoscene musicians alike. The page is very well organized, and upon startup provides the user with an organized menu. There are two main sections to this page and several smaller sections. The two main sections also have a large icon on the main page. The 'People' section, one of the two large branches from the main page, is a listing of people who frequent #trax. For most of the people listed, a picture is shown. All of the pictures that do appear have been scaled to the same size to provide a consistent appearance. In each personal biography for every person listed on this page, their real name, alias, email address, group affiliation, and talent is listed. Homepage links are provided through a click on the person's alias, email links are available by clicking on the email address, and group links are available by clicking on the group name. The other large section, the 'Groups' section, is a newer addition to the page and does not have many groups listed as of yet. Groups that are listed have a large group logo next to some brief group information. Listed is the group name, members, talents, and a contact email address. The maintainer of this page is Ryan Vettese (aka b0b). His email address is: b0b@datex.ca Webpage URL : http://www.datex.ca/trax Maintainer : Ryan Vettese (b0b) Send email to: b0b@datex.ca _____Impulse Tracker Homepage This is a page dedicated to Impulse Tracker, a module composition program coded by Jeffrey Limm. This tracker was first released in December 1995. Its interface is similar to that of Scream Tracker 3. This page provides users with a central location from which they can download the newest version of the program, download a few Impulse Tracker modules, send email to the author of the program, and link to the Impulse Tracker module directory on the Hornet Demo archive. Also provided on the page is the program's update history and module format technical specifications, as included with each release. The page is well structured, and is an excellent resource for fans of this tracking program. Webpage URL : http://www.citenet.net/noise/it Maintainer : Shawn M. Send email to: shawnm@citenet.net _____Conclusion The information provided on all of these pages is current and generally well organized. The maintainers have done a great job with the setup, and the content of each page reflects its title. The music scene has grown by great numbers because of the power of the Internet. Witness the computer music revolution through the eye of your web browser. GD / Hornet - gd@ftp.cdrom.com =------------------------------[Intro to 3D Graphics - Volume 04]--[Kiwidog]-= _____Introduction Hi again! :-) Well, it looks like we're done with the beginning 3D info, so it's time to take a break for a few weeks and change gears to something that people seem to be very interested in. You know 'em, you love 'em, and you love to hate 'em.... Polygon fillers. Or perhaps I should call them "shading algorithms"... well, not all of them are shading (f.ex. texture mapping), so "polygon fillers" is probably the better term. Anyway, the fillers I'm going to cover over time are ones we seem to see quite a bit of these days... - Flat/Lambert Shading (today's article! Yippee! :) - Gouraud Shading - Phong and Interpolated Phong Shading - Affine Texture Mapping - Perspective Texture Mapping - Environment Mapping (better called Reflection Mapping) There will be other articles in between all of these; for example, I've decided to move up the discussion of BSP trees to the NEXT ARTICLE, #5, up from what would have been #10 or so. This is because you can't do solid objects without some kind of face ordering, and the three generic options seem to be sorting (painter's algorithm), Z-buffering, and BSP trees. Since I hate sorting... I mean _REALLY_ hate sorting, and Z-buffering is just a pain in the neck, BSP trees seem to be a pretty important thing to discuss early on. So I'm doing them for the next article. After that, we'll be going up through Phong before I do some other stuff before texture mapping. This week's article is going to cover Flat Shading (shading an entire poly with one color), and Lambert Shading (same as flat shading, but that the one color is chosen by a lightsource). Hope you're prepared. :-) Before we begin, I've got to point out two things... One, the example source for article #3, (i.e. what would be DN3D_3.ZIP). After thinking about it, sample source just to demonstrate normals without reason is pretty asinine. It would make more sense to actually have a USE for those normals. As such, I'm going to concentrate the example source for both article #3 and this one, #4, into a single supplement, DN3D_3&4. This will allow me to actually have a purpose for the normals I explained last time, using them for solid objects. The second thing is a major thing from the last article... _____MAJOR Error In DemoNews 118 Within Article #3 If you got your copy of DemoNews 118 through the email listserver, or if you got it through FTP before around noon EST on 3/6/96, there is a major "bug" in my 3D article. Somehow during the course of assembling the final DemoNews, Snowman's text editor screwed up the spacing on the vector diagram in the middle of the article. If your diagram looks like this..... P2 .___ A P1 ----. \ \ B \ . P3 . P4 This is INCORRECT, and probably confused you if you're learning this stuff for the first time. The diagram SHOULD be this.... P2 .___ A P1 ----. \ \ B \ . \ P3 . P4 Again, this was a problem that resulted from the text editing, which I didn't see until after DN 118 was out, so it couldn't be prevented. This has happened a couple times in the past with other diagrams as well. I'll try to watch out for them in the future, but I want to apologize for this one to any people who got hopelessly confused by that flaw. The updated diagram here should clear things up (resolving where I said the normal goes, which point is the center point of the two vectors, etc). If you got DemoNews 118 through USENET or through FTP _after_ noon EST on 3/6/96, you probably have the correct version already, so don't worry about it. Nonetheless, if the info is pertinent, you might want to check to make sure. :) Okay, now that that's resolved... _____Flat Filling - What's Involved? Just like everything else, there are many ways to do flat filling. The two methods I see most commonly seem to be... 1. Dual Edge Fill - Start at the top of your polygon and work downward simultaneously along both the left and right edges, changing lines when vertices are hit on either side, and stop when both traces hit the final vertex. Fill as you go. 2. Single Edge Buffered Fill - Draw lines along each edge, not plotting the pixels but saving their offsets. Fill in an edge buffer appropriately. After all the sides are processed, use the edge buffer for the fill. Note that I just made up the names; if there are actual names for these methods then substitute those in there instead. :) So which one of these two methods is better? Well it depends. I've heard from people that the first method is faster (debatable), but that's _IF_ you get it to work. The problem with the first method is that there are so many conditions (like when vertices are hit along the edge, trying to update correctly without loosing track of which side is where, and problems with straight horizontal edges), that it becomes a big problem for debugging. I recall trying that first method when I first wanted to make a poly filler. It failed miserably, even after weeks of trying to debug it. Nonetheless, if you get it to work, it's reportedly quite fast. I can't confirm this myself, as I abandoned the algorithm. The second method, on the other hand, is quite easy to implement, and still quite fast from my point of view. It also has the advantage of working for any-number-of-sided polygons, just by pasting in a few more edge traces for the new edges; the algo stays the same. The versatility and ease of coding are big advantages for it, and fortunately there are _no_ special conditions to worry about, which helps in speed quite a bit... As you can probably tell, I'll be covering the second method in this article. ;-) _____Overview of the Edge Buffered Fill The fill basically has two very distinct parts. The first is the edge buffering, and the second is the filler itself. You need to set up a memory buffer that has room for two offsets for each Y line on the screen (in whatever resolution you use). The two offsets total either 4 bytes for real mode, or 8 bytes for protected mode. Multiply that amount by your Y resolution, and that's your buffer size. All we need to do is fill in this buffer with the left and right sides of the polygon for each scanline, and then the filler will just start at the left and fill to the right for each. No biggie. So how do we fill in this buffer? Well what we need is a special routine that "traces" a given edge and fills in the buffer as it goes along, checking each line to see where's it's at to know if the buffer needs to be updated. If the current offset is less than the leftmost offset at the current scanline, it replaces the left offset with itself. The same goes for the right offset.... if the current one is greater, it replaces the right offset with itself. This goes on until the edge trace is done. If you do this for all the edges of the polygon (3 for triangle, 4 for quadrilateral, etc.), you'll have your final buffer for the filler to use. Well now we need to make this special edge tracer. Well where do we begin? It turns out we don't need to start from scratch, that much is for sure... because most likely you've already made a lot of it. If you think about the fact that edges are straight lines, and they follow in a set path moving offset by offset, you'll see that the edge tracer is just a small modification to.... A generic line routine. :-) I'm assuming you've all made a line routine by this point. Whether it's a fixed point line or a DDA line (the one that uses an errorterm) doesn't matter. The point is you've got one. If not, there are other places you can get information from; a good algorithm to look up is Bresenham's line algorithm. I can't really cover that in detail here; that would be an article in itself, and I'm guessing that very very few of you need that info at this point. :) So anyway, you've got a line routine. Well all we need to do is use that exact same routine, with a few modifications... - Replace the part (or line of code) where the pixel is drawn to a section that checks the current offset against the left/right offsets of the current Y line and updates if necessary. - When the Y changes (in the major for Y-biased lines (abs(slope) > 1) and in the minor for X-biased lines (abs(slope) < 1) ), update the current Y line in the buffer so you know which left/right offsets to check against. The first Y will be the Y value from the first point, at the start of the line. That's all it is! :) If you do this for all of your edges of your polygon, you'll have a buffer that's ready for filling. But wait! What about when we first start the edge tracing? What do we do if there are no offsets to check against? Are there any "initial" values that we need? Yup, sure are. Before each poly fill, you need to refill the buffer with initial values. You can either refill the entire buffer, or as an optimization you can just refill the buffer just for the Y lines that the previous poly changed. Either way, you want to guarantee that when a trace is the first one to hit a given Y line, it is absolutely certain it WILL be the rightmost and WILL be the leftmost offset. What values to use then? Simple... use your maximum value (either FFFFh or FFFFFFFFh) for the leftmost offset, and minimum value (0) for the rightmost. There's not a single line that will go down that won't replace those. :) Anyway, now you've got this nice filled buffer for your polygon. Now we just gotta fill between the edges. Simple enough. For each line that the edge traces have filled in, you just start at the left offset, and fill (rightoffset-leftoffset) pixels in. In assembly, this is a simple thing to do in a linear screen layout, like Mode 13h (or a blitted linear virtual screen)... mov edi, leftoffset mov ecx, rightoffset sub ecx, edi mov al, color cld rep stosb You could also divide the length by 4 and use stosd, then fill in the remaining bytes after, like so... mov edi, leftoffset mov ecx, rightoffset sub ecx, edi mov ebx, ecx shr ecx, 2 mov eax, color ; assuming color is already prepared to be in all 4 bytes. cld rep stosd mov ecx, ebx and ecx, 3 rep stosd Something like that. There are variations and optimizations all over the place, and I'll leave those to you to figure out. :-) The only thing left that the filler needs to know is exactly WHICH scanlines are the ones that need to be filled, i.e., where's the top and bottom of the fill process? Well you've got several options. One would be to sort your vertices by Y before the fill process begins, and fill from the Y of the top one to the Y of the bottom one (this is very very easy for polys with low numbers of sides, like triangles). You can also do a tremendously slow method that checks the offset buffer each line for the values and ignores the line if both the left is the maximum value and the right is the minimum value, like the initialization gave it. That's another option. It's very inefficient unless you have polys with really high numbers of sides, but that's extremely rare (and in my opinion kinda dumb :) But nonetheless, it's an option.... there are lots of ways to accomplish each step. And that's it! Our flat filler is done... pretty simple, eh? This is one of those routines that people seem to think is a lot harder than it actually is, until you just get right down to it and code the sucker (note that that's with this method... I still believe that first method is damn difficult in all honesty... I doubt I'll ever break down and code it that way :-) Okay, so we can do flat filling. Well what if we want to lightsource that color? That's when our normals come into play... _____Turning Your Flat-filler Into A Lambert-filler The whole idea behind lightsourcing a color is pretty simple... find the angle between the surface and the lightsource (assumed to be a point somewhere), and shade appropriately. The narrower the angle (closest to zero), the more the surface points towards the light and the brighter it gets. The greater the angle (approaching 90 degrees), the more the surface gets darker and darker. Finally, between 90 and 180 degrees, the surface is pointing AWAY from the direction of the light and gets a "shadow" color, which is either the ambient light color (the minimum) or pure black if there's no ambient light (which can create some pretty cool effects actually). So all we have to figure out is, how do we find the angle between the direction of the surface and the lightsource? Here come our normals... We already know from last time that our normal is the direction the surface is "pointing" towards. Well we can find the angle "between" two vectors, using that thing we ignored the last time, the Dot Product... recall that the Dot Product A.B = (Ax * Bx) + (Ay * By) + (Az * Bz) Well the cosine of the angle Theta between the two vectors A and B is A.B Cos(Theta) = --------- |A|*|B| where |A| and |B| are the lengths of vectors A and B, respectively. Now we know that vector A is going to be our normal, so what's vector B? We need some kind of location for the lightsource, and that's what B is for. Our normal A is a vector from the origin, so if we make a second vector from the origin to the light by "moving" the position of the lightsource appropriately to preserve the same angle with the polygon, we'll get the B vector that we need. Well there's a problem here... in order to move (translate) the lightsource to be relative to the origin, we need to know where our relative origin is, i.e. what point on the polygon is our theoretical "new" origin? The point you use for the relative origin will determine exactly where the lightsource vector comes from, and will directly affect the final color. Now if you just use one of the vertices, you'll get a major accuracy problem. Take a cube for example... if one of the faces of the cube is pointed directly at the lightsource, you still won't get the brightest possible color if you use a vertex for checking, because even though the FACE is pointed right at the light, the normal AT THAT VERTEX is certainly not. It's parallel to the direction of the plane, but at a different place, which will give a different angle to the light. So what point should we use? Well if we think about it, we want the light to be judged by the most average point on the polygon, since that will give the best representation of what the color SHOULD be. What's the most average point on the polygon? Why the center, of course. :) Just average the coordinates of all the vertices on the poly (for each component), and the final coordinate should be right in the dead center of your surface. This is a new vertex which otherwise is meaningless as far as the model goes, but it's perfect to use for lightsourcing. :) Note, if this whole lightsourcing section has confused you to death (quite likely with the way I talk :) then don't fret... I'll put a PCX diagram in the supplement to clarify what I'm talking about in here. Now what about that "length" deal? We need to take the Dot Product of A and B, but then we need to divide by the length A * length B in order to get our angle cosine. The thing is, divides aren't cool. You might be realizing now why we set our normals to length 1 back in the last article. This is why. :) If we have both A and B as length 1, we can eliminate BOTH the divide AND a multiply and only use the dot product to find our cosine! :-) Now if you look at it, B is still not length 1.... we don't have a clue where the lightsource is until we translate, so it's probably not going to be length 1. This means we'd have to do a square root calculation and the divide anyway, to get the correct angle. It's at this point that you ask, what do I want to do with my lightsource? If you plan on keeping it in the same place all the time, then you can fudge the lighting a bit by not using surface centers but the _object_ center (like the center of a cube)... that way, you could have only one point checked for distance against the lightsource, and that can be precalculated to give the light a vector length of 1 from that point (for vector B). After all, all we really care about in a case like that is the light's angle, not its distance. Then, B would be length 1, and we're all happy. :) On the other hand, if you'd like moving lightsources, accuracy, and shading intensity determined NOT just by angle, but also by how far away the light is, then you'll have to put up with the length calculation (one square root, three multiplies, one divide). Now the three multiplies _can_ be avoided as they're just square calculations (X^2, Y^2, and Z^2), so if you have the memory and know what your maximum ranges are between the lightsource and your faces, you can pregenerate a "squares" table for those amounts. If the possible range is too high, you'll take a speed hit of 3 muls (not too bad in actuality). The divide is a pain, but there's not much we can do about it in this case. The REAL speed thief here is the square root... People have been discussing for ages how to do a fast square root. It's one of those things that people are perpetually trying to improve. I haven't kept completely up to date on the newest methods (there was one I recently read in a C/C++ magazine on algorithms, but I can't remember the method offhand). So I am only familiar with two ways personally... either make a lookup table (unacceptable unless you have a very limited number of values, really)... or a certain fixed point square root routine. I don't have the room here in the article for DemoNews to explain the algorithm for the fixed point square root that I use, but I'll explain it in the supplement. In the meantime, you can still experiment with the same principles using conventional floating point (it's slow, but it'll get the concepts down), or if you already know a fixed point sqrt(), go ahead and use it. But check the supplement when I release it for an explanation of one algorithm. :) Okay, so we now have all the components we need, which will give us the cosine of the angle between the lightsource wherever it is and the face we're trying to shade. Now you can either do one of two things... you can judge the lighting by the cosine ITSELF (1 is brightest, going down towards 0 gets darker, 0 is the threshold, and 0 to -1 is shadow), or you can make an arccos() table and use the angle itself. The only disadvantage of using the cosine alone is shading "falloff", since the cosine decreases more and more rapidly as you approach zero. Personally though, from the results that I see just using the cosine itself, it's not such bad falloff that it's worth doing an arccos() calculation for (granted, if you think it's bad, then feel free to put that last part in). :) Once you have your value, if you have a color gradient going from light to dark or vise-versa, you can directly match your cosine (or the angle itself) to the color, and voila you're done! Just drop that color into your new flat filler, and take 'er away. :-) Well I've run WAY over my space limit for this article, so I'm going to have to stop here... check out the supplement when I finish it (it will be DN3D_3&4.ZIP under ftp.cdrom.com/pub/demos/incoming/code) for source demonstrating the normals, flat filler, and lightsource calculations. I'll also cover that fixed point square root that I couldn't fit in here. :) Next time, we'll take an in-depth look at BSP trees, since I think they're far too cool to put off until later. And for those of you who already know BSP trees, DON'T ignore that article! I'll be covering a different kind of tree generator that I think is more efficient than the typical recursive method. :-) Until next time... Kiwidog / Hornet , Terraformer - kiwidog@vt.edu =-[Subscribing]-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= _____How to subscribe to DemoNews Mail to : listserver@unseen.aztec.co.za Body : subscribe demuan-list [first_name] [last_name] The listserver will send DemoNews to your e-mail's return address. _____Back Issues Older issues of DemoNews can be located under /demos/hornet/demonews. Newly released issues of DemoNews are posted to /demos/incoming/news. =-[Closing]-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= For questions and comments, you can contact us at r3cgm@cdrom.com Your mail will be forwarded to the appropriate individual. ...........................................................End.of.DemoNews.119.