Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!uwm.edu!rutgers!njin!limonce From: limonce@pilot.njin.net (Tom Limoncelli +1 201 408 5389) Newsgroups: comp.sys.amiga.programmer Subject: Re: Lemmings - a tutorial Part V (last) Message-ID: Date: 31 Mar 91 03:51:20 GMT References: <23788@well.sf.ca.us> <23837@well.sf.ca.us> <781@tnc.UUCP> Organization: Drew University - Madison NJ Lines: 74 In article mykes@amiga0.SF-Bay.ORG (Mike Schwartz) writes: > the KERNEL. The first thing the Kernel does is to copy itself down to low > memory ($200). [...] > Well, I am guaranteed that ALL 512K are mine to use. I can ORG any > graphics, code, or audio data at any hard coded location I want. This > practice allows things like blitter routines to have hard coded constant > addresses in them, which saves CPU cycles where you need them the most. This means that your code and data is always going to be in CHIP ram which is a killer for most graphics modes and for most accellerators. "saves CPU cycles where you need them the most". A bubble sort written in assembler has the same O() as a bubble sort in C. You get 2 extra registers and CHIP ram holds you back. Strange trade-off. (Yes, I know you claim to use FAST ram for any disk caches, but I'm sure you don't access that durring game-play.) --------------- Everything you program can be done (in C or Assembler) and only kill the OS if you are really low on memory. In that case, you can ask the user if this is OK. The only problem is that you have to *learn* something about AmigaDOS and work towards getting your code to exit properly. This is not easy, but can be done. Why don't you do this? Others call you lazy. It's not lazy to write an entire pseudo-KERNEL as well as trackdisk; but I bet that time could have been spent learning the OS. Your two big gripes are control over the blitter, the drives, and the CPU. You can OwnBlitter(), allocate the drives, and shut off Exec in approved ways. Best yet, when you are done you can un-own those resources (assuming that you didn't kill the OS due to a lack of memory) and the user can continue. Advantages: If you can re-enable Exec, etc. when the user wants to pause, you can also re-enable all that stuff when loading in stuff from the HD (if you make that an option), printing (I'd love to be able to do THAT for some games!), etc. I doubt you do any disk/harddrive access durring the game. My HD is faster than *any* trackdisk routines you write. Why not give the option of (1) your "fast" (faster than 1.3 trackdisk) trackdisk routines, (2) the native trackdisk routines (2.0 is *fast*), or (3) proper system calls for HD support. 2 & 3 require a return to multitasking. If you can re-enable Exec, etc. and deallocate the memory you don't need (reload it later) the user might be able to be productive AND use your game. Gosh. This argument is pretty fruitless. You seem to go on the European marketing statistics that you quote. I'd love to know the source of those statistics so that I could research them. Quoting statistics without giving a source that I can research means that you could be quoting from a Matt Groening or Dave Barry book for all I know. As soon as your statistical sample (European kids) starts getting '030s and HDs I'm sure that you'll produce software that I feel like buying. Too bad it takes so long for Europeans to come up to American standards. I guess we follow them in fashion and they follow us in... oh never mind. Everytime I meet someone looking to trash their 500 and buy an A3000 they say, "but I don't want to because all my games won't work". Mike et al seem to have made a captive audience. Mike won't change until the users do, if Mike had never started the users could upgrade. -Tom P.S. When someone is considering upgrading, I ask them to try to find the games that they think won't work on an A3000 running 2.0. Then I try to get them to notice that if they haven't used those in the last 6 months, they most-likely won't miss them.