heuser.marcus@freenet.de wrote:
On Aug 22, 8:38 am, "Michael J. Mahon" <mjma...@aol.com> wrote:heuser.mar...@freenet.de wrote: Fleshing out a design "on paper" is an excellent way of building several generations of "virtual prototypes" so that less effort is wasted going down major detailed blind alleys.I once did several versions of a tile-mapping routine (like those found in the earlier Ultima games) because I was curious if I can do it with acceptable speed in hires graphics mode which of course uses much more memory than the charcter graphics modes of the Atari and C64 platforms. It was a terrific experience as I only used graph paper (with 5 mm squares), a pencil, a 6502 mnemonics and cycle table and my trusty 25 year old calculator - while lying on my bed (I call it "testbed" since then and I don't make this up now!). Granted, I took my time with it and the cycle count didn't always come down but in the end, when I was satisfied with the speed/space ratio (version 7, IIRC), I hacked it in and it worked from the get-go. It really was a mixture of exercise and experiment and in the end it provided me with some 6502 training and showed me that it is very well possible to think a problem through, choose a good algorithm, implement it, debug it, improve it and have something working in the end. Immensely gratifying.The trick for me is sustaining enthusiasm for a long time without actually coding anything. I find that putting pencil to paper is both focusing and stimulating, but I'm sure folks differ in that respect. (My real wastebasket does tend to fill up with paper. ;-)I hear you!
This, in my opinion, is the most overlooked design process. I have a bunch of notebooks (engineering computational pads) that have a bright grid on the back side, and the front side has the faint image of the back side showing through. Jim Blinn once wrote a great article on the benefits of pencil and paper design - I think it is still available in his book "A Trip Down the Graphics Pipeline". One of those must-have books. Unlike Michael, I never throw stuff in the wastebasket. I leave the ideas that don't work out in my notebook. Either I will eventually find a purpose for the idea, or it will help remind me why it didn't work in the first place so I don't try it again!
Everyone talks about bottom-up and top-down design. I find that you can't really do one without the other. I have a system design in my head (or paper) and start coding the foundation. Based on the top-level ideas, I decide which are the most crucial low-level routines and write them with a lot of test cases. Making the low-level routines simple and robust ensures I won't be wasting valuable high-level programming time debugging the basic routines. Kind of like Legos, only I get to create the bricks, too. This also allows me to do coding while fleshing out the overall design. Sometimes the low-level routines will influence the high-level design.
I also find low-level code just as challenging as higher level routines. A really efficient memory manager or fast floating point divide routine can be projects in themselves. So create some mini-projects out of your big project to keep enthusiasm up and progress moving.
bye Marcus
And don't worry about expectations. This is a project for you, not anyone else. Even if it doesn't come to fruition, the ideas and discussions have value in themselves.
Dave...