Re: [Audyssey] game objects in memory
Willem; Not quite true, unless I'm not understanding you properly… We're not actually talking about any angles being displayed to the user here but working with angles in the engine itself, and interpreting those angles either explicitly or relatively to show / affect the placement / orientation of game objects as well as some behind-the-scenes uses in game play for the user. I.e. aiming and such. So the user will most likely only ever be aware of the actual angle an entity is facing in context of a compass heading. This is purely for the comfort of the developer so we can more easily work with game code and not lose our bloody minds doing so!… lol! -Know what I mean?… It's a whole lot easier working with 30 degrees rather than 0.5235987756 radians, yes? lol! Have a totally awesome night and hope the holidays are treating you and yours wonderfully! -Thanks for the great notes keeping this way cool topic happening!… Smiles, Cara :) On Dec 12, 2010, at 8:24 PM, dwill...@gmail.com wrote: Yes, but the actual value doesn't matter as long as you stick to using one or the other method. Under normal surcomstances it wont be shown anyway and only the angles that are displayed need to be converted. -original message- Subject: Re: [Audyssey] game objects in memory From: Cara Quinn caraqu...@draconisentertainment.com Date: 13/12/2010 1:53 am Hi Willem, right you are! -For me though, holy crap! I wouldn't feel at all comfortable dealing in radians all the time. lol! I prefer to work in degrees and just convert back and forth on the fly. I basically have two methods I send pointers to; one to get an angle which returns in degrees, and the other to set an angle which takes degrees. I personally just don't naturally think in radians, but there ya go. Have a terrific day!… Smiles, Cara :) On Dec 12, 2010, at 9:28 AM, Willem Venter wrote: Hi Cara and all. Thanks for the discussion. Reading all this was very informative and helpfull. An observation I might make is that if you work only in radians, multiplying and dividing with the constant (pi/180) becomes redundent. This will save some small calculation and simplify the code. If you really want to see the normal degree form of the angle you could just use standard functions to convert it back for displaying. On 12/12/10, Thomas Ward thomasward1...@gmail.com wrote: Hi Cara, Got it. I apologize if I was a bit short with you a bit earlier. It is just the fact I've written and rewritten this engine code so many times I'm ready to scream. One of those cases wereI feel like I can't do anything write, and the worst part of it is I'm both college educated and have a programming degree. I shouldn't have this much grief over something like this. Although, to be fair to myself some of it wasn't my personal fault. For example, when I was looking at going cross-platform Travis highly recommended SFML for Linux, Mac, and Windows. So I checked out the API. On the surface it seamed exactly like what I needed, and abandoned my plans to use SDL 1.2.13 and went with SFML 1.6 instead. Next thing I know the game is causing massive crashes all over the place, and many users reported the almighty blue screen of death. Initially I thought it was something I did, my own mistakes, etc and so ran it through the Visual Studio debuggers. Much to my surprise after I did a step by step debug it comes up with an error found in sfml-window.dll. So I go and report it to the developer of the project ask him if they know about this bug and what could be done to resolve it etc. Basically, the guy knew about it, and doesn't kno how to fix the bug at this time. His recommendation, upgrade your Windows vidio drivers. This immediately became a tech support nightmare, and the reason I'm pulling SFML 1.6 completely out of beta 17 and going with my original plan of using SDL 1.2.13. At least it is stable and has no vidio driver problems I'm aware of. So at this point I've got the cross-platform engine ripped apart and I'm now in the process of redesigning all the low level subsystems like the window manager, input, audio, networking support, etc. What a bite in the butt! On the bright side I have rewritten the window subsystem and have basic keyboard support back in place with SDL and so far so good. I'm probably going to work on joystick and mouse support tomorrow and the window and input subsystems will be ready to go. As for audio I'm still not sure where to go with that. I'd like to use OpenAL, but I feel as though I'll have to rite some bit of middleware like a library that wraps OpenAL and can load ogg, mp3, wma files, etc which will be a very time consuming project. In the mean time FMOD would give me that and more which would at least get the engine up and running again for beta 17. So the basic point of what I was saying here is I've already got a long development cycle ahead with low level stuff. If there was a need
Re: [Audyssey] game objects in memory
Willem; Not quite true, unless I'm not understanding you properly… We're not actually talking about any angles being displayed to the user here but working with angles in the engine itself, and interpreting those angles either explicitly or relatively to show / affect the placement / orientation of game objects as well as some behind-the-scenes uses in game play for the user. I.e. aiming and such. So the user will most likely only ever be aware of the actual angle an entity is facing in context of a compass heading. This is purely for the comfort of the developer so we can more easily work with game code and not lose our bloody minds doing so!… lol! -Know what I mean?… It's a whole lot easier working with 30 degrees rather than 0.5235987756 radians, yes? lol! Have a totally awesome night and hope the holidays are treating you and yours wonderfully! -Thanks for the great notes keeping this way cool topic happening!… Smiles, Cara :) On Dec 12, 2010, at 8:24 PM, dwill...@gmail.com wrote: Yes, but the actual value doesn't matter as long as you stick to using one or the other method. Under normal surcomstances it wont be shown anyway and only the angles that are displayed need to be converted. -original message- Subject: Re: [Audyssey] game objects in memory From: Cara Quinn caraqu...@draconisentertainment.com Date: 13/12/2010 1:53 am Hi Willem, right you are! -For me though, holy crap! I wouldn't feel at all comfortable dealing in radians all the time. lol! I prefer to work in degrees and just convert back and forth on the fly. I basically have two methods I send pointers to; one to get an angle which returns in degrees, and the other to set an angle which takes degrees. I personally just don't naturally think in radians, but there ya go. Have a terrific day!… Smiles, Cara :) On Dec 12, 2010, at 9:28 AM, Willem Venter wrote: Hi Cara and all. Thanks for the discussion. Reading all this was very informative and helpfull. An observation I might make is that if you work only in radians, multiplying and dividing with the constant (pi/180) becomes redundent. This will save some small calculation and simplify the code. If you really want to see the normal degree form of the angle you could just use standard functions to convert it back for displaying. On 12/12/10, Thomas Ward thomasward1...@gmail.com wrote: Hi Cara, Got it. I apologize if I was a bit short with you a bit earlier. It is just the fact I've written and rewritten this engine code so many times I'm ready to scream. One of those cases wereI feel like I can't do anything write, and the worst part of it is I'm both college educated and have a programming degree. I shouldn't have this much grief over something like this. Although, to be fair to myself some of it wasn't my personal fault. For example, when I was looking at going cross-platform Travis highly recommended SFML for Linux, Mac, and Windows. So I checked out the API. On the surface it seamed exactly like what I needed, and abandoned my plans to use SDL 1.2.13 and went with SFML 1.6 instead. Next thing I know the game is causing massive crashes all over the place, and many users reported the almighty blue screen of death. Initially I thought it was something I did, my own mistakes, etc and so ran it through the Visual Studio debuggers. Much to my surprise after I did a step by step debug it comes up with an error found in sfml-window.dll. So I go and report it to the developer of the project ask him if they know about this bug and what could be done to resolve it etc. Basically, the guy knew about it, and doesn't kno how to fix the bug at this time. His recommendation, upgrade your Windows vidio drivers. This immediately became a tech support nightmare, and the reason I'm pulling SFML 1.6 completely out of beta 17 and going with my original plan of using SDL 1.2.13. At least it is stable and has no vidio driver problems I'm aware of. So at this point I've got the cross-platform engine ripped apart and I'm now in the process of redesigning all the low level subsystems like the window manager, input, audio, networking support, etc. What a bite in the butt! On the bright side I have rewritten the window subsystem and have basic keyboard support back in place with SDL and so far so good. I'm probably going to work on joystick and mouse support tomorrow and the window and input subsystems will be ready to go. As for audio I'm still not sure where to go with that. I'd like to use OpenAL, but I feel as though I'll have to rite some bit of middleware like a library that wraps OpenAL and can load ogg, mp3, wma files, etc which will be a very time consuming project. In the mean time FMOD would give me that and more which would at least get the engine up and running again for beta 17. So the basic point of what I was saying here is I've already got a long development cycle ahead with low level stuff. If there was a need
Re: [Audyssey] game objects in memory
I think there is too much cconverting back and forth. When debugging you can convert the angle before displaying, but besides that there is no need to have angles in degrees. The developer never really has to work with the radians. -original message- Subject: Re: [Audyssey] game objects in memory From: Cara Quinn caraqu...@draconisentertainment.com Date: 13/12/2010 10:10 am Willem; Not quite true, unless I'm not understanding you properly… We're not actually talking about any angles being displayed to the user here but working with angles in the engine itself, and interpreting those angles either explicitly or relatively to show / affect the placement / orientation of game objects as well as some behind-the-scenes uses in game play for the user. I.e. aiming and such. So the user will most likely only ever be aware of the actual angle an entity is facing in context of a compass heading. This is purely for the comfort of the developer so we can more easily work with game code and not lose our bloody minds doing so!… lol! -Know what I mean?… It's a whole lot easier working with 30 degrees rather than 0.5235987756 radians, yes? lol! Have a totally awesome night and hope the holidays are treating you and yours wonderfully! -Thanks for the great notes keeping this way cool topic happening!… Smiles, Cara :) On Dec 12, 2010, at 8:24 PM, dwill...@gmail.com wrote: Yes, but the actual value doesn't matter as long as you stick to using one or the other method. Under normal surcomstances it wont be shown anyway and only the angles that are displayed need to be converted. -original message- Subject: Re: [Audyssey] game objects in memory From: Cara Quinn caraqu...@draconisentertainment.com Date: 13/12/2010 1:53 am Hi Willem, right you are! -For me though, holy crap! I wouldn't feel at all comfortable dealing in radians all the time. lol! I prefer to work in degrees and just convert back and forth on the fly. I basically have two methods I send pointers to; one to get an angle which returns in degrees, and the other to set an angle which takes degrees. I personally just don't naturally think in radians, but there ya go. Have a terrific day!… Smiles, Cara :) On Dec 12, 2010, at 9:28 AM, Willem Venter wrote: Hi Cara and all. Thanks for the discussion. Reading all this was very informative and helpfull. An observation I might make is that if you work only in radians, multiplying and dividing with the constant (pi/180) becomes redundent. This will save some small calculation and simplify the code. If you really want to see the normal degree form of the angle you could just use standard functions to convert it back for displaying. On 12/12/10, Thomas Ward thomasward1...@gmail.com wrote: Hi Cara, Got it. I apologize if I was a bit short with you a bit earlier. It is just the fact I've written and rewritten this engine code so many times I'm ready to scream. One of those cases wereI feel like I can't do anything write, and the worst part of it is I'm both college educated and have a programming degree. I shouldn't have this much grief over something like this. Although, to be fair to myself some of it wasn't my personal fault. For example, when I was looking at going cross-platform Travis highly recommended SFML for Linux, Mac, and Windows. So I checked out the API. On the surface it seamed exactly like what I needed, and abandoned my plans to use SDL 1.2.13 and went with SFML 1.6 instead. Next thing I know the game is causing massive crashes all over the place, and many users reported the almighty blue screen of death. Initially I thought it was something I did, my own mistakes, etc and so ran it through the Visual Studio debuggers. Much to my surprise after I did a step by step debug it comes up with an error found in sfml-window.dll. So I go and report it to the developer of the project ask him if they know about this bug and what could be done to resolve it etc. Basically, the guy knew about it, and doesn't kno how to fix the bug at this time. His recommendation, upgrade your Windows vidio drivers. This immediately became a tech support nightmare, and the reason I'm pulling SFML 1.6 completely out of beta 17 and going with my original plan of using SDL 1.2.13. At least it is stable and has no vidio driver problems I'm aware of. So at this point I've got the cross-platform engine ripped apart and I'm now in the process of redesigning all the low level subsystems like the window manager, input, audio, networking support, etc. What a bite in the butt! On the bright side I have rewritten the window subsystem and have basic keyboard support back in place with SDL and so far so good. I'm probably going to work on joystick and mouse support tomorrow and the window and input subsystems will be ready to go. As for audio I'm still not sure where to go with that. I'd like to use OpenAL, but I feel as though I'll have to rite some bit of middleware
Re: [Audyssey] game objects in memory
Hi Willem; I guess I'm confused as to what you're saying here, so perhaps you can elaborate?… I need to work between the two modes constantly. In order to convert an angular measurement in degrees into a unit vector, and vice versa, I sure do need to use radians. If you know of another way to do this, then can you share?… And, as I said, in order to stay sane while working with the code for vectors associated with objects and their rotation in an engine, I definitely need to use angular measurements in degrees. So what am I missing here? Yes, there's a lot of converting going on, but without using radians, I know of no other way to move between an angle in degrees and it's associated unit vector. Thanks so much and do have a lovely day!… Smiles, CQ :) On Dec 13, 2010, at 12:28 AM, dwill...@gmail.com wrote: I think there is too much converting back and forth. When debugging you can convert the angle before displaying, but besides that there is no need to have angles in degrees. The developer never really has to work with the radians. -original message- Subject: Re: [Audyssey] game objects in memory From: Cara Quinn caraqu...@draconisentertainment.com Date: 13/12/2010 10:10 am Willem; Not quite true, unless I'm not understanding you properly… We're not actually talking about any angles being displayed to the user here but working with angles in the engine itself, and interpreting those angles either explicitly or relatively to show / affect the placement / orientation of game objects as well as some behind-the-scenes uses in game play for the user. I.e. aiming and such. So the user will most likely only ever be aware of the actual angle an entity is facing in context of a compass heading. This is purely for the comfort of the developer so we can more easily work with game code and not lose our bloody minds doing so!… lol! -Know what I mean?… It's a whole lot easier working with 30 degrees rather than 0.5235987756 radians, yes? lol! Have a totally awesome night and hope the holidays are treating you and yours wonderfully! -Thanks for the great notes keeping this way cool topic happening!… Smiles, Cara :) On Dec 12, 2010, at 8:24 PM, dwill...@gmail.com wrote: Yes, but the actual value doesn't matter as long as you stick to using one or the other method. Under normal surcomstances it wont be shown anyway and only the angles that are displayed need to be converted. -original message- Subject: Re: [Audyssey] game objects in memory From: Cara Quinn caraqu...@draconisentertainment.com Date: 13/12/2010 1:53 am Hi Willem, right you are! -For me though, holy crap! I wouldn't feel at all comfortable dealing in radians all the time. lol! I prefer to work in degrees and just convert back and forth on the fly. I basically have two methods I send pointers to; one to get an angle which returns in degrees, and the other to set an angle which takes degrees. I personally just don't naturally think in radians, but there ya go. Have a terrific day!… Smiles, Cara :) On Dec 12, 2010, at 9:28 AM, Willem Venter wrote: Hi Cara and all. Thanks for the discussion. Reading all this was very informative and helpfull. An observation I might make is that if you work only in radians, multiplying and dividing with the constant (pi/180) becomes redundent. This will save some small calculation and simplify the code. If you really want to see the normal degree form of the angle you could just use standard functions to convert it back for displaying. On 12/12/10, Thomas Ward thomasward1...@gmail.com wrote: Hi Cara, Got it. I apologize if I was a bit short with you a bit earlier. It is just the fact I've written and rewritten this engine code so many times I'm ready to scream. One of those cases wereI feel like I can't do anything write, and the worst part of it is I'm both college educated and have a programming degree. I shouldn't have this much grief over something like this. Although, to be fair to myself some of it wasn't my personal fault. For example, when I was looking at going cross-platform Travis highly recommended SFML for Linux, Mac, and Windows. So I checked out the API. On the surface it seamed exactly like what I needed, and abandoned my plans to use SDL 1.2.13 and went with SFML 1.6 instead. Next thing I know the game is causing massive crashes all over the place, and many users reported the almighty blue screen of death. Initially I thought it was something I did, my own mistakes, etc and so ran it through the Visual Studio debuggers. Much to my surprise after I did a step by step debug it comes up with an error found in sfml-window.dll. So I go and report it to the developer of the project ask him if they know about this bug and what could be done to resolve it etc. Basically, the guy knew about it, and doesn't kno how to fix the bug at this time. His recommendation, upgrade your Windows vidio drivers. This immediately became a tech support
Re: [Audyssey] game objects in memory
Hi Willem; I guess I'm confused as to what you're saying here, so perhaps you can elaborate?… I need to work between the two modes constantly. In order to convert an angular measurement in degrees into a unit vector, and vice versa, I sure do need to use radians. If you know of another way to do this, then can you share?… And, as I said, in order to stay sane while working with the code for vectors associated with objects and their rotation in an engine, I definitely need to use angular measurements in degrees. So what am I missing here? Yes, there's a lot of converting going on, but without using radians, I know of no other way to move between an angle in degrees and it's associated unit vector. Thanks so much and do have a lovely day!… Smiles, CQ :) On Dec 13, 2010, at 12:28 AM, dwill...@gmail.com wrote: I think there is too much converting back and forth. When debugging you can convert the angle before displaying, but besides that there is no need to have angles in degrees. The developer never really has to work with the radians. -original message- Subject: Re: [Audyssey] game objects in memory From: Cara Quinn caraqu...@draconisentertainment.com Date: 13/12/2010 10:10 am Willem; Not quite true, unless I'm not understanding you properly… We're not actually talking about any angles being displayed to the user here but working with angles in the engine itself, and interpreting those angles either explicitly or relatively to show / affect the placement / orientation of game objects as well as some behind-the-scenes uses in game play for the user. I.e. aiming and such. So the user will most likely only ever be aware of the actual angle an entity is facing in context of a compass heading. This is purely for the comfort of the developer so we can more easily work with game code and not lose our bloody minds doing so!… lol! -Know what I mean?… It's a whole lot easier working with 30 degrees rather than 0.5235987756 radians, yes? lol! Have a totally awesome night and hope the holidays are treating you and yours wonderfully! -Thanks for the great notes keeping this way cool topic happening!… Smiles, Cara :) On Dec 12, 2010, at 8:24 PM, dwill...@gmail.com wrote: Yes, but the actual value doesn't matter as long as you stick to using one or the other method. Under normal surcomstances it wont be shown anyway and only the angles that are displayed need to be converted. -original message- Subject: Re: [Audyssey] game objects in memory From: Cara Quinn caraqu...@draconisentertainment.com Date: 13/12/2010 1:53 am Hi Willem, right you are! -For me though, holy crap! I wouldn't feel at all comfortable dealing in radians all the time. lol! I prefer to work in degrees and just convert back and forth on the fly. I basically have two methods I send pointers to; one to get an angle which returns in degrees, and the other to set an angle which takes degrees. I personally just don't naturally think in radians, but there ya go. Have a terrific day!… Smiles, Cara :) On Dec 12, 2010, at 9:28 AM, Willem Venter wrote: Hi Cara and all. Thanks for the discussion. Reading all this was very informative and helpfull. An observation I might make is that if you work only in radians, multiplying and dividing with the constant (pi/180) becomes redundent. This will save some small calculation and simplify the code. If you really want to see the normal degree form of the angle you could just use standard functions to convert it back for displaying. On 12/12/10, Thomas Ward thomasward1...@gmail.com wrote: Hi Cara, Got it. I apologize if I was a bit short with you a bit earlier. It is just the fact I've written and rewritten this engine code so many times I'm ready to scream. One of those cases wereI feel like I can't do anything write, and the worst part of it is I'm both college educated and have a programming degree. I shouldn't have this much grief over something like this. Although, to be fair to myself some of it wasn't my personal fault. For example, when I was looking at going cross-platform Travis highly recommended SFML for Linux, Mac, and Windows. So I checked out the API. On the surface it seamed exactly like what I needed, and abandoned my plans to use SDL 1.2.13 and went with SFML 1.6 instead. Next thing I know the game is causing massive crashes all over the place, and many users reported the almighty blue screen of death. Initially I thought it was something I did, my own mistakes, etc and so ran it through the Visual Studio debuggers. Much to my surprise after I did a step by step debug it comes up with an error found in sfml-window.dll. So I go and report it to the developer of the project ask him if they know about this bug and what could be done to resolve it etc. Basically, the guy knew about it, and doesn't kno how to fix the bug at this time. His recommendation, upgrade your Windows vidio drivers. This immediately became a tech support
Re: [Audyssey] game objects in memory
Hi Cara, Got it. I apologize if I was a bit short with you a bit earlier. It is just the fact I've written and rewritten this engine code so many times I'm ready to scream. One of those cases wereI feel like I can't do anything write, and the worst part of it is I'm both college educated and have a programming degree. I shouldn't have this much grief over something like this. Although, to be fair to myself some of it wasn't my personal fault. For example, when I was looking at going cross-platform Travis highly recommended SFML for Linux, Mac, and Windows. So I checked out the API. On the surface it seamed exactly like what I needed, and abandoned my plans to use SDL 1.2.13 and went with SFML 1.6 instead. Next thing I know the game is causing massive crashes all over the place, and many users reported the almighty blue screen of death. Initially I thought it was something I did, my own mistakes, etc and so ran it through the Visual Studio debuggers. Much to my surprise after I did a step by step debug it comes up with an error found in sfml-window.dll. So I go and report it to the developer of the project ask him if they know about this bug and what could be done to resolve it etc. Basically, the guy knew about it, and doesn't kno how to fix the bug at this time. His recommendation, upgrade your Windows vidio drivers. This immediately became a tech support nightmare, and the reason I'm pulling SFML 1.6 completely out of beta 17 and going with my original plan of using SDL 1.2.13. At least it is stable and has no vidio driver problems I'm aware of. So at this point I've got the cross-platform engine ripped apart and I'm now in the process of redesigning all the low level subsystems like the window manager, input, audio, networking support, etc. What a bite in the butt! On the bright side I have rewritten the window subsystem and have basic keyboard support back in place with SDL and so far so good. I'm probably going to work on joystick and mouse support tomorrow and the window and input subsystems will be ready to go. As for audio I'm still not sure where to go with that. I'd like to use OpenAL, but I feel as though I'll have to rite some bit of middleware like a library that wraps OpenAL and can load ogg, mp3, wma files, etc which will be a very time consuming project. In the mean time FMOD would give me that and more which would at least get the engine up and running again for beta 17. So the basic point of what I was saying here is I've already got a long development cycle ahead with low level stuff. If there was a need to change more things to do proper collision detection now would be the time to do it, but I don't want to add more time to the development cycle than absolutely necessary. Smile. On 12/12/10, Cara Quinn caraqu...@draconisentertainment.com wrote: Hi thomas; Just one last note for the evening. when I switched your z to y, it was for clarity's sake for the email. I'd assumed you would adapt the new code with your current orientation as I'd made other changes as you'd asked. The formulae are right but I was using x and y to show what I was doing in a standard way. -Only for clarity in my note. :) So sorry I obviously didn't make that clear enough. There's no reason, even in a worst case scenario that you should ever need to rewrite that much code for changes like these. I'll need to check back in with DX, but last I checked, you could essentially flip your world around any way you wanted it simply by changing two coordinates. -And, as I'd just mentioned, even if you change back y to z as I thought you would, the other changes I made will give you proper calculations. -but at the end of the day, if your engine is already essentially doing what you need then why change it at all? -this was, afterall, just a lil' experiment, yes? -I'm sure not asking you to change your style. :) I'm just personally working in one of the paradigms we were chatting about and having success with it. -But this is your baby after all. -If I can make suggestions that help, then great! If not, then don't use them. Yes? :) Anyway, Talk witcha on the 'morrow and have a terrific night!… Smiles, Cara :) --- Gamers mailing list __ Gamers@audyssey.org If you want to leave the list, send E-mail to gamers-unsubscr...@audyssey.org. You can make changes or update your subscription via the web, at http://audyssey.org/mailman/listinfo/gamers_audyssey.org. All messages are archived and can be searched and read at http://www.mail-archive.com/gamers@audyssey.org. If you have any questions or concerns regarding the management of the list, please send E-mail to gamers-ow...@audyssey.org.
Re: [Audyssey] game objects in memory
Hi Cara and all. Thanks for the discussion. Reading all this was very informative and helpfull. An observation I might make is that if you work only in radians, multiplying and dividing with the constant (pi/180) becomes redundent. This will save some small calculation and simplify the code. If you really want to see the normal degree form of the angle you could just use standard functions to convert it back for displaying. On 12/12/10, Thomas Ward thomasward1...@gmail.com wrote: Hi Cara, Got it. I apologize if I was a bit short with you a bit earlier. It is just the fact I've written and rewritten this engine code so many times I'm ready to scream. One of those cases wereI feel like I can't do anything write, and the worst part of it is I'm both college educated and have a programming degree. I shouldn't have this much grief over something like this. Although, to be fair to myself some of it wasn't my personal fault. For example, when I was looking at going cross-platform Travis highly recommended SFML for Linux, Mac, and Windows. So I checked out the API. On the surface it seamed exactly like what I needed, and abandoned my plans to use SDL 1.2.13 and went with SFML 1.6 instead. Next thing I know the game is causing massive crashes all over the place, and many users reported the almighty blue screen of death. Initially I thought it was something I did, my own mistakes, etc and so ran it through the Visual Studio debuggers. Much to my surprise after I did a step by step debug it comes up with an error found in sfml-window.dll. So I go and report it to the developer of the project ask him if they know about this bug and what could be done to resolve it etc. Basically, the guy knew about it, and doesn't kno how to fix the bug at this time. His recommendation, upgrade your Windows vidio drivers. This immediately became a tech support nightmare, and the reason I'm pulling SFML 1.6 completely out of beta 17 and going with my original plan of using SDL 1.2.13. At least it is stable and has no vidio driver problems I'm aware of. So at this point I've got the cross-platform engine ripped apart and I'm now in the process of redesigning all the low level subsystems like the window manager, input, audio, networking support, etc. What a bite in the butt! On the bright side I have rewritten the window subsystem and have basic keyboard support back in place with SDL and so far so good. I'm probably going to work on joystick and mouse support tomorrow and the window and input subsystems will be ready to go. As for audio I'm still not sure where to go with that. I'd like to use OpenAL, but I feel as though I'll have to rite some bit of middleware like a library that wraps OpenAL and can load ogg, mp3, wma files, etc which will be a very time consuming project. In the mean time FMOD would give me that and more which would at least get the engine up and running again for beta 17. So the basic point of what I was saying here is I've already got a long development cycle ahead with low level stuff. If there was a need to change more things to do proper collision detection now would be the time to do it, but I don't want to add more time to the development cycle than absolutely necessary. Smile. On 12/12/10, Cara Quinn caraqu...@draconisentertainment.com wrote: Hi thomas; Just one last note for the evening. when I switched your z to y, it was for clarity's sake for the email. I'd assumed you would adapt the new code with your current orientation as I'd made other changes as you'd asked. The formulae are right but I was using x and y to show what I was doing in a standard way. -Only for clarity in my note. :) So sorry I obviously didn't make that clear enough. There's no reason, even in a worst case scenario that you should ever need to rewrite that much code for changes like these. I'll need to check back in with DX, but last I checked, you could essentially flip your world around any way you wanted it simply by changing two coordinates. -And, as I'd just mentioned, even if you change back y to z as I thought you would, the other changes I made will give you proper calculations. -but at the end of the day, if your engine is already essentially doing what you need then why change it at all? -this was, afterall, just a lil' experiment, yes? -I'm sure not asking you to change your style. :) I'm just personally working in one of the paradigms we were chatting about and having success with it. -But this is your baby after all. -If I can make suggestions that help, then great! If not, then don't use them. Yes? :) Anyway, Talk witcha on the 'morrow and have a terrific night!… Smiles, Cara :) --- Gamers mailing list __ Gamers@audyssey.org If you want to leave the list, send E-mail to gamers-unsubscr...@audyssey.org. You can make changes or update your subscription via the web, at
Re: [Audyssey] game objects in memory
Hi Willem, Yeah, I know, but the engine is already written the way it is. I really don't want to rewrite anything I don't have to. This is a classic case of if it ain't broke don't try to fix it. The game mechanics, such as they are, do work and are both stable and reliable. On 12/12/10, Willem Venter dwill...@gmail.com wrote: Hi Cara and all. Thanks for the discussion. Reading all this was very informative and helpfull. An observation I might make is that if you work only in radians, multiplying and dividing with the constant (pi/180) becomes redundent. This will save some small calculation and simplify the code. If you really want to see the normal degree form of the angle you could just use standard functions to convert it back for displaying. --- Gamers mailing list __ Gamers@audyssey.org If you want to leave the list, send E-mail to gamers-unsubscr...@audyssey.org. You can make changes or update your subscription via the web, at http://audyssey.org/mailman/listinfo/gamers_audyssey.org. All messages are archived and can be searched and read at http://www.mail-archive.com/gamers@audyssey.org. If you have any questions or concerns regarding the management of the list, please send E-mail to gamers-ow...@audyssey.org.
Re: [Audyssey] game objects in memory
Hey thomas, thanks so much for your apology and no worries! I sure understand the feeling of stuff not working right! -I'm sure we all do. -It's sure not you though, I think sometimes, coding paradigms and getting libraries to play nice and such are just too fr**king needlessly complex at times! :) -Just my thoughts, of course… anyway, if you decide to try those methods again, just keep the part where the subtractions are done in the same order and the parts where I took out the +=. Those simple changes might give you what you want. those should work regardless of which axes you have in whatever directions you want. -Let me know how it goes, K?… Anyway, I'm sorry things have been such a blasted pain for ya. It definitely sounds frustrating. I wish you / yours a lovely and relaxing evening!… Smiles, Cara :) On Dec 12, 2010, at 12:43 AM, Thomas Ward wrote: Hi Cara, Got it. I apologize if I was a bit short with you a bit earlier. It is just the fact I've written and rewritten this engine code so many times I'm ready to scream. One of those cases wereI feel like I can't do anything write, and the worst part of it is I'm both college educated and have a programming degree. I shouldn't have this much grief over something like this. Although, to be fair to myself some of it wasn't my personal fault. For example, when I was looking at going cross-platform Travis highly recommended SFML for Linux, Mac, and Windows. So I checked out the API. On the surface it seamed exactly like what I needed, and abandoned my plans to use SDL 1.2.13 and went with SFML 1.6 instead. Next thing I know the game is causing massive crashes all over the place, and many users reported the almighty blue screen of death. Initially I thought it was something I did, my own mistakes, etc and so ran it through the Visual Studio debuggers. Much to my surprise after I did a step by step debug it comes up with an error found in sfml-window.dll. So I go and report it to the developer of the project ask him if they know about this bug and what could be done to resolve it etc. Basically, the guy knew about it, and doesn't kno how to fix the bug at this time. His recommendation, upgrade your Windows vidio drivers. This immediately became a tech support nightmare, and the reason I'm pulling SFML 1.6 completely out of beta 17 and going with my original plan of using SDL 1.2.13. At least it is stable and has no vidio driver problems I'm aware of. So at this point I've got the cross-platform engine ripped apart and I'm now in the process of redesigning all the low level subsystems like the window manager, input, audio, networking support, etc. What a bite in the butt! On the bright side I have rewritten the window subsystem and have basic keyboard support back in place with SDL and so far so good. I'm probably going to work on joystick and mouse support tomorrow and the window and input subsystems will be ready to go. As for audio I'm still not sure where to go with that. I'd like to use OpenAL, but I feel as though I'll have to rite some bit of middleware like a library that wraps OpenAL and can load ogg, mp3, wma files, etc which will be a very time consuming project. In the mean time FMOD would give me that and more which would at least get the engine up and running again for beta 17. So the basic point of what I was saying here is I've already got a long development cycle ahead with low level stuff. If there was a need to change more things to do proper collision detection now would be the time to do it, but I don't want to add more time to the development cycle than absolutely necessary. Smile. On 12/12/10, Cara Quinn caraqu...@draconisentertainment.com wrote: Hi thomas; Just one last note for the evening. when I switched your z to y, it was for clarity's sake for the email. I'd assumed you would adapt the new code with your current orientation as I'd made other changes as you'd asked. The formulae are right but I was using x and y to show what I was doing in a standard way. -Only for clarity in my note. :) So sorry I obviously didn't make that clear enough. There's no reason, even in a worst case scenario that you should ever need to rewrite that much code for changes like these. I'll need to check back in with DX, but last I checked, you could essentially flip your world around any way you wanted it simply by changing two coordinates. -And, as I'd just mentioned, even if you change back y to z as I thought you would, the other changes I made will give you proper calculations. -but at the end of the day, if your engine is already essentially doing what you need then why change it at all? -this was, afterall, just a lil' experiment, yes? -I'm sure not asking you to change your style. :) I'm just personally working in one of the paradigms we were chatting about and having success with it. -But this is your baby after all. -If I can make suggestions that help, then great! If not, then don't use them.
Re: [Audyssey] game objects in memory
Hi Willem, right you are! -For me though, holy crap! I wouldn't feel at all comfortable dealing in radians all the time. lol! I prefer to work in degrees and just convert back and forth on the fly. I basically have two methods I send pointers to; one to get an angle which returns in degrees, and the other to set an angle which takes degrees. I personally just don't naturally think in radians, but there ya go. Have a terrific day!… Smiles, Cara :) On Dec 12, 2010, at 9:28 AM, Willem Venter wrote: Hi Cara and all. Thanks for the discussion. Reading all this was very informative and helpfull. An observation I might make is that if you work only in radians, multiplying and dividing with the constant (pi/180) becomes redundent. This will save some small calculation and simplify the code. If you really want to see the normal degree form of the angle you could just use standard functions to convert it back for displaying. On 12/12/10, Thomas Ward thomasward1...@gmail.com wrote: Hi Cara, Got it. I apologize if I was a bit short with you a bit earlier. It is just the fact I've written and rewritten this engine code so many times I'm ready to scream. One of those cases wereI feel like I can't do anything write, and the worst part of it is I'm both college educated and have a programming degree. I shouldn't have this much grief over something like this. Although, to be fair to myself some of it wasn't my personal fault. For example, when I was looking at going cross-platform Travis highly recommended SFML for Linux, Mac, and Windows. So I checked out the API. On the surface it seamed exactly like what I needed, and abandoned my plans to use SDL 1.2.13 and went with SFML 1.6 instead. Next thing I know the game is causing massive crashes all over the place, and many users reported the almighty blue screen of death. Initially I thought it was something I did, my own mistakes, etc and so ran it through the Visual Studio debuggers. Much to my surprise after I did a step by step debug it comes up with an error found in sfml-window.dll. So I go and report it to the developer of the project ask him if they know about this bug and what could be done to resolve it etc. Basically, the guy knew about it, and doesn't kno how to fix the bug at this time. His recommendation, upgrade your Windows vidio drivers. This immediately became a tech support nightmare, and the reason I'm pulling SFML 1.6 completely out of beta 17 and going with my original plan of using SDL 1.2.13. At least it is stable and has no vidio driver problems I'm aware of. So at this point I've got the cross-platform engine ripped apart and I'm now in the process of redesigning all the low level subsystems like the window manager, input, audio, networking support, etc. What a bite in the butt! On the bright side I have rewritten the window subsystem and have basic keyboard support back in place with SDL and so far so good. I'm probably going to work on joystick and mouse support tomorrow and the window and input subsystems will be ready to go. As for audio I'm still not sure where to go with that. I'd like to use OpenAL, but I feel as though I'll have to rite some bit of middleware like a library that wraps OpenAL and can load ogg, mp3, wma files, etc which will be a very time consuming project. In the mean time FMOD would give me that and more which would at least get the engine up and running again for beta 17. So the basic point of what I was saying here is I've already got a long development cycle ahead with low level stuff. If there was a need to change more things to do proper collision detection now would be the time to do it, but I don't want to add more time to the development cycle than absolutely necessary. Smile. On 12/12/10, Cara Quinn caraqu...@draconisentertainment.com wrote: Hi thomas; Just one last note for the evening. when I switched your z to y, it was for clarity's sake for the email. I'd assumed you would adapt the new code with your current orientation as I'd made other changes as you'd asked. The formulae are right but I was using x and y to show what I was doing in a standard way. -Only for clarity in my note. :) So sorry I obviously didn't make that clear enough. There's no reason, even in a worst case scenario that you should ever need to rewrite that much code for changes like these. I'll need to check back in with DX, but last I checked, you could essentially flip your world around any way you wanted it simply by changing two coordinates. -And, as I'd just mentioned, even if you change back y to z as I thought you would, the other changes I made will give you proper calculations. -but at the end of the day, if your engine is already essentially doing what you need then why change it at all? -this was, afterall, just a lil' experiment, yes? -I'm sure not asking you to change your style. :) I'm just personally working in one of the
Re: [Audyssey] game objects in memory
Hi Cara, That makes two of us. I don't think in radians either. I have a few calculation functions in the engine that actually returns a degree either absolute or relative based on what I need the direction for. If it is a trajectory/targeting solution I'll use relative since obviously I need to know the direction the player character is facing as well as the actual position of the target. Doing that using radians would be, well, i don't want to think about it. Lol! Cheers! On 12/12/10, Cara Quinn caraqu...@draconisentertainment.com wrote: Hi Willem, right you are! -For me though, holy crap! I wouldn't feel at all comfortable dealing in radians all the time. lol! I prefer to work in degrees and just convert back and forth on the fly. I basically have two methods I send pointers to; one to get an angle which returns in degrees, and the other to set an angle which takes degrees. I personally just don't naturally think in radians, but there ya go. Have a terrific day!… Smiles, Cara :) --- Gamers mailing list __ Gamers@audyssey.org If you want to leave the list, send E-mail to gamers-unsubscr...@audyssey.org. You can make changes or update your subscription via the web, at http://audyssey.org/mailman/listinfo/gamers_audyssey.org. All messages are archived and can be searched and read at http://www.mail-archive.com/gamers@audyssey.org. If you have any questions or concerns regarding the management of the list, please send E-mail to gamers-ow...@audyssey.org.
Re: [Audyssey] game objects in memory
HI Cara, Thanks for understanding. For me I have felt like the perverbial dog chasing his own tail. Trying this API, trying that one, and trying to make it do exactly what I want is a serious pain in the butt. Of course, the principle problem is trying to design high quality ccross-platform software that actually does run cross-platform. If I wanted to write games just for Windows that would be a piece of cake. Just slap together an engine using DirectInput, DirectSound, and Direct3D, Sapi 5, and away I go. Not that simple if we try to consider designing the same game for Mac OS and Linux too. SDL is a fairly decent API, all things considered, but is noway the equal of DirectX. Which can get a developer into trouble when Windows gamers start requesting features not supported by SDL, or that don't exactly work as they expect it too. For example, right now I'm working on the SDL input system for G3D. As you know SDL uses an event driven input system. This is fine for most games, but I do notice there are things that don't exactly work the way they would with DirectInput. You can't walk and pick up a gun or something at the same time. I personally don't care, but a few Windows gamers really complained that they could do that with DirectInput but not with SFML or SDL. It is like how exactly do you address a complaint like that when the API just doesn't work the same as what they are expecting? Smile. On 12/12/10, Cara Quinn caraqu...@draconisentertainment.com wrote: Hey thomas, thanks so much for your apology and no worries! I sure understand the feeling of stuff not working right! -I'm sure we all do. -It's sure not you though, I think sometimes, coding paradigms and getting libraries to play nice and such are just too fr**king needlessly complex at times! :) -Just my thoughts, of course… anyway, if you decide to try those methods again, just keep the part where the subtractions are done in the same order and the parts where I took out the +=. Those simple changes might give you what you want. those should work regardless of which axes you have in whatever directions you want. -Let me know how it goes, K?… Anyway, I'm sorry things have been such a blasted pain for ya. It definitely sounds frustrating. I wish you / yours a lovely and relaxing evening!… Smiles, Cara :) --- Gamers mailing list __ Gamers@audyssey.org If you want to leave the list, send E-mail to gamers-unsubscr...@audyssey.org. You can make changes or update your subscription via the web, at http://audyssey.org/mailman/listinfo/gamers_audyssey.org. All messages are archived and can be searched and read at http://www.mail-archive.com/gamers@audyssey.org. If you have any questions or concerns regarding the management of the list, please send E-mail to gamers-ow...@audyssey.org.
Re: [Audyssey] game objects in memory
Yes, but the actual value doesnt matter as long as you stick to using one or the other method. Under normal surcomstances it wont be shown anyway and only the angles that are displayed need to be converted. -original message- Subject: Re: [Audyssey] game objects in memory From: Cara Quinn caraqu...@draconisentertainment.com Date: 13/12/2010 1:53 am Hi Willem, right you are! -For me though, holy crap! I wouldn't feel at all comfortable dealing in radians all the time. lol! I prefer to work in degrees and just convert back and forth on the fly. I basically have two methods I send pointers to; one to get an angle which returns in degrees, and the other to set an angle which takes degrees. I personally just don't naturally think in radians, but there ya go. Have a terrific day!… Smiles, Cara :) On Dec 12, 2010, at 9:28 AM, Willem Venter wrote: Hi Cara and all. Thanks for the discussion. Reading all this was very informative and helpfull. An observation I might make is that if you work only in radians, multiplying and dividing with the constant (pi/180) becomes redundent. This will save some small calculation and simplify the code. If you really want to see the normal degree form of the angle you could just use standard functions to convert it back for displaying. On 12/12/10, Thomas Ward thomasward1...@gmail.com wrote: Hi Cara, Got it. I apologize if I was a bit short with you a bit earlier. It is just the fact I've written and rewritten this engine code so many times I'm ready to scream. One of those cases wereI feel like I can't do anything write, and the worst part of it is I'm both college educated and have a programming degree. I shouldn't have this much grief over something like this. Although, to be fair to myself some of it wasn't my personal fault. For example, when I was looking at going cross-platform Travis highly recommended SFML for Linux, Mac, and Windows. So I checked out the API. On the surface it seamed exactly like what I needed, and abandoned my plans to use SDL 1.2.13 and went with SFML 1.6 instead. Next thing I know the game is causing massive crashes all over the place, and many users reported the almighty blue screen of death. Initially I thought it was something I did, my own mistakes, etc and so ran it through the Visual Studio debuggers. Much to my surprise after I did a step by step debug it comes up with an error found in sfml-window.dll. So I go and report it to the developer of the project ask him if they know about this bug and what could be done to resolve it etc. Basically, the guy knew about it, and doesn't kno how to fix the bug at this time. His recommendation, upgrade your Windows vidio drivers. This immediately became a tech support nightmare, and the reason I'm pulling SFML 1.6 completely out of beta 17 and going with my original plan of using SDL 1.2.13. At least it is stable and has no vidio driver problems I'm aware of. So at this point I've got the cross-platform engine ripped apart and I'm now in the process of redesigning all the low level subsystems like the window manager, input, audio, networking support, etc. What a bite in the butt! On the bright side I have rewritten the window subsystem and have basic keyboard support back in place with SDL and so far so good. I'm probably going to work on joystick and mouse support tomorrow and the window and input subsystems will be ready to go. As for audio I'm still not sure where to go with that. I'd like to use OpenAL, but I feel as though I'll have to rite some bit of middleware like a library that wraps OpenAL and can load ogg, mp3, wma files, etc which will be a very time consuming project. In the mean time FMOD would give me that and more which would at least get the engine up and running again for beta 17. So the basic point of what I was saying here is I've already got a long development cycle ahead with low level stuff. If there was a need to change more things to do proper collision detection now would be the time to do it, but I don't want to add more time to the development cycle than absolutely necessary. Smile. On 12/12/10, Cara Quinn caraqu...@draconisentertainment.com wrote: Hi thomas; Just one last note for the evening. when I switched your z to y, it was for clarity's sake for the email. I'd assumed you would adapt the new code with your current orientation as I'd made other changes as you'd asked. The formulae are right but I was using x and y to show what I was doing in a standard way. -Only for clarity in my note. :) So sorry I obviously didn't make that clear enough. There's no reason, even in a worst case scenario that you should ever need to rewrite that much code for changes like these. I'll need to check back in with DX, but last I checked, you could essentially flip your world around any way you wanted it simply by changing two coordinates. -And, as I'd just mentioned, even if you change
Re: [Audyssey] game objects in memory
Hi Thomas;
I'll comment and adapt your code below.
These methods should all return normal vectors anyway, so you shouldn't need to
normalize. I just did a few tweaks as that's all they seem to need. changed z
to y for consistency. Let me know how it goes, K?…
Smiles,
Cara :)
On Dec 9, 2010, at 7:22 PM, Thomas Ward wrote:
Hi Cara,
Sure no problem. below is the functions I'm using to calculate the
angle and vector Mara will travel to reach her next coordinates on the
map. However, before you ask the reason the calculations don't have a
fps or time parameter that's because I assume 1 as the frames per
second which is a slow frame rate I know. Here goes.
// Name: GetDirection (double, double, double, double).
// Description: Calculates the angle between
// two game objects.
// CQ
// will switch your z to y so i can think straight :)
float Calculate::GetDirection (double x1, double y1, double x2, double y2)
{
// CQ
// changing this so both subtractions are in the same order
// as this changes the result
// Subtract x1 from x2
double x = x2 - x1;
// Subtract y1 from y2
double y = y2 - y1;
// CQ
// this should be y over x
// Calculate theta by the arc tangent
// of -y/x
double theta = std::atan2 (y,x);
// Now, multiply theta by 180
// and divide by PI
double direction = (theta * 180) / PI;
// Return the direction
return (float)direction;
}
// Name: GetX(double, double, double).
// Description: Calculates the next possible x component.
float Calculate::GetX (double direction, double x, double velocity)
{
// Calculate the next x component by
// multiplying velocity by the cosine of
// direction*PI/180
// CQ
// switched this to cos and changed calculation slightly
x = velocity * std::cos ((direction * PI) / 180));
// Return the new x component
return (float)x;
}
// Name: GetY(double, double, double).
// Description: Calculates the next possible y component.
float Calculate::GetY (double direction, double y, double velocity)
{
// Calculate the next y component by
// multiplying velocity by the sine of
// direction*PI/180
y = velocity * std::sin ((direction * PI) / 180);
// Return the new y component
return (float)y;
}
---
Gamers mailing list __ Gamers@audyssey.org
If you want to leave the list, send E-mail to gamers-unsubscr...@audyssey.org.
You can make changes or update your subscription via the web, at
http://audyssey.org/mailman/listinfo/gamers_audyssey.org.
All messages are archived and can be searched and read at
http://www.mail-archive.com/gam...@audyssey.org.
If you have any questions or concerns regarding the management of the list,
please send E-mail to gamers-ow...@audyssey.org.
Re: [Audyssey] game objects in memory
Hi again Thomas;
-A couple of things I forgot to mention in my last note. Firstly, before you
send x or y to your getX or getY methods, the vector should already be
normalized. I overlooked this before as I was only looking at what your methods
were returning.
You can normalize your current vector of travel by doing the following:
• subtract the start and end points of your vector, as in: x2 - x1, y2 - y1,
and z2 - z1.
• get the length (len) of the vector by first getting the square root of x^2 +
y^2 + z^2.
• and then divide the vector by the length as in: x = x / len, y = y / len, and
z = z / len.
• this is your new normalized vector, which you can then magnify (multiply) by
a desired move rate or some such number to get a proper end point.
HTH!
Cara :)
Hi Thomas;
I'll comment and adapt your code below.
These methods should all return normal vectors anyway, so you shouldn't need to
normalize. I just did a few tweaks as that's all they seem to need. changed z
to y for consistency. Let me know how it goes, K?…
Smiles,
Cara :)
On Dec 9, 2010, at 7:22 PM, Thomas Ward wrote:
Hi Cara,
Sure no problem. below is the functions I'm using to calculate the
angle and vector Mara will travel to reach her next coordinates on the
map. However, before you ask the reason the calculations don't have a
fps or time parameter that's because I assume 1 as the frames per
second which is a slow frame rate I know. Here goes.
// Name: GetDirection (double, double, double, double).
// Description: Calculates the angle between
// two game objects.
// CQ
// will switch your z to y so i can think straight :)
float Calculate::GetDirection (double x1, double y1, double x2, double y2)
{
// CQ
// changing this so both subtractions are in the same order
// as this changes the result
// Subtract x1 from x2
double x = x2 - x1;
// Subtract y1 from y2
double y = y2 - y1;
// CQ
// this should be y over x
// Calculate theta by the arc tangent
// of -y/x
double theta = std::atan2 (y,x);
// Now, multiply theta by 180
// and divide by PI
double direction = (theta * 180) / PI;
// Return the direction
return (float)direction;
}
// Name: GetX(double, double, double).
// Description: Calculates the next possible x component.
float Calculate::GetX (double direction, double x, double velocity)
{
// Calculate the next x component by
// multiplying velocity by the cosine of
// direction*PI/180
// CQ
// switched this to cos and changed calculation slightly
x = velocity * std::cos ((direction * PI) / 180));
// Return the new x component
return (float)x;
}
// Name: GetY(double, double, double).
// Description: Calculates the next possible y component.
float Calculate::GetY (double direction, double y, double velocity)
{
// Calculate the next y component by
// multiplying velocity by the sine of
// direction*PI/180
y = velocity * std::sin ((direction * PI) / 180);
// Return the new y component
return (float)y;
}
---
Gamers mailing list __ Gamers@audyssey.org
If you want to leave the list, send E-mail to gamers-unsubscr...@audyssey.org.
You can make changes or update your subscription via the web, at
http://audyssey.org/mailman/listinfo/gamers_audyssey.org.
All messages are archived and can be searched and read at
http://www.mail-archive.com/gam...@audyssey.org.
If you have any questions or concerns regarding the management of the list,
please send E-mail to gamers-ow...@audyssey.org.
Re: [Audyssey] game objects in memory
ACk! I just noticed that there is an instance of 'direction' in the getY
method. This should be velocity. -eek! NOt sure how that got in there, but
there ya go! :)
-Good thing I reread these! lol!
Smiles,
Cara :)
On Dec 11, 2010, at 10:22 AM, Cara Quinn wrote:
Hi Thomas;
I'll comment and adapt your code below.
These methods should all return normal vectors anyway, so you shouldn't need to
normalize. I just did a few tweaks as that's all they seem to need. changed z
to y for consistency. Let me know how it goes, K?…
Smiles,
Cara :)
On Dec 9, 2010, at 7:22 PM, Thomas Ward wrote:
Hi Cara,
Sure no problem. below is the functions I'm using to calculate the
angle and vector Mara will travel to reach her next coordinates on the
map. However, before you ask the reason the calculations don't have a
fps or time parameter that's because I assume 1 as the frames per
second which is a slow frame rate I know. Here goes.
// Name: GetDirection (double, double, double, double).
// Description: Calculates the angle between
// two game objects.
// CQ
// will switch your z to y so i can think straight :)
float Calculate::GetDirection (double x1, double y1, double x2, double y2)
{
// CQ
// changing this so both subtractions are in the same order
// as this changes the result
// Subtract x1 from x2
double x = x2 - x1;
// Subtract y1 from y2
double y = y2 - y1;
// CQ
// this should be y over x
// Calculate theta by the arc tangent
// of -y/x
double theta = std::atan2 (y,x);
// Now, multiply theta by 180
// and divide by PI
double direction = (theta * 180) / PI;
// Return the direction
return (float)direction;
}
// Name: GetX(double, double, double).
// Description: Calculates the next possible x component.
float Calculate::GetX (double direction, double x, double velocity)
{
// Calculate the next x component by
// multiplying velocity by the cosine of
// direction*PI/180
// CQ
// switched this to cos and changed calculation slightly
x = velocity * std::cos ((direction * PI) / 180));
// Return the new x component
return (float)x;
}
// Name: GetY(double, double, double).
// Description: Calculates the next possible y component.
float Calculate::GetY (double direction, double y, double velocity)
{
// Calculate the next y component by
// multiplying velocity by the sine of
// direction*PI/180
y = velocity * std::sin ((direction * PI) / 180);
// Return the new y component
return (float)y;
}
---
Gamers mailing list __ Gamers@audyssey.org
If you want to leave the list, send E-mail to gamers-unsubscr...@audyssey.org.
You can make changes or update your subscription via the web, at
http://audyssey.org/mailman/listinfo/gamers_audyssey.org.
All messages are archived and can be searched and read at
http://www.mail-archive.com/gam...@audyssey.org.
If you have any questions or concerns regarding the management of the list,
please send E-mail to gamers-ow...@audyssey.org.
---
Gamers mailing list __ Gamers@audyssey.org
If you want to leave the list, send E-mail to gamers-unsubscr...@audyssey.org.
You can make changes or update your subscription via the web, at
http://audyssey.org/mailman/listinfo/gamers_audyssey.org.
All messages are archived and can be searched and read at
http://www.mail-archive.com/gam...@audyssey.org.
If you have any questions or concerns regarding the management of the list,
please send E-mail to gamers-ow...@audyssey.org.
Re: [Audyssey] game objects in memory
Thomas;
I have a question for you. By removing the + in the getX and getY functions, I
may have taken out a feature you wanted. Were you just wanting to calculate the
new vector or actually change Mara's position with the two functions? If you
simply want to calculate the new movement vector, then the changes I made are
what you want. If you're wanting to also apply the new vector to Mara's current
coordinates, then the += are what you want. Sorry if I misinterpreted. :)
The reversal of sine and cosine is still correct though, but I wanted to make
sure I know what you're after and what code you're using for what. :)
I personally split up my code into less complex functions and combine them
rather than placing a lot of steps in one method. For example, I have one
method to simply get the angle the player is facing and another method to set
the angle. So naturally, these really basic functions get called in other
methods in the course of doing more complex calculations.
Depending on what you want to do, you may not want to normalize as in my second
note. Normalizing is good if you need to keep a particular vector but change
its length. I.E. change velocity on a game object.
This brings up an interesting point, in that a vector is not a point. The
player's position in space can be represented by a point, but their movement
can be represented with a vector. A vector is in essence, a point's movement in
a direction over time. the confusion can come because you can represent a
vector as it's end point. So it's not always easy to tell what someone's code
is meant to do in this regard. -Know what I mean?… If you project a vector on
to a point, then you end up with the same vector but another end point. If you
project a vector on to another vector, you have a third vector. -Confused yet?…
lol!
Anyway, hope the changes to the code work well.
As a note, my use of X and Y is meant with a positive Z in the up direction.
Smiles,
Cara :)
On Dec 11, 2010, at 10:23 AM, Cara Quinn wrote:
Hi again Thomas;
-A couple of things I forgot to mention in my last note. Firstly, before you
send x or y to your getX or getY methods, the vector should already be
normalized. I overlooked this before as I was only looking at what your methods
were returning.
You can normalize your current vector of travel by doing the following:
• subtract the start and end points of your vector, as in: x2 - x1, y2 - y1,
and z2 - z1.
• get the length (len) of the vector by first getting the square root of x^2 +
y^2 + z^2.
• and then divide the vector by the length as in: x = x / len, y = y / len, and
z = z / len.
• this is your new normalized vector, which you can then magnify (multiply) by
a desired move rate or some such number to get a proper end point.
HTH!
Cara :)
Hi Thomas;
I'll comment and adapt your code below.
These methods should all return normal vectors anyway, so you shouldn't need to
normalize. I just did a few tweaks as that's all they seem to need. changed z
to y for consistency. Let me know how it goes, K?…
Smiles,
Cara :)
On Dec 9, 2010, at 7:22 PM, Thomas Ward wrote:
Hi Cara,
Sure no problem. below is the functions I'm using to calculate the
angle and vector Mara will travel to reach her next coordinates on the
map. However, before you ask the reason the calculations don't have a
fps or time parameter that's because I assume 1 as the frames per
second which is a slow frame rate I know. Here goes.
// Name: GetDirection (double, double, double, double).
// Description: Calculates the angle between
// two game objects.
// CQ
// will switch your z to y so i can think straight :)
float Calculate::GetDirection (double x1, double y1, double x2, double y2)
{
// CQ
// changing this so both subtractions are in the same order
// as this changes the result
// Subtract x1 from x2
double x = x2 - x1;
// Subtract y1 from y2
double y = y2 - y1;
// CQ
// this should be y over x
// Calculate theta by the arc tangent
// of -y/x
double theta = std::atan2 (y,x);
// Now, multiply theta by 180
// and divide by PI
double direction = (theta * 180) / PI;
// Return the direction
return (float)direction;
}
// Name: GetX(double, double, double).
// Description: Calculates the next possible x component.
float Calculate::GetX (double direction, double x, double velocity)
{
// Calculate the next x component by
// multiplying velocity by the cosine of
// direction*PI/180
// CQ
// switched this to cos and changed calculation slightly
x = velocity * std::cos ((direction * PI) / 180));
// Return the new x component
return (float)x;
}
// Name: GetY(double, double, double).
// Description: Calculates the next possible y component.
float Calculate::GetY (double direction, double y, double velocity)
{
// Calculate the next y component by
// multiplying velocity by the sine of
// direction*PI/180
y = velocity * std::sin ((direction * PI) / 180);
// Return the new y component
return (float)y;
}
---
Re: [Audyssey] game objects in memory
Hi Cara, The GetX() and GetZ() functions simply calculates the vector for any and all game objects moving in the game world. It doesn't actually move any of them. They have their own functions to actually move them. They juste use the functions to calculate the new vector. As for reversing sine and cosine in this instants would totally break the engine. The reason is I use 0 as do north, 90, as east, 180 as south, and 270 degrees as west. Yes, I know this is totally not standard, but there is a reason I do it that way rather than having 0 as do east etc. Are you aware of the bearing system? Basically, if you ever were to plot a course using a ship 000 would be do north, 090 would be do east, 180 do south, and 270 do west. It is a system I've always liked and feel most comfortable with so wrote my engine to orient using 000 as do north. If I switch that sine and cosine as you suggest orienting 000 as do east, which is what I think will happen here, everything and anything will immediately blow up. We are talking rewriting the enemy A.I. system, rewriting the walk/jump/run commands, rewriting the targeting system, speak direction functions, etc. Basically, I might as well trash the current engine and start over from scratch. As you can see I'm not exactly enthused of reversing the sine and cosine in this case unless you have a pretty convincing argument why I must do so other than it is the accepted/standard way of doing things. Smile. On 12/11/10, Cara Quinn caraqu...@draconisentertainment.com wrote: Thomas; I have a question for you. By removing the + in the getX and getY functions, I may have taken out a feature you wanted. Were you just wanting to calculate the new vector or actually change Mara's position with the two functions? If you simply want to calculate the new movement vector, then the changes I made are what you want. If you're wanting to also apply the new vector to Mara's current coordinates, then the += are what you want. Sorry if I misinterpreted. :) The reversal of sine and cosine is still correct though, but I wanted to make sure I know what you're after and what code you're using for what. :) I personally split up my code into less complex functions and combine them rather than placing a lot of steps in one method. For example, I have one method to simply get the angle the player is facing and another method to set the angle. So naturally, these really basic functions get called in other methods in the course of doing more complex calculations. Depending on what you want to do, you may not want to normalize as in my second note. Normalizing is good if you need to keep a particular vector but change its length. I.E. change velocity on a game object. This brings up an interesting point, in that a vector is not a point. The player's position in space can be represented by a point, but their movement can be represented with a vector. A vector is in essence, a point's movement in a direction over time. the confusion can come because you can represent a vector as it's end point. So it's not always easy to tell what someone's code is meant to do in this regard. -Know what I mean?… If you project a vector on to a point, then you end up with the same vector but another end point. If you project a vector on to another vector, you have a third vector. -Confused yet?… lol! Anyway, hope the changes to the code work well. As a note, my use of X and Y is meant with a positive Z in the up direction. Smiles, Cara :) --- Gamers mailing list __ Gamers@audyssey.org If you want to leave the list, send E-mail to gamers-unsubscr...@audyssey.org. You can make changes or update your subscription via the web, at http://audyssey.org/mailman/listinfo/gamers_audyssey.org. All messages are archived and can be searched and read at http://www.mail-archive.com/gamers@audyssey.org. If you have any questions or concerns regarding the management of the list, please send E-mail to gamers-ow...@audyssey.org.
Re: [Audyssey] game objects in memory
HI Cara, Hmmm...Doesn't look too bad. I should be able to add the necesssary code to the Calculation module of the engine so it normalizes vectors before handing off that info to the object requesting a new end point. Cheers! On 12/11/10, Cara Quinn caraqu...@draconisentertainment.com wrote: Hi again Thomas; -A couple of things I forgot to mention in my last note. Firstly, before you send x or y to your getX or getY methods, the vector should already be normalized. I overlooked this before as I was only looking at what your methods were returning. You can normalize your current vector of travel by doing the following: • subtract the start and end points of your vector, as in: x2 - x1, y2 - y1, and z2 - z1. • get the length (len) of the vector by first getting the square root of x^2 + y^2 + z^2. • and then divide the vector by the length as in: x = x / len, y = y / len, and z = z / len. • this is your new normalized vector, which you can then magnify (multiply) by a desired move rate or some such number to get a proper end point. HTH! Cara :) --- Gamers mailing list __ Gamers@audyssey.org If you want to leave the list, send E-mail to gamers-unsubscr...@audyssey.org. You can make changes or update your subscription via the web, at http://audyssey.org/mailman/listinfo/gamers_audyssey.org. All messages are archived and can be searched and read at http://www.mail-archive.com/gamers@audyssey.org. If you have any questions or concerns regarding the management of the list, please send E-mail to gamers-ow...@audyssey.org.
Re: [Audyssey] game objects in memory
HI Cara, Why did you change z to y? As I under stand it x runs east/west, z runs north/south, and y is up/down. This is how DirectX operates and principle why I wwrote my engine the way I did. If I am going to pass a vector to DirectX's buffer3d object I have to provide the coordinates as x east/west, y up/down, and z as north/south. Any other way would absolutely hose the engine big time. Yeah, I could change to have say z as up/down and y as north/south, but were talking one massive rewrite to do it. As MOTA is nearly done practically rewriting the engine and game right now would be suicide. I tried out the code changes you suggested and it made a huge mess of things. The G3D engine no longer works properly at all. The GetDirection() function no longer returns the proper angle to the object/target. Instead of returning 0 degrees, do north,it returns some other value. I'm sorry to say this, I know you are trying to help, but applying those changes has massively messed up the operation of the engine. Everything, and I do mean everything, is broken. Nothing works right, and in order to resolve the problem I'm going to have to rewrite several hundred lines of code in the engine and in games like MOTA to implement these suggestions. So the big question is how necessary are these changes in reality? Is it worth it, my time and energy, spending six weeks or so rewriting the engine from the ground up to make these changes making 0 do east, or whatever your code does, and switching z and y around? Is there any real compelling reason to do it your way over the methodology I'm already using besides the fact my code apparently is non-standard? Thanks. On 12/11/10, Cara Quinn caraqu...@draconisentertainment.com wrote: Hi Thomas; I'll comment and adapt your code below. These methods should all return normal vectors anyway, so you shouldn't need to normalize. I just did a few tweaks as that's all they seem to need. changed z to y for consistency. Let me know how it goes, K?… Smiles, Cara :) --- Gamers mailing list __ Gamers@audyssey.org If you want to leave the list, send E-mail to gamers-unsubscr...@audyssey.org. You can make changes or update your subscription via the web, at http://audyssey.org/mailman/listinfo/gamers_audyssey.org. All messages are archived and can be searched and read at http://www.mail-archive.com/gamers@audyssey.org. If you have any questions or concerns regarding the management of the list, please send E-mail to gamers-ow...@audyssey.org.
Re: [Audyssey] game objects in memory
Hi thomas; Just one last note for the evening. when I switched your z to y, it was for clarity's sake for the email. I'd assumed you would adapt the new code with your current orientation as I'd made other changes as you'd asked. The formulae are right but I was using x and y to show what I was doing in a standard way. -Only for clarity in my note. :) So sorry I obviously didn't make that clear enough. There's no reason, even in a worst case scenario that you should ever need to rewrite that much code for changes like these. I'll need to check back in with DX, but last I checked, you could essentially flip your world around any way you wanted it simply by changing two coordinates. -And, as I'd just mentioned, even if you change back y to z as I thought you would, the other changes I made will give you proper calculations. -but at the end of the day, if your engine is already essentially doing what you need then why change it at all? -this was, afterall, just a lil' experiment, yes? -I'm sure not asking you to change your style. :) I'm just personally working in one of the paradigms we were chatting about and having success with it. -But this is your baby after all. -If I can make suggestions that help, then great! If not, then don't use them. Yes? :) Anyway, Talk witcha on the 'morrow and have a terrific night!… Smiles, Cara :) On Dec 11, 2010, at 8:28 PM, Thomas Ward wrote: HI Cara, Why did you change z to y? As I under stand it x runs east/west, z runs north/south, and y is up/down. This is how DirectX operates and principle why I wrote my engine the way I did. If I am going to pass a vector to DirectX's buffer3d object I have to provide the coordinates as x east/west, y up/down, and z as north/south. Any other way would absolutely hose the engine big time. Yeah, I could change to have say z as up/down and y as north/south, but were talking one massive rewrite to do it. As MOTA is nearly done practically rewriting the engine and game right now would be suicide. I tried out the code changes you suggested and it made a huge mess of things. The G3D engine no longer works properly at all. The GetDirection() function no longer returns the proper angle to the object/target. Instead of returning 0 degrees, do north,it returns some other value. I'm sorry to say this, I know you are trying to help, but applying those changes has massively messed up the operation of the engine. Everything, and I do mean everything, is broken. Nothing works right, and in order to resolve the problem I'm going to have to rewrite several hundred lines of code in the engine and in games like MOTA to implement these suggestions. So the big question is how necessary are these changes in reality? Is it worth it, my time and energy, spending six weeks or so rewriting the engine from the ground up to make these changes making 0 do east, or whatever your code does, and switching z and y around? Is there any real compelling reason to do it your way over the methodology I'm already using besides the fact my code apparently is non-standard? Thanks. On 12/11/10, Cara Quinn caraqu...@draconisentertainment.com wrote: Hi Thomas; I'll comment and adapt your code below. These methods should all return normal vectors anyway, so you shouldn't need to normalize. I just did a few tweaks as that's all they seem to need. changed z to y for consistency. Let me know how it goes, K?… Smiles, Cara :) --- Gamers mailing list __ Gamers@audyssey.org If you want to leave the list, send E-mail to gamers-unsubscr...@audyssey.org. You can make changes or update your subscription via the web, at http://audyssey.org/mailman/listinfo/gamers_audyssey.org. All messages are archived and can be searched and read at http://www.mail-archive.com/gamers@audyssey.org. If you have any questions or concerns regarding the management of the list, please send E-mail to gamers-ow...@audyssey.org. --- Gamers mailing list __ Gamers@audyssey.org If you want to leave the list, send E-mail to gamers-unsubscr...@audyssey.org. You can make changes or update your subscription via the web, at http://audyssey.org/mailman/listinfo/gamers_audyssey.org. All messages are archived and can be searched and read at http://www.mail-archive.com/gamers@audyssey.org. If you have any questions or concerns regarding the management of the list, please send E-mail to gamers-ow...@audyssey.org.
Re: [Audyssey] game objects in memory
Hi Cara, No problem. Looking forward to it. Also if you can please respond to my off list message with the technical questions regarding Mac vs Windows programming languages and APIs. Thanks. On 12/10/10, Cara Quinn caraqu...@draconisentertainment.com wrote: Thomas; Thanks for sending this along and am happy to rewrite / send along some code. :) -Will check back in on the 'morrow witcha! -I'm a sleepy girl now!… Smiles, Cara :) --- Gamers mailing list __ Gamers@audyssey.org If you want to leave the list, send E-mail to gamers-unsubscr...@audyssey.org. You can make changes or update your subscription via the web, at http://audyssey.org/mailman/listinfo/gamers_audyssey.org. All messages are archived and can be searched and read at http://www.mail-archive.com/gam...@audyssey.org. If you have any questions or concerns regarding the management of the list, please send E-mail to gamers-ow...@audyssey.org.
Re: [Audyssey] game objects in memory
HI Thomas since you said that Mara passes through walls sometimes when you're at just the right angle, I'm betting that: 1. your walls are very close to the same thickness to Mara's move rate. (the distance she usually moves in a frame) 2. that it's easier or more likely that she will walk through a wall the closer you get to walking at a 45 degree angle in regard to your X and Y axes. If the above is true, then I think I know the solution, as in my last note about normalizing and magnifying. If you want to post your code, I'd sure be up for taking a look at it, and I can post mine here as well, if you'd like. -Perhaps peeps might like to see this in practice so to speak?… -Just as a quick explanation in 2D, if you have a vector that's 5 units long and goes straight along the X axis as in 5.0, 0.0 and you try to create a vector five units long on a forty five degree angle simply by defining it as 5.0, 5.0 you're actually making a vector which is longer than five units. I.E. since you're essentially mapping curves with a square coordinate system, you're actually covering more distance on a diagonal then on one of the axes. If you could turn your 5.0, 5.0 vector so it traveled straight along your X axis, you'd find that it actually went well beyond 5.0, 0.0. If you think of squares on a piece of graph paper; if you draw a line along the edge of a square, and then draw a line from one corner of the square to the other, and then measure the line, you'd see that the corner to corner line is longer than the other one. This is what's happening inside the computer. We're just working with graph paper on a very large scale! :) so there are a couple of processes we can do to properly measure the vector so that it's always the same length regardless of which direction it's traveling in. Does this make sense? There's no need to calculate in advance of where any entity will be at any given time. This is the work of the detection routine to let you know what gets touched where, rather than you needing to try to guess it ahead of time. Use small game units, and real rates of travel, realistically sized entities and features, and the detection routines should work fine. Smiles, Cara :) On Dec 8, 2010, at 7:01 PM, Thomas Ward wrote: Hi Cara, I'm just basically using a trig based formula for calculating the next possible x/y/z vectors. As far as I know the formula is correct, and it does work fine with the array based collision detection I have now. It is just when I try to calculate a 3d coordinate and see if items touch where it breaks down. On 12/8/10, Cara Quinn caraqu...@draconisentertainment.com wrote: Ah, Thomas, just reread your note and something else springs to mind. HOw are you doing your calculations for your movement? Remember to use Pythagorus so you get the correct values when dealing with diagonal motion. I.E. Always normalize and then magnify your movement vectors so you always get the proper amount of motion in any direction you move. -Make sense?… HTH! Smiles, Cara :) --- Gamers mailing list __ Gamers@audyssey.org If you want to leave the list, send E-mail to gamers-unsubscr...@audyssey.org. You can make changes or update your subscription via the web, at http://audyssey.org/mailman/listinfo/gamers_audyssey.org. All messages are archived and can be searched and read at http://www.mail-archive.com/gam...@audyssey.org. If you have any questions or concerns regarding the management of the list, please send E-mail to gamers-ow...@audyssey.org. --- Gamers mailing list __ Gamers@audyssey.org If you want to leave the list, send E-mail to gamers-unsubscr...@audyssey.org. You can make changes or update your subscription via the web, at http://audyssey.org/mailman/listinfo/gamers_audyssey.org. All messages are archived and can be searched and read at http://www.mail-archive.com/gam...@audyssey.org. If you have any questions or concerns regarding the management of the list, please send E-mail to gamers-ow...@audyssey.org.
Re: [Audyssey] game objects in memory
Oh, and there was a 3, and I bet: 3. that your storm troopers don't actually move on diagonals! lol! this would explain why they don't happily skip right through the map. :) Talk soon!… Smiles, Cara :) On Dec 9, 2010, at 10:08 AM, Cara Quinn wrote: HI Thomas since you said that Mara passes through walls sometimes when you're at just the right angle, I'm betting that: 1. your walls are very close to the same thickness to Mara's move rate. (the distance she usually moves in a frame) 2. that it's easier or more likely that she will walk through a wall the closer you get to walking at a 45 degree angle in regard to your X and Y axes. If the above is true, then I think I know the solution, as in my last note about normalizing and magnifying. If you want to post your code, I'd sure be up for taking a look at it, and I can post mine here as well, if you'd like. -Perhaps peeps might like to see this in practice so to speak?… -Just as a quick explanation in 2D, if you have a vector that's 5 units long and goes straight along the X axis as in 5.0, 0.0 and you try to create a vector five units long on a forty five degree angle simply by defining it as 5.0, 5.0 you're actually making a vector which is longer than five units. I.E. since you're essentially mapping curves with a square coordinate system, you're actually covering more distance on a diagonal then on one of the axes. If you could turn your 5.0, 5.0 vector so it traveled straight along your X axis, you'd find that it actually went well beyond 5.0, 0.0. If you think of squares on a piece of graph paper; if you draw a line along the edge of a square, and then draw a line from one corner of the square to the other, and then measure the line, you'd see that the corner to corner line is longer than the other one. This is what's happening inside the computer. We're just working with graph paper on a very large scale! :) so there are a couple of processes we can do to properly measure the vector so that it's always the same length regardless of which direction it's traveling in. Does this make sense? There's no need to calculate in advance of where any entity will be at any given time. This is the work of the detection routine to let you know what gets touched where, rather than you needing to try to guess it ahead of time. Use small game units, and real rates of travel, realistically sized entities and features, and the detection routines should work fine. Smiles, Cara :) On Dec 8, 2010, at 7:01 PM, Thomas Ward wrote: Hi Cara, I'm just basically using a trig based formula for calculating the next possible x/y/z vectors. As far as I know the formula is correct, and it does work fine with the array based collision detection I have now. It is just when I try to calculate a 3d coordinate and see if items touch where it breaks down. On 12/8/10, Cara Quinn caraqu...@draconisentertainment.com wrote: Ah, Thomas, just reread your note and something else springs to mind. HOw are you doing your calculations for your movement? Remember to use Pythagorus so you get the correct values when dealing with diagonal motion. I.E. Always normalize and then magnify your movement vectors so you always get the proper amount of motion in any direction you move. -Make sense?… HTH! Smiles, Cara :) --- Gamers mailing list __ Gamers@audyssey.org If you want to leave the list, send E-mail to gamers-unsubscr...@audyssey.org. You can make changes or update your subscription via the web, at http://audyssey.org/mailman/listinfo/gamers_audyssey.org. All messages are archived and can be searched and read at http://www.mail-archive.com/gam...@audyssey.org. If you have any questions or concerns regarding the management of the list, please send E-mail to gamers-ow...@audyssey.org. --- Gamers mailing list __ Gamers@audyssey.org If you want to leave the list, send E-mail to gamers-unsubscr...@audyssey.org. You can make changes or update your subscription via the web, at http://audyssey.org/mailman/listinfo/gamers_audyssey.org. All messages are archived and can be searched and read at http://www.mail-archive.com/gam...@audyssey.org. If you have any questions or concerns regarding the management of the list, please send E-mail to gamers-ow...@audyssey.org. --- Gamers mailing list __ Gamers@audyssey.org If you want to leave the list, send E-mail to gamers-unsubscr...@audyssey.org. You can make changes or update your subscription via the web, at http://audyssey.org/mailman/listinfo/gamers_audyssey.org. All messages are archived and can be searched and read at http://www.mail-archive.com/gam...@audyssey.org. If you have any questions or concerns regarding the management of the list, please send E-mail to gamers-ow...@audyssey.org.
Re: [Audyssey] game objects in memory
Hi cara Ever thought of updating jediquake? -Original Message- From: gamers-boun...@audyssey.org [mailto:gamers-boun...@audyssey.org] On Behalf Of Cara Quinn Sent: 09 December 2010 18:24 To: Gamers Discussion list Subject: Re: [Audyssey] game objects in memory Oh, and there was a 3, and I bet: 3. that your storm troopers don't actually move on diagonals! lol! this would explain why they don't happily skip right through the map. :) Talk soon!. Smiles, Cara :) On Dec 9, 2010, at 10:08 AM, Cara Quinn wrote: HI Thomas since you said that Mara passes through walls sometimes when you're at just the right angle, I'm betting that: 1. your walls are very close to the same thickness to Mara's move rate. (the distance she usually moves in a frame) 2. that it's easier or more likely that she will walk through a wall the closer you get to walking at a 45 degree angle in regard to your X and Y axes. If the above is true, then I think I know the solution, as in my last note about normalizing and magnifying. If you want to post your code, I'd sure be up for taking a look at it, and I can post mine here as well, if you'd like. -Perhaps peeps might like to see this in practice so to speak?. -Just as a quick explanation in 2D, if you have a vector that's 5 units long and goes straight along the X axis as in 5.0, 0.0 and you try to create a vector five units long on a forty five degree angle simply by defining it as 5.0, 5.0 you're actually making a vector which is longer than five units. I.E. since you're essentially mapping curves with a square coordinate system, you're actually covering more distance on a diagonal then on one of the axes. If you could turn your 5.0, 5.0 vector so it traveled straight along your X axis, you'd find that it actually went well beyond 5.0, 0.0. If you think of squares on a piece of graph paper; if you draw a line along the edge of a square, and then draw a line from one corner of the square to the other, and then measure the line, you'd see that the corner to corner line is longer than the other one. This is what's happening inside the computer. We're just working with graph paper on a very large scale! :) so there are a couple of processes we can do to properly measure the vector so that it's always the same length regardless of which direction it's traveling in. Does this make sense? There's no need to calculate in advance of where any entity will be at any given time. This is the work of the detection routine to let you know what gets touched where, rather than you needing to try to guess it ahead of time. Use small game units, and real rates of travel, realistically sized entities and features, and the detection routines should work fine. Smiles, Cara :) On Dec 8, 2010, at 7:01 PM, Thomas Ward wrote: Hi Cara, I'm just basically using a trig based formula for calculating the next possible x/y/z vectors. As far as I know the formula is correct, and it does work fine with the array based collision detection I have now. It is just when I try to calculate a 3d coordinate and see if items touch where it breaks down. On 12/8/10, Cara Quinn caraqu...@draconisentertainment.com wrote: Ah, Thomas, just reread your note and something else springs to mind. HOw are you doing your calculations for your movement? Remember to use Pythagorus so you get the correct values when dealing with diagonal motion. I.E. Always normalize and then magnify your movement vectors so you always get the proper amount of motion in any direction you move. -Make sense?. HTH! Smiles, Cara :) --- Gamers mailing list __ Gamers@audyssey.org If you want to leave the list, send E-mail to gamers-unsubscr...@audyssey.org. You can make changes or update your subscription via the web, at http://audyssey.org/mailman/listinfo/gamers_audyssey.org. All messages are archived and can be searched and read at http://www.mail-archive.com/gam...@audyssey.org. If you have any questions or concerns regarding the management of the list, please send E-mail to gamers-ow...@audyssey.org. --- Gamers mailing list __ Gamers@audyssey.org If you want to leave the list, send E-mail to gamers-unsubscr...@audyssey.org. You can make changes or update your subscription via the web, at http://audyssey.org/mailman/listinfo/gamers_audyssey.org. All messages are archived and can be searched and read at http://www.mail-archive.com/gam...@audyssey.org. If you have any questions or concerns regarding the management of the list, please send E-mail to gamers-ow...@audyssey.org. --- Gamers mailing list __ Gamers@audyssey.org If you want to leave the list, send E-mail to gamers-unsubscr...@audyssey.org. You can make changes or update your subscription via the web, at http://audyssey.org/mailman/listinfo/gamers_audyssey.org. All messages are archived and can be searched and read at http://www.mail-archive.com/gam...@audyssey.org. If you have any questions or concerns regarding the management of the list, please send E
Re: [Audyssey] game objects in memory
Ben, yes. JQ is actually being updated now, but not by me. :) I made my code completely free and available so others can work with it howe ever they'd like. The code is Quake C which is a flavor of the C language and only works within the context of Quake. I.E. you can't develop in any other environment with it. The Quake engine itself however, is written in straight C and is open-source so people are free to look at it or use it in their own contexts. Many current games still use flavors of the Quake engines and I believe the game that Phil just posted about, Imperial Academy, actually uses the Quake 3 engine. So the quick answer is yes, and the not so quick answer is perhaps in the future. :) Happy holidays to you and yours, and have a wonderful day!… Woohoo! Smiles, Cara :) On Dec 9, 2010, at 10:31 AM, Ben wrote: Hi cara Ever thought of updating jediquake? -Original Message- From: gamers-boun...@audyssey.org [mailto:gamers-boun...@audyssey.org] On Behalf Of Cara Quinn Sent: 09 December 2010 18:24 To: Gamers Discussion list Subject: Re: [Audyssey] game objects in memory Oh, and there was a 3, and I bet: 3. that your storm troopers don't actually move on diagonals! lol! this would explain why they don't happily skip right through the map. :) Talk soon!. Smiles, Cara :) On Dec 9, 2010, at 10:08 AM, Cara Quinn wrote: HI Thomas since you said that Mara passes through walls sometimes when you're at just the right angle, I'm betting that: 1. your walls are very close to the same thickness to Mara's move rate. (the distance she usually moves in a frame) 2. that it's easier or more likely that she will walk through a wall the closer you get to walking at a 45 degree angle in regard to your X and Y axes. If the above is true, then I think I know the solution, as in my last note about normalizing and magnifying. If you want to post your code, I'd sure be up for taking a look at it, and I can post mine here as well, if you'd like. -Perhaps peeps might like to see this in practice so to speak?. -Just as a quick explanation in 2D, if you have a vector that's 5 units long and goes straight along the X axis as in 5.0, 0.0 and you try to create a vector five units long on a forty five degree angle simply by defining it as 5.0, 5.0 you're actually making a vector which is longer than five units. I.E. since you're essentially mapping curves with a square coordinate system, you're actually covering more distance on a diagonal then on one of the axes. If you could turn your 5.0, 5.0 vector so it traveled straight along your X axis, you'd find that it actually went well beyond 5.0, 0.0. If you think of squares on a piece of graph paper; if you draw a line along the edge of a square, and then draw a line from one corner of the square to the other, and then measure the line, you'd see that the corner to corner line is longer than the other one. This is what's happening inside the computer. We're just working with graph paper on a very large scale! :) so there are a couple of processes we can do to properly measure the vector so that it's always the same length regardless of which direction it's traveling in. Does this make sense? There's no need to calculate in advance of where any entity will be at any given time. This is the work of the detection routine to let you know what gets touched where, rather than you needing to try to guess it ahead of time. Use small game units, and real rates of travel, realistically sized entities and features, and the detection routines should work fine. Smiles, Cara :) On Dec 8, 2010, at 7:01 PM, Thomas Ward wrote: Hi Cara, I'm just basically using a trig based formula for calculating the next possible x/y/z vectors. As far as I know the formula is correct, and it does work fine with the array based collision detection I have now. It is just when I try to calculate a 3d coordinate and see if items touch where it breaks down. On 12/8/10, Cara Quinn caraqu...@draconisentertainment.com wrote: Ah, Thomas, just reread your note and something else springs to mind. HOw are you doing your calculations for your movement? Remember to use Pythagorus so you get the correct values when dealing with diagonal motion. I.E. Always normalize and then magnify your movement vectors so you always get the proper amount of motion in any direction you move. -Make sense?. HTH! Smiles, Cara :) --- Gamers mailing list __ Gamers@audyssey.org If you want to leave the list, send E-mail to gamers-unsubscr...@audyssey.org. You can make changes or update your subscription via the web, at http://audyssey.org/mailman/listinfo/gamers_audyssey.org. All messages are archived and can be searched and read at http://www.mail-archive.com/gam...@audyssey.org. If you have any questions or concerns regarding the management of the list, please send E-mail to gamers-ow...@audyssey.org. --- Gamers mailing list __ Gamers@audyssey.org If you want to leave the list, send E
Re: [Audyssey] game objects in memory
Hi Cara, Actually, the storm troopers can move in any direction AKA 360 degrees. They have to in order to properly aim and stuff. I did some testing and I figure the real reason they didn't pas through the wall is because on beginner the speed was set to 0.25, but on expert when they were set to 1 unit per frame they walked right through the walls. On 12/9/10, Cara Quinn caraqu...@draconisentertainment.com wrote: Oh, and there was a 3, and I bet: 3. that your storm troopers don't actually move on diagonals! lol! this would explain why they don't happily skip right through the map. :) Talk soon!… Smiles, Cara :) --- Gamers mailing list __ Gamers@audyssey.org If you want to leave the list, send E-mail to gamers-unsubscr...@audyssey.org. You can make changes or update your subscription via the web, at http://audyssey.org/mailman/listinfo/gamers_audyssey.org. All messages are archived and can be searched and read at http://www.mail-archive.com/gam...@audyssey.org. If you have any questions or concerns regarding the management of the list, please send E-mail to gamers-ow...@audyssey.org.
Re: [Audyssey] game objects in memory
Thomas, how thick are your walls?… -Just curious… -Hey, -sounds like a bad pick-up line! lol! Smiles, CQ :) On Dec 9, 2010, at 2:36 PM, Thomas Ward wrote: Hi Cara, Actually, the storm troopers can move in any direction AKA 360 degrees. They have to in order to properly aim and stuff. I did some testing and I figure the real reason they didn't pas through the wall is because on beginner the speed was set to 0.25, but on expert when they were set to 1 unit per frame they walked right through the walls. On 12/9/10, Cara Quinn caraqu...@draconisentertainment.com wrote: Oh, and there was a 3, and I bet: 3. that your storm troopers don't actually move on diagonals! lol! this would explain why they don't happily skip right through the map. :) Talk soon!… Smiles, Cara :) --- Gamers mailing list __ Gamers@audyssey.org If you want to leave the list, send E-mail to gamers-unsubscr...@audyssey.org. You can make changes or update your subscription via the web, at http://audyssey.org/mailman/listinfo/gamers_audyssey.org. All messages are archived and can be searched and read at http://www.mail-archive.com/gam...@audyssey.org. If you have any questions or concerns regarding the management of the list, please send E-mail to gamers-ow...@audyssey.org. --- Gamers mailing list __ Gamers@audyssey.org If you want to leave the list, send E-mail to gamers-unsubscr...@audyssey.org. You can make changes or update your subscription via the web, at http://audyssey.org/mailman/listinfo/gamers_audyssey.org. All messages are archived and can be searched and read at http://www.mail-archive.com/gam...@audyssey.org. If you have any questions or concerns regarding the management of the list, please send E-mail to gamers-ow...@audyssey.org.
Re: [Audyssey] game objects in memory
Hi, Yeah, the Quake 3 engine is still extensively being used. I know several games from Activision depend on the Quake 3 engine. Right off the top of my head I know Star Trek Elite Force and Star Trek Elite Force II both use a Quake engine. On 12/9/10, Cara Quinn caraqu...@draconisentertainment.com wrote: Ben, yes. JQ is actually being updated now, but not by me. :) I made my code completely free and available so others can work with it howe ever they'd like. The code is Quake C which is a flavor of the C language and only works within the context of Quake. I.E. you can't develop in any other environment with it. The Quake engine itself however, is written in straight C and is open-source so people are free to look at it or use it in their own contexts. Many current games still use flavors of the Quake engines and I believe the game that Phil just posted about, Imperial Academy, actually uses the Quake 3 engine. So the quick answer is yes, and the not so quick answer is perhaps in the future. :) Happy holidays to you and yours, and have a wonderful day!… Woohoo! Smiles, Cara :) --- Gamers mailing list __ Gamers@audyssey.org If you want to leave the list, send E-mail to gamers-unsubscr...@audyssey.org. You can make changes or update your subscription via the web, at http://audyssey.org/mailman/listinfo/gamers_audyssey.org. All messages are archived and can be searched and read at http://www.mail-archive.com/gam...@audyssey.org. If you have any questions or concerns regarding the management of the list, please send E-mail to gamers-ow...@audyssey.org.
Re: [Audyssey] game objects in memory
Hi, Well, thin enough the neighbors can hear a pin drop. Grin. No, seriously I set the walls on the level to 1 unit. I think this might be the source of the problem.Normally this isn't a problem with the current array based system, but when I created a sample level using the 3d coordinates Mara just walks through them. It could be that the thickness of the walls are too thin there fore she steps right over the barrier before the collision detection can check if the two are in contact with each other. On 12/9/10, Cara Quinn caraqu...@draconisentertainment.com wrote: Thomas, how thick are your walls?… -Just curious… -Hey, -sounds like a bad pick-up line! lol! Smiles, CQ :) --- Gamers mailing list __ Gamers@audyssey.org If you want to leave the list, send E-mail to gamers-unsubscr...@audyssey.org. You can make changes or update your subscription via the web, at http://audyssey.org/mailman/listinfo/gamers_audyssey.org. All messages are archived and can be searched and read at http://www.mail-archive.com/gam...@audyssey.org. If you have any questions or concerns regarding the management of the list, please send E-mail to gamers-ow...@audyssey.org.
Re: [Audyssey] game objects in memory
Hi Cara, Hmmm...That makes sense. That also seams to be the problem. Mara's rate is 1 unit per frame and the walls are 1 unit thick. Now, if I walk at them head on I'll smack face first into the wall, door, whatever. If I take them at an angle say 15 degrees I'll walk right through them. On 12/9/10, Cara Quinn caraqu...@draconisentertainment.com wrote: HI Thomas since you said that Mara passes through walls sometimes when you're at just the right angle, I'm betting that: 1. your walls are very close to the same thickness to Mara's move rate. (the distance she usually moves in a frame) 2. that it's easier or more likely that she will walk through a wall the closer you get to walking at a 45 degree angle in regard to your X and Y axes. If the above is true, then I think I know the solution, as in my last note about normalizing and magnifying. If you want to post your code, I'd sure be up for taking a look at it, and I can post mine here as well, if you'd like. -Perhaps peeps might like to see this in practice so to speak?… -Just as a quick explanation in 2D, if you have a vector that's 5 units long and goes straight along the X axis as in 5.0, 0.0 and you try to create a vector five units long on a forty five degree angle simply by defining it as 5.0, 5.0 you're actually making a vector which is longer than five units. I.E. since you're essentially mapping curves with a square coordinate system, you're actually covering more distance on a diagonal then on one of the axes. If you could turn your 5.0, 5.0 vector so it traveled straight along your X axis, you'd find that it actually went well beyond 5.0, 0.0. If you think of squares on a piece of graph paper; if you draw a line along the edge of a square, and then draw a line from one corner of the square to the other, and then measure the line, you'd see that the corner to corner line is longer than the other one. This is what's happening inside the computer. We're just working with graph paper on a very large scale! :) so there are a couple of processes we can do to properly measure the vector so that it's always the same length regardless of which direction it's traveling in. Does this make sense? There's no need to calculate in advance of where any entity will be at any given time. This is the work of the detection routine to let you know what gets touched where, rather than you needing to try to guess it ahead of time. Use small game units, and real rates of travel, realistically sized entities and features, and the detection routines should work fine. Smiles, Cara :) --- Gamers mailing list __ Gamers@audyssey.org If you want to leave the list, send E-mail to gamers-unsubscr...@audyssey.org. You can make changes or update your subscription via the web, at http://audyssey.org/mailman/listinfo/gamers_audyssey.org. All messages are archived and can be searched and read at http://www.mail-archive.com/gam...@audyssey.org. If you have any questions or concerns regarding the management of the list, please send E-mail to gamers-ow...@audyssey.org.
Re: [Audyssey] game objects in memory
Thomas; -Just a quickie for now; How are you working out which direction you'd like to have Mara travel in? I'm assuming you're deciding based on a degree and then working out a vector from that? How are you creating your vector from your angle? (this might be the issue) I.E. if you're supposed to be moving at 1 unit, then the proper vector length if you're moving at a 45 degree angle, should be something like 0.7174, 0.7174 or some such. :) It shouldn't be 1.0, 1.0. If it's not less than 1 on each axis, then you'll need to normalize your vector using the Pythagorus Theorem to get it to a length of 1 unit. Hope this makes sense and talk soon!… Smiles, Cara :) On Dec 9, 2010, at 3:00 PM, Thomas Ward wrote: Hi Cara, Hmmm...That makes sense. That also seams to be the problem. Mara's rate is 1 unit per frame and the walls are 1 unit thick. Now, if I walk at them head on I'll smack face first into the wall, door, whatever. If I take them at an angle say 15 degrees I'll walk right through them. On 12/9/10, Cara Quinn caraqu...@draconisentertainment.com wrote: HI Thomas since you said that Mara passes through walls sometimes when you're at just the right angle, I'm betting that: 1. your walls are very close to the same thickness to Mara's move rate. (the distance she usually moves in a frame) 2. that it's easier or more likely that she will walk through a wall the closer you get to walking at a 45 degree angle in regard to your X and Y axes. If the above is true, then I think I know the solution, as in my last note about normalizing and magnifying. If you want to post your code, I'd sure be up for taking a look at it, and I can post mine here as well, if you'd like. -Perhaps peeps might like to see this in practice so to speak?… -Just as a quick explanation in 2D, if you have a vector that's 5 units long and goes straight along the X axis as in 5.0, 0.0 and you try to create a vector five units long on a forty five degree angle simply by defining it as 5.0, 5.0 you're actually making a vector which is longer than five units. I.E. since you're essentially mapping curves with a square coordinate system, you're actually covering more distance on a diagonal then on one of the axes. If you could turn your 5.0, 5.0 vector so it traveled straight along your X axis, you'd find that it actually went well beyond 5.0, 0.0. If you think of squares on a piece of graph paper; if you draw a line along the edge of a square, and then draw a line from one corner of the square to the other, and then measure the line, you'd see that the corner to corner line is longer than the other one. This is what's happening inside the computer. We're just working with graph paper on a very large scale! :) so there are a couple of processes we can do to properly measure the vector so that it's always the same length regardless of which direction it's traveling in. Does this make sense? There's no need to calculate in advance of where any entity will be at any given time. This is the work of the detection routine to let you know what gets touched where, rather than you needing to try to guess it ahead of time. Use small game units, and real rates of travel, realistically sized entities and features, and the detection routines should work fine. Smiles, Cara :) --- Gamers mailing list __ Gamers@audyssey.org If you want to leave the list, send E-mail to gamers-unsubscr...@audyssey.org. You can make changes or update your subscription via the web, at http://audyssey.org/mailman/listinfo/gamers_audyssey.org. All messages are archived and can be searched and read at http://www.mail-archive.com/gam...@audyssey.org. If you have any questions or concerns regarding the management of the list, please send E-mail to gamers-ow...@audyssey.org. --- Gamers mailing list __ Gamers@audyssey.org If you want to leave the list, send E-mail to gamers-unsubscr...@audyssey.org. You can make changes or update your subscription via the web, at http://audyssey.org/mailman/listinfo/gamers_audyssey.org. All messages are archived and can be searched and read at http://www.mail-archive.com/gam...@audyssey.org. If you have any questions or concerns regarding the management of the list, please send E-mail to gamers-ow...@audyssey.org.
Re: [Audyssey] game objects in memory
Hi Cara,
Sure no problem. below is the functions I'm using to calculate the
angle and vector Mara will travel to reach her next coordinates on the
map. However, before you ask the reason the calculations don't have a
fps or time parameter that's because I assume 1 as the frames per
second which is a slow frame rate I know. Here goes.
// Name: GetDirection (double, double, double, double).
// Description: Calculates the angle between
// two game objects.
float Calculate::GetDirection (double x1, double z1, double x2, double z2)
{
// Subtract x2 from x1
double x = x1 - x2;
// Subtract z1 from z2
double z = z2 - z1;
// Calculate theta by the arc tangent
// of -x*z
double theta = std::atan2 (-x, z);
// Now, multiply theta by 180
// and divide by PI
double direction = (theta * 180) / PI;
// Return the direction
return (float)direction;
}
// Name: GetX(double, double, double).
// Description: Calculates the next possible x vector.
float Calculate::GetX (double direction, double x, double velocity)
{
// Calculate the next x vector by
// multiplying velocity by the sine of
// direction*PI/180
x += velocity * std::sin ((direction * PI) / 180);
// Return the new x vector
return (float)x;
}
// Name: GetZ(double, double, double).
// Description: Calculates the next possible z vector.
float Calculate::GetZ (double direction, double z, double velocity)
{
// Calculate the next z vector by
// multiplying velocity by the cosine of
// direction*PI/180
z += velocity * std::cos ((direction * PI) / 180);
// Return the new z vector
return (float)z;
}
Now, looking at these functions I see I didn't use the Pythagorus
Theorem to normalize the distance which would in deed be part of the
problem. If you could remind me how to do this I'd appreciate it. In
fact, if you can rewrite the functions to do this correctly I'd
appreciate it. This will not only improve the SW game it will be a
nice little bug fix for MOTA which also uses the G3D engine too.
On 12/9/10, Cara Quinn caraqu...@draconisentertainment.com wrote:
Thomas;
-Just a quickie for now;
How are you working out which direction you'd like to have Mara travel in?
I'm assuming you're deciding based on a degree and then working out a vector
from that? How are you creating your vector from your angle? (this might be
the issue)
I.E. if you're supposed to be moving at 1 unit, then the proper vector
length if you're moving at a 45 degree angle, should be something like
0.7174, 0.7174 or some such. :) It shouldn't be 1.0, 1.0.
If it's not less than 1 on each axis, then you'll need to normalize your
vector using the Pythagorus Theorem to get it to a length of 1 unit.
Hope this makes sense and talk soon!…
Smiles,
Cara :)
---
Gamers mailing list __ Gamers@audyssey.org
If you want to leave the list, send E-mail to gamers-unsubscr...@audyssey.org.
You can make changes or update your subscription via the web, at
http://audyssey.org/mailman/listinfo/gamers_audyssey.org.
All messages are archived and can be searched and read at
http://www.mail-archive.com/gam...@audyssey.org.
If you have any questions or concerns regarding the management of the list,
please send E-mail to gamers-ow...@audyssey.org.
Re: [Audyssey] game objects in memory
Thomas;
Thanks for sending this along and am happy to rewrite / send along some code. :)
-Will check back in on the 'morrow witcha! -I'm a sleepy girl now!…
Smiles,
Cara :)
On Dec 9, 2010, at 7:22 PM, Thomas Ward wrote:
Hi Cara,
Sure no problem. below is the functions I'm using to calculate the
angle and vector Mara will travel to reach her next coordinates on the
map. However, before you ask the reason the calculations don't have a
fps or time parameter that's because I assume 1 as the frames per
second which is a slow frame rate I know. Here goes.
// Name: GetDirection (double, double, double, double).
// Description: Calculates the angle between
// two game objects.
float Calculate::GetDirection (double x1, double z1, double x2, double z2)
{
// Subtract x2 from x1
double x = x1 - x2;
// Subtract z1 from z2
double z = z2 - z1;
// Calculate theta by the arc tangent
// of -x*z
double theta = std::atan2 (-x, z);
// Now, multiply theta by 180
// and divide by PI
double direction = (theta * 180) / PI;
// Return the direction
return (float)direction;
}
// Name: GetX(double, double, double).
// Description: Calculates the next possible x vector.
float Calculate::GetX (double direction, double x, double velocity)
{
// Calculate the next x vector by
// multiplying velocity by the sine of
// direction*PI/180
x += velocity * std::sin ((direction * PI) / 180);
// Return the new x vector
return (float)x;
}
// Name: GetZ(double, double, double).
// Description: Calculates the next possible z vector.
float Calculate::GetZ (double direction, double z, double velocity)
{
// Calculate the next z vector by
// multiplying velocity by the cosine of
// direction*PI/180
z += velocity * std::cos ((direction * PI) / 180);
// Return the new z vector
return (float)z;
}
Now, looking at these functions I see I didn't use the Pythagorus
Theorem to normalize the distance which would in deed be part of the
problem. If you could remind me how to do this I'd appreciate it. In
fact, if you can rewrite the functions to do this correctly I'd
appreciate it. This will not only improve the SW game it will be a
nice little bug fix for MOTA which also uses the G3D engine too.
On 12/9/10, Cara Quinn caraqu...@draconisentertainment.com wrote:
Thomas;
-Just a quickie for now;
How are you working out which direction you'd like to have Mara travel in?
I'm assuming you're deciding based on a degree and then working out a vector
from that? How are you creating your vector from your angle? (this might be
the issue)
I.E. if you're supposed to be moving at 1 unit, then the proper vector
length if you're moving at a 45 degree angle, should be something like
0.7174, 0.7174 or some such. :) It shouldn't be 1.0, 1.0.
If it's not less than 1 on each axis, then you'll need to normalize your
vector using the Pythagorus Theorem to get it to a length of 1 unit.
Hope this makes sense and talk soon!…
Smiles,
Cara :)
---
Gamers mailing list __ Gamers@audyssey.org
If you want to leave the list, send E-mail to gamers-unsubscr...@audyssey.org.
You can make changes or update your subscription via the web, at
http://audyssey.org/mailman/listinfo/gamers_audyssey.org.
All messages are archived and can be searched and read at
http://www.mail-archive.com/gam...@audyssey.org.
If you have any questions or concerns regarding the management of the list,
please send E-mail to gamers-ow...@audyssey.org.
---
Gamers mailing list __ Gamers@audyssey.org
If you want to leave the list, send E-mail to gamers-unsubscr...@audyssey.org.
You can make changes or update your subscription via the web, at
http://audyssey.org/mailman/listinfo/gamers_audyssey.org.
All messages are archived and can be searched and read at
http://www.mail-archive.com/gam...@audyssey.org.
If you have any questions or concerns regarding the management of the list,
please send E-mail to gamers-ow...@audyssey.org.
Re: [Audyssey] game objects in memory
Hi Cara, My idea was originally to have an array of pointers to objects defining the characteristics of the object at that location. I also thought to have e.g. one wall object andd a lot of pointers to that one object in the array locations where the wall should be. That said, I think you've just convinced me to use the 3d coordination system with collision detection. :-) One thing I still have to figure out though, is how to handle something like an explosion. In the array system I would've just remove all the pointers along a specific radius. May be one way is to give every shape in 3d space a sub-object (another shape) specifying where it's damaged. So you would have a rectangle-like object representing a wall, with a circular shape specifying where a mine/projectile struck. Is there a better way of doing this? Take care, Rynhardt * Cara Quinn caraqu...@draconisentertainment.com [101207 23:56]: Hi Rynhardt, in theory this sounds good, but I have a couple of questions for you. What data types are you storing in your array? I.E. HOw are you showing that there is a wall and not air per se in a particular area? I'm assuming here, that we're talking about a full-scale map of the level. Also, is your player moving in only 1 unit per frame? I ask these because firstly, it sounds like you're simply treating the world as a very large array of described points in essence. (Which begins to sound exactly like a 3D coordinate system again) :) The exception being that you have labels for each point, which can really unnecessarily inflate the amount of data needed to render a map. Even just using a byte of data per coordinate, it inflates the map eight times larger than it needs to be rather than using a simpler collision-based model. -And, incidentally, you'll still, in effect, need to use collision detection anyway, since the map is full-scale. I.E. if your player is moving at 5 coordinates per second in a direction but that move rate isn't always the same, you'll still need to check to see if the path of the player will come into contact with some feature of the map. You'd need some form of collision detection for this. -Yes?? To address your other point, about needing to move through each entity in the game each frame, you could simply use the current room as your bound for checking entities. There's no sense checking entities on the other side of the map. Even if you simply used the player's radius instead, and did more detailed collision detection based on that, the math to check every entity's position in a level really wouldn't be anything for a modern machine. I like your idea though, using perhaps an array of 8 bit integers, which could simply represent a full-scale environment with amazing detail, in the sense that one could simply test for a point anywhere on the map and instantly know what exactly was there. I.E. A point could contain air, water, be solid or not with numerous materials. I question how much faster or less intensive this would really be in gameplay though. -But honestly, I'm not sure it really matters on the scale we're talking about here. I.E. we're not even actually rendering any of this in graphics so these shapes and structures we're testing against are purely hypothetical in the sense that a sphere is simply a 3F coordinate and another float for a radius. That's so little data to represent and so little math to manage, that it's nothing for a computer these days. -Know what I mean?? I think it's really interesting though, as I've said, as it really sounds like your and other's full-scale approach is really beginning to blend with a raw 3D coord system anyway. :) I love the idea of symbolic representation of 'reality' and vice versa!? woohoo! :) Have a totally awesome day!? Smiles, Cara :) --- Gamers mailing list __ Gamers@audyssey.org If you want to leave the list, send E-mail to gamers-unsubscr...@audyssey.org. You can make changes or update your subscription via the web, at http://audyssey.org/mailman/listinfo/gamers_audyssey.org. All messages are archived and can be searched and read at http://www.mail-archive.com/gam...@audyssey.org. If you have any questions or concerns regarding the management of the list, please send E-mail to gamers-ow...@audyssey.org.
Re: [Audyssey] game objects in memory
Hi Cara, Yah, I see that. Unfortunately, I tried creating a level for Mysteries of the Sith using a 3d coordinates system like you said and I must have done something wrong because the main character, Mara Jade, kept walking through walls for some reason. Some times she would hit it, but other times if the angle was off she could pass right through it which drove me nuts. Diddo for the doors. She would hit them and other times pass right through the door. I couldn't figure out what exactly caused the collision detection to fail. now, when the troopers encountered the same wall they were blocked properly. So I think I will need some technical help getting that working if I'm going to move away from an array based map to true 3d coordinates. Cheers! On 12/7/10, Cara Quinn caraqu...@draconisentertainment.com wrote: Yes Thomas, this seems to be a different approach than the popular one people are taking here, in that it seems to kind of free up the programmer to use real physics and constant relatively low-cost collision detection without needing to worry so much on the exact position an entity will be in at any given time. I.E. let the detection routine do the work and deal with the touches on an entity by entity basis. Touches and collisions can be dealt with uniquely, depending on the two or more entities touching. Each entity has it's own touch routines that get called and the correct results easily work for all the entities without so much forethought on the part of the developer. I.E. Let the entity itself check what touched it or create a short-lived object to represent the touch between two entities and act accordingly. -It can be a very cool paradigm… In essence, the map now has only the barest coordinates representing the actual objects and the rest is just nothing! lol! So it's a whole lot less data to manage. the down-side in my opinion, is that each type of map element really needs to be defined in terms of active objects. I.E. a body of water really needs to be it's own entity with a bounding box or some shape. Admittedly, it could be represented with a really minimal amount of data, (three floats) but still, it's still another object like a wall or door. Sizewise though, maps really are a lot smaller than the array-based paradigms we've been talking about now, and could be stored in files that are very small text files. I kind of like a combo approach, myself, as I've said, where the map uses a straight 3D coordinate system, but still is divided into regions like rooms and such. Anyway, -Just some thoughts… Smiles, Cara :) --- Gamers mailing list __ Gamers@audyssey.org If you want to leave the list, send E-mail to gamers-unsubscr...@audyssey.org. You can make changes or update your subscription via the web, at http://audyssey.org/mailman/listinfo/gamers_audyssey.org. All messages are archived and can be searched and read at http://www.mail-archive.com/gam...@audyssey.org. If you have any questions or concerns regarding the management of the list, please send E-mail to gamers-ow...@audyssey.org.
Re: [Audyssey] game objects in memory
Hi Thomas, are you calling the detection routine each frame? Secondly, when your player is moving, is her movement being divided by the frames per second? I.E. it sounds like she's skipping over the wall because she's not actually passing through the space but skipping through it. If you divide her move rate by the number of frames per second and detect based on that, (unless even that move rate is larger than the thickness of your thinest wall) then she should properly interact with your map, rather than simply happily go skipping right through it! lol! -KNow what I mean?… Smiles, Cara :) On Dec 8, 2010, at 4:59 PM, Thomas Ward wrote: Hi Cara, Yah, I see that. Unfortunately, I tried creating a level for Mysteries of the Sith using a 3d coordinates system like you said and I must have done something wrong because the main character, Mara Jade, kept walking through walls for some reason. Some times she would hit it, but other times if the angle was off she could pass right through it which drove me nuts. Diddo for the doors. She would hit them and other times pass right through the door. I couldn't figure out what exactly caused the collision detection to fail. now, when the troopers encountered the same wall they were blocked properly. So I think I will need some technical help getting that working if I'm going to move away from an array based map to true 3d coordinates. Cheers! On 12/7/10, Cara Quinn caraqu...@draconisentertainment.com wrote: Yes Thomas, this seems to be a different approach than the popular one people are taking here, in that it seems to kind of free up the programmer to use real physics and constant relatively low-cost collision detection without needing to worry so much on the exact position an entity will be in at any given time. I.E. let the detection routine do the work and deal with the touches on an entity by entity basis. Touches and collisions can be dealt with uniquely, depending on the two or more entities touching. Each entity has it's own touch routines that get called and the correct results easily work for all the entities without so much forethought on the part of the developer. I.E. Let the entity itself check what touched it or create a short-lived object to represent the touch between two entities and act accordingly. -It can be a very cool paradigm… In essence, the map now has only the barest coordinates representing the actual objects and the rest is just nothing! lol! So it's a whole lot less data to manage. the down-side in my opinion, is that each type of map element really needs to be defined in terms of active objects. I.E. a body of water really needs to be it's own entity with a bounding box or some shape. Admittedly, it could be represented with a really minimal amount of data, (three floats) but still, it's still another object like a wall or door. Sizewise though, maps really are a lot smaller than the array-based paradigms we've been talking about now, and could be stored in files that are very small text files. I kind of like a combo approach, myself, as I've said, where the map uses a straight 3D coordinate system, but still is divided into regions like rooms and such. Anyway, -Just some thoughts… Smiles, Cara :) --- Gamers mailing list __ Gamers@audyssey.org If you want to leave the list, send E-mail to gamers-unsubscr...@audyssey.org. You can make changes or update your subscription via the web, at http://audyssey.org/mailman/listinfo/gamers_audyssey.org. All messages are archived and can be searched and read at http://www.mail-archive.com/gam...@audyssey.org. If you have any questions or concerns regarding the management of the list, please send E-mail to gamers-ow...@audyssey.org. --- Gamers mailing list __ Gamers@audyssey.org If you want to leave the list, send E-mail to gamers-unsubscr...@audyssey.org. You can make changes or update your subscription via the web, at http://audyssey.org/mailman/listinfo/gamers_audyssey.org. All messages are archived and can be searched and read at http://www.mail-archive.com/gam...@audyssey.org. If you have any questions or concerns regarding the management of the list, please send E-mail to gamers-ow...@audyssey.org.
Re: [Audyssey] game objects in memory
Rynhardt; That's actually a way I was thinking of, myself, to accomplish this. I personally haven't been working with destructible maps, but it's something that I really want to do. -And had just been toying with the idea of doing exactly what you just suggested. I.E. place an object in an area of a wall which would create an opening there, like a door or such. In essence, the type of collision detection you'd then do on that new special object, would in effect, be a negative collision detection. -Know what I mean? If your player is then completely touching the object, or in other words, passing through it, then the player would be allowed to pass into the next room or area of the map. -Does this make sense?… Another alternative, would be if you're using an array of integers to represent a map, like we've been discussing, you could then simply set all the points in a particular radius to a value representing air. These are the ways I'd consider doing this at present… Hope this helps… Smiles, Cara :) On Dec 8, 2010, at 2:11 PM, Rynhardt Kruger wrote: Hi Cara, My idea was originally to have an array of pointers to objects defining the characteristics of the object at that location. I also thought to have e.g. one wall object and a lot of pointers to that one object in the array locations where the wall should be. That said, I think you've just convinced me to use the 3d coordination system with collision detection. :-) One thing I still have to figure out though, is how to handle something like an explosion. In the array system I would've just remove all the pointers along a specific radius. May be one way is to give every shape in 3d space a sub-object (another shape) specifying where it's damaged. So you would have a rectangle-like object representing a wall, with a circular shape specifying where a mine/projectile struck. Is there a better way of doing this? Take care, Rynhardt * Cara Quinn caraqu...@draconisentertainment.com [101207 23:56]: Hi Rynhardt, in theory this sounds good, but I have a couple of questions for you. What data types are you storing in your array? I.E. HOw are you showing that there is a wall and not air per se in a particular area? I'm assuming here, that we're talking about a full-scale map of the level. Also, is your player moving in only 1 unit per frame? I ask these because firstly, it sounds like you're simply treating the world as a very large array of described points in essence. (Which begins to sound exactly like a 3D coordinate system again) :) The exception being that you have labels for each point, which can really unnecessarily inflate the amount of data needed to render a map. Even just using a byte of data per coordinate, it inflates the map eight times larger than it needs to be rather than using a simpler collision-based model. -And, incidentally, you'll still, in effect, need to use collision detection anyway, since the map is full-scale. I.E. if your player is moving at 5 coordinates per second in a direction but that move rate isn't always the same, you'll still need to check to see if the path of the player will come into contact with some feature of the map. You'd need some form of collision detection for this. -Yes?? To address your other point, about needing to move through each entity in the game each frame, you could simply use the current room as your bound for checking entities. There's no sense checking entities on the other side of the map. Even if you simply used the player's radius instead, and did more detailed collision detection based on that, the math to check every entity's position in a level really wouldn't be anything for a modern machine. I like your idea though, using perhaps an array of 8 bit integers, which could simply represent a full-scale environment with amazing detail, in the sense that one could simply test for a point anywhere on the map and instantly know what exactly was there. I.E. A point could contain air, water, be solid or not with numerous materials. I question how much faster or less intensive this would really be in gameplay though. -But honestly, I'm not sure it really matters on the scale we're talking about here. I.E. we're not even actually rendering any of this in graphics so these shapes and structures we're testing against are purely hypothetical in the sense that a sphere is simply a 3F coordinate and another float for a radius. That's so little data to represent and so little math to manage, that it's nothing for a computer these days. -Know what I mean?? I think it's really interesting though, as I've said, as it really sounds like your and other's full-scale approach is really beginning to blend with a raw 3D coord system anyway. :) I love the idea of symbolic representation of 'reality' and vice versa!? woohoo! :) Have a totally awesome day!? Smiles, Cara :) --- Gamers mailing
Re: [Audyssey] game objects in memory
Ah, Thomas, just reread your note and something else springs to mind. HOw are you doing your calculations for your movement? Remember to use Pythagorus so you get the correct values when dealing with diagonal motion. I.E. Always normalize and then magnify your movement vectors so you always get the proper amount of motion in any direction you move. -Make sense?… HTH! Smiles, Cara :) On Dec 8, 2010, at 4:59 PM, Thomas Ward wrote: Hi Cara, Yah, I see that. Unfortunately, I tried creating a level for Mysteries of the Sith using a 3d coordinates system like you said and I must have done something wrong because the main character, Mara Jade, kept walking through walls for some reason. Some times she would hit it, but other times if the angle was off she could pass right through it which drove me nuts. Diddo for the doors. She would hit them and other times pass right through the door. I couldn't figure out what exactly caused the collision detection to fail. now, when the troopers encountered the same wall they were blocked properly. So I think I will need some technical help getting that working if I'm going to move away from an array based map to true 3d coordinates. Cheers! On 12/7/10, Cara Quinn caraqu...@draconisentertainment.com wrote: Yes Thomas, this seems to be a different approach than the popular one people are taking here, in that it seems to kind of free up the programmer to use real physics and constant relatively low-cost collision detection without needing to worry so much on the exact position an entity will be in at any given time. I.E. let the detection routine do the work and deal with the touches on an entity by entity basis. Touches and collisions can be dealt with uniquely, depending on the two or more entities touching. Each entity has it's own touch routines that get called and the correct results easily work for all the entities without so much forethought on the part of the developer. I.E. Let the entity itself check what touched it or create a short-lived object to represent the touch between two entities and act accordingly. -It can be a very cool paradigm… In essence, the map now has only the barest coordinates representing the actual objects and the rest is just nothing! lol! So it's a whole lot less data to manage. the down-side in my opinion, is that each type of map element really needs to be defined in terms of active objects. I.E. a body of water really needs to be it's own entity with a bounding box or some shape. Admittedly, it could be represented with a really minimal amount of data, (three floats) but still, it's still another object like a wall or door. Sizewise though, maps really are a lot smaller than the array-based paradigms we've been talking about now, and could be stored in files that are very small text files. I kind of like a combo approach, myself, as I've said, where the map uses a straight 3D coordinate system, but still is divided into regions like rooms and such. Anyway, -Just some thoughts… Smiles, Cara :) --- Gamers mailing list __ Gamers@audyssey.org If you want to leave the list, send E-mail to gamers-unsubscr...@audyssey.org. You can make changes or update your subscription via the web, at http://audyssey.org/mailman/listinfo/gamers_audyssey.org. All messages are archived and can be searched and read at http://www.mail-archive.com/gam...@audyssey.org. If you have any questions or concerns regarding the management of the list, please send E-mail to gamers-ow...@audyssey.org. --- Gamers mailing list __ Gamers@audyssey.org If you want to leave the list, send E-mail to gamers-unsubscr...@audyssey.org. You can make changes or update your subscription via the web, at http://audyssey.org/mailman/listinfo/gamers_audyssey.org. All messages are archived and can be searched and read at http://www.mail-archive.com/gam...@audyssey.org. If you have any questions or concerns regarding the management of the list, please send E-mail to gamers-ow...@audyssey.org.
Re: [Audyssey] game objects in memory
HI Cara, That's actually one reason I'm still in favor of the array method we've been talking about as I find it very easy to blow punch holes in walls, doors, and still leave part of the structure standing. For example, in Mysteries of the Sith, the SW game I'm working on, if Mara uses a thermal detonator or rail charge near a wall, door, etc I can calculate a blast radious for the device and simply erace all the elements with in that radious seting them to 0 or air if you want to call it that.That effectively makes a large hole that is not only easy to find, but easy to make too. For example, on level 7 in Ka'pa the Huts palace on Tatooine Mara has to return a stolen item to Ka'pa the Hut, but you can't get into his audience chamber because his guards won't let you in. One way to reach the audience chamber is to enter the room above his thrown, whatever you call that thing he is laying on, set some explosives, and force run out of the way. It will blow a big hole in the ceiling of the audience chamber allowing you to safety ddrop through the hole into the room below and thus finish that level. Obviously, to accurately recreate this part of the game I'm going to have to figure out a way to make a sizable whole without trying to calculate where and when the player will touch the floor. For me, at any rate, using an array like I have been doing is the easiest approach. Simply calculate the blast radious and find out if a certen element is in the radious and set it to 0 effectively destroying whatever is there. Cheers! On 12/8/10, Cara Quinn caraqu...@draconisentertainment.com wrote: Rynhardt; That's actually a way I was thinking of, myself, to accomplish this. I personally haven't been working with destructible maps, but it's something that I really want to do. -And had just been toying with the idea of doing exactly what you just suggested. I.E. place an object in an area of a wall which would create an opening there, like a door or such. In essence, the type of collision detection you'd then do on that new special object, would in effect, be a negative collision detection. -Know what I mean? If your player is then completely touching the object, or in other words, passing through it, then the player would be allowed to pass into the next room or area of the map. -Does this make sense?… Another alternative, would be if you're using an array of integers to represent a map, like we've been discussing, you could then simply set all the points in a particular radius to a value representing air. These are the ways I'd consider doing this at present… Hope this helps… Smiles, Cara :) --- Gamers mailing list __ Gamers@audyssey.org If you want to leave the list, send E-mail to gamers-unsubscr...@audyssey.org. You can make changes or update your subscription via the web, at http://audyssey.org/mailman/listinfo/gamers_audyssey.org. All messages are archived and can be searched and read at http://www.mail-archive.com/gam...@audyssey.org. If you have any questions or concerns regarding the management of the list, please send E-mail to gamers-ow...@audyssey.org.
Re: [Audyssey] game objects in memory
Hi Cara, I'm just basically using a trig based formula for calculating the next possible x/y/z vectors. As far as I know the formula is correct, and it does work fine with the array based collision detection I have now. It is just when I try to calculate a 3d coordinate and see if items touch where it breaks down. On 12/8/10, Cara Quinn caraqu...@draconisentertainment.com wrote: Ah, Thomas, just reread your note and something else springs to mind. HOw are you doing your calculations for your movement? Remember to use Pythagorus so you get the correct values when dealing with diagonal motion. I.E. Always normalize and then magnify your movement vectors so you always get the proper amount of motion in any direction you move. -Make sense?… HTH! Smiles, Cara :) --- Gamers mailing list __ Gamers@audyssey.org If you want to leave the list, send E-mail to gamers-unsubscr...@audyssey.org. You can make changes or update your subscription via the web, at http://audyssey.org/mailman/listinfo/gamers_audyssey.org. All messages are archived and can be searched and read at http://www.mail-archive.com/gam...@audyssey.org. If you have any questions or concerns regarding the management of the list, please send E-mail to gamers-ow...@audyssey.org.
Re: [Audyssey] game objects in memory
Hi Cara, Yeah, makes sense. That's basically what I was thinking. For some reason Mara just skips through the wall, and I am dividing by the elapsed time, FPS, and somewhere in the code she skips something somewhere. Must be a new Jedi force skill. The ability to pass through walls like a ghost. Lol! Cheers! On 12/8/10, Cara Quinn caraqu...@draconisentertainment.com wrote: Hi Thomas, are you calling the detection routine each frame? Secondly, when your player is moving, is her movement being divided by the frames per second? I.E. it sounds like she's skipping over the wall because she's not actually passing through the space but skipping through it. If you divide her move rate by the number of frames per second and detect based on that, (unless even that move rate is larger than the thickness of your thinest wall) then she should properly interact with your map, rather than simply happily go skipping right through it! lol! -KNow what I mean?… Smiles, Cara :) --- Gamers mailing list __ Gamers@audyssey.org If you want to leave the list, send E-mail to gamers-unsubscr...@audyssey.org. You can make changes or update your subscription via the web, at http://audyssey.org/mailman/listinfo/gamers_audyssey.org. All messages are archived and can be searched and read at http://www.mail-archive.com/gam...@audyssey.org. If you have any questions or concerns regarding the management of the list, please send E-mail to gamers-ow...@audyssey.org.
Re: [Audyssey] game objects in memory
Hi, Interesting...guess Yoda knew less than he thought. Best Regards, Hayden -Original Message- From: gamers-boun...@audyssey.org [mailto:gamers-boun...@audyssey.org] On Behalf Of Thomas Ward Sent: Wednesday, December 08, 2010 9:08 PM To: Gamers Discussion list Subject: Re: [Audyssey] game objects in memory Hi Cara, Yeah, makes sense. That's basically what I was thinking. For some reason Mara just skips through the wall, and I am dividing by the elapsed time, FPS, and somewhere in the code she skips something somewhere. Must be a new Jedi force skill. The ability to pass through walls like a ghost. Lol! Cheers! On 12/8/10, Cara Quinn caraqu...@draconisentertainment.com wrote: Hi Thomas, are you calling the detection routine each frame? Secondly, when your player is moving, is her movement being divided by the frames per second? I.E. it sounds like she's skipping over the wall because she's not actually passing through the space but skipping through it. If you divide her move rate by the number of frames per second and detect based on that, (unless even that move rate is larger than the thickness of your thinest wall) then she should properly interact with your map, rather than simply happily go skipping right through it! lol! -KNow what I mean?. Smiles, Cara :) --- Gamers mailing list __ Gamers@audyssey.org If you want to leave the list, send E-mail to gamers-unsubscr...@audyssey.org. You can make changes or update your subscription via the web, at http://audyssey.org/mailman/listinfo/gamers_audyssey.org. All messages are archived and can be searched and read at http://www.mail-archive.com/gam...@audyssey.org. If you have any questions or concerns regarding the management of the list, please send E-mail to gamers-ow...@audyssey.org. --- Gamers mailing list __ Gamers@audyssey.org If you want to leave the list, send E-mail to gamers-unsubscr...@audyssey.org. You can make changes or update your subscription via the web, at http://audyssey.org/mailman/listinfo/gamers_audyssey.org. All messages are archived and can be searched and read at http://www.mail-archive.com/gam...@audyssey.org. If you have any questions or concerns regarding the management of the list, please send E-mail to gamers-ow...@audyssey.org.
Re: [Audyssey] game objects in memory
Hi Cara,
The reason I thought the 3d array would be faster is:
Lets say you want to check if the player object moves into a wall when it takes
a step. In the case where every object
has attributes for the 3d coordinate, you have to search through all the
objects currently in the level and check if one
of them is at the position of the players next position. If all the objects are
stored in a 3d array, it requires only
using the players next location as an array index and checking if an object
occupies that array element. In
languages like c or c++, getting an array element requires only the calculation
of the correct offset in memory based on
the array index and element size and referencing that location in memory.
In this case I'd thought of storing wall-like elements in
the array apposed to rooms.
Another way might be to (as you said) give each object bounding coordinates
e.g. a left upper coordinate and a right
lower coordinate and have all the objects in an array or other data structure.
May be having rooms in stead of walls
represented by objects will decrease the number of objects so the search time
isn't so big?
A reason I like this method is that rooms can have interesting shapes e.g. a
round room and that you can move a hole
room to another location, possibly moving everything inside as well to create a
vehicle like object.
Take care,
Rynhardt
* Cara Quinn caraqu...@draconisentertainment.com [101207 07:53]:
Rynhardt;
-It occurred to me that I didn't completely answer your question in my last
note, so my apologies. :)
In my own personal opinion, yes, it's good to have map data in an array, as
well as using a flexible coordinate system as in my code example. HOwever,
even though game objects can still rely on a coordinate system to move within
the game, they can still be stored in an array as well.
I.E. one could use two arrays in-game; one to store the amount of active
entities and the other to represent rooms in a level. Within the rooms array,
game entities can freely move in 3D space using the usual 3D coordinate
system we're discussing.
this is one approach I personally like, but it's also not perfect in my
opinion.
For one thing, using one element of an array per room, can make it difficult
to accurately or easily map certain complex room layouts, though on the
up-side, it can be really easy to juggle and switch rooms around to cause
some really neat effects for cool game-play.
Perhaps my very fav mapping type would simply be to map out the entire space
with a coordinate system and simply take the 3D coordinate-based physics
approach and rely on collision management and such?
-Just my thoughts?
-Hope this comes closer to answering your questions / addressing your
comments?
Smiles,
Cara :)
On Dec 6, 2010, at 5:22 PM, Cara Quinn wrote:
Hi Rynhardt;
ACtually collision detection really isn't that expensive. Here's some C++ for
checking two axis-aligned bounding boxes in 3D.
// set the lower and upper coordinates of each box
// and set their position
Box A (-1.0, -1.0, -1.0, 1.0, 1.0, 1.0);
A.setPosition (3.0, 3.0, 3.0);
Box B (-1.0, -1.0, -1.0, 1.0, 1.0, 1.0);
B.setPosition (0.0, 0.0, 0.0);
// check to see if any part of the above boxes touch or overlap
if((A.lower.x = B.upper.x A.lower.y = B.upper.y A.lower.z =
B.upper.z) (A.upper.x = B.lower.x A.upper.y = B.lower.y A.upper.z
= B.lower.z)) {
// Manage collision
}
In this case, the two boxes are not touching, as the bottom-most point of A
is at 2.0, 2.0, 2.0 and the top-most point of B is at 1.0, 1.0, 1.0 so
there's a length of one coordinate between them. Does this make sense??
The above code is all you need to detect whether two boxes in 3D space touch
or overlap each other. This really isn't overly intensive. YOu can also check
for collision of spheres easily too, but it is a bit more expensive than the
above, but it is equally simple, relying on the Pythagorus theorem. Basically
you can just check the length of the line between the centers of two spheres
and see if it's less than or greater than the radii of each sphere. So if the
two radii add up to (or are greater than) the distance you just found, then
the spheres are touching or overlapping.
On the subject of arrays, (depending on the type of array) it's not
necessarily any less expensive to access an array vs doing something like the
above every frame of a game, since the system may need to move through the
array to find what it needs, regardless of how easy it looks to the user. so
just because you can call an element of an array as in array[x] doesn't mean
the system doesn't need to do any work to access that element.
There are faster ways of storing data which are easier on the system in C++
but I'm not as familiar with them as I'd like, so forgive me but I just know
they're there, but have no explanation for you. :)
Re: [Audyssey] game objects in memory
Hi Rynhardt, in theory this sounds good, but I have a couple of questions for you. What data types are you storing in your array? I.E. HOw are you showing that there is a wall and not air per se in a particular area? I'm assuming here, that we're talking about a full-scale map of the level. Also, is your player moving in only 1 unit per frame? I ask these because firstly, it sounds like you're simply treating the world as a very large array of described points in essence. (Which begins to sound exactly like a 3D coordinate system again) :) The exception being that you have labels for each point, which can really unnecessarily inflate the amount of data needed to render a map. Even just using a byte of data per coordinate, it inflates the map eight times larger than it needs to be rather than using a simpler collision-based model. -And, incidentally, you'll still, in effect, need to use collision detection anyway, since the map is full-scale. I.E. if your player is moving at 5 coordinates per second in a direction but that move rate isn't always the same, you'll still need to check to see if the path of the player will come into contact with some feature of the map. You'd need some form of collision detection for this. -Yes?… To address your other point, about needing to move through each entity in the game each frame, you could simply use the current room as your bound for checking entities. There's no sense checking entities on the other side of the map. Even if you simply used the player's radius instead, and did more detailed collision detection based on that, the math to check every entity's position in a level really wouldn't be anything for a modern machine. I like your idea though, using perhaps an array of 8 bit integers, which could simply represent a full-scale environment with amazing detail, in the sense that one could simply test for a point anywhere on the map and instantly know what exactly was there. I.E. A point could contain air, water, be solid or not with numerous materials. I question how much faster or less intensive this would really be in gameplay though. -But honestly, I'm not sure it really matters on the scale we're talking about here. I.E. we're not even actually rendering any of this in graphics so these shapes and structures we're testing against are purely hypothetical in the sense that a sphere is simply a 3F coordinate and another float for a radius. That's so little data to represent and so little math to manage, that it's nothing for a computer these days. -Know what I mean?… I think it's really interesting though, as I've said, as it really sounds like your and other's full-scale approach is really beginning to blend with a raw 3D coord system anyway. :) I love the idea of symbolic representation of 'reality' and vice versa!… woohoo! :) Have a totally awesome day!… Smiles, Cara :) On Dec 7, 2010, at 2:30 AM, Rynhardt Kruger wrote: Hi Cara, The reason I thought the 3d array would be faster is: Lets say you want to check if the player object moves into a wall when it takes a step. In the case where every object has attributes for the 3d coordinate, you have to search through all the objects currently in the level and check if one of them is at the position of the players next position. If all the objects are stored in a 3d array, it requires only using the players next location as an array index and checking if an object occupies that array element. In languages like c or c++, getting an array element requires only the calculation of the correct offset in memory based on the array index and element size and referencing that location in memory. In this case I'd thought of storing wall-like elements in the array apposed to rooms. Another way might be to (as you said) give each object bounding coordinates e.g. a left upper coordinate and a right lower coordinate and have all the objects in an array or other data structure. May be having rooms in stead of walls represented by objects will decrease the number of objects so the search time isn't so big? A reason I like this method is that rooms can have interesting shapes e.g. a round room and that you can move a hole room to another location, possibly moving everything inside as well to create a vehicle like object. Take care, Rynhardt * Cara Quinn caraqu...@draconisentertainment.com [101207 07:53]: Rynhardt; -It occurred to me that I didn't completely answer your question in my last note, so my apologies. :) In my own personal opinion, yes, it's good to have map data in an array, as well as using a flexible coordinate system as in my code example. HOwever, even though game objects can still rely on a coordinate system to move within the game, they can still be stored in an array as well. I.E. one could use two arrays in-game; one to store the amount of active entities and the other to represent rooms in a level. Within the rooms array,
Re: [Audyssey] game objects in memory
Hi Cara, Cara wrote: What data types are you storing in your array? I.E. HOw are you showing that there is a wall and not air per se in a particular area? I'm assuming here, that we're talking about a full-scale map of the level. My responce: At least the way I do it in g3D I have a header called surface.h which has several defined surface types such as walls, doors, water, ladders, ropes, vines, etc to reference different surfaces and objects in the game world. There fore all I need to do is create a 3d array of type int and fill it with these surface constants, and I can later reference the array to find out what if anything is at any given point on the map on demand. Since I have those surface constants it makes referencing this stuff pretty easy. Cara wrote: I ask these because firstly, it sounds like you're simply treating the world as a very large array of described points in essence. (Which begins to sound exactly like a 3D coordinate system again) :) The exception being that you have labels for each point, which can really unnecessarily inflate the amount of data needed to render a map. Even just using a byte of data per coordinate, it inflates the map eight times larger than it needs to be rather than using a simpler collision-based model. My response: That's exactly the issue I encountered when creating levels of any real size and complexity. That is one reason I was thinking of shrinking the levels. The way I'm handling things really inflates the amount of data to store the level in memory. It is something of a CPU/memory hog when it really doesn't need to. For that reason I really and truly believe i need to implement a true 3d coordinates system with proper colision detection to improve the engine. That said, using an array as a colision detection system is a bit easier because as you say everything is labeled. For example, if I want to know if there is a wall 3 units away I can look along that vector three coordinate units and see exactly what is there just by referencing the array. It is simple, but is rather waistful of memory and CPU power in the process. Cara wrote: -And, incidentally, you'll still, in effect, need to use collision detection anyway, since the map is full-scale. I.E. if your player is moving at 5 coordinates per second in a direction but that move rate isn't always the same, you'll still need to check to see if the path of the player will come into contact with some feature of the map. You'd need some form of collision detection for this. -Yes?… My response: Yes and no. Implementing a true colision detection system would certainly be more appropriate, but I have managed without one. As I said I managed to do it with a simpkle 3d array regardless of the player's rate. Here is an an example of how I do it. // Get the player's current direction, location, and speed direction = player.IsDirection(); speed = player.IsSpeed(); x1 = player.IsX(); y1 = player.IsY(); z1 = player.IsZ(); // Calculate the player's new location x2 = GetX(direction, x1, speed); y2 = GetY(0, y1, speed); z2 = GetZ(direction, z1, speed); // Now return the surface at the specified coordinates surface = world.IsSurface(x2, y2, z2); Of course, I'm using internal functions from my G3D engine as my example, but how it works is actually simple. The GetX(), GetY(), and GetZ() functions simply takes the player's direction, speed, and coordinates and looks along that vector however many units the player would travel in a certain frame. The new coordinates or position is then passed off to my world object which has an array holding the game world and finds out what if anything is there at that coordinates. As I said earlier it works fine except for the fact it definitely inflates the amount of data that needs to be stored to get colision detection and you can't have more than one object in any given position at a time. Cara wrote: I like your idea though, using perhaps an array of 8 bit integers, which could simply represent a full-scale environment with amazing detail, in the sense that one could simply test for a point anywhere on the map and instantly know what exactly was there. I.E. A point could contain air, water, be solid or not with numerous materials. My response: That's the upside alright and why I chose that method when creating G3D. I just found it easier on the programmer to keep track of things and doesn't require being a math major to figure out. Although, my grades in math were decent in school I still have troubles with geometry and trig without someone to refresh me on how to do this or that from time to time. In fact, i often have to ask friends in the know to help with me with math calculations in my programming as my own math skills are fair, but not great.In fact, the first time I took trig I almost flunked it just because I couldn't wrap my brain around sins, cosins, tangents, etc. Although, I think as I get older I'm becoming a little better at it because game programming has
Re: [Audyssey] game objects in memory
Hi Cara,
Hmmm...I'm going to have to try that. When you put it like that it
looks pretty easy. Essentially, all I should have to do is create a
class to hold something like a wall and define its maximum x, y, and z
boundries and detect if the player comes into contact with any point
of the wall, door, whatever. I've got to try this as it sounds
interesting.
Cheers!
On 12/6/10, Cara Quinn caraqu...@draconisentertainment.com wrote:
Hi Rynhardt;
ACtually collision detection really isn't that expensive. Here's some C++
for checking two axis-aligned bounding boxes in 3D.
// set the lower and upper coordinates of each box
// and set their position
Box A (-1.0, -1.0, -1.0, 1.0, 1.0, 1.0);
A.setPosition (3.0, 3.0, 3.0);
Box B (-1.0, -1.0, -1.0, 1.0, 1.0, 1.0);
B.setPosition (0.0, 0.0, 0.0);
// check to see if any part of the above boxes touch or overlap
if((A.lower.x = B.upper.x A.lower.y = B.upper.y A.lower.z =
B.upper.z) (A.upper.x = B.lower.x A.upper.y = B.lower.y A.upper.z
= B.lower.z)) {
// Manage collision
}
In this case, the two boxes are not touching, as the bottom-most point of A
is at 2.0, 2.0, 2.0 and the top-most point of B is at 1.0, 1.0, 1.0 so
there's a length of one coordinate between them. Does this make sense?…
The above code is all you need to detect whether two boxes in 3D space touch
or overlap each other. This really isn't overly intensive. YOu can also
check for collision of spheres easily too, but it is a bit more expensive
than the above, but it is equally simple, relying on the Pythagorus theorem.
Basically you can just check the length of the line between the centers of
two spheres and see if it's less than or greater than the radii of each
sphere. So if the two radii add up to (or are greater than) the distance you
just found, then the spheres are touching or overlapping.
On the subject of arrays, (depending on the type of array) it's not
necessarily any less expensive to access an array vs doing something like
the above every frame of a game, since the system may need to move through
the array to find what it needs, regardless of how easy it looks to the
user. so just because you can call an element of an array as in array[x]
doesn't mean the system doesn't need to do any work to access that element.
There are faster ways of storing data which are easier on the system in C++
but I'm not as familiar with them as I'd like, so forgive me but I just know
they're there, but have no explanation for you. :)
Anyway, hope this sheds some light…
Smiles,
Cara :)
---
Gamers mailing list __ Gamers@audyssey.org
If you want to leave the list, send E-mail to gamers-unsubscr...@audyssey.org.
You can make changes or update your subscription via the web, at
http://audyssey.org/mailman/listinfo/gamers_audyssey.org.
All messages are archived and can be searched and read at
http://www.mail-archive.com/gam...@audyssey.org.
If you have any questions or concerns regarding the management of the list,
please send E-mail to gamers-ow...@audyssey.org.
Re: [Audyssey] game objects in memory
Yes Thomas, this seems to be a different approach than the popular one people
are taking here, in that it seems to kind of free up the programmer to use real
physics and constant relatively low-cost collision detection without needing to
worry so much on the exact position an entity will be in at any given time.
I.E. let the detection routine do the work and deal with the touches on an
entity by entity basis.
Touches and collisions can be dealt with uniquely, depending on the two or more
entities touching. Each entity has it's own touch routines that get called and
the correct results easily work for all the entities without so much
forethought on the part of the developer. I.E. Let the entity itself check what
touched it or create a short-lived object to represent the touch between two
entities and act accordingly. -It can be a very cool paradigm…
In essence, the map now has only the barest coordinates representing the actual
objects and the rest is just nothing! lol! So it's a whole lot less data to
manage. the down-side in my opinion, is that each type of map element really
needs to be defined in terms of active objects. I.E. a body of water really
needs to be it's own entity with a bounding box or some shape. Admittedly, it
could be represented with a really minimal amount of data, (three floats) but
still, it's still another object like a wall or door.
Sizewise though, maps really are a lot smaller than the array-based paradigms
we've been talking about now, and could be stored in files that are very small
text files.
I kind of like a combo approach, myself, as I've said, where the map uses a
straight 3D coordinate system, but still is divided into regions like rooms and
such. Anyway, -Just some thoughts…
Smiles,
Cara :)
On Dec 7, 2010, at 3:23 PM, Thomas Ward wrote:
Hi Cara,
Hmmm...I'm going to have to try that. When you put it like that it
looks pretty easy. Essentially, all I should have to do is create a
class to hold something like a wall and define its maximum x, y, and z
boundries and detect if the player comes into contact with any point
of the wall, door, whatever. I've got to try this as it sounds
interesting.
Cheers!
On 12/6/10, Cara Quinn caraqu...@draconisentertainment.com wrote:
Hi Rynhardt;
ACtually collision detection really isn't that expensive. Here's some C++
for checking two axis-aligned bounding boxes in 3D.
// set the lower and upper coordinates of each box
// and set their position
Box A (-1.0, -1.0, -1.0, 1.0, 1.0, 1.0);
A.setPosition (3.0, 3.0, 3.0);
Box B (-1.0, -1.0, -1.0, 1.0, 1.0, 1.0);
B.setPosition (0.0, 0.0, 0.0);
// check to see if any part of the above boxes touch or overlap
if((A.lower.x = B.upper.x A.lower.y = B.upper.y A.lower.z =
B.upper.z) (A.upper.x = B.lower.x A.upper.y = B.lower.y A.upper.z
= B.lower.z)) {
// Manage collision
}
In this case, the two boxes are not touching, as the bottom-most point of A
is at 2.0, 2.0, 2.0 and the top-most point of B is at 1.0, 1.0, 1.0 so
there's a length of one coordinate between them. Does this make sense?…
The above code is all you need to detect whether two boxes in 3D space touch
or overlap each other. This really isn't overly intensive. YOu can also
check for collision of spheres easily too, but it is a bit more expensive
than the above, but it is equally simple, relying on the Pythagorus theorem.
Basically you can just check the length of the line between the centers of
two spheres and see if it's less than or greater than the radii of each
sphere. So if the two radii add up to (or are greater than) the distance you
just found, then the spheres are touching or overlapping.
On the subject of arrays, (depending on the type of array) it's not
necessarily any less expensive to access an array vs doing something like
the above every frame of a game, since the system may need to move through
the array to find what it needs, regardless of how easy it looks to the
user. so just because you can call an element of an array as in array[x]
doesn't mean the system doesn't need to do any work to access that element.
There are faster ways of storing data which are easier on the system in C++
but I'm not as familiar with them as I'd like, so forgive me but I just know
they're there, but have no explanation for you. :)
Anyway, hope this sheds some light…
Smiles,
Cara :)
---
Gamers mailing list __ Gamers@audyssey.org
If you want to leave the list, send E-mail to gamers-unsubscr...@audyssey.org.
You can make changes or update your subscription via the web, at
http://audyssey.org/mailman/listinfo/gamers_audyssey.org.
All messages are archived and can be searched and read at
http://www.mail-archive.com/gam...@audyssey.org.
If you have any questions or concerns regarding the management of the list,
please send E-mail to gamers-ow...@audyssey.org.
---
Gamers mailing list __ Gamers@audyssey.org
If you want to leave the list, send E-mail
Re: [Audyssey] game objects in memory
You might be able to make a separate array called immediateEnvironment or
something like that which will periodically be updated, maintaining a list
of only near by objects to be considered.
-Original Message-
From: gamers-boun...@audyssey.org [mailto:gamers-boun...@audyssey.org] On
Behalf Of Rynhardt Kruger
Sent: Tuesday, December 07, 2010 5:31 AM
To: Gamers Discussion list
Subject: Re: [Audyssey] game objects in memory
Hi Cara,
The reason I thought the 3d array would be faster is:
Lets say you want to check if the player object moves into a wall when it
takes a step. In the case where every object has attributes for the 3d
coordinate, you have to search through all the objects currently in the
level and check if one of them is at the position of the players next
position. If all the objects are stored in a 3d array, it requires only
using the players next location as an array index and checking if an object
occupies that array element. In languages like c or c++, getting an array
element requires only the calculation of the correct offset in memory based
on the array index and element size and referencing that location in memory.
In this case I'd thought of storing wall-like elements in the array apposed
to rooms.
Another way might be to (as you said) give each object bounding coordinates
e.g. a left upper coordinate and a right lower coordinate and have all the
objects in an array or other data structure. May be having rooms in stead of
walls represented by objects will decrease the number of objects so the
search time isn't so big?
A reason I like this method is that rooms can have interesting shapes e.g. a
round room and that you can move a hole room to another location, possibly
moving everything inside as well to create a vehicle like object.
Take care,
Rynhardt
* Cara Quinn caraqu...@draconisentertainment.com [101207 07:53]:
Rynhardt;
-It occurred to me that I didn't completely answer your question in my
last note, so my apologies. :)
In my own personal opinion, yes, it's good to have map data in an array,
as well as using a flexible coordinate system as in my code example.
HOwever, even though game objects can still rely on a coordinate system to
move within the game, they can still be stored in an array as well.
I.E. one could use two arrays in-game; one to store the amount of active
entities and the other to represent rooms in a level. Within the rooms
array, game entities can freely move in 3D space using the usual 3D
coordinate system we're discussing.
this is one approach I personally like, but it's also not perfect in my
opinion.
For one thing, using one element of an array per room, can make it
difficult to accurately or easily map certain complex room layouts, though
on the up-side, it can be really easy to juggle and switch rooms around to
cause some really neat effects for cool game-play.
Perhaps my very fav mapping type would simply be to map out the entire
space with a coordinate system and simply take the 3D coordinate-based
physics approach and rely on collision management and such?
-Just my thoughts?
-Hope this comes closer to answering your questions / addressing your
comments?
Smiles,
Cara :)
On Dec 6, 2010, at 5:22 PM, Cara Quinn wrote:
Hi Rynhardt;
ACtually collision detection really isn't that expensive. Here's some C++
for checking two axis-aligned bounding boxes in 3D.
// set the lower and upper coordinates of each box // and set their
position
Box A (-1.0, -1.0, -1.0, 1.0, 1.0, 1.0); A.setPosition (3.0, 3.0,
3.0);
Box B (-1.0, -1.0, -1.0, 1.0, 1.0, 1.0); B.setPosition (0.0, 0.0,
0.0);
// check to see if any part of the above boxes touch or overlap
if((A.lower.x = B.upper.x A.lower.y = B.upper.y A.lower.z =
B.upper.z) (A.upper.x = B.lower.x A.upper.y = B.lower.y
A.upper.z = B.lower.z)) {
// Manage collision
}
In this case, the two boxes are not touching, as the bottom-most point of
A is at 2.0, 2.0, 2.0 and the top-most point of B is at 1.0, 1.0, 1.0 so
there's a length of one coordinate between them. Does this make sense??
The above code is all you need to detect whether two boxes in 3D space
touch or overlap each other. This really isn't overly intensive. YOu can
also check for collision of spheres easily too, but it is a bit more
expensive than the above, but it is equally simple, relying on the
Pythagorus theorem. Basically you can just check the length of the line
between the centers of two spheres and see if it's less than or greater than
the radii of each sphere. So if the two radii add up to (or are greater
than) the distance you just found, then the spheres are touching or
overlapping.
On the subject of arrays, (depending on the type of array) it's not
necessarily any less expensive to access an array vs doing something like
the above every frame of a game, since the system may need to move through
the array to find what it needs, regardless of how easy it looks
[Audyssey] game objects in memory
Hi, Another question to the devs on this list: What have you find to be the best way of representing the map and other game objects in software? Two ways I can think of is to either have everything in an big 3d array, or to give each object attributes specifying the 3d position. Advantages of giving each object an x y and z attribute: * objects can have floating point positions * uses less memory than the array method (not really an issue anymore) * More than one object can be in the same position (think of doors or walking through walls in SOD) * Possible for objects to be bigger than one unit e.a. having a start position as well as an end position Disadvantages: * Detecting collisions may be expensive as all the objects need to be searched to find an object at a specific position. Something like binary search may be useful, but then all the objects must be sorted every time an object moves. * Increasing the number of objects in the game may decrease performance as the list of objects to be searched gets longer. Advantages of the 3d array method: * Very fast to reference an object at a specific position. This makes path finding and collision detection very fast. * One object may be placed in several array locations, e.g. having a lot of references/pointers in the array point to one wall object. * If the array size stays constant, adding more objects will not have such a great effect on game performance. Disadvantages: * Not possible to have more than one object at the same position, unless each array location points to another list. * Not possible for an object to be bigger than one unit. * Not possible for objects to have floating point positions. Something I've missed? Another way might be to combine the two approaches, e.g. having all fixed objects like walls and floors be placed in a 3d array, and the movable objects like the player and items use the other method. What are your thoughts on this? Take care, Rynhardt --- Gamers mailing list __ Gamers@audyssey.org If you want to leave the list, send E-mail to gamers-unsubscr...@audyssey.org. You can make changes or update your subscription via the web, at http://audyssey.org/mailman/listinfo/gamers_audyssey.org. All messages are archived and can be searched and read at http://www.mail-archive.com/gam...@audyssey.org. If you have any questions or concerns regarding the management of the list, please send E-mail to gamers-ow...@audyssey.org.
Re: [Audyssey] game objects in memory
Hi Rynhardt;
ACtually collision detection really isn't that expensive. Here's some C++ for
checking two axis-aligned bounding boxes in 3D.
// set the lower and upper coordinates of each box
// and set their position
Box A (-1.0, -1.0, -1.0, 1.0, 1.0, 1.0);
A.setPosition (3.0, 3.0, 3.0);
Box B (-1.0, -1.0, -1.0, 1.0, 1.0, 1.0);
B.setPosition (0.0, 0.0, 0.0);
// check to see if any part of the above boxes touch or overlap
if((A.lower.x = B.upper.x A.lower.y = B.upper.y A.lower.z = B.upper.z)
(A.upper.x = B.lower.x A.upper.y = B.lower.y A.upper.z =
B.lower.z)) {
// Manage collision
}
In this case, the two boxes are not touching, as the bottom-most point of A is
at 2.0, 2.0, 2.0 and the top-most point of B is at 1.0, 1.0, 1.0 so there's a
length of one coordinate between them. Does this make sense?…
The above code is all you need to detect whether two boxes in 3D space touch or
overlap each other. This really isn't overly intensive. YOu can also check for
collision of spheres easily too, but it is a bit more expensive than the above,
but it is equally simple, relying on the Pythagorus theorem. Basically you can
just check the length of the line between the centers of two spheres and see if
it's less than or greater than the radii of each sphere. So if the two radii
add up to (or are greater than) the distance you just found, then the spheres
are touching or overlapping.
On the subject of arrays, (depending on the type of array) it's not necessarily
any less expensive to access an array vs doing something like the above every
frame of a game, since the system may need to move through the array to find
what it needs, regardless of how easy it looks to the user. so just because you
can call an element of an array as in array[x] doesn't mean the system doesn't
need to do any work to access that element.
There are faster ways of storing data which are easier on the system in C++ but
I'm not as familiar with them as I'd like, so forgive me but I just know
they're there, but have no explanation for you. :)
Anyway, hope this sheds some light…
Smiles,
Cara :)
On Dec 6, 2010, at 3:19 PM, Rynhardt Kruger wrote:
Hi,
Another question to the devs on this list:
What have you find to be the best way of representing the map and other game
objects in software?
Two ways I can think of is to either have everything in an big 3d array, or to
give each object attributes specifying
the 3d position.
Advantages of giving each object an x y and z attribute:
* objects can have floating point positions
* uses less memory than the array method (not really an issue anymore)
* More than one object can be in the same position (think of doors or walking
through walls in SOD)
* Possible for objects to be bigger than one unit e.a. having a start position
as well as an end position
Disadvantages:
* Detecting collisions may be expensive as all the objects need to be searched
to find an object at a specific position.
Something like binary search may be useful, but then all the objects must be
sorted every time an object moves.
* Increasing the number of objects in the game may decrease performance as the
list of objects to be searched gets
longer.
Advantages of the 3d array method:
* Very fast to reference an object at a specific position.
This makes path finding and collision detection very fast.
* One object may be placed in several array locations, e.g. having a lot of
references/pointers in the array point to
one
wall object.
* If the array size stays constant, adding more objects will not have such a
great effect on game performance.
Disadvantages:
* Not possible to have more than one object at the same position, unless each
array location points to another list.
* Not possible for an object to be bigger than one unit.
* Not possible for objects to have floating point positions.
Something I've missed?
Another way might be to combine the two approaches, e.g. having all fixed
objects like walls and floors be placed in a
3d array, and the movable objects like the player and items use the other
method.
What are your thoughts on this?
Take care,
Rynhardt
---
Gamers mailing list __ Gamers@audyssey.org
If you want to leave the list, send E-mail to gamers-unsubscr...@audyssey.org.
You can make changes or update your subscription via the web, at
http://audyssey.org/mailman/listinfo/gamers_audyssey.org.
All messages are archived and can be searched and read at
http://www.mail-archive.com/gam...@audyssey.org.
If you have any questions or concerns regarding the management of the list,
please send E-mail to gamers-ow...@audyssey.org.
---
Gamers mailing list __ Gamers@audyssey.org
If you want to leave the list, send E-mail to gamers-unsubscr...@audyssey.org.
You can make changes or update your subscription via the web, at
http://audyssey.org/mailman/listinfo/gamers_audyssey.org.
All messages are archived and can be searched and read at
http://www.mail-archive.com/gam...@audyssey.org.
Re: [Audyssey] game objects in memory
Rynhardt;
-It occurred to me that I didn't completely answer your question in my last
note, so my apologies. :)
In my own personal opinion, yes, it's good to have map data in an array, as
well as using a flexible coordinate system as in my code example. HOwever, even
though game objects can still rely on a coordinate system to move within the
game, they can still be stored in an array as well.
I.E. one could use two arrays in-game; one to store the amount of active
entities and the other to represent rooms in a level. Within the rooms array,
game entities can freely move in 3D space using the usual 3D coordinate system
we're discussing.
this is one approach I personally like, but it's also not perfect in my opinion.
For one thing, using one element of an array per room, can make it difficult to
accurately or easily map certain complex room layouts, though on the up-side,
it can be really easy to juggle and switch rooms around to cause some really
neat effects for cool game-play.
Perhaps my very fav mapping type would simply be to map out the entire space
with a coordinate system and simply take the 3D coordinate-based physics
approach and rely on collision management and such…
-Just my thoughts…
-Hope this comes closer to answering your questions / addressing your comments…
Smiles,
Cara :)
On Dec 6, 2010, at 5:22 PM, Cara Quinn wrote:
Hi Rynhardt;
ACtually collision detection really isn't that expensive. Here's some C++ for
checking two axis-aligned bounding boxes in 3D.
// set the lower and upper coordinates of each box
// and set their position
Box A (-1.0, -1.0, -1.0, 1.0, 1.0, 1.0);
A.setPosition (3.0, 3.0, 3.0);
Box B (-1.0, -1.0, -1.0, 1.0, 1.0, 1.0);
B.setPosition (0.0, 0.0, 0.0);
// check to see if any part of the above boxes touch or overlap
if((A.lower.x = B.upper.x A.lower.y = B.upper.y A.lower.z = B.upper.z)
(A.upper.x = B.lower.x A.upper.y = B.lower.y A.upper.z =
B.lower.z)) {
// Manage collision
}
In this case, the two boxes are not touching, as the bottom-most point of A is
at 2.0, 2.0, 2.0 and the top-most point of B is at 1.0, 1.0, 1.0 so there's a
length of one coordinate between them. Does this make sense?…
The above code is all you need to detect whether two boxes in 3D space touch or
overlap each other. This really isn't overly intensive. YOu can also check for
collision of spheres easily too, but it is a bit more expensive than the above,
but it is equally simple, relying on the Pythagorus theorem. Basically you can
just check the length of the line between the centers of two spheres and see if
it's less than or greater than the radii of each sphere. So if the two radii
add up to (or are greater than) the distance you just found, then the spheres
are touching or overlapping.
On the subject of arrays, (depending on the type of array) it's not necessarily
any less expensive to access an array vs doing something like the above every
frame of a game, since the system may need to move through the array to find
what it needs, regardless of how easy it looks to the user. so just because you
can call an element of an array as in array[x] doesn't mean the system doesn't
need to do any work to access that element.
There are faster ways of storing data which are easier on the system in C++ but
I'm not as familiar with them as I'd like, so forgive me but I just know
they're there, but have no explanation for you. :)
Anyway, hope this sheds some light…
Smiles,
Cara :)
On Dec 6, 2010, at 3:19 PM, Rynhardt Kruger wrote:
Hi,
Another question to the devs on this list:
What have you find to be the best way of representing the map and other game
objects in software?
Two ways I can think of is to either have everything in an big 3d array, or to
give each object attributes specifying
the 3d position.
Advantages of giving each object an x y and z attribute:
* objects can have floating point positions
* uses less memory than the array method (not really an issue anymore)
* More than one object can be in the same position (think of doors or walking
through walls in SOD)
* Possible for objects to be bigger than one unit e.a. having a start position
as well as an end position
Disadvantages:
* Detecting collisions may be expensive as all the objects need to be searched
to find an object at a specific position.
Something like binary search may be useful, but then all the objects must be
sorted every time an object moves.
* Increasing the number of objects in the game may decrease performance as the
list of objects to be searched gets
longer.
Advantages of the 3d array method:
* Very fast to reference an object at a specific position.
This makes path finding and collision detection very fast.
* One object may be placed in several array locations, e.g. having a lot of
references/pointers in the array point to
one
wall object.
* If the array size stays constant, adding more objects will not have such a
great effect on game
