Umm....
Well, there you go. Hackers vs C++ grad.
SteeringController
Moderator: Moderators
I like that killer Doom-level jph 
The way I see it is that SteeringController is written for 2d-games using the default camera setup. This is demonstrated in the Steering-project that comes with ZGE. There is nothing stopping you from using it in 3d-games as long as the movement is in 2d. This I believe is what jph is using for most of his projects. The alignment of the camera in ZGE is what I considered being the most intuitive for me when I wrote the original code. But in all 3d-projects I'm involved in I always need to have the axis alignment written down in a textfile or on paper to remind me which direction positive Z is in.
As I mentioned before SteeringController could be implemented for 3d-movement, but there are many other hurdles for making full 3d-games with ZGE that in my opinion have higher priority. The adjustheading-property is buggy because in makes twitchy adjustments so if you have a suggestion on how to fix it I'll gladly update the code. If I understand correctly you suggest having properties that would make SteeringController work with another camera alignment, and I guess this could be implemented without much work.
However I'm not sure I agree that the SteeringController is something that scare away newcomers . I would be surprised if they even find it. Probably they download ZGE and find that the user interface is too confusing and not very welcoming with built-in wizards and tutorials, and stop using it long before reaching the point of actually trying to build something. The fact is that ZGE is currently a niche product for graphical experiments and simple games. It is not very easy to use, mainly because of two reasons:
1. Making a clear and simple user interface is a difficult task and it is not my specialty. I rather focus on adding features in the engine because that's what I'm good at. It would require another developer to work exclusively on the user interface to make real progress. Video tutorials are also important and I hope to add a couple to the wiki when Kjell (or someone else) have them ready.
2. It is the one of the primary design decisions to keep the ZGE runtime very small. This sometimes makes me choose between making a component easy to use OR keeping the runtime small. I try to balance between the two, but consider the size option more important because that is what makes ZGE unique. However no one (definitely less than 1% of potential users) cares about small runtime size so it will probably stay pretty lonely here on these forums for the foreseeable future . This is a shame and I would have thought the 1.9.9 release would attract at least a couple of new active forum members.
The way I see it is that SteeringController is written for 2d-games using the default camera setup. This is demonstrated in the Steering-project that comes with ZGE. There is nothing stopping you from using it in 3d-games as long as the movement is in 2d. This I believe is what jph is using for most of his projects. The alignment of the camera in ZGE is what I considered being the most intuitive for me when I wrote the original code. But in all 3d-projects I'm involved in I always need to have the axis alignment written down in a textfile or on paper to remind me which direction positive Z is in.
As I mentioned before SteeringController could be implemented for 3d-movement, but there are many other hurdles for making full 3d-games with ZGE that in my opinion have higher priority. The adjustheading-property is buggy because in makes twitchy adjustments so if you have a suggestion on how to fix it I'll gladly update the code. If I understand correctly you suggest having properties that would make SteeringController work with another camera alignment, and I guess this could be implemented without much work.
However I'm not sure I agree that the SteeringController is something that scare away newcomers
. I would be surprised if they even find it. Probably they download ZGE and find that the user interface is too confusing and not very welcoming with built-in wizards and tutorials, and stop using it long before reaching the point of actually trying to build something. The fact is that ZGE is currently a niche product for graphical experiments and simple games. It is not very easy to use, mainly because of two reasons:1. Making a clear and simple user interface is a difficult task and it is not my specialty. I rather focus on adding features in the engine because that's what I'm good at. It would require another developer to work exclusively on the user interface to make real progress. Video tutorials are also important and I hope to add a couple to the wiki when Kjell (or someone else) have them ready.
2. It is the one of the primary design decisions to keep the ZGE runtime very small. This sometimes makes me choose between making a component easy to use OR keeping the runtime small. I try to balance between the two, but consider the size option more important because that is what makes ZGE unique. However no one (definitely less than 1% of potential users) cares about small runtime size so it will probably stay pretty lonely here on these forums for the foreseeable future
. This is a shame and I would have thought the 1.9.9 release would attract at least a couple of new active forum members.There's something to be said for not making it too easy to use. There's lots of forums for easy apps, that are kid spam magnets. It's quiet, respectful, and fairly intellectual here. I like it. I'll just keep cobbling together some form of documentation so there is at least some clear path to an objective, no matter how meandering.
"great expectations"
JPH could you do a benchmark for me?
Try to see what the differences are if you turn on or off the depthsorting in your code, and see if the differences are really big or not-so-terrible.
Try to see what the differences are if you turn on or off the depthsorting in your code, and see if the differences are really big or not-so-terrible.
In the fall of 1972 President Nixon announced that the rate of increase of inflation was decreasing. This was the first time a sitting president used the third derivative to advance his case for reelection.
-=Hugo Rossi=-
-=Hugo Rossi=-
-
jph_wacheski
- Posts: 1005
- Joined: Sat Feb 16, 2008 8:10 pm
- Location: Canada
- Contact:
kjell - how do you get your benchmark numbers?
I am just increasing the number of demons till i see frame rate drops,. must be the Behaviors that are the main bottleneck here(?) as i don't see much difference with the depthsorting on or off (350 demons = 55-58 fps on my setup, and I get a solid 60 with <300 of 'em)
I suppose I could write a single processor that updates all of the demons in steps so I can set an update rate for their movements,. (I was just going to build a little room based shooty game
so 300 is enouph ) It is interesting to push the limits and see where things are being slowed though,. the built in depthsorting seems ok,.
I am just increasing the number of demons till i see frame rate drops,. must be the Behaviors that are the main bottleneck here(?) as i don't see much difference with the depthsorting on or off (350 demons = 55-58 fps on my setup, and I get a solid 60 with <300 of 'em)
I suppose I could write a single processor that updates all of the demons in steps so I can set an update rate for their movements,. (I was just going to build a little room based shooty game
so 300 is enouph ) It is interesting to push the limits and see where things are being slowed though,. the built in depthsorting seems ok,.iterationGAMES.com
Growth is not exponential but quadratic: in "standard" situations you should see the computational cost to go like (# of monsters)^2, so doubling the models reduces performance by 4; the important thing is that the models must be randomly placed and not "almost already sorted" otherwise the number is really little significant.
Then, it should be getting something like 1.3% slower with 2.500 models, that's plenty for our use.
Then, it should be getting something like 1.3% slower with 2.500 models, that's plenty for our use.
In the fall of 1972 President Nixon announced that the rate of increase of inflation was decreasing. This was the first time a sitting president used the third derivative to advance his case for reelection.
-=Hugo Rossi=-
-=Hugo Rossi=-
Of course, makes sense .. should have thought about it a bit instead of just looking at the numbers
I guess it depends on your CPU though at what model-count the curve suddenly starts to shoot up.It's a little tricky doing benchmarking in ZGE since the FPS is capped at your refresh rate ( didn't "Free" used to be uncapped though? ), so you have to find "points" on the performance curve that are below the cap, but are not too far away from to the cap otherwise you lose "resolution".
@jph - Depends on what you want to measure, but basically it all boils down to the FPS.
K
Not to be sorry.
After sleeping on this, I can see how this thread has lead to useful code being produced for a number of aspects of the loosely defined "2 1/2 D" genre.
Kjell's
J.P.H.'s code - converted to the norm
<ZLibrary>
<Source>
<![CDATA[ float Point_Direction(float X,float Z,float X2,float Z2){
return atan2(X-X2, Z-Z2)/(2*PI);
}]]>
</Source>
</ZLibrary>
<ZExpression>
<Expression>
<![CDATA[
CurrentModel.rotation.Y =
Point_Direction(CurrentModel.position.X,
CurrentModel.position.Z,
app.cameraPosition.X,
app.cameraPosition.Z); //always face camera]]>
</Expression>
</ZExpression>
would be best for a row of static tree sprites, where each faces a slightly different angle, the result being they all always face the camera.
After sleeping on this, I can see how this thread has lead to useful code being produced for a number of aspects of the loosely defined "2 1/2 D" genre.
Kjell's
is best for a single, dynamic model no matter what is up.CurrentModel.Rotation.Up = App.CameraRotation.Up*-1; // CurrentModel being the Sprite
J.P.H.'s code - converted to the norm
<ZLibrary>
<Source>
<![CDATA[ float Point_Direction(float X,float Z,float X2,float Z2){
return atan2(X-X2, Z-Z2)/(2*PI);
}]]>
</Source>
</ZLibrary>
<ZExpression>
<Expression>
<![CDATA[
CurrentModel.rotation.Y =
Point_Direction(CurrentModel.position.X,
CurrentModel.position.Z,
app.cameraPosition.X,
app.cameraPosition.Z); //always face camera]]>
</Expression>
</ZExpression>
would be best for a row of static tree sprites, where each faces a slightly different angle, the result being they all always face the camera.
"great expectations"