Subject: RE: [stella] Reflex: Source of PAIN! From: "Lee Fastenau" <stella@xxxxxxxxxxxxxxx> Date: Mon, 5 Apr 2004 12:02:23 -0500 |
Andrew, Thank you for taking the time to pour over the source code. Truth is, I had been itching to make this code more modular since I began this project, and it means a lot to me that a veteran such as yourself thinks it's a worthy reference for beginners. > It is very clear and well written, and an excellent example of how to code > things properly. Intuitive use of subroutines, logical grouping of > functions and clear and easy to understand code. This is an > excellent piece > of code for use as a "how to". It is also tackling a game > concept which is > interesting, yet not too difficult as to be too tricky as a first project. > So, i admire the style - not to mention the speed of development. Some of > that is due to the style, of course. The change in coding style is relatively new. I tore the program down and put it back together as subroutines that revolve around a series of game "states." It gives me much more flexibility as a programmer. > Looks to me like you're a Delphi/Pascal programmer, judging by your > first-letter lowercase, following words capitalised first letter format :) Actually, that's our standard casing for JavaScript and VBScript where I work. But I do have a Pascal background. It was my first compiled language. > I'd say comments are a tad sparse -- especially for > beginners. Maintaining comments in a block of code as I'm working on it can get tedious. I will dedicate some time each week to add/update comments. > The use of the standardised macros (eg: CLEAN_START) is pleasing. Why reinvent the wheel? :) > The use > of 'subroutine' to identify subroutines -- totally not necessary, but > extremely good style because it aids readability. The use of local labels > within subroutines -- again, not necessary, but does prevent unexpected > branches to inside routines, and clarifies the scope of labels/loops. I even have subroutines with labels that aren't referenced anywhere else, but they do help tremendously with keeping track of everything. Local labels are great and I think the way DASM implements them is very intuitive. Merlin for the Apple II, by contrast, implements local labels in a rather unintuitive and confusing manner. > The > variable declarations are of a style I don't myself like (byte, > word) -- but > that's just a style issue. Overall, it's clear that you're a particularly > cautious programmer. There are a few different ways to declare variable space, so I picked what I thought was the cleanest. I just hope it's not too difficult for people to port it to other assemblers. > However (and there's always a however!), it is not always going to be > possible to code this way. I wouldn't like people to think that > this style > of coding is the norm and all the other programs are poorly written. When > you are pushing the very limits of your ROM size, and you need to fix one > more bug, and you have 10 bytes left and you NEED 20, you find yourself > sacrificing clarity, readability and sanity to get those extra bytes. > Suddenly your structure goes to pieces and you start to realise the real > value in sphagetti code.... destroy the structure and run the threads of > execution in a knotted mess to save a byte? sure, go for it! I completely agree, and stated almost the same in a previous reply to Kirk. This breakout concept has allowed me to code with a more traditional (high-level) programming structure. I mean, even the game section of the display kernel is a single, simple module. I don't think I could have picked a better project to begin with. It's allowing me to code in a familiar way, doesn't require too many TIA tricks, and (above all) it's appealing to gamers! > Sometimes, even 2 levels of subroutines are just too expensive. > Sometimes, > the extra 12 cycles required for a subroutine call/return are out of the > question. Now that you are very close to mastering the > fundamental "how to" > program the '2600 (and, again, great job!) -- it will be interesting > watching you 'push the envelope' which is, of course, your next challenge. It's been a blast so far, and I can never spend enough time coding. It may not be the tightest or most elegant way to build a game for the Atari 2600, but it's certainly been educational. I'm already thinking about ideas for a followup project. I'm not going to say I want a "greater" challenge because I think each and every program has its own unique challenges. I just hope to make another game that's fun to build and play! > Overally, I don't have anything to criticise in this effort. > You've clearly > studied other people's code and suggestions, and the stella posts > carefully. This list and everyone that participates in it ... words can't describe. This has been some of the best programming collaboration I've ever experienced. > Well done! Thank you! > PS: I would love to see this program's source code included on > the AtariAge > "2600 Programming for Newbies" forum as an example of clear and > understandable source code for beginners to learn from, or even on the > companion CD to my "Programming the '2600" book. I'll followup on this. :) Again, thanks! -Lee PS: Yeah, I thought about the uppercase constants ... maybe the next project. :) ---------------------------------------------------------------------------------------------- Archives (includes files) at http://www.biglist.com/lists/stella/archives/ Unsub & more at http://www.biglist.com/lists/stella/
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [stella] Reflex: Source of PAIN, Andrew Davie | Thread | [stella] DASM, Andrew Davie |
Re: [stella] Reflex: Source of PAIN, KirkIsrael | Date | Re: [stella] INV+ yet again - inv40, Thomas Jentzsch |
Month |