Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!elroy.jpl.nasa.gov!ames!vsi1!zorch!amiga0!mykes From: mykes@amiga0.SF-Bay.ORG (Mike Schwartz) Newsgroups: comp.sys.amiga.programmer Subject: Re: Lemmings - a tutorial Part V (last) Message-ID: Date: 31 Mar 91 10:50:39 GMT References: <781@tnc.UUCP> <1991Mar31.003933.1483@mintaka.lcs.mit.edu> Organization: Amiga makes it possible Lines: 392 In article <1991Mar31.003933.1483@mintaka.lcs.mit.edu> rjc@geech.gnu.ai.mit.edu (Ray Cromwell) writes: > > Hmm. TIme to open my mouth again. > > Poof! You just passed the point of no return. Couldn't you spare an >extra 1k of code to test for people with an extra 512k of ram? If on a > >512k machine, then save the state of the OS. It doesn't much matter >about returning to the OS, since your game REQUIRES a reboot to load. > Tell me Mike, have you ever programmed a game other than a action >game? I find that todays game designs just plain suck. I'd still play >Tetris, Donkey Kong, Pac-Man over shadow of the beast. I'm willing to bet >that your game would be boring except for the ohh-ahh of pretty >graphics. Games like Bards Tale, Ultima, Pool of Radiance, and Neuromancer >should multitask. > If you read the entire posting, it said that I do use the OS in the boot program to detect memory beyond 512K. Rather than saving the state of the OS there, I use it to cache the major parts of the game so disk accesses aren't needed to reload them. Once they are loaded from floppy, the software doesn't go to floppy for the same data again. I deliberately choose to do this instead of protecting portions of the OS. I know how to do it, just don't want to. The approach I choose takes advantage of the extra memory and makes the game more playable for those who have stock A2000's (1Meg RAM) or 1Meg A500's, and of course, the rest of the enhanced machines, too. [ stuff about how programs benefit from taking over delted ] > The majority of these benefits are just laziness. Sure, it's nice to ORG >code instead of worry about dynamic memory, and wasting a few extra cycles >to plot graphics, but unless it's absolutely needed it's wrong. > > Consider this. You start writing a game, and optimize it as much as you >can, shaving cycles, memory, etc And end up with 64 BOBs moving at 60fps. >It's possible to degrade the game to 60 BOBs instead of 64 with no >recognizable loss in quality. > The way I do things is by design, and not out of laziness. I don't make 300K games, I make 512K games. It is by design. > My guess is, when you do a game, your don't have a full design on paper >or know how much performance you need, therefore you just take the >easy route and go for all out performance. Once you achieve your >game design goal and you find out you still have extra BOB/raster time >left, you go back to the game design and ADD more objects in, thinking >'hey, these extra objects are going to make the game alot more exciting.' >Either that, or you throw in a rediculous animation sequence, or >sampled sound. If you want to design your own games, go ahead. But don't tell me and everyone else how to do it. If everyone designs games exactly the way you do, it would get real boring real fast. The fact that individuals design games, instead of a design by community approach, gives us variety in game play, look and feel, and style. > I'm going to go out on a limb and say that Budokan did not need >100% of the Amiga's CPU power to animate the combatants. It may have needed >all 512k of ram for player objects, but not the entire CPU. > Budo was done in Extra Half Brite mode which steals 50% of the CPU cycles. The shadows for the players were calculated with the CPU, too. You assume that animation is all that's going on, and you didn't factor nearly everything that is going on. >>EVERY single instruction that ever gets executed is my own code. When >>I single step through routines, I get symbolic information for every >>single instruction. I never see jsr offset(a6) and wonder what the >>heck is going on. When I do use the OS and step partway into one >>of the ROM routines, I am apalled by how ugly and inefficient the >>code is. When I write the code myself, I am in full control of >>every clock cycle and byte that is used by the program. > > That's what compiled C code looks like. C is used for large projects >that an Assembly programmer could never accomplish in a resonable >amount of time. I programmed Assembly for 7 years, and I can do things >in C++/LISP that would take insurmountable time in assembly. >I do wish C= would optimize certain parts of the OS with AssemblY. >(Optimize Layers Library clipping code in assembly, and Exec's dispatcher, >and the vertical blank interupt handler. Intuition should stay in C, but >stuff like WritePixel should be in Asy) > A couple of points. Exec is already in assembler language. You might optimize just a few bytes/cycles out of it. It is the foundation of the OS. It was done RIGHT (assembler). Layers is really not that slow when you consider what it has to do (and compare it with other OS performance). ReadPixel and WritePixel are still going to be slow because it has to do rastport clipping (so you don't plot pixels outside of a window). Finally, development time is also not as much of an issue as is quality. When you call printf() you are relying on someone else's coding ability. When you call an OS routine, you are relying on someone else's coding ability, too. You not only have your own bugs to deal with but those in the (link) library and those in the ROM. When you run native under the OS, you are also relying on a wide variety of PD software hacks (like POPCLI, etc.) that people use to also not have bugs. Remember, one wild store in any of this software crashes everything. As far as 'C' goes, I have stepped through enough disassembled 'C' code to see enough. How much RAM is wasted on LINK, UNLK instructions? How many cycles are wasted by pushing arguments on the stack to call a subroutine? How many cycles are wasted by calling a "glue" routine? How many cycles and bytes are wasted by fixing up the stack after each and every subroutine returns? How much stack do you need to allow for all the dynamic allocation of local variables? 512K is not a lot of RAM to go and waste memory all the time. A 7.14 MHz 68000 isn't fast enough to waste all the extra cycles, if you are striving for performance. >>I NEVER need to do dynamic memory allocation, so my memory never fragments. >>Under the OS, if an application doesn't respond quickly enough to >>Intuimessages, or you have enough windows opened, the OS starts allocating >>memory and never frees it up. And the OS has serious problems with >>low memory situations (mostly it gurus). > > I'm willing to bet that all of the memory leaks are fixed in 2.0. >Give the CBM some credit! > I do give CBM credit. The OS still has problems when it can't allocate the memory that it needs. It also "leaks" memory in places by design, as in the case of IntuiMessages. >>I implement my own BOBs and Multitasking routines. > Are you really mulTitasking? It sounds to me like your VB interupt >is just looping on a state machine dispatching sub routines. (e.g. >Grab state, look up routIne in lookup table, jump to it if the state is >enabled) This is more like coroutines than real time-slicing. Is it >possible for one of your BOB tasks to be interupted by another? > Preemptive multitasking isn't necessary for a game. The multitasking kernel I wrote round robins the tasks. There are a dynamic number of tasks running at any one time. The state of each task is preserved when switching to a different task. The task structure I use is similar to what exec uses and the software works similar to the way that exec does when it is running a lot of tasks at the same priority. And to improve things, my tasking system only preserves half of the CPU registers instead of all of them (making a task switch faster than Exec's). BOBs are separate data structures. It is possible for a single task to control many BOBs or for a task to control NO BOBs. It is also possible for a BOB to be controlled by nobody (consider a torch animating on the wall that has no other properties). > No. If the game was written properly for the OS there would be no >problem. If a user runs BROKEN programs like GOMF, then it's his fault, not >the game programmer's. Too many people will blame the game software. They already are blaming phantom garbage on games. >>The blitter is a very powerful coprocessor and is no piece of cake to learn. > > I found that the blitter is very easy to learn with the help of >Tom Rockiki's BlitLab manual. The difficulty with the blitter is >learning the tricks with masking, and the bltadat stuff to perform >arbitrary blits anywhere. Also, the fact that the Hardware Manual >(v1.1 that I have) is WRONG in a loT of places and non of the example >code works (it assumes NO OS). When I was first fooling with the blitter >I didn't know how to do a barrel-shift to the left (for a smooth >scroller of course) This is because the HW manual didn't mention >the difference in the way the barrel shifter works in asc/descending modes. >Thank god to Tom Rokiki's and Jeremy San's improvements to the 1.3 HW manual >and for the BlitLab Manual in those early days. Sounds to me like Commodore hasn't done much to help. You obviously have some experience programming at the hardware level, so perhaps the blitter was just naturally easier for you to learn. Having written blitter code in software (for the Atari ST), I find that it is not a trivial task and is quite challenging to make it fast. What language and OS do you think Jeremy Sans uses to program the Amiga? I think he is an awesome programmer. Too bad he hasn't improved the rest of the manuals. > The Amiga hardware seems to have a lot of quirks that have to be overcome >by tricks. Like stopping a Audio DMA sample, using Disk DMA, programming >the blitter for 'bit blits' instead of word blits. The blitter is a word machine no matter how you look at it. As in any language, once you have a good set of routines to do these things, you can leverage them. You can modify existing working code to do specific things or simply reuse them. > It reminds me of the C64 days of polling the serial/disk ports, timing >out raster's to the cycle, and tricking the video chip to hardware scroll >the screen up and down or provide interlace. > These are techniques that allow the C64 to do better than the designers expected it would ever do. They also allowed Commodore to sell the machine for a few years more than it would have otherwise. >>If you don't need to take over the machine, >>don't. If you want to push the machine to its limits, there is NO >>other way. Let the game come first. If you know you can do the >>game in a small amount of RAM and that performance is not an issue, >>go ahead and use the OS. In my approach, if I have RAM left over, >>I use it for more sounds or instrument samples to make the music >>better, or to cache more data from the floppy drives. > > This confirms what I said above. You don't design the game in the >beginning. You program the game according to your ideas, and when you have >finished, if you find ANY Ram/CPU time left, you TAKE IT ANYWAY. >Let's assume you find you have 150k of ram left over after all game >graphics and sound is loaded. There is no reason to use this extra ram >for a rediculous animation/sample. It doesn't improve the playability of >the game. Using this 150k of extra ram, you can save the state of the OS >for restoration. > We had 90K left over in Budokan and that was used by Rob Hubbard to be as creative as he wanted with the music. I love the music in Budo (Rob is well known as THE top musician in the games business). The music would have suffered if he didn't use all 90K. There is NOTHING wrong with doing this. Budo had something like 9 different original musical scores done for it. Too many games just loop a single sample and just change the pitch and call it music. If all you want is hard disk installability, talk to commodore. I am. You don't need the OS for that. Taking part of the machine and killing off the OS is not better than taking the whole machine and killing off the OS. Why use part of the machine when you can use it all? Once people install something on hard disk, they want to run it and other Amiga programs at the same time. >>Unfortunately, the sales life of a game is about 3 months. Royalties >>don't keep trickling in. > > I bet a game written for 2000/3000 machines would sell for a long time. >Why? Because there's a niche there that no one has tapped yet, and >the majority of A2000/3000 owners are not pirates, obviously if they can >afford an A3000, they can afford a $30 game. > How much can you buy SIM CITY for mail order these days? I see lots of games done in the last year selling for $15. This is what is called a fire sale. People reduce the prices to get rid of inventory that is not moving. I bought Pirates (access software) for $19. It installs on the hard disk. It does not require 1Meg, which 2000/3000 machines have. The 2000 does not have a hard disk (the 2000HD does). >>Did you know that LoadRGB4() takes a full 60th of a second on a 68000? >>How long does MrgCop() take (pick random number). How long does >>RethinkDisplay() take (seconds)? How long does BltMaskBitMapRastPort() >>take? > > Probably because LoadRGB4 recomputes the copper list. Remember >screens/views are a sharable resource. Nothing is preventing you from >making a screen, disabling the inputdevice (Amiga n/m screen switch) >and Owning the Copper and Blitter on that custom screen. Whatever these routines do, they do too much more than you need in a game. None of the benefits you mention are even remotely desirable in action software. You suggest making an already tight for space program bigger at the expense of better things. > Mike, take alook at Tom Rokiki's RadBoogie. Granted, it doesn't have >a SoundTracker playing, or filled vectors, but from a programming >point of view, it's an excellent example, and proof that you can program >fast action graphics and still leave the OS functioning. >(Rad boogie calculates multiple splines in real time, blits a huge Amiga >logo, moves a large sprite, plays a Sonix music, and has a customcopper >going. Most all of those European Filled Vector scrolls/objects PRECOMPUTE >the object rotations and sin/cos paths with a C/Basic/Rexx program. Then >the Assembly code merely looks up table values, and uses the blitter >to draw lines/fill areas) This is fine technique. You still need the CPU/Blitter time to do the drawing if you have a few shapes. > >[deleted... The Amiga is not a C64. Mac's dont have any good actions >games because a game that takes over the MacOS won't sell. Period.] > Sales are poor, even for hit games. The people who did the two Dark Castles won't touch games after being burned twice. >>>I'm not trying to flame or put down anyone, but better games than the >>>current crop can still be written! Better both in terms of >>>awesome-take-over-the-machine-graphics, and better in terms of >>>awesome-playability-and-multitasking-code. >>> >> >>I agree here too. Looking at most Amiga games next to C64 games >>makes me want to puke. It is painful to see Amiga games run at 8 >>frames per second while the C64 version of the same game runs at >>60. There is no excuse for this. If you can't achieve the performance >>under the OS, boot it by all means. That is what the C64 guys do. It >>is a proven technique. > > There is no secret why C64 games run at 60fps. That's because 98% of >all C64 games are totally sprite driven. Any backgrounds are merely character >graphics. The C64 doesn't have the horsepower to scroll bitmaps, or >full color character mapped screens in real time. (You can't do it >in 1/60 of a second.) It's a pity the Amiga sprites are smaller than the C64's. >If they were 24/32 pixels wide a lot of games could use them (all 8) instead of >attaching 2 or 4 together. Shadow of the Beast runs at 60FPS because they were clever enough to use the Amiga's sprites. The Amiga sprites are multiplexable down the screen just as the C64's are. The Amiga has plenty of horsepower to put dozens of sprites on the screen AND use a bunch of blitter objects. It depends on how you use it all. I wouldn't ignore any feature of the Amiga's hardware. > The C64 was really pushed to it's limit in both programming a game design. >The Amiga has already been pushed to it's limit (mostly) What it really >needs is GOOD Design. > There is no law of physics that precludes a game from looking as good as SOTB and playing as good as whatever you consider playable and fun. > Mike, if you submit something to a magazine, put it in context. WHat I mean, >is that don't give the impression that the correct way to program the >Amiga is to boot the OS. Action games have their place, but there are >many types of games beside action games that don't need to boot the OS. >The Amiga is not a C64 (Even WOrd Processors on the C64 booted the OS) > If Mike Farren somehow gets his stuff published, he should do the same. > I know that the OS is a big overhead for using the blitter and disk to its >maximum abilities, but the fact that you said it only took you three days >to do that game code shows that you have put much work into it. > For me, those three days were 72+ hours (not much sleepy time). Again, the game uses 0% of the OS. I did it to prove that a smallish game can do it (takeover/restore). People seem to doubt that I have the ability... I still wouldn't ship a product that worked that way. >Bypassing the OS is not >the way to do this, unless you plan on writing custom routines for >each hardware configuration. Assembler is nice to know, but its a huge >waste to use assembler for everything. As hardware gets more and more >complex (parallel processing, risc, etc) the assembler programmer must >know more and more about the hardware. The hardware today is becoming so >complex that the ORDER of operations is becoming important. Certain >processors now require instructions to occur in precise order to insure >the pipeline is filled. Only compilers can keep track of register and >operation usage throughout the entire program. > No compiler for the 68000 can outdo what anyone can do by hand in assembler. Talking about RISC and incompatible hardware, etc. is not an issue in the Amiga world. > If you're an assembler programmer, the OS is especially annoying because >almost every OS function operates on C structures and linked lists. I became >annoyed because there were too many label names to remember for structure >offsets, and duplicate label names in different structures can't be done >in assemblers witouth collision. This is why C should be used for almost >all operations except speed dependent stuff. I'd suggest that most of >the 'kill the os' move over to CDTV when it hits the market. There you have >600 megs of disk space, and the ability to kill the OS and have no >complaints. > Gee, in a Screen structure, the rastport offset is called RastPort and the rastport offset in a Window structure is RPort. This kind of orthagonality makes it hard no matter what language you use. I do think that the BEST feature of 'C' is in its structure handling capabilities. However, just as COmmodore provides us with .h header files, they also provide us with .i header files. They closely parallel on another and they use a quite logical convention for avoiding label conflicts. Many of the assembler conventions have even made their way into the .h files. Why do some structures use simple names (as in Window.Height) and others use assembler style (as in TextAttr.ta_Name)? In practice, assembler is quite good at both data structures and event driven programming. If you haven't tried it, check it out and then comment again. > >-- >/~\_______________________________________________________________________/~\ >|n| rjc@albert.ai.mit.edu Amiga, the computer for the creative mind. |n| >|~| .-. .-. |~| >|_|________________________________| |_| |________________________________|_| -- ******************************************************** * Appendix A of the Amiga Hardware Manual tells you * * everything you need to know to take full advantage * * of the power of the Amiga. And it is only 10 pages! * ********************************************************