Before shooting there's an expected FPS of around 900-1000. Firing all cannons at once drops this to 200. We plan on having multiple ships on screen at once, so this frameloss is pretty bad.

Here's how we're firing.

In the boat code we have:

dir = 0; MVector loc = new MVector(Location.x, 0.0f, Location.z); cannonball = new Cannonball(MyWorld, loc, dir, -11);

-11 is a multiplier (not important for front cannon)

---

Cannonball code:

switch dir case 0: this.Rotation = MMatrix.LookTowards(MVector.MakeDirection(theBoat.Instance.Yaw, 0, 145)); this.Location = loc + theBoat.Instance.Rotation.GetDir() + theBoat.Instance.Rotation.GetUp() * 1.5f; Velocity += Rotation.GetDir() * 25.0f; break;

Reality's built in gravity is too heavy for the cannonball to go far enough (If anyone knows how to adjust the gravity, do tell me!), so we had to find another way to kill off the cannonball.

Tried three ways, reduce its velocity, reduce its Location.y or set up a killtimer.

All three generally work the same:

Killtimer -= MHelpers.DeltaTime if (Killtimer <0) { destroy(); }

...except "use C++" lol. Due to time constraints, learning C++ isn't an option I'm afraid.

[This message has been edited by skynes (edited June 19, 2007).]

[This message has been edited by skynes (edited June 19, 2007).]

[This message has been edited by skynes (edited June 19, 2007).]

[This message has been edited by skynes (edited June 19, 2007).]

------------------
Visit my portfolio (and check out my projects):
www.JestermaxStudios.com

I've played with the side cannon code (the one really causing bother)

The Boat does this:

cannonball = new Cannonball(MyWorld, loc, dir, 0.5f); cannonball = new Cannonball(MyWorld, loc, dir, 1f); cannonball = new Cannonball(MyWorld, loc, dir, -0.5f); cannonball = new Cannonball(MyWorld, loc, dir, -1.0f);

This, along with the above post spawns 4 cannonballs at 0.5 forward, equal to ship, -0.5 and -1, in other words it looks like a broadside.

I heard from Patrick that by using C# with RE, it will use 4 times processor power that full detailed rendering uses, that's alot. Apparently you have to stick with C++.

I changed all the cannonball names to unique names. No more heavy FPS loss... DOH.

quote:

---

Originally posted by David Lancaster:
Are you using C# or C++.

I heard from Patrick that by using C# with RE, it will use 4 times processor power that full detailed rendering uses, that's alot. Apparently you have to stick with C++.

---

It's C#, we don't have the time to go to C++
---

While the topic is open, does anyone have any nifty tips and tricks regarding reality they'd care to share? Obscure code, undocumented functions, that kinda thing.

anything an arcadey pirate ship warfare game might need, lol.

[This message has been edited by skynes (edited June 19, 2007).]

quote:

---

Originally posted by skynes:
Just worked it out.

I changed all the cannonball names to unique names. No more heavy FPS loss... DOH.

---

Have you considered using an array or a list?

// List implementation List<Cannonball> cballs = new List<Cannonball>(); for (int cnt = 0; cnt < 4; cnt++) cballs.add(new Cannonball(MyWorld, loc, dir, (cnt * 0.5f) - 1.0f));

// Array implementation Cannonball cballs[4]; for (int cnt = 0; cnt < cballs.length; cnt++) cballs[cnt] = new Cannonball(MyWorld, loc, dir, (cnt * 0.5f) - 1.0f);

Just a thought -- it could possibly make it easier for ships to fire varying numbers of cannonballs in the future to use something like a list to store them all.

Good job figuring it all out though!

--clint

The Tick function of cannonball calls base.Tick() which updates all the physics.

Removing that line allows me over 600 cannonballs with 400FPS. However cannonballs do not move.

Having it allows me 20 ish to 300FPS. Cannonballs will move.

Any thoughts?

http://www.rendernetgames.com/phpBB2/

This is unofficial help since Artificial Studios no longer officially supports RE. Paul aka LordsWarrior (who is a Christian, btw) runs the site and he'll check you out for getting access. Just mention XrucifiX.

quote:

---

despite it using MS Visual Studio, we can't use that break point thing, because it doesn't actually RUN in Visual Studio.

---

Wow! That's strange...and frustrating.

Try putting each cannonball on its own thread. May help a little.

Does each new cannonball cause a hit to the FPS or is it just the first one? Does each new cannonball cause the same amout of framerate loss? Does the physics code have any static data which may get messed up if multi-threaded?

quote:

---

anything an arcadey pirate ship warfare game might need, lol.

---

Different types of ships. Big, bad, but slow. Small, weak, but very nimble. Different types of shots. Check out Sid Meier's Pirates for an example. I thought the ship battles were a nice blend of arcade and action.

Don't make it overly complicated. Or the opposite: Make it simple. Some of the pirate/ship games I've played are so involved I never really got passed the first tutorial. They tend to serve a small niche of players. Pirates, on the other hand, is very simple and very accessible to even the casual gamer.

quote:

---

Wow! That's strange...and frustrating.

---

Yep, I'm guessing it's because Reality uses VS for scripting, but to run the game you run its OWN Builder.

quote:

---

Try putting each cannonball on its own thread. May help a little.

---

How do you mean?

quote:

---

Does each new cannonball cause a hit to the FPS or is it just the first one? Does each new cannonball cause the same amout of framerate loss?

---

The Expected FPS flickers up and down constantly, so its impossible to tell precisely. Shooting one cannonball you don't notice. When you shoot 4 it's very noticeable.

quote:

---

Does the physics code have any static data which may get messed up if multi-threaded?

---

I've no idea. I don't understand how the underlying physics works.

quote:

---

Different types of ships. Big, bad, but slow. Small, weak, but very nimble. Different types of shots.

---

Got most of that. Since we only have 8 more weeks, we're keeping it very simple. Basic speed and strength power ups.

quote:

---

Check out Sid Meier's Pirates for an example. I thought the ship battles were a nice blend of arcade and action.

---

We're aiming for more frantic geometry wars style

quote:

---

Don't make it overly complicated. Or the opposite: Make it simple. Some of the pirate/ship games I've played are so involved I never really got passed the first tutorial. They tend to serve a small niche of players. Pirates, on the other hand, is very simple and very accessible to even the casual gamer.

---

It will be very simple as it's only a demo. We've to make enough to show the idea and how it could progress.

Another thing to check would be to see what flags/options you've got turned on for the cannonball objects. Are there such things as "collision groups" in RE? Basically, groups of objects that they can collide with?

You'll save yourself some time if only check as few collisions as possible (I.E., don't check cannonballs against other cannonballs, only against ships, and possibly the terrain)

If you have very accurate physics (such as inertia, rotation, wind friction) turned on for the cannonballs, that might be slowing you down as well (since physics are processed in the tick() function as well).

Also, if the engine has to make a special call into managed code for each tick() function, you might save time by doing a single TickCannonballs() function that calls a tick for each cannonball in a single call.

Just some thoughts.

--clint

I went a looked up the User Collision groups. I set the player's boat and the cannonballs to Group 1 and told cannonballs to IGNORE group 1.

Expected FPS sits over 1000 with me spamming cannons.

[This message has been edited by skynes (edited June 19, 2007).]

Regarding multi-threading...

Right now, if your game is not multi-threaded, each cannonball Tick is run one at a time. Cannonball A does its Tick, followed by B, then C, etc. In multi-threading, you can have multiple cannonballs processing their Tick at the same time. Even better on a multi-processor machine because each processor can process these multiple threads. So, while A is calculating its physics on thread 1, B is calculating its physcis at the same time on thread 2.

My favorite site for tutorials/examples is CodeProject. Here is an example of Threading in C#.

Since I have no idea how the cannonball Tick gets called (part of the framework? some timer?), I can't quite give an example of how you may use the Thread, but it may be something like requring you to create your cannonball inside of the thread.

The threading idea is not necessarily the ideal situation for your game. It sounds like there is some other fundamental issue which needs to be resolved. Multi-threading may improve performance, but it may also be masking an underlying issue.

Also, how many ticks are happening per second? Maybe the tick is happening too often. Try for 10/second first and see if things improve. If the tick is somehow tied to the actual FPS, then you will be processing a lot of physics, indeed! You don't necessarily want the tick to be equal to FPS.

EDIT: Aaah, looks like you have an answer! Cool!

[This message has been edited by ssquared (edited June 19, 2007).]

------------------
-I believe in faeries, goblins, dragons, ghosts, and computers that work perfectly.
-My guide to programming at work... <--Click Me

public class Politician extends Man {public void doSomething() throws UnreasonableException {throw new UnreasonableException(convenientExcuse);}}

[This message has been edited by gump (edited June 19, 2007).]

quote:

---

Originally posted by skynes:
Clint, I hand you a cookie. Any size you want, choc chip, nut, cinammon. whatever.

---

A cookie sounds wonderful -- though I'd settle for a high-five should we ever meet at one of the CGDCs.

--clint

We didn't write any of the physics or base.Tick(), it's part of the engine we're using and in part I'm grateful for it. Cause I was NOT looking forward to writing 3D collision-detection code, lol.

the documentation in a word... sucks, so it'll be no help.

With the adding of a collision group I've got the ex FPS to 900 with spamming cannonballs. Much better than a drop to 300. But still creating 9 Actors shouldn't drop the FPS that much, soooo more optimizing!

quote:

---

Also, how many ticks are happening per second? Maybe the tick is happening too often. Try for 10/second first and see if things improve. If the tick is somehow tied to the actual FPS, then you will be processing a lot of physics, indeed! You don't necessarily want the tick to be equal to FPS.

---

I tried limiting the number of ticks in the cannonball. The cannonball stopped moving, lol. Without base.tick there's no movement. So reducing the Ticks, reduces the movement.

---

quote:

---

A cookie sounds wonderful -- though I'd settle for a high-five should we ever meet at one of the CGDCs.

---

If I ever know I'm going to one, I'll let you know first

But,

quote:

---

Originally posted by skynes:
[B] Firing all cannons at once drops this to 200.

---

Wow, the complaint is that it drops to 200 frames per second?

Gee, well I guess I'd better switch engines.

lol

quote:

---

Wow, the complaint is that it drops to 200 frames per second?

---

One single ship shooting dropped it to 200 FPS. On a dual-core PC with a Geforce 8800 graphics card.

Now imagine a full game with 20+ ships all firing at once. Death by lag, lol.

Further changes:

I was using the same name for each cannonball

i.e.

quote:

---

Cannonball cannonball

cannonball = new cannonball();
cannonball = new cannonball();
cannonball = new cannonball();

---

By giving them unique names I was able to save another couple of hundred FPS.

We did have a particle trail on the end of the cannonballs. Even with these changes including it dropped FPS from 1100 to 200 again...

Our MODELLER of all people looked at the code and said "Here's your proble, you're recreating the particle trail every Tick!"

As so I was... making a whole new particle trail and destroying the last one every Tick. Bad bad bad...

So we made a particle trail as a hash, then just moved it.

Shooting 9 cannonballs, all with trails drops FPS from 1100 to about 1000. Vast improvement.

quote:

---

By giving them unique names I was able to save another couple of hundred FPS.

---

Or just do something like:

(new SmiteHoming(MyWorld, Target1)).Server_Init(eyeTransform.m3 + 1.0f * MHelpers.VectorDown, Owner.Rotation.GetDir(), Owner.Velocity + eyeRot * SmiteSpawnVelocity, 0, Owner);

And in the definition for cannonball have something like:

public void Server_Init(MVector location, MVector Direction, MVector velocity, int timingOffset, MActor creator) { Location = new MVector(location); Velocity = new MVector(velocity); TimingOffset = timingOffset; Rotation = MMatrix.LookTowards(Direction); if (creator is MNetworkActor) CreatorID = ((MNetworkActor)creator).objectID; if (creator is Pawn) IgnoreActor = ((Pawn)creator).GetOwnerToIgnore(); else IgnoreActor = creator; }

---

I made a big personal accomplishment on Friday.

This is a 3D game with a third person (ish) camera. Thus hitting objects screws the camera over cause it's now outside the game boundaries looking in. Very bad.

So I've been toying with code Thursday and 15 mins on Friday.

Now here's how it works, no code snippets I'm afraid cause I'm at home, so you'll have to live with my pseudo-variant, lol.

Get the next position the camera's going to move to.
Check to see if the camera collides with the environment
If it will, move it higher than normal and looking down at a sharper angle
If not, move it to its next position.

Really BIG thing for me to have done that. I know this method won't work in a lot of games, especially indoor ones. but since ours is in a bath, with no roof it's a good solution.

We also incorporated a 'drive-by shooting' cam. Where by pressing Q or E moves the camera to the left or right of the ship and looks to the other direction.

Check this please. Video update on how we're doing

What was that at the end where all of you vanished.

------------------
They will know that we are Christians by our love.

This was the first video we did, when we first did the disappearing trick.