Page #1 OutLine of Documentation 1-3... This document has 3 pages relating to tetris 4-6... Section on general programming tips 7-8... Section critizing poor programming efforts on Amiga 9 ... Greetings + Mailing Address ;************************************************************************* ;************************************************************************* ;************************************************************************* One - tetris ;************************************************************************* ;************************************************************************* ;************************************************************************* Welcome to Amiga Tetris.s by Andy Hook These are some of the thoughts behind my release of this source code: I've been programming for a while now, and in looking back, I wish that I'd known, when I first started programming, the tricks and shortcuts that I know and use now. I guess learning may be a kind of snowball effect, and a good push seems to sometimes get the ball rolling that much faster. Tetris itself, I think tetris is a good example of addictive game design. The game operates under a rule based system allowing you to anticipate the effects of any action - before you make it... your own successes or failures accumulate to spell your final outcome...the game is crisp, bright. The components of the graphics, sound and rules all stand out in bright contrast within themselves, not mushy and vague like most games. The rules in particular are meaningful within the scope of the game, not capricious and arbitrary. In regards to releasing "Tetris" to the public domain: I don't try to hide the fact that this is a clone of the arcade "Tetris". I don't call it obsession, or "steishinflagellate", or "tetrix" and sell it as shareware and attempt to immorally make a profit off of somebody elses genius. My understanding of the legality of this public domain release is that I can use any copyrighted name,logo or music as long as its not for profit. The legality of it becomes a bit murky when somebody like Fred Fish charges a duplication fee for it...but I have disseminated the source widely and far, thus I think that would protects Mr. Fish if he added this to his collection. (Additionally I think all those other versions of tetris are somewhat poor and their not releasing the source code further diminishes the value of their product... ) Additionally I would like to encourage other developers to breed good programmers, and to help out the community at large rather than maliciously profiting off their own "secret" technical knowledge in lieu of any ability to come up with good product concepts. Feel free to browse the source code, use it, learn from it. Page #2 In tetris.s I have attempted to teach in a certain way: To *not* teach instruction opcodes, but to teach instruction routines, or techniques. I believe that the programmer finds the opcode to suit the logic operation, not visa versa. To demonstrate the nitty-gritty of various technical aspects, without relying on black-box style magical system functions. My past experience as a novice M.L. programmer showed a personal weakness in Amiga specific technical knowledge. I believe this source code should demonstrate most technical aspects required for a complete Amiga project. Another tremendous help now is the new Amiga Techical Reference Manual. A weakness, which I see in some other programmers, is their not having a "mental-library" of approaches to any particular algorithm. I believe this is due to magazines focusing on the crudest aspects of teaching Machine Code, the opcodes themselves, versus what to do with them. Really there is no public avenue for a programmer to become truly competent at any particular system. (And I think this is a shame because I am sure that there are many potential programmers who could easily blow me away...I mean if I can learn to program - and I'm no shining example of intelligence - then anybody should be able to learn to program) I hope that you enjoy this source and that you write many wonderful games for me to play! If I get a positive reaction to this release I may write other products for the public domain...(what the hell, it pays about the same as my freelance work and its twice as fun). Other topics I may cover: A public domain replacement for QBak, covering aspects of DOS from AmigaDos to raw MFM. You can mail me at: Andy Hook c/o The Computer Shop 3515 18th St SW Calgary Alta CANADA! T2T-4T9 FAX: (403) 246-2861 (Daytime only please) Online: (403) 246-1858 24hr (Andy Hook c/o sysop), name:AMUC,pass:SIG Page #3 Notes: You will find that I do not use macros or include files. My language outputs macro-contents in an Aztek compatible stream and typically for machine code I don't really find a need for include files. I suggest the use of macros normally. Note that I have used a very formal coding style, I would recommend a less commented style for most normal programming jobs. I don't suggest using Aztek. I use Aztek by fault of the evil forces of Hydraulic Despotism [FH]. I do suggest using CED. I wrote tetris during my "spare-time" (hah) after work, I wrote the critical support routines first, once I had my mockup. Page #4 ;************************************************************************* ;************************************************************************* ;************************************************************************* ;Four - General Tips ;************************************************************************* ;************************************************************************* ;************************************************************************* Here is an example of what I consider to be good programming practices: ;---------------------------------------------------------------------------- ; ; SonyRoutine.asm © Mr. Good Code People Corp 1990 All Rights Reserved ; ; *** On a copyright notice there are no extra spaces, commas, periods ; or anything that might suggest that the copyright is not ; directly bound to the named object and the named creator. ; "All Rights Reserved" protects you; In Canada mere creation ; of a thing gives you implicit copyright, however I understand ; that you must declare your rights. Of course having rights ; depends solely on your ability to enforce them. ; You should talk to your lawyer and work through the laws in ; your state regarding copyrights. include 'publics.i' ; ; This is an example of some good coding practices ; Passed: ; D0 = A Good Coding Practice Register ; SonyRoutine move.l d0,d1 ; D1 = My First Line move.l SonyAlpha(pc,d0.w),d5 ; D5 = My Second Line lea SonyVector(pc),a0 ; A0 = Another Line move.l SonyMemory(pc),a1 ; A1 = Yet another line cmp.l #0,a0 ; you can't "tst" a0 bne.s SonyRoutine200 moveq #40-1,d1 ; Show #,then -1 for dbf count SonyRoutine100 move.l (a0)+,(a1)+ ; Lets Copy Something... dbf d1,SonyRoutine100 SonyRoutine200 rts SonyAlpha dc.l 1,2,3,4,5,6,7,8 SonyVector dc.l 0 SonyMemory dc.l 'DISK' ; end of routine.asm ;----------------------------------------------------------------------------- Page #5 ; Quick Comments on Above "Sony" Source Code ; When Labels are related, having the same header name like "Sony..." ; makes them easier to see when searching a debuggers symbol list. ; Having long form names like "Routine" versus "Rtn" makes it easier ; to remember what you are looking for, and what you are doing. ; Having comments always rigidly placed on a margin makes life much ; easier for quick scanning through code ; Use PC Relative Code, (keep code modules to less than 64 K) ; Don't put comments on the same lines as Labels ; Don't have comments more than one line long unless left justified. ; Comments don't go off the visible text editor screen to the right. ; When using fixed memory spaces, such as Amiga Hardware registers, ; index off of A6 or some other definately free register (this speeds ; up code tremendously, and reduces code size). ; Use bra.s moveq ect, unless your compiler optimizes automagically. ; Use Makefiles for MANX code, system takeover or not. ; When using MANX deal with the stupidity of 'publics' by putting ; them all in one header file. ; The first line of any code segment should be the name ; The last line of any code file should be the name ; This makes printing much easier ; Machine Code doesn't flow visually very well when not aligned, don't ; bother putting spaces at X if X is [ move.l (a0)+ X ,(a1)+ ] ; Sometimes when I have a temporary line I will space it over one ; from the left margin, versus actually tabbing it into a proper ; position, this helps me remove all debugging code later. ; Learn to type without watching what you see on the screen for ; feedback, Watching the screen slows you down to the speed of ; your editors output. (trust the audio and tactile cues...) ; Buy CED and MANX, buy ReSource, SEKA, RAW, CONVERTOR, AUDIOMASTER... ; Buy DPAINT3 (for easy animation of character graphics). ; (CED will prevent accidents like losing source due to crash while ; saving and is a phenomenal editor) ; You *must* have a hard-drive and at least 1 megabyte of memory ; to program commercially. PAGE #6 ; My only conceptual oriented suggestion: When the conceptual going ; gets tough, the tough modularize.... Any routine that becomes ; unwieldy...just make the unwieldy part into a subroutine. Remember ; what makes programmers great isn't that they can program...anybody ; can program, but programmers can INTEGRATE, using the massive ; inferential ability that all human minds have; and that computers ; (right now) don't. ; Writing Code is the easy part, with a little forethought a person ; can sit down and basically produce a stream of code, the major ; stumbling block is debugging. My suggestion is don't make bugs... ; but if you do here are some things you can do: ; ; Have a state-trace-debugger to freeze the machine (I wish). ; ; Write a fake-state-trace-debugger using 68xxx Trace Mode ; (have it interupt driven, and detect mouse to stop) ; ; Write some custom screen print routines to give you feedback ; on bugs, or even just general occurances. ; ; If you are not taking over the system, use MANX db. ; ; Some things I do: ; ; I find it's more useful for me to write buglists/things-to-do ; on small cards versus a whole sheet of paper. ; ; I use tables a lot in my code, versus mulu's or shifts. ; I write code for speed, not size; Amiga has tons of memory. ; ; On the Amiga I use $bfe001 and $dff180 a lot for debugging... ; ;ClassicalExample: ;1$ add.w #1,d0 ; move.w d0,$dff180 ; Flash Screen ; btst #6,$bfe001 ; Wait till Mouse Pressed ; bne.s 1$ ; rts ; ; I try to think as much as I can before actually attacking ; a project, this prevents design flaws. But sometimes I will ; force myself to start even if unprepared, this will catalyze ; my thought process to action and then I can sit back and think ; it through; kind of like zero-on-zero brainstorming. ; ; I try to bring my computer as close to my natural enviroment ; as possible; having a bed, bathroom, kitchen, soft huggable ; female person all within reach is very important. ; Exercise becomes important also. ; ; Keep on the edge of available tools, available software and ; latest news...Don't be afraid to read PC magazines. ; ; Learn as much as possible from other programmers around you, ; even if it is sometimes a humbling experience. ; ; If you're going to work for your first company: ; ; Make damn sure that you define to yourself and to them ; precisely what you expect out of the partnership. ; If you're not in a bargaining position you may give up ; a lot, but you should still be able to gain a lot ; (in terms of knowledge, although probably not in money). PAGE #7 ;************************************************************************* ;************************************************************************* ;Seven - Critiques ;************************************************************************* ;************************************************************************* ;************************************************************************* Shadow Of the Beast Pysgnosis of all Companies has the potential to put out the best games, they finally got their programming act together and combined with their tremendous graphics are now putting out programs that run fast enough to play and look dynamic. Yet they are still completely missing "minor" elements like consistency of topic, atmosphere, theme and playability.... And the time delays here are something else also. If they used a simple sector based DMA driven disk read they could probably get it so that you wouldn't notice the load lag. I would say that it is the best arcade style game out for the Amiga so far, in the Sword of Sodan vein. With the T-Shirt thrown in its a good buy. (PS Boot Disk #3 of S of S). Aztek MANX Assembler V4.x Terrible, really quite bad, a really secondhand effort. Incompatible, cryptic, buggy, slow, rudimentary. Annoying because it has such potential. To its benefit however it does offer a standard enviroment (ie assembling, linking, includes, and CLI compatible), even with its drawbacks, that have made it my solution to assembly language programming for the past year. Now I've just switched to genim2 and am just realizing that Aztek wasn't very good. QuarterBack Poor: Difficult to find large files that distort disk count. Does not offer compression, Does not holographically record master data to each disk thus if disk #1 goes bad entire batch is lost. Has option (which is default) to turn off error checking. However is the only backup solution available at the moment. CPR Code Probe By Lattice has got to win the award for most stupid interface. Those flickery windows have got to be some sort of acid burn test right? I suggest Aztek SDB instead, cept its incompatible with the known universe. WORDPERFECT Arg....! I'll bet that given one week on the Word Perfect Source code I could get that thing to run an order of magnitude faster just by fixing the screen i/o; replacing it with custom 1 bitplane overscanned copperlist and text routines. Still blows away most other Word Processors. PAGE #8 POPULOUS Ok graphics, nice integrated concept, where's the game? Seems a bit slow, where's the blitter? What would be really cool is if the lumpen-folk built around roads, which could only be on flat land, not just simply houses...oh well, its still an ok game. Lack of Definitive Desk Top Publishing Tools Lack of Definitive Accounting Packages Lack of Definitive Spread Sheet Packages What really bothers me about most the products, aside from Shadow of the Beast is that the Developers know about conventional programming practices, but do not understand even the simplest things about interface design. I personally dislike having to switch between mouse, keyboard, joystick within the frame of one mental operation. I also think that many of these products are compromised by trying to follow the letter of the Amiga Workbench interface designs, without thought to the original spirit; which is to make a standard interface, which is visible, fun, fast and easy to use. CPR is probably the worst example of all the above, the Aztek SDB is a beautiful piece of code, its a real credit to its developers John3 could learn a lot by looking at that simple, elegant interface. I have to really say that I can't really be so critical. The tools which most these developers have to use are pretty bad, and everybody is so busy making money that nobody stops long enough to develop or market adequate tools themselves. And Commodore itself has been less than supportive of its Developer Community...Most these Developers are working in greedy isolation; clutching their feeble routines close to heart, one protruding eye bleakly warding off possible threats. Good Stuff: Dungeon Master Sublime, completely sublime. The animation sucks, but the game is just phenomonal. The best game ever made. ReSource, DevPac, CED, CMON, - Sublime development tools. Dragons Lair II Incredible, actually playable, branch points at different places in the game completely destroy the myth of a single memorized solution. I find myself gasping as I try to out-guess the next screen. I love it. A complete contrast to SpaceAce which is basically an attempt to tear money out of the market (SpaceAce was by David Fester-ing wound). (DL II: Singes Revenge, is by Randy Linden) Matt Dillon, the guy is so prolific, that he counts as a good thing in himself. The quality and quantity of his work is stupendous, and the fact that he releases source code is the coup de grace. (Actually there are many people who I unabashedly admire, such as Stephen Vermulen, Fred Fish, Chris Draco Grey, Randy Linden...) PAGE #9 ;************************************************************************* ;************************************************************************* ;*****************,******************************************************* ;Eight - Communiques ;************************************************************************* ;************************************************************************* ;************************************************************************* Please don't send me software that I do not have legal permission to use without pre-purchase. The Source Code in Tetris is entirely my own work. I am no longer owned by a corporate think-tank, and none of the work here compromises any technologies that they own. You are free to disseminate Tetris as widely as possible. I have no malicious intent against any of the many previous companys I have worked for. My attitude is that I can simply outperform any individual or corporate group that has decided to (for example) not pay me, or not meet contract demands. Honor is very important to me in an industry where so many people seem dishonorable. I am not responsible for any problems you have with Tetris, Tetris is entirely a public domain work, and as such I am not liable for any bugs Tetris has or deaths that Tetris may cause in your family. If you find any bugs in Tetris please fix them and send me a copy. If you have the impetuous please add a dancing lego-man to tetris. I'm always looking for people to work for me, or people for whom I could work. If you're interested or interesting, or you just have some questions feel free to send me a message. I have all kinds of interesting projects and subroutines. Unlike othe people (whom we won't mention here) I'm always willing to discuss my ideas on programming strategies, politics, and money. (Of course I can't discuss areas related to current contract work). I have a group of people I am now working with, we are a loose collective of programmers, with experience and contacts in the industry, and I am always willing to put you in touch with the company or group best suited to releasing your products. I might even be willing to help you write a project, for free if its a purely technical issue where I can just code your solution. If anything I think I can suggest abstract approaches for general program design, which I consider to be my forte (You must sign a non-disclosure with me however, before discussing any of your ideas; this protects you). I also love to get demos and utilities! One of the projects which I've wanted to do for about 3 years now is a vector-tilemap game, more commonly known as vectorballs. A kind of 3D Emerald Mines. I played around with the math in Vortex a bit (see the very first title page for example) and I think I could produce an entire game around the concept. So I'm always happy to get demos which demonstrate particular approaches like that. My favorites are the RED-SECTOR vectorballs demo and I also like the PARANOIMIA vector- ball-text demo (although I think PARANOMIA/QUARTEX are losers for selling cracked games). If you have any demos, utilities or source code to exchange with me you can mail me at this address: Andy Hook c/o The Computer Shop 3515 18th St Sw Calgary, Alta, CANADA!!!! T2T-4T9 Yours Truly Anselm Hook P.S. Although LLaama soft may recomend Godel Esher Bach I would suggest Metamagical Themas Jeff! Appendum Feb 18 1990: I tried to fix 2 bugs, 1) With a 68030, Kick 1.3, Custom Font the tetris text is reported to be bad. 2) Workbench support.