Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!rpi!uwm.edu!bionet!agate!apple!motcsd!starnet!sschaem From: sschaem@starnet.uucp (Stephan Schaem) Newsgroups: comp.sys.amiga.programmer Subject: Mike Farren Tutorial. Summary: ....?! Message-ID: <1991Mar24.204206.11145@starnet.uucp> Date: 24 Mar 91 20:42:06 GMT Distribution: comp Organization: Starnet-Public Access UNIX-Los Altos,CA 415-949-3133, login:info Lines: 1452 This is post only on the programer side and is a reply of the tutorial writen by Mike Farren. I really hope you have time to read the following.You might find that game programer are not all ignorant people like Mike Farren want us to beleive! After reading his 4 part Attack/leason on game programing I had to prove something... >(Mike Farren): >even more, I hope that game programmers will take a >hint or two - leave us our Amigas, please! Dont I feel a little pretention here.I dont like that, especially when you attack other people! especially my profesion. First a VERY few things I wanted to comment on your posting. -ROM CODE: Sure it was designed to make action games:-). It can be used for it but it's not made for it! Try to do intensive copper activity with the system function! Try to do anything the rom was not design for! -DISPLAY: Some game actually need steady frame rate. Ok, now that you got trought Lemings can you write the same sugestion with TurricanII or SW-IV or OVERDRIVE etc...? -MULTITASKING: Have you EVER monitored the system! Move your mouse around, moving the mouse take more than 20% of the CPU time! 1%? Why do you want to multitask if you use the CPU 1% on the other side! And puting the OS to sleep and waiking it UP is the closest you can get to it with this kind of game. Here also make TurricanII or XENONII or OVERDRIVE etc.. true multitasking. -DISK FORMAT: 980K? not 1035K? (why have they step down?) Right now you can get over 1.1 meg, but not with the system. And 1.7 meg with data crunching included in the driver ... So 880K VS 1.7 MEG! You can have 2.4 meg disk messing around with MFM clocks, not safe... Also Game like SW-IV or OVERDRIVE use the drive has virtual memory. So 512K user can have 1MEG quality games! -MEMORY: Dont you think some people apreciate to be able to buy software for their 512K machine!!! I hope so. -HD INSTALABLE: There is absolutly no barrier for that for any floppy games. Well only piracy. >BLABLABLA.... >I hope that these postings have been useful fuel for thought. I hope >even more that any fledgling game developers reading this will think, >the next time they do a game, about how simple it can be to have both >a good game and an Amiga-friendly game. You don't have to give up >much of anything, and you gain the respect and admiration of those who >like to use their computers to their fullest, while not losing the >respect of those who don't care. Well not everybody do simple games like you! People could ONLY take your advice seriously if you actually done serious coding and know whats involve.From what you write in your 4 letters I seen a LARGE lack of knowledge. Yes, Like the Bitmap Brother, the people at Rainbow Art, Inerprise etc etc.. dont know all about the stuff you are saying! Ok, what would you sugest to make my curent project 'more Amiga-friendly'? Maybe the following will tell you that other game programer KNOW what they are doing! and what is realistic. OVERDRIVE curently run from my HD, I can install it in memory (making it resident!) and play anytime I want without loading anything... So if I use DPaint III I just press a key to enter the game and onother key to return to DPaint. Even if the comercial version is only on disk and connot be resident, we are thinking of making the developer version available.Well if we survive that money pit! Games can be complex.We started a Ground Zero, with DevpacII, CED, DPIII, soundtracker and our life investment! nothing less, nothing more. NOTE: CED PRO and DevpacII are actually PERFECT Product.People at MICHTRON and especially CYGNUS can be respected! (we also have the backbone for a mutliprocessor compiler, for precessor type code convertion) For example that's what involved in OVERDRIVE: -A Duplicator driver for the Amiga ONLY, with function not found on ANY other profesional system.(We are thinking of making a commercial version). -A Disk languages was created for developing OVERDRIVE. The language have more than 80 instruction.like those: TYPE Specify the file type. Three types are available: EXTRAC, DI, CREATE and COMPACTOR. The first one allow you to extrac data from files. The second allow you to create a disk format. Each track can be created with it. (Each track should be... See TRACK instruction) Each type you want to use this disk write TYPE DISK "name". The third allow you to create a game disk. The forth take a soft disk created with GAME and write it on any units you want... You have to specify the disk name to be used. The fifth allow you to compact or convert some files. PICTURE (EXTRAC) This allow you to define picture decompactage. Four decompactage are available: NORMAL (Default) RAWBLIT SPRITE4 SPRITE16 HARDCOMP SIZE Allow you to save size at sta NOSIZE (Default) PIXEL X size written in pixel WPIXEL (Default) X size written in WordWidth*1 WORD X size written in word BYTESIZE Size written in a byte or wor WORDSIZE (Default) CTRL (Default) Save control word in sprite NOCTRL REMAP NOREMAP (Default) SYNC (DISK/GAME) Synchronisation is four hexadecimal number. In GAME mode: Define synchronisation to use for next file in GAME mode. Then it can be at any offset in track. In DISK mode: This define synchronisation of actual track. You can write SYNC+ to reach next track after you have define sync of this track. (Note: If end of disk is reached no track will be defined, and then you will need to use TRACK instruction again) This last way suppose you already define a track number. And it's very usefull when it's use at the end of a track definition! Note that the lways 0.5... ETC... So heres a little programe to extract a directory with IFF brushed: (of course the language is interactive). Type Extract Picture Size Picture RawBlit Depth 6 IffDir Picture Ram: -A Floppy disk driver for virtual memory. Sory Private information.But beleive me its good. -A Compacting algorithem. LZH is better... But I will get back to it! Including data type detection (using diferent algorithem for 8bit digit and text for example) -A Powerfull MAP Editor with literaly hundreds of functions. For example one of the selection screen of the editor has 53 functions for map manipulation and 35 for curent brush manipulation (GADGETS). All have key shortcut. Of course alot of gadget have sub window:like the filer option offer 7 other option. You can have an 'infinity' of brushes, with pattern fill with patterns. Multiple windows (having your ANYSIZE block screen next to your map, see multiple part of the map etc...) Of course you can do everything other editor do, save every single seting and configuration of the software. Of course everything file we read or write support iff. And Data manipulation are VERY powerfull. You have color manipualtion screen with mixing, sorting, remaping import/export etc... ColorCycling screen... Information screen.Where you can set the block info.Like level, type, Ttype, borders.(Let you modify system block info: superinfo, animation display type: rotation, xflip, yflip etc...) You can call an info screen and place it at the bottom to have a scall down of your screen/map with your location... And the editor can have multiple maps and block. AND alot more.... -A 290 functions library.Here is some of them...: We have resource tracking, error tracking, data check, structure check, debug function, function check etc... LIBINIT ;The CSD Console LIBDEF _OpenCSDConsole LIBDEF _CloseCSDConsole LIBDEF _CSDWrite LIBDEF _AnalyseString ........ LIBDEF _WOpen ;Open CSDWindow LIBDEF _WClose ;Close CSDWindow/Intuition LIBDEF _WaitW ;Wait For any Task window MSG LIBDEF _GetWMsg ;Message of this task Windows LIBDEF _ExecuteW ;Execute Message From Window The above handle 100% of the overhead for you, simple plug the structure! Of course you can KILL a CSD task with 100% of the resource restored. Analize string handle ansi text (not to mention). We also have another text control sequence for special display and calculation. We also document the function: ;---------------------------------------------------------------------------- CSDAllocMem NAME CSDAllocMem - Allocate memory for CSD usage SYNOPSIS MemBlk = CSDAllocMem(ByteSize, Requirements, StartPtr, EndPtr) SR/D0/A0 D0 D1 A0 A1 MemBlk = D1 FUNCTION This routine use ROM structure but don't go trough the Allocate function of ROM. This routine is made to "understand" largest flag bit. Also it's now easily possible to allocate the largest part of memory. But in this case you must always specify D0 like block size. (Also you will look for the largest block under D0 or with D0 size) Normaly if largest bit is set you will receive some memory... To have the largest possible block you will set D0 to null or -1. To end, D1 is returned with the size of allocated block. When FORCE and/or MEMABS bit are used A0 and A1 are needed to have a good allocation. A0 define the less start address of allocation and A1 the higher one. If MEMABS is specify also only A1 is usefull and define start address. (Like in ROM 1.x) At this time LARGEST bit and FORCE one couldn't be used at the same time. All the CSD memory allocations are linked togheter. Also if you forge to free all your allocated memories, CSD will do it for you. (NOTE: a requester will appear at the end when you will make the CloseLibra INPUTS ByteSize of memory to be allocated (Long word) Requiments - Defined type of memory (Largest allowed) PUBLIC All allowed memory for every tasks. CHIP Special processor memory. FAST 68000 memory only. CLEAR Return cleared memory. LARGEST Allocation of 8 bytes of memory to D0 bytes. FORCE Allocation of memory between A0 and A1 pointers. MEMABS Allocation of memory at address A1. RESULTS MemBlk - Pointer to the allocated memory (Already returned in A0) SR z - z is set correspondly to the result. If no allocation was done z will be zero, atherwise it will be set. SizeBlk - Return size of allocated block, this must be use to know block size after an allocate with the largest bit specification. If no allocation is done (With or not Largest bit) D1 will be null EXECPTIONS If length is null and largest bit is clear no memory is allocated. If length is null and largest bit is set the largest actual memory is allocated. Start and end addresses are reorder. Then you can send them in any or BUGS Don't return 0 in D1 when allocation is not done and largest bit is n (But return size...) SEE ALSO CSDAllocMemError() CSDFreeMem() CSDMemList() CSDTypeOfMem() ;---------------------------------------------------------------------------- AllocListSize NAME AllocListSize - Try to alloc memory and add it to a list SYNOPSIS Node = AllocListSize(List, ByteSize) D0 A0 D0 FUNCTION This function look for memory (Always cleared and public) and if memory was allocated, add it in a list and then the size is written in structure at the next position of "previous" pointer. Then you will be able to use this with FreeAllList() and a size of 0. A0 can be null if no list was already created. If not enough memory is present also no list will be adding. NOTE: the list is insert with InsertList routine (See). INPUTS List - List pointer (Null for none) ByteSize - Size in byte of the allocated list node (Note the size must contain the height byte of next and previous pointers of the beginning) RESULTS Node - Pointer to the added node EXCEPTIONS None NOTES A list of this type is formed with a Next pointer a Previous pointer and a word Size. Then you will be able to use the structure from the byte ten. BUGS None know SEE ALSO AllocList() AllocLargeList() CountList() CountEndList() FreeAllList() FreeEndList() FreeList() HeadList() InsertList() NextList() PreviousList() QueueList() RemoveList() SearchList() SearchNextList() All the our code are written in HIGHLY optimized assembly, Fully multitasking, Very structured.... We have pure code, READ only.Well We want to creat an operating system:-) And of course there is ALOT more than the above. 65xx, I remember doing a 1024 byte full text editor with disk support... But remember the 68000 is not a 6510, and graphics on 8bit machine is something else! MEMORY: ------- -DRAWINGS: Each level has more than 400 IMAGES of 16 pixel minimum and 50% in 16 colors and the rest full 64 colors! -MAPS: With 1024 Tiles of 16x16 in 64 colors for the map drawings.the map has big has 400 screens.Each block have control many words to tell the way they will be displayed, the way they are compacted, but colors blocks etc.. Those maps are 578K big with 160K of tiles: 738K already! -SOUND: 64K dedicated to sound and music. -SCREEN: 88K for the 64 colors half bright screens. -Each Fire (25 diferents) have buffer for up to 32 on screen. Fire have speed, aceleration, power, efect type, direction, animation... -OBJECT: You have to fill the 400 screens with something! you can get more than 100 moving object on screen... Each Object Have their own: SHADOWS Showing their height position. POWER For weapon protection and colision. WEAPON Type (see above), plus programed types. TRAJECTORY An internal interpreter, With the most used math function. ANIMATION Can be set by trajectory interpreter and many other ways. LINKAGE Object can be linked one another. EXPLOSION 5 type, up to 64x64 pixels. And alot more... We ave more than 80K of structure definition... ETC... I could write megs to explain the all game functions! OVERDRIVE use almost every bytes of those 512K! That's why its 3 months late now:-( Almost everything is compated during game play (not the sound or code). And if we knew that we could have made a 1meg version without loosing money 4 peoples wouldn't have developed for it for 1 1/2 years! We are STRONG AMIGA beleivers, and we get kicks writting ANYthings at least that it run on an AMIGA. Some of my good friends, like The creator of LightQuest and 5 others amiga games have to do PC, atari version too! He can program at the hardware level on 6 machine, but will get nothing by lEARNing the Amiga OS... See my point? DISK: ----- Actually I would say that the DOS we are using in OVERDRIVE is safer than AmigaDos!! So please... (Already talk about that, checksum done in read buffer). MULTITASKING: ------------- I also have a project started: a Multitasking game running a 60 frames second scroling in 32 colors.The scroll and interface work, so you could say that multitasking is possible... Its not an action game, so the system have enought time to run smothly.(A CLI scrolling and game scrolling work nice together.) CONCLUSION: ----------- Actually some people other than you know the Amiga.And if you want to tell them what to do, put them down, give them lessons you better check that the 'student' dont know more than the 'teacher'.... People dont make decision just like that! And if games dont multitask or are not HD installable dont mean that the developers are BRAIN DEAD and dont know the amiga! You text being published, that would hurt! Stephan Schaem. NOTE: Have you ever passed more than 15,000 hours on a single project?