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
Date: 13/12/2010 10:10 am
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
Date: 13/12/2010 10:10 am
omstances 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
Date: 13/12/2010 1:53 am
Hi Willem, right you are! -For me though, holy crap! I wouldn't feel at all
comfortab
the angles that are displayed need to be converted.
-original message-
Subject: Re: [Audyssey] game objects in memory
From: Cara Quinn
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 pref
the angles that are displayed need to be converted.
-original message-
Subject: Re: [Audyssey] game objects in memory
From: Cara Quinn
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 pref
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
Date
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 softw
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
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, an
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
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
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 yo
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
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 wa
Hey Thomas, no, I'd sure not want you to need to rewrite the engine! :)
However, you should simply be able to set your player's point of view so that
the world is oriented the way you want. I.E. With OpenAL I can set my
orientation so that Up is Z positive and ahead is Y positive just like you
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/w
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 wrote:
> Hi again Thomas;
>
> -A couple of
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 a
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, t
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 ada
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 ve
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,
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 wrote:
> Thomas;
>
> Thanks for sending this along and am happy to rewrite / s
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 t
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
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 suppos
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
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 j
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 wrote:
> Ben, yes.
>
> JQ is act
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 som
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
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 a
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
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 th
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 thro
] 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 th
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. L
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 wher
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
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 g
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 are
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 divid
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 tim
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
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
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 a
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, d
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
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.
Al
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
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 st
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
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
53 matches
Mail list logo
