Thanks, the model for the front glass works. I am not getting any more problems with the balls leaving the board.

However, I still can't use sprites for balls. It's hard to explain. They work, but they don't move as well, and they get stuck in the funnels. Models look natural and go through the funnels without a hitch. For both models and sprites I have the bounding box set to sphere. How do I make sprites perform like the models?

Quote:

---

How do I make sprites perform like the models?

---

Make them into a model?

The problem you are running into I suspect is that when it comes to collisions, it's all about the contact points. The more points you have, the better the collision. One on One contact point collisions are unpredictable. I have no idea how they implement it, but a sprite will have contat points, by definition, simply "on plane". Thus maybe it has ONE point in the center or FOUR points at the corners (or interstitial) I dont' know, but you will go crazy trying to get a 2D flat surface to collide like a 3D surface.

This is also the reason you want to have a larger quant object to physically register; the larger the object, the more contact points; the more contact points, the stabler the system (though as was pointed out abover, this does cut into performace, thus a balance must be reached between stability and performance).

Yes, that must be what is happening, I think the sprites are behaving more like bouncy coins than balls.

It's going to be very difficult to keep the fps up with this.

Anyway, I made some progress today. I'll try and make the spinners tomorrow and maybe redesign the playing field.

Just some friendly advice...get your balls and playing field in order before you move on to spinners. I'm assuming that you want to maximize ball count in your project, thus the following scheme might benefit:

Every object you register with the engine will count against a Maximum number of PE registered entities you can field at once and keep the simulation "believable" (never realistic...just believable ). Your "quantum" object, the most basic physical object in your game is the steel ball; thus it seems natural to max out your playing field with no other physical objects and see how many balls you can field at once. This becomes you Bare Maximum.

You can now better analyze each new physical object you wish to introduce (spinners, gates, flippers) as counting against this Bare Maximum. In other words, how many balls would I have to take out to introduce this new physical object and keep my simulation running smooth.

This is not a hard and fast rule but rather something that might make your development a bit easier since it makes no sense to design a feature that has too large an impact on your ball count nor would it make sense to drop a feature if you only lose one or two balls by implementing it.

Right now, even forty balls onscreen at one time is pushing it. More than 60 and it will drop below 20fps, which in my opinion is unacceptable.

It's not just the balls. They are not the MOST important thing on the screen (though with a game like pachinko, the more the better, thousands are cool). The balls have to go through things like funnels and spinners to make it interesting, and to make it exciting they have to spit out the winning slot in the thousands!(litterally, when you win at pachinko, you have some big buckets of ball bearings to take to the counter -to take to that completely legal hole in the wall around the corner )

This thousands of winning balls spewing out troubles me, because it so important to the fun aspect of the game. For now I'll just concentrate on the main playing field. Just that is hard enough for now.

That's odd. Like I said, I had 100 entities onscreen @ 20fps no problem. Granted they weren't all moving very fast....hmmmm....60 might not be a unrealistic high end.

Here's how we can do this:
Finish the level...tweak it out real nice with all sorts of non-physics bells and whistles....don't do a lick of physics....send me your level balls included...I'LL tweak your physics settings and see if I can't get a few extra balls/fps.

Thanks Fastlane,

I think part of the problem is my level geometry. Trouble with BSB is that every damn thing needs to be a block. Once I start cutting into the backface to make holes for the balls to fall through and everything gets cut into triangles and the poly count rockets. I don't really want blocks since very little can really be hidden in this type of simulation anyway. Today, I did push my luck by making the pins eight sided. Realisticly, I think four sided is the minimum. Three sided and there is too much chance of a head on collision. I've had a bit of an attempt to search the internet for other pinball simulation development tips, but it hasn't turned up anything useful yet.

The physics are starting to look realistic. I'm starting to get the right number of balls on the screen and they are moving down at about the rate I'd expect from a real machine. Balls are still getting stuck in blocks (usually they find their way out again, but it looks funny). Balls are still getting stuck in funnels 'even if they are models). Also having a little trouble with SED's debugger showing me changes in some variable s (it doesn't like local variables, and some global ones too -don't know what is going on there).


I'm sure there are work arounds for all these things (dicking the balls when they stop moving, transporting balls in funnels, making goal entities instead of chopping holes...). However the more the physics engine can take care of without resorting to those measures the better. I've seen some pretty cool pinball simulations, and I wonder how they pulled it off.

I'm not going to give it up just yet, and the advice I'm getting from Marco and yourself is greatly appreciated.

Things are working much better now. I want to add a flipper to knock the balls out rather than just applying a force directly to them. I'm using a slider for this. I couldn't find an example of setting up a flipper and I'm having a little trouble with it:

Code:

---

function init_flipper()

{

   var constraint1;	



phcon_add(ph_slider, my, 0);

	ph_con_setparams2(constraint1, vector(50,0,0),nullvector,nullvector); //this gives an error

	

	while(my!=null)

	{

	

		temp.x=-spring+random(200)-100;

		temp.y=0;

		temp.z=0;

			

		//punch ball out shoot			

		phcon_setmotor(constraint1, temp, nullvector, nullvector); 

		

		sleep(1);

	}

}  

---

This wouldn't be a flipper, it would be the Ball Launcher...maybe they are known as flippers two in the "parlance", I don't know; I never was a pinball wizard



Seems like you haven't set you constraint axis vector:


Code:

---

 function init_flipper()
{
 	
  var constraint1[3]=1,0,0;	  



phcon_add(ph_slider, my, 0);
	ph_con_setparams2(constraint1, vector(50,0,0),nullvector,nullvector); //this gives an error
	
	while(my!=null)
	{
	
		temp.x=-spring+random(200)-100;
		temp.y=0;
		temp.z=0;
			
		//punch ball out shoot			
		phcon_setmotor(constraint1, temp, nullvector, nullvector); 
		
		sleep(1);
	}
}  
 

---

Okay, let's call it a ball launcher then. That is a better word. Thanks for that tip, though I'm still having trouble with my ball launcher. It behaves very strangely indeed:

Code:

---

//Ball launcher



constaint1[3]=1,0,0; //only allows movement on x axis?



function create_ball_launcher()

{

	temp.x=ball_pos.x+400; //put in position relativeto where ball is created

	temp.y=ball_pos.y;

	temp.z=ball_pos.z-130;

	

	ent_create("ball_launcher.wmb", temp, init_ball_launcher);	

}



function init_ball_launcher()

{





	phent_settype(my, ph_rigid, ph_box);

	phcon_add(ph_slider, my, 0);

	

	phcon_setparams1(constraint1, vector(1,0,0),nullvector,nullvector); // I thought that the second agument of this set the contraint axis?

	phcon_setparams2(constraint1, vector(-50,0,0),nullvector,nullvector);

	

	while(my!=null)

	{

	

		temp.x=-spring + random(200)-100;

		temp.y=1600000;

		temp.z=0;			

		//punch ball out shoot			

		phcon_setmotor(constraint1, temp, nullvector, nullvector);

		sleep(0.5);

		temp.x-=temp.x;

		phcon_setmotor(constraint1, temp, nullvector, nullvector);

		sleep(0.5);

	}

}

	

	  

---

The entity bobs around and spins.

Also, is there a way to stop the entity from spinning?