From: owner-csmp@ee.mcgill.ca Subject: csmp digest Vol 4 No 045 C.S.M.P. Digest Mon, 24 Nov 97 Volume 4 : Issue 45 Today's Topics: 3D collision... AIFF sound files Dialog picture item opcodes for single gray line Fast font and screen blitters... PPC assembler? Q: timing issues with Sound Manager Quickdraw fast with regions? Shutting Down the Comp.? Updated toolbox references Which books for 3D programming & 3d maths The Comp.Sys.Mac.Programmer Digest is moderated by Mark Aiken (marka@ee.mcgill.ca). The digest is a collection of article threads from the internet newsgroups comp.sys.mac.programmer.help, csmp.tools, csmp.misc and csmp.games. It is designed for people who read news semi-regularly and want an archive of the discussions. If you don't know what a newsgroup is, you probably don't have access to it. Ask your systems administrator(s) for details. If you don't have access to news, you may still be able to post messages to the group by using a mail server like anon.penet.fi (mail help@anon.penet.fi for more information). Each issue of the digest contains one or more sets of articles (called threads), with each set corresponding to a 'discussion' of a particular subject. The articles are not edited; all articles included in this digest are in their original posted form (as received by our news server at ee.mcgill.ca). Article threads are not added to the digest until the last article added to the thread is at least two weeks old (this is to ensure that the thread is dead before adding it to the digest). Article threads that consist of only one message are generally not included in the digest. The digests can be obtained by email, ftp or through the World Wide Web. If you want to receive the digest by mail, send email to majordomo@ee.mcgill.ca with no subject and one of the following commands as body: help Sends you a summary of commands subscribe csmp Adds you to the mailing list unsubscribe csmp Removes you from the list Once you have subscribed, you will automatically receive each new issue as it is created. Back issues are available by ftp from Info-Mac mirror sites in the per/csmp subdirectory, e.g. ftp://sumex-aim.stanford.edu/info-mac/per/csmp/ The contents of all back issues can be searched by accessing the following URL, courtesy of Andrew Barry (ajbarry@ozemail.com.au): http://marvin.stattech.com.au/search.html They can also be searched through the following URLs, thanks to Tim Tuck (Tim.Tuck@sensei.com.au): http://wais.sensei.com.au/searchform.html wais://wais.sensei.com.au:210/csmp? ------------------------------------------------------- >From nagilum@mindspring.com (Nagilum) Subject: 3D collision... Date: Fri, 24 Oct 1997 07:40:08 -0800 Organization: Fission I am making a 3D game, similar in many ways to quake. I need to do collision, but I don't have any idea how I should do it. I want to be albe to impliment fairly realistic phyisics, so the method would have to be able to acomidate things like a spike stiking out of the wall (of course also it has to support slanted walls, as this game will have very complex arcitexture). I already have a way of dealing with groud, I only need a way to make walls, any size or shape, collide with other things (players, monsters, rockets...). Does anyone have any idea of how Quake or Duke does collision? PLEASE HELP ME! Thanks. -- - --------------------------------- James Marr nagilum@mindspring.com - --------------------------------- I think, therefore I use a Mac. +++++++++++++++++++++++++++ >From johnb@hk.super.net.remove_this_to_mail_me (John W. Blackburne) Date: Sat, 25 Oct 1997 21:21:50 +0800 Organization: Hong Kong Supernet In article , nagilum@mindspring.com (Nagilum) wrote: : I am making a 3D game, similar in many ways to quake. I need to do :collision, but I don't have any idea how I should do it. I want to be albe :to impliment fairly realistic phyisics, so the method would have to be :able to acomidate things like a spike stiking out of the wall It depends mostly on how complex your world is. If it's more like Doom/Marathon than Quake, i.e. with only vertical walls, only horizontal floors and with solid objects (trees, desks, etc) treated as walls you can do most of your colision detection in 2D, basically storing the 2D map and testing for collisions in that, then using the 3D info to decide the result of the 'collision', e.g. you might need to decide whether a player stops at or steps/jumps onto a wall. If you really want to ipmlement a Quake type engine you are in for a lot more work, as Quake has a true 3D world where walls/floors need not be horizontal or vertical. To keep the processing manageble you will probably want to treat all players and non-player characters as boxes or cylinders, i.e. so their complex interior geometry is ignored. Then you just need to do some 3D math, to see whether the corners or edges or the player might overlap adacent walls. In either case you will probably store a list of basic game environment objects, such as rooms, walls, floors, spikes, trees, desks, etc., together with their surfaces. If you make sure you store the global (x, y and possibly z) location of each object centre you can quickly eliminate those objects not near a player which you don't need to check against. For a large map you can reduce checking further by dividing your map into zones (e.g. rooms or floors) so that if a player is in one zone you only need to check proximity to and collisions with objects in that room. And for both 2D and 3D checking you can save time by storing the unit normal to each wall/floor surface and the result of the scalar product of this with a point on the wall. If you repeat the calculation again with another point (the corner or center of the player) the difference between the results tells you which side of the wall the test point is on and how far away it is. As for 'fairly realistic physics', you then want to be able to handle elastic collisions, where things bounce off walls, changing speed and direction accordingly. This is pretty straigntforward to do using vector math once you know the normal to the surface and the velocity vector of the object colliding with it. For an impressive degree of realism you could also deal with extended objects properly, allowing objects to start spinning or change their rate of rotation if hit on one side/at one end. I've not seen this done in games, so if you manage this it will be fairly impressive. John -- John Blackburne; programmer, writer, consultant, trainer tel/fax: Hong Kong (+852) 2816 7484 home page: +++++++++++++++++++++++++++ >From nagilum@mindspring.com (Nagilum) Date: Sun, 26 Oct 1997 18:51:53 -0800 Organization: Fission In article , johnb@hk.super.net.remove_this_to_mail_me (John W. Blackburne) wrote: > In article , > nagilum@mindspring.com (Nagilum) wrote: > > : I am making a 3D game, similar in many ways to quake. I need to do > :collision, but I don't have any idea how I should do it. I want to be albe > :to impliment fairly realistic phyisics, so the method would have to be > :able to acomidate things like a spike stiking out of the wall > > It depends mostly on how complex your world is. If it's more like > Doom/Marathon than Quake, i.e. with only vertical walls, only horizontal > floors and with solid objects (trees, desks, etc) treated as walls you > can do most of your colision detection in 2D, basically storing the 2D map > and testing for collisions in that, then using the 3D info to decide the > result of the 'collision', e.g. you might need to decide whether a player > stops at or steps/jumps onto a wall. > > If you really want to ipmlement a Quake type engine you are in for a lot > more work, as Quake has a true 3D world where walls/floors need not be > horizontal or vertical. To keep the processing manageble you will probably > want to treat all players and non-player characters as boxes or cylinders, > i.e. so their complex interior geometry is ignored. Then you just need to > do some 3D math, to see whether the corners or edges or the player might > overlap adacent walls. > > In either case you will probably store a list of basic game environment > objects, such as rooms, walls, floors, spikes, trees, desks, etc., > together with their surfaces. If you make sure you store the global (x, y > and possibly z) location of each object centre you can quickly eliminate > those objects not near a player which you don't need to check against. For > a large map you can reduce checking further by dividing your map into > zones (e.g. rooms or floors) so that if a player is in one zone you only > need to check proximity to and collisions with objects in that room. > > And for both 2D and 3D checking you can save time by storing the unit > normal to each wall/floor surface and the result of the scalar product of > this with a point on the wall. If you repeat the calculation again with > another point (the corner or center of the player) the difference between > the results tells you which side of the wall the test point is on and how > far away it is. > > As for 'fairly realistic physics', you then want to be able to handle > elastic collisions, where things bounce off walls, changing speed and > direction accordingly. This is pretty straigntforward to do using vector > math once you know the normal to the surface and the velocity vector of > the object colliding with it. For an impressive degree of realism you > could also deal with extended objects properly, allowing objects to start > spinning or change their rate of rotation if hit on one side/at one end. > I've not seen this done in games, so if you manage this it will be fairly > impressive. thanks! Any idea where I can get some formulas for this (I'm only 16 and in Advance Algebra 2 (zzzz)). -- - --------------------------------- James Marr nagilum@mindspring.com - --------------------------------- I think, therefore I use a Mac. +++++++++++++++++++++++++++ >From nagilum@mindspring.com (Nagilum) Date: Thu, 30 Oct 1997 21:55:38 +0800 Organization: Fission In article , ivolow1@ic3.ithaca.edu (Ilan Volow) wrote: > In article , > nagilum@mindspring.com (Nagilum) wrote: > > > In article , > > johnb@hk.super.net.remove_this_to_mail_me (John W. Blackburne) wrote: > > > > > In article , > > > nagilum@mindspring.com (Nagilum) wrote: > > > > > > : I am making a 3D game, similar in many ways to quake. I need to do > > > :collision, but I don't have any idea how I should do it. I want to be albe > > > :to impliment fairly realistic phyisics, so the method would have to be > > > :able to acomidate things like a spike stiking out of the wall > > > > > > It depends mostly on how complex your world is. If it's more like > > > Doom/Marathon than Quake, i.e. with only vertical walls, only horizontal > > > floors and with solid objects (trees, desks, etc) treated as walls you > > > can do most of your colision detection in 2D, basically storing the 2D map > > > and testing for collisions in that, then using the 3D info to decide the > > > result of the 'collision', e.g. you might need to decide whether a player > > > stops at or steps/jumps onto a wall. > > > > > > If you really want to ipmlement a Quake type engine you are in for a lot > > > more work, as Quake has a true 3D world where walls/floors need not be > > > horizontal or vertical. To keep the processing manageble you will probably > > > want to treat all players and non-player characters as boxes or cylinders, > > > i.e. so their complex interior geometry is ignored. Then you just need to > > > do some 3D math, to see whether the corners or edges or the player might > > > overlap adacent walls. > > > > > > In either case you will probably store a list of basic game environment > > > objects, such as rooms, walls, floors, spikes, trees, desks, etc., > > > together with their surfaces. If you make sure you store the global (x, y > > > and possibly z) location of each object centre you can quickly eliminate > > > those objects not near a player which you don't need to check against. For > > > a large map you can reduce checking further by dividing your map into > > > zones (e.g. rooms or floors) so that if a player is in one zone you only > > > need to check proximity to and collisions with objects in that room. > > > > > > And for both 2D and 3D checking you can save time by storing the unit > > > normal to each wall/floor surface and the result of the scalar product of > > > this with a point on the wall. If you repeat the calculation again with > > > another point (the corner or center of the player) the difference between > > > the results tells you which side of the wall the test point is on and how > > > far away it is. > > > > > > As for 'fairly realistic physics', you then want to be able to handle > > > elastic collisions, where things bounce off walls, changing speed and > > > direction accordingly. This is pretty straigntforward to do using vector > > > math once you know the normal to the surface and the velocity vector of > > > the object colliding with it. For an impressive degree of realism you > > > could also deal with extended objects properly, allowing objects to start > > > spinning or change their rate of rotation if hit on one side/at one end. > > > I've not seen this done in games, so if you manage this it will be fairly > > > impressive. > > > > thanks! Any idea where I can get some formulas for this (I'm only 16 and > > in Advance Algebra 2 (zzzz)). > > > > -- > > ----------------------------------- > > James Marr > > nagilum@mindspring.com > > ----------------------------------- > > I think, therefore I use a Mac. > > You might want to take physics course so you can familiar with the > different phyics formulas needed to make the game seem realistic. Also, the > book "The Tricks of the Mac Game Programming Guru's" has a whole chapter on > game physics, and it would be a very good source for the most basic info on > attatching real-world movement to your graphics. > > -- > "C:\ONGRTLNS.W95" I ment does anyone have any formauls for a quake style collision system. I have a friend who is in physics, and he said he would help me out with the physics part, but before I can realisticly bounce a grenade off a wall, I must know that the greneade it hitting the wall. I don't have anyover head; so I can adapt to any system that anyone can think of. Anything, I am really getting discuraged by this problems; I don't want to do anything else with my game until I have finalised what collision system I am going to use, as anything I do may not be compatible with the new collision system... Thanks -- - --------------------------------- James Marr nagilum@mindspring.com - --------------------------------- I think, therefore I use a Mac. +++++++++++++++++++++++++++ >From ivolow1@ic3.ithaca.edu (Ilan Volow) Date: Fri, 31 Oct 1997 06:19:42 -0400 Organization: None In article , nagilum@mindspring.com (Nagilum) wrote: > In article , > johnb@hk.super.net.remove_this_to_mail_me (John W. Blackburne) wrote: > > > In article , > > nagilum@mindspring.com (Nagilum) wrote: > > > > : I am making a 3D game, similar in many ways to quake. I need to do > > :collision, but I don't have any idea how I should do it. I want to be albe > > :to impliment fairly realistic phyisics, so the method would have to be > > :able to acomidate things like a spike stiking out of the wall > > > > It depends mostly on how complex your world is. If it's more like > > Doom/Marathon than Quake, i.e. with only vertical walls, only horizontal > > floors and with solid objects (trees, desks, etc) treated as walls you > > can do most of your colision detection in 2D, basically storing the 2D map > > and testing for collisions in that, then using the 3D info to decide the > > result of the 'collision', e.g. you might need to decide whether a player > > stops at or steps/jumps onto a wall. > > > > If you really want to ipmlement a Quake type engine you are in for a lot > > more work, as Quake has a true 3D world where walls/floors need not be > > horizontal or vertical. To keep the processing manageble you will probably > > want to treat all players and non-player characters as boxes or cylinders, > > i.e. so their complex interior geometry is ignored. Then you just need to > > do some 3D math, to see whether the corners or edges or the player might > > overlap adacent walls. > > > > In either case you will probably store a list of basic game environment > > objects, such as rooms, walls, floors, spikes, trees, desks, etc., > > together with their surfaces. If you make sure you store the global (x, y > > and possibly z) location of each object centre you can quickly eliminate > > those objects not near a player which you don't need to check against. For > > a large map you can reduce checking further by dividing your map into > > zones (e.g. rooms or floors) so that if a player is in one zone you only > > need to check proximity to and collisions with objects in that room. > > > > And for both 2D and 3D checking you can save time by storing the unit > > normal to each wall/floor surface and the result of the scalar product of > > this with a point on the wall. If you repeat the calculation again with > > another point (the corner or center of the player) the difference between > > the results tells you which side of the wall the test point is on and how > > far away it is. > > > > As for 'fairly realistic physics', you then want to be able to handle > > elastic collisions, where things bounce off walls, changing speed and > > direction accordingly. This is pretty straigntforward to do using vector > > math once you know the normal to the surface and the velocity vector of > > the object colliding with it. For an impressive degree of realism you > > could also deal with extended objects properly, allowing objects to start > > spinning or change their rate of rotation if hit on one side/at one end. > > I've not seen this done in games, so if you manage this it will be fairly > > impressive. > > thanks! Any idea where I can get some formulas for this (I'm only 16 and > in Advance Algebra 2 (zzzz)). > > -- > ----------------------------------- > James Marr > nagilum@mindspring.com > ----------------------------------- > I think, therefore I use a Mac. You might want to take physics course so you can familiar with the different phyics formulas needed to make the game seem realistic. Also, the book "The Tricks of the Mac Game Programming Guru's" has a whole chapter on game physics, and it would be a very good source for the most basic info on attatching real-world movement to your graphics. -- "C:\ONGRTLNS.W95" +++++++++++++++++++++++++++ >From jmunkki@alpha.hut.fi (Juri Munkki) Date: 1 Nov 1997 02:53:36 GMT Organization: Helsinki University of Technology In article nagilum@mindspring.com (Nagilum) writes: >physics part, but before I can realisticly bounce a grenade off a wall, I >must know that the greneade it hitting the wall. I don't have anyover >head; so I can adapt to any system that anyone can think of. Anything, I >am really getting discuraged by this problems; I don't want to do anything >else with my game until I have finalised what collision system I am going >to use, as anything I do may not be compatible with the new collision >system... Thanks Here's a brief outline of what Avara uses for grenades and other fast moving objects: Each time the object is moved, a ray is shot from the old position to the new and that ray is collision-tested with objects that are in the vicinity. Ray/object algorithms can easily be found, because they are used for raytracing algorithms. If the ray doesn't intersect with anything, the actual object is moved and then its bounding volume (in the case of Avara, the intersection of a bounding box & sphere) is tested against other bounding volumes. If there's a hit, the grenade explodes. Bounding volume intersections can become complicated, if you use complicated bounding volumes. Even though Avara uses relatively simple bounding volume shapes, there's a slight bug in the way box/box intersections are detected. Fortunately the sphere/sphere, sphere/box and box/sphere tests make this problem almost unnoticeable, unless you know exactly what to look for. More general babbling: Don't get discouraged. Geometry and algorithms for geometrical problems are really quite fascinating mental puzzles. There's usually a neat solution, if you are clever. In many cases you can think of the problem in 2D and use the 2D solution to solve the 3D case. It doesn't always work, but it usually gives you at least some insight to the 3D problem. Try to stay away from working with angles. Use normalized axis vectors instead. In most cases you only need a few dot products here and there to solve your problem. -- Juri Munkki jmunkki@iki.fi Life is easy when polygons are cheap. http://www.iki.fi/jmunkki Windsurfing: Faster than the wind. +++++++++++++++++++++++++++ >From johnb@hk.super.net.remove_this_to_mail_me (John W. Blackburne) Date: Mon, 03 Nov 1997 22:18:21 +0800 Organization: Hong Kong Supernet In article , nagilum@mindspring.com (Nagilum) wrote: [ SNIP ! ] :I ment does anyone have any formauls for a quake style collision system. I :have a friend who is in physics, and he said he would help me out with the :physics part, but before I can realisticly bounce a grenade off a wall, I :must know that the greneade it hitting the wall. I don't have anyover :head; so I can adapt to any system that anyone can think of. Anything, I :am really getting discuraged by this problems; I don't want to do anything :else with my game until I have finalised what collision system I am going :to use, as anything I do may not be compatible with the new collision :system... Thanks I don't think it's possible to just provide a set of formulae to do this. Generic formulae are close to useless, as in any real world situation there are always many shortcuts specific to your world that you can apply. E.g. the most generic formulae would treat all 3D objects as polyhedra and do 3D math on their surfaces, edges and vertices to determine if and when/where objects collide. But in practice you rarely want or can afford such precision. Most 3D worlds use many compromises to limit the number of calcuations, e.g. typically many objects (switches, doors) are geometrically flat, with textures used to give the illusion of 3D, while the player and non-player characters are often treated geometrically as cuboids or cylinders. Other compromises include flat vs sloped floors, elastic collisions (proper bounces) vs pseudo-elastic or inelastic, how/whether gravity/drag effects motion/projectiles, whether bridges or outdoors/indoors environments are (well) supported. It's considerations such as these which seperate games: e.g. Doom has a strictly 2D map with only 2D objects, no ballisic projectiles and no outdoor environments. Marathon has maps with multiple layers but still no bridges, still only 2D sprites. Dark Forces partly supports bridges and 3D objects, but most objects are sprites and collisions are still all done in 2D. Duke has 3D surfaces, full support for bridges and better ballistics and bounces but still uses a 2D map and sprites. Quake has a 3D environment and objects/enemies but still uses textures for switches and simple bounding boxes for player/object collisions. Avara has one of the most complete 3D implimentations, but it doesn't do textures. Each of these will have it's own optimisations for 3D rendering and collision testing, because a complete, realistic 3D system would just be too complex for modern computers. It also allows them to trade compromises, e.g. using textures to represent some 3D objects to allow for more [complex] 3D objects elsewhere, using bounding boxes to reduce the complexity of hit-testing. Your best bet would be to read up on or take a course on the physics and math involved, to get a handle on what you need. Once you have this you could try implimenting some simple ideas in a demo, to give you a better idea of what's involved and so you can see the impact the decisions you make on how to impliment 3D in your game will have. Unfortunately it won't be until you are close to completing coding that you'll be able to really see what effects such decisions will have, and so you may be still making such decisions well down the line. Implimenting a 3D engine is far from trivial and is not something to be undertaken lightly. If it were easy you wouldn't see so many commercial games recycling other people's 3D engines: all the 3D engines above, except for Avara's, have been adopted by other publishers in commercial games. John -- John Blackburne; programmer, writer, consultant, trainer tel/fax: Hong Kong (+852) 2816 7484 home page: +++++++++++++++++++++++++++ >From Andre-John Mas Date: Tue, 04 Nov 1997 16:18:30 +0000 Organization: DHL Systems Ltd One approach to checking for 3D collision would be to take your 2D collision algorithm and modify it to work in a 3D environment. Your 2D algorithm will take into account X and Y, you simply need to add support for the Z coordinate. BTW I haven't actually tested the above AJ -- * Andre Mas ** Tel. +44 181 996 3841 * * mailto:amas@lhr-sys.dhl.com ** Fax. +44 181 996 3802 * * current geographical Location - United Kingdom ....... * +++++++++++++++++++++++++++ >From johnb@hk.super.net.remove_this_to_mail_me (John W. Blackburne) Date: Thu, 06 Nov 1997 23:47:00 +0800 Organization: Hong Kong Supernet In article <345F4AD6.6496@lhr-sys.dhl.com>, Andre-John Mas wrote: :One approach to checking for 3D collision would be to take your :2D collision algorithm and modify it to work in a 3D environment. :Your 2D algorithm will take into account X and Y, you simply need :to add support for the Z coordinate. This would work fine if you only had horizontal floors and vertical walls, as in Doom (I, II), Marathon (I, II, inf) Dark Forces. Then you just do 2D hit testing in a 2D map (you may use floors or layers to make it more 3D but it's still basically a 2D map) and use the z valuse to decide what to do with it, e.g. did the rocket 'hit' that low wall high enough to go over it. But I think the original poster wanted proper physics in a Quake-like 3D world, in which case you are going to have to deal with X, Y and Z all at once and at some point do proper 3D math, which is similar to but a fair bit more complex than the 2D stuff, especially if you want to come close to realistic physics. John -- John Blackburne; programmer, writer, consultant, trainer tel/fax: Hong Kong (+852) 2816 7484 home page: --------------------------- >From jrl@netcom.com (Dr. J. Robert Lee) Subject: AIFF sound files Date: Thu, 30 Oct 1997 15:32:10 GMT Organization: Netcom Online Communications Services (408-241-9760 login: guest) Looking for documentation on AIFF sound file structure.. The docs that I found at Apple are incomplete. Any suuggestions? -- J. Robert Lee, Ph.D. +++++++++++++++++++++++++++ >From shanks@yallara.cs.rmit.edu.au (Vaughan) Date: 3 Nov 1997 00:40:52 GMT Organization: Comp Sci, RMIT University, Melbourne, Australia. Dr. J. Robert Lee (jrl@netcom.com) wrote: : Looking for documentation on AIFF sound file structure.. The docs that : I found at Apple are incomplete. Any suuggestions? There's a few pages explaining the structure in Think Reference (a commercial online reference that came with Symantec C/C++ 8) Vaughan :-) +++++++++++++++++++++++++++ >From nebulus@netcom.com (Bruce McDiffett) Date: Mon, 3 Nov 1997 04:46:24 GMT Organization: Cineplex Odious Vaughan (shanks@yallara.cs.rmit.edu.au) wrote: : Dr. J. Robert Lee (jrl@netcom.com) wrote: : : Looking for documentation on AIFF sound file structure.. The docs that : : I found at Apple are incomplete. Any suuggestions? : There's a few pages explaining the structure in Think Reference (a : commercial online reference that came with Symantec C/C++ 8) : Vaughan :-) You can also grab the AIFF-C spec off the web - one URL that works is: ftp://ftp.sgi.com/sgi/aiff-c.9.26.91.ps.Z The AIFF-C format supports various kinds of compression of the digital audio data within the AIFF wrapper. Bruce Microsoft Windows - Who Do You Have To Blow Today? --------------------------- >From 3gl21@qlink.queensu.ca (Gregory Lo) Subject: Dialog picture item opcodes for single gray line Date: Thu, 30 Oct 1997 19:48:16 -0500 Organization: Queen's University Hey all, I seem to remember reading somewhere of a trick to create a small PICT resource containing only the opcodes for a horizontal line (sometimes with a pattern), and merely using that PICT in a DITL wherever a horizontal divider was needed. However, I can't seem to find a reference to it anywhere. Anyone care to post it? I'd appreciate the refresher. TIA, GLo +++++++++++++++++++++++++++ >From MacComCenter@airmail.net (Alec Carlson) Date: Sun, 02 Nov 1997 12:36:30 -0500 Organization: Smith Micro Software, Inc. In article <3gl21-3010971948160001@du114.n221.resnet.queensu.ca>, 3gl21@qlink.queensu.ca wrote: > Hey all, > > I seem to remember reading somewhere of a trick to create a small PICT > resource containing only the opcodes for a horizontal line (sometimes with > a pattern), and merely using that PICT in a DITL wherever a horizontal > divider was needed. However, I can't seem to find a reference to it > anywhere. > > Anyone care to post it? I'd appreciate the refresher. > Try this trick. Open ResEdit. Create a new cicn resource. Create a new PICT resource. Open the cicn resource, use the pencil to create a 4 pixel color rectangle in the upper left corner. Select all 4 pixels. Click to the PICT resource and Paste these into the PICT. You can now use the PICT resource in a dialog to define a line of that color in any thickness or length. Alec Carlson +++++++++++++++++++++++++++ >From smfr@santafe.edu (Simon Fraser) Date: Mon, 03 Nov 1997 09:14:46 +0000 Organization: Imperial College, London, UK In article <782F0DB6357844C1.769B15C9B1FBC423.C4966F11332AE6C2@library-proxy.airnews.net>, MacComCenter@airmail.net (Alec Carlson) wrote: > In article <3gl21-3010971948160001@du114.n221.resnet.queensu.ca>, > 3gl21@qlink.queensu.ca wrote: > > > I seem to remember reading somewhere of a trick to create a small PICT > > resource containing only the opcodes for a horizontal line (sometimes with > > a pattern), and merely using that PICT in a DITL wherever a horizontal > > divider was needed. However, I can't seem to find a reference to it > > anywhere. > > > > Anyone care to post it? I'd appreciate the refresher. > > > Try this trick. Open ResEdit. Create a new cicn resource. Create a new PICT > resource. Open the cicn resource, use the pencil to create a 4 pixel color > rectangle in the upper left corner. Select all 4 pixels. Click to the PICT > resource and Paste these into the PICT. You can now use the PICT resource > in a dialog to define a line of that color in any thickness or length. You don't even need to do this. There is such a PICT in the System file, with an ID of 11. This will give you a grey pattern in mono, and grey in colour dialogs. Just set the ID of the PICT item in the dialog to 11. Not sure if/where this is documented, but it's worked on all systems that I've tried. Simon --------------------------- >From Jessica Wirna Subject: Fast font and screen blitters... Date: Sat, 8 Nov 1997 05:46:09 -0700 Organization: AMUG Internet Services Hi all! I'm looking at what's taking up the most time in my game code, and it's basically two parts: Blitting the screen from my back-buffer directly onto the visible screen, and writing fonts onto the back-buffer. Does anyone know of a good tutorial or book/discussion on speeding up these two functions? I've already spent a fairly significant amount of time working on my screen blitter code, but since it only partly looks like *dest++ = *src++; I am guessing maybe there is more work I could put into it to speed it up a bit. Every ounce counts in this game, because it's got to scream! (haven't we all heard this requirement before.... :) My biggest problem is that it seems you can't just blindly copy the first 640*480 bytes of back-buffer into the screen memory of the current portmap, because (now here's where I might be fuzzy) the macintosh has set up a larger memory block than is visible on-screen in the portmap pixel block memory, and the non-visible portions are actually used to store information about the colormap/mouse cursor graphic/etc, so, if you blindly copy, you basically crash your mac. Maybe someone has some tips about how this can be safely optimized more! My font blitter is also a bit strange, I'm just doing memory copies from 16x16 tiles of letters/numbers onto my screen where the score and other text should appear. This unfortunately causes any section of the tile where the pixel values are black to overwrite what's beneath it in the back-buffer, so I'm looking at making a more sophisticated blitter that only writes pixel values that are non-black in the source pixel block. One possibility that seems easy is to track where the pixel runs 'start' and 'stop' on each horizontal line in the source pixel block and write a routine that does variable length pixel copies from the source block to the destination back-buffer, however, I've heard about things like 'compiled sprites/fonts' and I'm sure there are many things I haven't even heard of. Would anyone be willing to tutor me a little? :) Thanks, Jessica :) PS, If you could cc me in email with your response, I would be very grateful! I just got back to netnews and this newsgroup and realized I missed a lot of responses to my PPC asm question. :( My netnews isn't very reliable.... +++++++++++++++++++++++++++ >From "Matthew" Date: Sun, 09 Nov 1997 11:42:07 -0500 Organization: PANIX Public Access Internet and Unix, NYC Of course you should write your own sprite blitters, but - and Im sure youve heard this before - there is no good reason to not use copybits if you are just copying the whole back buffer to the screen. You risk not being compatable with every graphics card and future Mac OS versions (including Rhapsody). Copybits for large areas will be fine tuned for each machine and each processor and each graphic card. Sometimes there are obvious exceptions like if you are going to draw every other line or use pixel doubling or have some other special effect you are going for. At least have a checkbox in your prefs dialog letting the user turn on a 'more compatable' mode which uses Copybits. >> I'm looking at what's taking up the most time in my game code, and it's basically two parts: Blitting the screen from my back-buffer directly onto the visible screen, and writing fonts onto the back-buffer. Does anyone know of a good tutorial or book/discussion on speeding up these two functions? I've already spent a fairly significant amount of time working on my screen blitter code, but since it only partly looks like *dest++ = *src++; << Well make sure the pointers are double ptrs (for PPC only). Unroll your loop ie: for (count=0; count<50; count++) *dest++ = *src++; could become: for (count=0; count<10; count++) {*dest++ = *src++; *dest++ = *src++; *dest++ = *src++; *dest++ = *src++; *dest++ = *src++;} but dont unroll too much as to "blow your cache" - that is - your entire loop needs to fit it the processor's cache or else it will spend too much time looking at slower RAM. also if you are doing a sprite based game you usually dont need to draw to the entire screen - just the parts that changed. if you are doing a scrolling game there is a trick to make that run alot faster too (look at how SpriteWorld 2.0 or SAT 2.5 handles scrolling). It basically involves *not* redrawing the enitre back buffer each time and copying the screen in quarters - very clever stuff! >> My biggest problem is that it seems you can't just blindly copy the first 640*480 bytes of back-buffer into the screen memory of the current portmap, << correct >> My font blitter is also a bit strange, I'm just doing memory copies from 16x16 tiles of letters/numbers onto my screen where the score and other text should appear. This unfortunately causes any section of the tile where the pixel values are black to overwrite what's beneath it in the back-buffer, so I'm looking at making a more sophisticated blitter that only writes pixel values that are non-black in the source pixel block. One possibility that seems easy is to track where the pixel runs 'start' and 'stop' on each horizontal line in the source pixel block and write a routine that does variable length pixel copies from the source block to the destination back-buffer, however, I've heard about things like 'compiled sprites/fonts' and I'm sure there are many things I haven't even heard of. Would anyone be willing to tutor me a little? :) << I wouldnt want to dissuade someone from a DIY project - but why re-invest the wheel when you can put your energies into the work it will take to make your game unique. Check out Spriteworld and SAT and if either library can handle your graphic/sprite/blitter needs Id suggest using these well-tested free libraries and concentrate on just the specifics of your game. hope this helps, Matthew >> I missed a lot of responses to my PPC asm question. :( My netnews isn't << ok - here is what I wrote about your previous post: >>> Try < http://www.tau.it/lightsoft> which sells a ppc assembler called 'Fantasm' - you can download ppc example code from their site. also try writing C example code and then use your C development environment to *disassemble* it and see how it works (make sure to turn off all code optimizations or the disassembled code might be indecipherable) are you sure your project needs to be written in ppc assembler? <<< +++++++++++++++++++++++++++ >From "Lawson English" Date: 9 Nov 1997 16:47:00 -0700 Organization: Primenet Services for the Internet Matthew said: > > Well make sure the pointers are double ptrs (for PPC only). Unroll your > loop ie: > for (count=0; count<50; count++) > *dest++ = *src++; > Unrolling a loop like this past a certain point on a PowerPC may not give you much speed-gain due to the way the PowerPC accesses memory and schedules instructions. A tight loop may be better than large loop because a smaller instruction loop may actually fit completely within the on-chip instruction pipeline, thereby requiring NO access to memory for new instructions. Experiment. If you have access to a 604, try using the monitor registers to determine actual instructions-per-cycle and so on. Also, direct screen-writes are so slow compared to DRAM writes that it may be possible to include simple filters *within* the blitter without ANY loss of speed. You can do simple things like rotate by 90 degrees, for instance, and still have cycles leftover due to the latency of VRAM. You can also try to stagger writes to different addresses (this makes more sense with DRAM) so that the CPU can be doing more per cycle, rather than waiting for a chache-line to become available again. IE, instead of writing consecutive bytes (words/long-words) in a single stream, try writing several streams to different scan-lines or parts of the same scan-line within the same loop. Lots of possibilities here. As I said: PowerPC assembler is easy. OTOH, making *optimized* PowerPC assembly code can be difficult and you may find that your code isn't that much (if any) faster then the equivalent algorithm written in C. - ------------------------------------------------- For the next few weeks, as a show of support, use this sig ONLY. I use Cyberdog. - ------------------------------------------------- --------------------------- >From Jessica Wirna Subject: PPC assembler? Date: Mon, 3 Nov 1997 15:36:52 -0700 Organization: AMUG Internet Services I bought the IBM book on the powerPC series processors, and, while it does contain the complete instruction set and has some discussion on how things should be used and what registers need to be set for given operations, etc, etc, etc, it isn't really at my level because I am basically an absolute beginner. Does anyone know a good book/tutorial on assembler for the macintosh? Thanks, Jessica +++++++++++++++++++++++++++ >From Gregory_Norz@baylor.edu (Greg Norz) Date: Mon, 03 Nov 1997 23:13:30 -0500 Organization: Ambient Entertainment In article , Jessica Wirna wrote: > > I bought the IBM book on the powerPC series processors, and, while > it does contain the complete instruction set and has some discussion on > how things should be used and what registers need to be set for given > operations, etc, etc, etc, it isn't really at my level because I am > basically an absolute beginner. Does anyone know a good book/tutorial on > assembler for the macintosh? Hmm...a book on PPC assembler? There are a few good ones out there. Unfortunately, there aren't many that will give you help in learning. Most of the ones that I've seen are quite technical on the specs of the PPC processor. You may want to try 'PowerPC Numerics', an Inside Macintosh volume. Also, look on www.amazon.com and search for titles. There are some good ones there. I think that the Inside Macintosh book may be your best bet for a beginner, tho. greg norz +++++++++++++++++++++++++++ >From twr@po.cwru.edu (Tom Remotigue) Date: Tue, 04 Nov 1997 17:59:56 -0700 Organization: Case Western Reserve University > Hmm...a book on PPC assembler? There are a few good ones out there. > Unfortunately, there aren't many that will give you help in learning. Most > of the ones that I've seen are quite technical on the specs of the PPC > processor. You may want to try 'PowerPC Numerics', an Inside Macintosh > volume. Also, look on www.amazon.com and search for titles. There are some > good ones there. > > I think that the Inside Macintosh book may be your best bet for a beginner, tho. Also, don't limit yourself to just books on PPC assembly. If you can find a textbook from any microprocessors class, you might want to check it out. Assembly for any architecture is more or less the same idea (just watch out for big-endian vs. little-endian). Tom -- twr@po.cwru.edu Department of Electrical Engineering Case Western Reserve University +++++++++++++++++++++++++++ >From jbuttles@netheaven.com (Jared Buttles) Date: 5 Nov 1997 00:55:45 GMT Organization: (none) In article , Jessica Wirna wrote: > > I bought the IBM book on the powerPC series processors, and, while > it does contain the complete instruction set and has some discussion on > how things should be used and what registers need to be set for given > operations, etc, etc, etc, it isn't really at my level because I am > basically an absolute beginner. Does anyone know a good book/tutorial on > assembler for the macintosh? You might want to do some exploring at http://www.tau.it/lightsoft/fantasm/fant.html Also, I hear that the asm manual that comes with CodeWarrior is pretty complete, though I haven't looked at it. -- Jared Buttles: Christian, Mac user, programmer, furry, sailor jbuttles@netheaven.com "Saying Windows 95 is equal to Macintosh is like finding a potato that looks like Jesus and believing you've witnessed the second coming." - ---Guy Kawasaki Apple Fellow +++++++++++++++++++++++++++ >From "Lawson English" Date: 6 Nov 1997 12:46:01 -0700 Organization: Primenet Services for the Internet Tom Remotigue said: > > Also, don't limit yourself to just books on PPC assembly. If you can find > a textbook from any microprocessors class, you might want to check it out. > Assembly for any architecture is more or less the same idea (just watch > out for big-endian vs. little-endian). Also, don't forget to test your ASM implementation against your C/C++ version. PPC asm is easy to do, but a bitch to significantly optimize past what a decent PPC compiler is already capable of. You may find that you can't get the PPCAsm code to work *as fast* as the equivalent C code, letalone faster. Finally, the best place to find answers about PPC coding is comp.sys.powerpc.tech - ------------------------------------------------- For the next few weeks, as a show of support, use this sig ONLY. I use Cyberdog. - ------------------------------------------------- --------------------------- >From hirmes@panix.com (hirmes) Subject: Q: timing issues with Sound Manager Date: Tue, 21 Oct 1997 18:35:00 -0500 Organization: PANIX Public Access Internet and Unix, NYC i'm trying to write a simple sound sequencer. basically, i'd like to have several "tracks" that have a specific 'snd ' or AIFF sample associated with each track. the tracks would be divided into, say, 100 "frames" per second. the track data structure could be an array of Booleans(i.e. Boolean tracks[ MAX_TRACKS ][ MAX_LENGTH_IN_SECONDS * 100 ] ). a timing mechanism could check all the tracks every 1/100th of a second. if tracks[ currentTrack ][ currentTime ] was TRUE then the sound sample would begin to play. i guess what i'm basically describing is similar to a MIDI sequencer except that the sound samples are kept as resources or loaded from files, there's no pitch/frequency control, and everything is done via the Sound Manager. My questions are: is this possible using basic Extended Time Manager and Sound Manager calls? i.e. can Sound Manager calls such as SndPlay (used asynchronously) get called several times a second on several channels by the Time Manager? if so, does anyone have any sample Time Manager code that does this sort of rapid execution of functions? any better ideas about what kind of datastructures to use? etc.. oh, also assume this is PPC only. thanks, d. hirmes hirmes@pobox.com +++++++++++++++++++++++++++ >From hirmes@panix.com (hirmes) Date: Wed, 22 Oct 1997 11:12:38 -0500 Organization: PANIX Public Access Internet and Unix, NYC In article , nospam@nospam.net.com.edu (Darrin Cardani) wrote: > In article , > hirmes@panix.com (hirmes) wrote: > > > i'm trying to write a simple sound sequencer. > [...] > >i guess what i'm basically describing is similar to a MIDI > > sequencer except that the sound samples are kept as resources or loaded > > from files, there's no pitch/frequency control, and everything is done via > > the Sound Manager. > > You might want to check out an old issue of develop that had an article on > how to write a simple multi-track recorder. The code was called Cheap > Studio, and I think it can be found at www.devworld.com. They used to have > all the back issues of develop, and I would assume they still do. > > Darrin i guess i shouldn't have mentioned MIDI at all-- it seems to have confused the issue. the great thing about QuickTime MIDI support is that it's easy to use and doesn't require any additional hardware. the bad thing about QT MIDI support is that unless you have additional hardware, you're stuck with the standard MIDI library of sounds that comes with your system. if there was a way to create additional MIDI sound libraries from AIFF files, then i probably wouldn't need to write the program i described. basically, i want the _structure_ of a MIDI sequencer, but the ability to trigger actual AIFF or 'snd ' files instead of sounds from a the MIDI library... thanks anyway! d. hirmes +++++++++++++++++++++++++++ >From nospam@nospam.net.com.edu (Darrin Cardani) Date: Wed, 22 Oct 1997 09:12:44 -0500 Organization: Total Integration, Inc. In article , hirmes@panix.com (hirmes) wrote: > i'm trying to write a simple sound sequencer. [...] >i guess what i'm basically describing is similar to a MIDI > sequencer except that the sound samples are kept as resources or loaded > from files, there's no pitch/frequency control, and everything is done via > the Sound Manager. You might want to check out an old issue of develop that had an article on how to write a simple multi-track recorder. The code was called Cheap Studio, and I think it can be found at www.devworld.com. They used to have all the back issues of develop, and I would assume they still do. Darrin +++++++++++++++++++++++++++ >From jaeho@xs4all.nl (Jae Ho Chang) Date: Thu, 23 Oct 1997 00:41:03 +0200 Organization: XS4ALL, networking for the masses >is this possible using basic Extended Time Manager and Sound Manager >calls? i.e. can Sound Manager calls such as SndPlay (used asynchronously) >get called several times a second on several channels by the Time >Manager? It will cause a system error, because SndPlay() can't be called at interrupt time. I've never tried this, but the clue might be using SndDoImmediate() with Time Manager. Jae Ho Chang =) -- http://www.xs4all.nl/~jaeho Institute of Sonology Royal Conservatory, The Hague +++++++++++++++++++++++++++ >From Michel.Pollet@teaser.fr (Michel Pollet) Date: Thu, 6 Nov 1997 17:54:54 +0100 Organization: SAT/SAGEM hirmes wrote: > is this possible using basic Extended Time Manager and Sound Manager > calls? i.e. can Sound Manager calls such as SndPlay (used > asynchronously) get called several times a second on several channels by > the Time Manager? I think it would be much better to actually use the SndDblPlay, and use the interruption is gives to compute the time you want. You could then decide what to play. The SndDblTime interrupt is MUCH more precise than the Time Manager, who is reputed (and proven) to be of a resolution that is NOT to the millisecond :-) You could just compute from the frequency of the sound you wish to play the delay needed... and generate balck sample for the delays you need. For your SndPlay, you could use a SndPlay on your preloaded sounds with a command callback, generate a Pause Command as the first interrupt for each sound, and generate a resume sound command from your main SndDblBuffer sheduler. That would bypass the problem of the SndPlay & interrupts... -- Michel Pollet Macintosh developer & MkLinux hacker Email: michel@dcm.sat.fr Phone: +33 4 92 96 68 66 http://www.teaser.fr/~mpollet/ <-- Have a look at my guitars ! +++++++++++++++++++++++++++ >From Michel.Pollet@teaser.fr (Michel Pollet) Date: Mon, 10 Nov 1997 16:58:24 +0100 Organization: SAT/SAGEM hirmes wrote: > is this possible using basic Extended Time Manager and Sound Manager > calls? i.e. can Sound Manager calls such as SndPlay (used > asynchronously) get called several times a second on several channels by > the Time Manager? I think it would be much better to actually use the SndDblPlay, and use the interruption is gives to compute the time you want. You could then decide what to play. The SndDblTime interrupt is MUCH more precise than the Time Manager, who is reputed (and proven) to be of a resolution that is NOT to the millisecond :-) You could just compute from the frequency of the sound you wish to play the delay needed... and generate balck sample for the delays you need. For your SndPlay, you could use a SndPlay on your preloaded sounds with a command callback, generate a Pause Command as the first interrupt for each sound, and generate a resume sound command from your main SndDblBuffer sheduler. That would bypass the problem of the SndPlay & interrupts... -- Michel Pollet Macintosh developer & MkLinux hacker Email: michel@dcm.sat.fr Phone: +33 4 92 96 68 66 http://www.teaser.fr/~mpollet/ <-- Have a look at my guitars ! --------------------------- >From spam@dev.nul (Nate Wilson) Subject: Quickdraw fast with regions? Date: Sat, 25 Oct 1997 23:11:19 -0500 Organization: (none) Hello, I need some advice on Quickdraw and would appreciate your suggestions. I have a window that displays a grid, like a tic-tac-toe game, with text drawn in the squares. The grid never changes but the text in the squares does. Would it be faster to redraw the contents of the window by: a) Erasing the whole window portRect Redrawing the grid with a bunch of MoveTo() and LineTo()'s Redrawing the text with a bunch of MoveTo(), DrawSting()'s or b) Defining a complicated region of just the squares inside the grid (would only have to be done once when app launches) Erasing the region Redrawing the text with a bunch of MoveTo(), DrawSting()'s The second approach eliminates the unnecesary(sp) redrawing of the grid, but I imagine that it would take QD longer to erase a complicated, dis-contiguos region than a simple recangle. Any thoughts on the subject? Thanks, Nate +++++++++++++++++++++++++++ >From woody@alumni.caltech.edu (William Edward Woody) Date: Sat, 25 Oct 1997 23:19:39 -0700 Organization: In Phase Consulting spam@dev.nul (Nate Wilson) wrote: > The second approach eliminates the unnecesary(sp) redrawing > of the grid, but I imagine that it would take QD longer to erase > a complicated, dis-contiguos region than a simple recangle. > Any thoughts on the subject? Yes. There is real speed, and there is apparent (or perceived) speed. And while erasing a bunch of discontinuous regions in the fashion you suggest may be harder and slower for QuickDraw, I'll bet you it will feel a *lot* faster. The ultimate example of slow drawing which seems faster is code to draw the window off-screen and blow the bits on the screen when the drawing is done. This is used a lot with some CAD systems and other drawing tools, and while it is sometimes takes twice as long to draw the display, it feels a lot faster. - Bill -- William Edward Woody | In Phase Consulting woody@alumni.caltech.edu | Macintosh & Microsoft Windows http://www.alumni.caltech.edu/~woody | http://www.znd.net/inphase +++++++++++++++++++++++++++ >From dstone@BIT.chem.utoronto.ca (David Stone) Date: 27 Oct 1997 15:25:45 GMT Organization: University of Toronto Chemistry In article , woody@alumni.caltech.edu (William Edward Woody) wrote: > > spam@dev.nul (Nate Wilson) wrote: > > The second approach eliminates the unnecesary(sp) redrawing > > of the grid, but I imagine that it would take QD longer to erase > > a complicated, dis-contiguos region than a simple recangle. > > Any thoughts on the subject? [snip] > The ultimate example of slow drawing which seems faster is code > to draw the window off-screen and blow the bits on the screen > when the drawing is done. I think what he's trying to suggest is drawing the grid into an offscreen GWorld when your program starts up (anyway you like...) and then CopyBits it to the screen whenever you need a new game board. That way you only ever really _draw_ the board once; redraws will be much faster. David Stone (remove the obvious bit to reply...) +++++++++++++++++++++++++++ >From woody@alumni.caltech.edu (William Edward Woody) Date: Mon, 27 Oct 1997 10:30:56 -0800 Organization: In Phase Consulting In article , dstone@BIT.chem.utoronto.ca (David Stone) wrote: > In article , woody@alumni.caltech.edu > (William Edward Woody) wrote: > > > > spam@dev.nul (Nate Wilson) wrote: > > > The second approach eliminates the unnecesary(sp) redrawing > > > of the grid, but I imagine that it would take QD longer to erase > > > a complicated, dis-contiguos region than a simple recangle. > > > Any thoughts on the subject? > [snip] > > The ultimate example of slow drawing which seems faster is code > > to draw the window off-screen and blow the bits on the screen > > when the drawing is done. > > I think what he's trying to suggest is drawing the grid into an > offscreen GWorld when your program starts up (anyway you like...) > and then CopyBits it to the screen whenever you need a new game board. > That way you only ever really _draw_ the board once; redraws will be > much faster. Not quite; I was talking about drawing the entire game off-screen into an offscreen GWorld and using CopyBits to copy it on to the screen whenver you need to redraw the screen <> <> <