=[ OUT source code ]======================================================== badly commented code, but here it is anyway... ============================================================================ - getting started ---------------------------------------------------------- if you want to get started and check out or modify some screens, read on. the style of source code is 99% the same as with the 'delta' demo. a key feature being the screens may be included with my demo system, but also they can be used standalone. the screen source code has the extension '.so'. a .so file can be assembled and ran standalone without any extra measures. it just includes a test environment 'tester.s' (including a fps counter and such) and takes off. mostly however, you need to press some stuff on the numeric keypad to get things going. these keys directly access the custom event routines of the screen. if you want to assemble the demo as a whole you can open 'demo.s', assemble it and run. the demo system primarily depends on sync commands from the playing modfile, but can also be synced by keyboard input by changing an equate. - the libraries ------------------------------------------------------------ there are various, most with the extension '.i'. a few others use the '.s' extension. the following are use by this demo: dsp_fix s : dsp bootstrapper by NoCrew earxplao s : the 'multitasking' dsp modplayer fscr2 i : video routines: palette, resolution, blitting and such math i : guess what mem i : dynamic memory management without the swiss cheese effect object3d i : primitive 3d objects and damaging routs for use with human fly s_flydsp s : the human fly rendering pipeline sys i : some cookie shit, cache crap texture i : perlin texture generator, some palettes for a more detailed description of human fly, check out the other text files, bundled with this package: faq txt : an early and incomplete faq format txt : description of humanfly's native 3d object format flow_dsp txt : implementation details of dsp version of humanfly paint txt : humanfly's paintmodes and their implementation rle txt : description of humanfly's native rle sprite format - the screens -------------------------------------------------------------- contourd so : dither-blurred multi frame rotozoomer dspbilin so : bilinear filtered rotozoomer dsprad so : radial blurred logo '#atariscne' fast so : fast environment mapped crosses with background gridspec so : wireframe city kaleido so : 3d environment mapped kaleidoscope showpic so : shows the intro picture spiral4 so : texturemapped spirals (helix) and alpha blended sprites - screen code layout ------------------------------------------------------- a screen contains a jump table of custom events. the demo system has a list to the jump table of every screen. when running standalone, the table address is put into a pointer, for instance: move.l #Radial.table,fxAdr the test environment then knows where to start. a screen contains 4 compulsory first routines: DC.L mainLoop DC.L init DC.L initRT DC.L deinitRT all routines are terminated by an rts. 'mainLoop' should be self explanatory. 'init' is the routine that is called prior to running the demo, i.e. the precalc stuff. 'initRT' is the routine that is called prior to running the screen itself, this needs to be a little zappy unless you want to pause with some still screen or whatever... 'deinitRT' is the routine that frees up all memory reserved by 'initRT'. a failure of init, initRT, deinitRT, i.e. returning a negative number in d0, will cause the demo system to exit. after these four the custom event routines start. the list is terminated by a zero (dc.l 0). as mentioned above, both in the demo system as well as in the standalone screens, the numerical keypad may be used to access these custom events. event | key ------+------- 0 | ( 1 | ) 2 | / 3 | * 4 | 7 5 | 8 6 | 9 7 | - 8 | 4 9 | 5 A | 6 B | + C | 1 D | 2 E | 3 F | 0 10 | . 11 | enter note: although only 18 events can be addressed by the keys, there may be up to 128 for use by the demo system. a key matching an unimplemented event is omitted. - demo system -------------------------------------------------------------- the demo system consists basicly of only a few parts: - the libraries - initialisation of the libraries - initialisation of the screens, their init routs are called - the event sequencer the useful parts amongst the library are the memory manager which is really unmissable if you want to squeeze a demo in 4MB without a harddisk going off every 5 seconds and delaying the flow. the demo system initializes all screens. each screen says they want a block of a certain size to the memory manager (Mem.register). after initialization the memory manager takes the biggest registered block (aligned on long boundary also) (Mem.take). when a screen enters it's realtime initialisation it may call Mem.getBlock, which returns the block's address. also the video part is very useful if you want to change resolution and palette without stripes or other poo on your screen. Screen.requestUpdate this takes palette, resolution routine and screenbase addresses and changes them in the following vbl. passing a zero for each parameter means no change. the event sequencer has two modes, controlled by the equate: 'MANUAL_CONTROL', which says all. Setting it to zero causes the mod file to control the events, see the section below. otherwise screens can be switched to by using the main part of the keyboard 0...9, Q..P (different in french and german, but the order is still there. ;) after you switch to a certain screen you can also control the screen's event by hammering on the keypad. there's one more special thing: the 'testmode'. this equate can help with debugging if your screens are coded in a special way. the idea is to put every screen or palette or whatever critical action between: IFEQ testmode ... ENDC this is mostly useful when running a screen standalone. when it crashes, at least you can see the desktop (or devpac) again. it is useful, but admitantly, a watchdog would be a better solution. - mod file event sequencer ------------------------------------------------- earxplao.s feeds itself with standard mod files, saved from protracker or flextrax. the key is the 'unused' 8xx command. this provides a means of synchronisation, yes, but instead of just using a $800 every so often to jump to the next event in your list, this actually allows the musician to control every event of the demo in what ever order he likes. the most basic commands are the following: $800 : exit demo $801 - $87F : switch to screen 1 - 127 the switching is performed by means of the 'initRT' and 'deinitRT' routines in the screens' jumptables. a command to switch to a non-existing screen is ommited. to fire some events: $880 - $8FF : fire the current screen's event 1 - 128 events are handled from left to right, that means channel 1 is handled first, proceeding to the higher numbered channels. all events on one 'row' in a pattern are handled in between a animation frame of the screen, i.e. one call to a screen's 'mainloop'. ============================================================= lineout 2004 =