home *** CD-ROM | disk | FTP | other *** search
/ Club Amiga de Montreal - CAM / CAM_CD_1.iso / files / 366.lha / Tetris / tetris.docs < prev    next >
Text File  |  1990-04-10  |  21KB  |  610 lines
  1.                                 Page #1
  2. OutLine of Documentation
  3.  
  4.     1-3... This document has 3 pages relating to tetris
  5.     4-6... Section on general programming tips
  6.     7-8... Section critizing poor programming efforts on Amiga
  7.     9  ... Greetings + Mailing Address
  8.  
  9. ;*************************************************************************
  10. ;*************************************************************************
  11. ;*************************************************************************
  12. One - tetris
  13. ;*************************************************************************
  14. ;*************************************************************************
  15. ;*************************************************************************
  16.  
  17.     Welcome to Amiga Tetris.s by Andy Hook
  18.  
  19.     These are some of the thoughts behind my release of this source code:
  20.  
  21.         I've been programming for a while now, and in looking back,
  22.         I wish that I'd known, when I first started programming,
  23.         the tricks and shortcuts that I know and use now.
  24.  
  25.         I guess learning may be a kind of snowball effect, and a
  26.         good push seems to sometimes get the ball rolling that much
  27.         faster.
  28.  
  29.         Tetris itself, I think tetris is a good example of
  30.         addictive game design.  The game operates under a rule
  31.         based system allowing you to anticipate the effects of
  32.         any action - before you make it... your own successes or
  33.         failures accumulate to spell your final outcome...the
  34.         game is crisp, bright.  The components of the graphics,
  35.         sound and rules all stand out in bright contrast within
  36.         themselves, not mushy and vague like most games.  The rules
  37.         in particular are meaningful within the scope of the game,
  38.         not capricious and arbitrary.
  39.  
  40.         In regards to releasing "Tetris" to the public domain:
  41.         I don't try to hide the fact that this is a clone of
  42.         the arcade "Tetris".  I don't call it obsession, or
  43.         "steishinflagellate", or "tetrix" and sell it as shareware
  44.         and attempt to immorally make a profit off of somebody
  45.         elses genius.  My understanding of the legality of this
  46.         public domain release is that I can use any copyrighted
  47.         name,logo or music as long as its not for profit.  The
  48.         legality of it becomes a bit murky when somebody like
  49.         Fred Fish charges a duplication fee for it...but I
  50.         have disseminated the source widely and far, thus I think
  51.         that would protects Mr. Fish if he added this to his
  52.         collection.
  53.  
  54.         (Additionally I think all those other versions of
  55.          tetris are somewhat poor and their not releasing the
  56.          source code further diminishes the value of their product...
  57.          )
  58.  
  59.         Additionally I would like to encourage other developers
  60.         to breed good programmers, and to help out the community
  61.         at large rather than maliciously profiting off their own
  62.         "secret" technical knowledge in lieu of any ability to
  63.         come up with good product concepts.
  64.  
  65.     Feel free to browse the source code, use it, learn from it.
  66.  
  67.                                 Page #2
  68.     In tetris.s I have attempted to teach in a certain way:
  69.  
  70.         To *not* teach instruction opcodes, but to teach instruction
  71.         routines, or techniques.  I believe that the programmer finds
  72.         the opcode to suit the logic operation, not visa versa.
  73.  
  74.         To demonstrate the nitty-gritty of various technical aspects,
  75.         without relying on black-box style magical system functions.
  76.  
  77.     My past experience as a novice M.L. programmer showed a personal
  78.     weakness in Amiga specific technical knowledge.  I believe this
  79.     source code should demonstrate most technical aspects required for
  80.     a complete Amiga project.  Another tremendous help now is the
  81.     new Amiga Techical Reference Manual.
  82.  
  83.     A weakness, which I see in some other programmers, is their not
  84.     having a "mental-library" of approaches to any particular
  85.     algorithm.
  86.  
  87.     I believe this is due to magazines focusing on the crudest aspects
  88.     of teaching Machine Code, the opcodes themselves, versus what to do
  89.     with them.  Really there is no public avenue for a programmer to
  90.     become truly competent at any particular system.
  91.     (And I think this is a shame because I am sure that there are many
  92.      potential programmers who could easily blow me away...I mean if I
  93.     can learn to program - and I'm no shining example of intelligence -
  94.     then anybody should be able to learn to program)
  95.  
  96.     I hope that you enjoy this source and that you write many wonderful
  97.     games for me to play!
  98.  
  99.     If I get a positive reaction to this release I may write other
  100.     products for the public domain...(what the hell, it pays about the
  101.     same as my freelance work and its twice as fun).
  102.  
  103.     Other topics I may cover: A public domain replacement for QBak,
  104.     covering aspects of DOS from AmigaDos to raw MFM.
  105.  
  106.     You can mail me at:
  107.         Andy Hook
  108.         c/o The Computer Shop
  109.         3515 18th St SW Calgary Alta CANADA!
  110.         T2T-4T9
  111.  
  112.     FAX:    (403) 246-2861    (Daytime only please)
  113.     Online:    (403) 246-1858    24hr (Andy Hook c/o sysop), name:AMUC,pass:SIG
  114.  
  115.  
  116.  
  117.  
  118.  
  119.  
  120.  
  121.  
  122.  
  123.  
  124.  
  125.  
  126.  
  127.  
  128.  
  129.  
  130.  
  131.  
  132.  
  133.                                 Page #3
  134.     Notes:
  135.  
  136.     You will find that I do not use macros or include files.   My
  137.     language outputs macro-contents in an Aztek compatible stream
  138.     and typically for machine code I don't really find a need for
  139.     include files.  I suggest the use of macros normally.
  140.  
  141.     Note that I have used a very formal coding style, I would recommend
  142.     a less commented style for most normal programming jobs.
  143.  
  144.     I don't suggest using Aztek.
  145.     I use Aztek by fault of the evil forces of Hydraulic Despotism [FH].
  146.  
  147.     I do suggest using CED.
  148.  
  149.     I wrote tetris during my "spare-time" (hah) after work, I wrote the
  150.     critical support routines first, once I had my mockup.
  151.  
  152.  
  153.  
  154.  
  155.  
  156.  
  157.  
  158.  
  159.  
  160.  
  161.  
  162.  
  163.  
  164.  
  165.  
  166.  
  167.  
  168.  
  169.  
  170.  
  171.  
  172.  
  173.  
  174.  
  175.  
  176.  
  177.  
  178.  
  179.  
  180.  
  181.  
  182.  
  183.  
  184.  
  185.  
  186.  
  187.  
  188.  
  189.  
  190.  
  191.  
  192.  
  193.  
  194.  
  195.  
  196.  
  197.  
  198.  
  199.                                 Page #4
  200. ;*************************************************************************
  201. ;*************************************************************************
  202. ;*************************************************************************
  203. ;Four - General Tips
  204. ;*************************************************************************
  205. ;*************************************************************************
  206. ;*************************************************************************
  207.  
  208.     Here is an example of what I consider to be good programming
  209.     practices:
  210.  
  211. ;----------------------------------------------------------------------------
  212. ;
  213. ;    SonyRoutine.asm © Mr. Good Code People Corp 1990 All Rights Reserved
  214. ;
  215. ;    *** On a copyright notice there are no extra spaces, commas, periods
  216. ;        or anything that might suggest that the copyright is not
  217. ;        directly bound to the named object and the named creator.
  218. ;        "All Rights Reserved" protects you;  In Canada mere creation
  219. ;        of a thing gives you implicit copyright, however I understand
  220. ;        that you must declare your rights.  Of course having rights
  221. ;        depends solely on your ability to enforce them.
  222.  
  223. ;        You should talk to your lawyer and work through the laws in
  224. ;        your state regarding copyrights.
  225.  
  226.  
  227.     include 'publics.i'
  228.  
  229. ;
  230. ;    This is an example of some good coding practices
  231. ;    Passed:
  232. ;        D0 = A Good Coding Practice Register
  233. ;
  234. SonyRoutine
  235.         move.l    d0,d1            ; D1 = My First Line
  236.         move.l    SonyAlpha(pc,d0.w),d5    ; D5 = My Second Line
  237.         lea    SonyVector(pc),a0    ; A0 = Another Line
  238.         move.l    SonyMemory(pc),a1    ; A1 = Yet another line
  239.         cmp.l    #0,a0            ; you can't "tst" a0
  240.         bne.s    SonyRoutine200
  241.         moveq    #40-1,d1        ; Show #,then -1 for dbf count
  242. SonyRoutine100
  243.         move.l    (a0)+,(a1)+        ; Lets Copy Something...
  244.         dbf    d1,SonyRoutine100
  245. SonyRoutine200
  246.         rts
  247.  
  248. SonyAlpha    dc.l    1,2,3,4,5,6,7,8
  249. SonyVector    dc.l    0
  250. SonyMemory    dc.l    'DISK'
  251.  
  252. ; end of routine.asm
  253. ;-----------------------------------------------------------------------------
  254.  
  255.  
  256.  
  257.  
  258.  
  259.  
  260.  
  261.  
  262.  
  263.  
  264.  
  265.                                 Page #5
  266. ; Quick Comments on Above "Sony" Source Code
  267.  
  268. ;    When Labels are related, having the same header name like "Sony..."
  269. ;    makes them easier to see when searching a debuggers symbol list.
  270.  
  271. ;    Having long form names like "Routine" versus "Rtn" makes it easier
  272. ;    to remember what you are looking for, and what you are doing.
  273.  
  274. ;    Having comments always rigidly placed on a margin makes life much
  275. ;    easier for quick scanning through code
  276.  
  277. ;    Use PC Relative Code, (keep code modules to less than 64 K)
  278.  
  279. ;    Don't put comments on the same lines as Labels
  280.  
  281. ;    Don't have comments more than one line long unless left justified.
  282. ;    Comments don't go off the visible text editor screen to the right.
  283.  
  284. ;    When using fixed memory spaces, such as Amiga Hardware registers,
  285. ;    index off of A6 or some other definately free register (this speeds
  286. ;    up code tremendously, and reduces code size).
  287.  
  288. ;    Use bra.s moveq ect, unless your compiler optimizes automagically.
  289.  
  290. ;    Use Makefiles for MANX code, system takeover or not.
  291.  
  292. ;    When using MANX deal with the stupidity of 'publics' by putting
  293. ;    them all in one header file.
  294.  
  295. ;    The first line of any code segment should be the name
  296. ;    The last line of any code file should be the name
  297. ;    This makes printing much easier
  298.  
  299. ;    Machine Code doesn't flow visually very well when not aligned, don't
  300. ;    bother putting spaces at X if X is [ move.l (a0)+ X ,(a1)+ ]
  301. ;    Sometimes when I have a temporary line I will space it over one
  302. ;    from the left margin, versus actually tabbing it into a proper
  303. ;    position, this helps me remove all debugging code later.
  304.  
  305. ;    Learn to type without watching what you see on the screen for
  306. ;    feedback, Watching the screen slows you down to the speed of
  307. ;    your editors output.  (trust the audio and tactile cues...)
  308.  
  309. ;    Buy CED and MANX, buy ReSource, SEKA, RAW, CONVERTOR, AUDIOMASTER...
  310. ;    Buy DPAINT3 (for easy animation of character graphics).
  311.  
  312. ;    (CED will prevent accidents like losing source due to crash while
  313. ;    saving and is a phenomenal editor)
  314.  
  315. ;    You *must* have a hard-drive and at least 1 megabyte of memory
  316. ;    to program commercially.
  317.  
  318.  
  319.  
  320.  
  321.  
  322.  
  323.  
  324.  
  325.  
  326.  
  327.  
  328.  
  329.  
  330.  
  331.                                 PAGE #6
  332. ;    My only conceptual oriented suggestion:  When the conceptual going
  333. ;    gets tough, the tough modularize....  Any routine that becomes
  334. ;    unwieldy...just make the unwieldy part into a subroutine.  Remember
  335. ;    what makes programmers great isn't that they can program...anybody
  336. ;    can program, but programmers can INTEGRATE, using the massive
  337. ;    inferential ability that all human minds have; and that computers
  338. ;    (right now) don't.
  339.  
  340. ;    Writing Code is the easy part, with a little forethought a person
  341. ;    can sit down and basically produce a stream of code, the major
  342. ;    stumbling block is debugging.  My suggestion is don't make bugs...
  343. ;    but if you do here are some things you can do:
  344. ;
  345. ;        Have a state-trace-debugger to freeze the machine (I wish).
  346. ;
  347. ;        Write a fake-state-trace-debugger using 68xxx Trace Mode
  348. ;        (have it interupt driven, and detect mouse to stop)
  349. ;
  350. ;        Write some custom screen print routines to give you feedback
  351. ;        on bugs, or even just general occurances.
  352. ;
  353. ;        If you are not taking over the system, use MANX db.
  354. ;
  355.  
  356. ;    Some things I do:
  357. ;
  358. ;        I find it's more useful for me to write buglists/things-to-do
  359. ;        on small cards versus a whole sheet of paper.
  360. ;
  361. ;        I use tables a lot in my code, versus mulu's or shifts.
  362. ;        I write code for speed, not size; Amiga has tons of memory.
  363. ;
  364. ;        On the Amiga I use $bfe001 and $dff180 a lot for debugging...
  365. ;
  366. ;ClassicalExample:
  367. ;1$        add.w    #1,d0
  368. ;        move.w    d0,$dff180        ; Flash Screen
  369. ;        btst    #6,$bfe001        ; Wait till Mouse Pressed
  370. ;        bne.s    1$
  371. ;        rts
  372. ;
  373. ;        I try to think as much as I can before actually attacking
  374. ;        a project, this prevents design flaws.  But sometimes I will
  375. ;        force myself to start even if unprepared, this will catalyze
  376. ;        my thought process to action and then I can sit back and think
  377. ;        it through; kind of like zero-on-zero brainstorming.
  378. ;
  379. ;        I try to bring my computer as close to my natural enviroment
  380. ;        as possible; having a bed, bathroom, kitchen, soft huggable
  381. ;        female person all within reach is very important.
  382. ;        Exercise becomes important also.
  383. ;
  384. ;        Keep on the edge of available tools, available software and
  385. ;        latest news...Don't be afraid to read PC magazines.
  386. ;
  387. ;        Learn as much as possible from other programmers around you,
  388. ;        even if it is sometimes a humbling experience.
  389. ;
  390. ;    If you're going to work for your first company:
  391. ;
  392. ;        Make damn sure that you define to yourself and to them
  393. ;        precisely what you expect out of the partnership.
  394. ;        If you're not in a bargaining position you may give up
  395. ;        a lot, but you should still be able to gain a lot
  396. ;        (in terms of knowledge, although probably not in money).
  397.                                 PAGE #7
  398. ;*************************************************************************
  399. ;*************************************************************************
  400. ;Seven - Critiques
  401. ;*************************************************************************
  402. ;*************************************************************************
  403. ;*************************************************************************
  404.  
  405.     Shadow Of the Beast
  406.         Pysgnosis of all Companies has the potential to put out the
  407.         best games, they finally got their programming act together
  408.         and combined with their tremendous graphics are now putting
  409.         out programs that run fast enough to play and look dynamic.
  410.         Yet they are still completely missing "minor" elements like
  411.         consistency of topic, atmosphere, theme and playability....
  412.         And the time delays here are something else also.  If they
  413.         used a simple sector based DMA driven disk read they could
  414.         probably get it so that you wouldn't notice the load lag.
  415.         I would say that it is the best arcade style game out for
  416.         the Amiga so far, in the Sword of Sodan vein.  With the
  417.         T-Shirt thrown in its a good buy. (PS Boot Disk #3 of S of S).
  418.  
  419.     Aztek MANX Assembler V4.x
  420.         Terrible, really quite bad, a really secondhand effort.
  421.         Incompatible, cryptic, buggy, slow, rudimentary.
  422.         Annoying because it has such potential.  To its benefit 
  423.         however it does offer a standard enviroment (ie assembling,
  424.         linking, includes, and CLI compatible), even with its
  425.         drawbacks, that have made it my solution to assembly language
  426.         programming for the past year.  Now I've just switched to
  427.         genim2 and am just realizing that Aztek wasn't very good.
  428.  
  429.     QuarterBack
  430.         Poor:  Difficult to find large
  431.         files that distort disk count.  Does not offer compression,
  432.         Does not holographically record master data to each disk
  433.         thus if disk #1 goes bad entire batch is lost.  Has option
  434.         (which is default) to turn off error checking.
  435.         However is the only backup solution available at the moment.
  436.  
  437.     CPR
  438.         Code Probe By Lattice has got to win the award for most
  439.         stupid interface.  Those flickery windows have got to be some
  440.         sort of acid burn test right?
  441.         I suggest Aztek SDB instead, cept its incompatible with the
  442.         known universe.
  443.  
  444.     WORDPERFECT
  445.         Arg....!
  446.         I'll bet that given one week on the Word Perfect Source
  447.         code I could get that thing to run an order of magnitude
  448.         faster just by fixing the screen i/o; replacing it with
  449.         custom 1 bitplane overscanned copperlist and text routines.
  450.         Still blows away most other Word Processors.
  451.  
  452.  
  453.  
  454.  
  455.  
  456.  
  457.  
  458.  
  459.  
  460.  
  461.  
  462.  
  463.                                 PAGE #8
  464.     POPULOUS
  465.         Ok graphics, nice integrated concept, where's the game?
  466.         Seems a bit slow, where's the blitter?
  467.         What would be really cool is if the lumpen-folk built
  468.         around roads, which could only be on flat land, not just
  469.         simply houses...oh well, its still an ok game.
  470.  
  471.     Lack of Definitive Desk Top Publishing Tools
  472.     Lack of Definitive Accounting Packages
  473.     Lack of Definitive Spread Sheet Packages
  474.  
  475.     What really bothers me about most the products, aside from
  476.     Shadow of the Beast is that the Developers know about conventional
  477.     programming practices, but do not understand even the simplest
  478.     things about interface design.  I personally dislike having to
  479.     switch between mouse, keyboard, joystick within the frame of
  480.     one mental operation.
  481.  
  482.     I also think that many of these products are compromised by trying
  483.     to follow the letter of the Amiga Workbench interface designs,
  484.     without thought to the original spirit; which is to make a
  485.     standard interface, which is visible, fun, fast and easy to use.
  486.  
  487.     CPR is probably the worst example of all the above, the Aztek
  488.     SDB is a beautiful piece of code, its a real credit to its developers
  489.     John3 could learn a lot by looking at that simple, elegant interface.
  490.  
  491.     I have to really say that I can't really be so critical.  The
  492.     tools which most these developers have to use are pretty bad, and
  493.     everybody is so busy making money that nobody stops long enough
  494.     to develop or market adequate tools themselves.
  495.  
  496.     And Commodore itself has been less than supportive of its
  497.     Developer Community...Most these Developers are working in greedy
  498.     isolation; clutching their feeble routines close to heart, one
  499.     protruding eye bleakly warding off possible threats.
  500.  
  501. Good Stuff:
  502.  
  503.     Dungeon Master
  504.         Sublime, completely sublime.  The animation sucks, but the
  505.         game is just phenomonal.  The best game ever made.
  506.  
  507.     ReSource, DevPac, CED, CMON,  - Sublime development tools.
  508.  
  509.     Dragons Lair II
  510.         Incredible, actually playable, branch points at different
  511.         places in the game completely destroy the myth of a single
  512.         memorized solution.  I find myself gasping as I try to
  513.         out-guess the next screen.  I love it. A complete contrast to 
  514.         SpaceAce which is basically an attempt to tear money out
  515.         of the market (SpaceAce was by David Fester-ing wound).
  516.         (DL II: Singes Revenge, is by Randy Linden)
  517.  
  518.     Matt Dillon, the guy is so prolific, that he counts as a good thing
  519.         in himself.  The quality and quantity of his work is
  520.         stupendous, and the fact that he releases source code is
  521.         the coup de grace.
  522.  
  523.     (Actually there are many people who I unabashedly admire, such as
  524.      Stephen Vermulen, Fred Fish, Chris Draco Grey, Randy Linden...)
  525.  
  526.  
  527.  
  528.  
  529.                                 PAGE #9
  530. ;*************************************************************************
  531. ;*************************************************************************
  532. ;*****************,*******************************************************
  533. ;Eight - Communiques
  534. ;*************************************************************************
  535. ;*************************************************************************
  536. ;*************************************************************************
  537.  
  538.     Please don't send me software that I do not have legal permission
  539.     to use without pre-purchase.
  540.  
  541.     The Source Code in Tetris is entirely my own work.  I am no longer
  542.     owned by a corporate think-tank, and none of the work here compromises
  543.     any technologies that they own.  You are free to disseminate Tetris
  544.     as widely as possible.  I have no malicious intent against any of
  545.     the many previous companys I have worked for.  My attitude is that
  546.     I can simply outperform any individual or corporate group that has
  547.     decided to (for example) not pay me, or not meet contract demands.
  548.     Honor is very important to me in an industry where so many people
  549.     seem dishonorable.
  550.  
  551.     I am not responsible for any problems you have with Tetris, Tetris
  552.     is entirely a public domain work, and as such I am not liable for
  553.     any bugs Tetris has or deaths that Tetris may cause in your family.
  554.  
  555.     If you find any bugs in Tetris please fix them and send me a copy.
  556.     If you have the impetuous please add a dancing lego-man to tetris.
  557.  
  558.     I'm always looking for people to work for me, or people for whom I
  559.     could work.  If you're interested or interesting, or you just have
  560.     some questions feel free to send me a message.
  561.  
  562.     I have all kinds of interesting projects and subroutines.
  563.  
  564.     Unlike othe people (whom we won't mention here) I'm always willing to
  565.     discuss my ideas on programming strategies, politics, and money.
  566.     (Of course I can't discuss areas related to current contract work).
  567.  
  568.     I have a group of people I am now working with, we are a loose
  569.     collective of programmers, with experience and contacts in the
  570.     industry, and I am always willing to put you in touch with the
  571.     company or group best suited to releasing your products.  I might
  572.     even be willing to help you write a project, for free if its
  573.     a purely technical issue where I can just code your solution.
  574.  
  575.     If anything I think I can suggest abstract approaches for general
  576.     program design, which I consider to be my forte (You must sign
  577.     a non-disclosure with me however, before discussing any of your
  578.     ideas; this protects you).
  579.  
  580.     I also love to get demos and utilities!  One of the projects which
  581.     I've wanted to do for about 3 years now is a vector-tilemap game,
  582.     more commonly known as vectorballs.   A kind of 3D Emerald Mines.
  583.     I played around with the math in Vortex a bit (see the very first
  584.     title page for example) and I think I could produce an entire game
  585.     around the concept.  So I'm always happy to get demos which
  586.     demonstrate particular approaches like that.  My favorites are the
  587.     RED-SECTOR vectorballs demo and I also like the PARANOIMIA vector-
  588.     ball-text demo (although I think PARANOMIA/QUARTEX are losers for
  589.     selling cracked games).
  590.  
  591.     If you have any demos, utilities or source code to exchange with
  592.     me you can mail me at this address:
  593.             Andy Hook
  594.             c/o The Computer Shop
  595.             3515 18th St Sw
  596.             Calgary, Alta, CANADA!!!!
  597.             T2T-4T9
  598.  
  599.                         Yours Truly
  600.                         Anselm Hook
  601.  
  602.     P.S. Although LLaama soft may recomend Godel Esher Bach I would suggest
  603.     Metamagical Themas Jeff!
  604.  
  605.     Appendum Feb 18 1990:
  606.  
  607.     I tried to fix 2 bugs, 1) With a 68030, Kick 1.3, Custom Font the
  608.     tetris text is reported to be bad.  2) Workbench support.
  609.  
  610.