Copy Link
Add to Bookmark
Report
Demo News 119
.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
-- ----- --------.--- -- ----- --------.--- -- ----- --------.---
<COMBINED LIST> <DEMOS LIST> <GRAPHICS LIST>
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 <MUSIC LIST> <CODE LIST>
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
<Files downloaded total : 061148>
=-[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.
