950 lines
49 KiB
Plaintext
950 lines
49 KiB
Plaintext
.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.
|
|
|