My address until 23/7/92: 9 Pendean Burgess Hill West Sussex RH15 ODW. My address after 23/7/92: 71 Shearwater Drive, Langford Village, Bicester, Oxon. OX6 OYS. Hi All! I'll answer a couple of questions of Marks first, that may be of general interest: How do bob-bob collisions in Tanxs (now Tank-Attack) work ? And how do you use "my" trace routine in a practical situation ? 1)Bob-bob collisions. To detect collsions I am still using the blit_zero flag, as per bob-scenery collisions, however the situation is more complex because both bobs are unlikely to lie at word boundaries. Ideally we could work out mask & scroll values for two blitter channels, for the bobs, and with the D channel turned OFF, AND the two channels together, and check for (non-)zero. However I couldnt get my brain into gear when it came to writing that routine, so I cheated: I worked out the pixel positions of the bobs relative to each other, copied one bobs hitmap to a blank area of memory (p map) and then treated the situation as a bob-scenery collision check since only one bob had to be offset! This cheat also meant that I didnt have to think about any masking required with two active channels looking at data of 'limited width'. Using the 68000 is a good alternative: most bobs are small, and you only need to test until you get one pixel overlap - you neednt do the rest then. 2)How does the trace routine work? Point one : Dave Edwards wrote this! I've just hacked it around a bit. Its latest incarnation can be found in my source this month, and I have fully commented it this time. Two : How to use it? Well, its not really a viable debugging tool in the sense of Monam or RossiMon - I just use it to check that registers get loaded with the correct values etc. See this months source for an example of its use - pressing the left mouse button steps through instructions. The trick in developing non-system code is to either write code that works 100% of the time anyway (fat chance), or (more usually) write it in such a way that you can step through it with monam with debug hunks & source code on/loaded. In this months code, I can specify '-Esystem' on the genam3 command line and the code will then not touch the interrupts/copper etc. yet still run - sure you to use a graphics ripper to view whats going on on screen, but it sure beats looking at the source code with no ideas as to what it causing the problem. (Else own/make an ActionReplay cartridge type device that allows you to break into any code. These cartidges are REALLY EASY to jam out though so if anyone reading this thinks they'll be able to hack games to pieces then they are mistaken!) And now onto my code... I had been looking for answers to several development problems: 1)Speed up assembly times when file have lots of included data - linking doesnt help one bit off floppy. 2)How to manage memory more efficiently - Tank-Attack had large chunks of data that were only used occasionally : if I could have avoided this by loading them in, the game would have used less memory total. 3)How to develop something for 100% non-system use : eg. a game, that can totally trash DOS and forget about it, and still be able to debug it ? 4)Provide means of recovering from normally fatal errors. 5)STILL allow code to be written freely with few constraints. My solution was to code PKDOS : -Memory management/allocation routines -A DOS file loader (with support for crunched files,directories,disks etc) -Revised bob code from Tank-Attack -Recoded screentyper3 from scratch, added loads of options: embedded codes, font/screen handling etc. :-) -LOTS of error trapping! Failsafe code in many places! -And more! Yep, the strain of doing too many exams has caused me to crack up.... The code is still very much a BETA version and is likely to EVOLVE considerably - every function will have a JUMPTABLE entry (eventually). I would then be able to just INCBIN the file at the start of any code... I am also toying with the idea of an interrupt driven blitter system - linked to blit_free - and possibly code to allow interrupts to be added/removed as required: they would use the same list processing code, so writing both wouldn't take much more effort than just one. I will write full documentation when the code has solidified a bit more! NB Disk routine error trapping is not yet 100%! SOURCE: PKDOS.S - Main code, does nothing bar - check bobs/trace etc. Provides disk routines, memory allocation code, text control/formatting etc etc. :-) This is the file to add your code to! MEMORYTEST.S - Test the memory control routines: Allocation/Deallocation/Running out of memory Trashing the memory lists etc. Drops back to AMIGADOS with a reqtools requester telling you what went wrong! TESTER.S - Test of bob routines & of texthandling code. Look at the comments to see how to use 'DOBOB' etc. DISKFX.S - Routines to do the spiralling blocks in tester.s *** FOR THE NEXT TWO EXMAPLES TO WORK, THE DISK MUST BE CALLED *** *** "PKDOS_1" UNLESS YOU CHANGE THE FILENAMES TO DF0: ETC. *** *** THE DISKTEST + SLIDESHOW DON'T CATCH ALL DISK ERRORS YET *** DISKTEST.S - Check PKDOS load file routines work - load some files from different directories on the disk. Flash the screen lots of meaningful colours too. SLIDESHOW.S - A sample (really easy) application - a simple hardware slideshow. Loads raw data files from The gfx directory on disk - they are crunched using the lh crunch routines in the LHLIB directory. (LH beats Powerpacker & Imploder by the way...) The little bar at the top of the screen is RED during a load or decrunch. GREEN when you can press the left mouse to advance. The pictures are from "Golems Gate Slideshow". INCLUDES: (amoungst other files) COMBISTART.S - Workbench startup file. HWSTART.S - System on/off type startup file, with error handling code : '_ERROR(a0)' function - uses reqtools.library by N.Francois! MYMACROS.S/HARDWARE.I - As usual. DISK.S - DOS loader code - supports disknames, directories, and files crunched with LH. Works out which drives are on the system etc. POSSIBLY an IFF>RAW runtime loader coming soon! 'dos.library' DEBUGABLE loader coming soon! eg. DF0:devs/keymaps/gb will work and so will PKDOS_1:Lhlib/Lhlib.doc LHDECODE.S - Patch file to decrunch LH crunched files. MEMORYMNGR.S - Memory init/allocation etc. code. When we dont need to return to the system, will use the ENTIRE system memory, having got details from EXECs memlists. (Eventually : Havent needed to code this yet - though little work!) SMPI.S - My sample player/controller code. TEXTHANDLER.S - AS it says. Handles ALL forms of text output. See the file for what it can do + check out the example in TESTER.S WARNING: *SLOW* calculates mask for every letter... NB Uses 68000 for fonts, so fonts do not need to be in chip memory. DO NOT use where a fast update is required! - The code is meant for menus/titles etc. GFX: - All example graphics/fonts required by examples! LHLIB: - FULL distribution of 'LhLib' from FISH 436 NB You must use the HEADER option for the files to be recognised as crunched! (+use a .lh suffix) TESTDIR: - And contents. Required for DISKTEST.S Thats it (so far) folks! I hope to tidy the code up *alot* over the next few days, as my friends & I try to distill a few ideas into another game... If we dont come up with anything, next month you may see both a newer version of PKDOS and some fast vector demo type code...(or whatever catches my imagination!) Sorry there isnt any formal documentation, but the code is likely to change so the docs wouldnt be valid for very long! NB Much of the disk routine is by DEAN ASHTON, taken from DISKCODER. I will send my game in if I hear nothing from any magasines in a couple of months. Yours sincerely, Paul Kent 24/6/92 ...one step closer...