666 replies to this topic

[arngrim]

yeah i know but it is not that easy, especially with a rotated screen and when there are multiple objects at the same place, i prefer to throw a ball, didn't test the latest build yet

[fuzzel]

@fuzzel: now that we have mouse support in the input code, wouldn't the touchscreen feature that somebody asked before be a piece of cake?

(basically touch is translated to mouse clicks if one doesn't handle it explicitly, right?!)

 

would be killer to be able to play VP on tablets (even if its only windows based ones)

I don't know how windows handles the touch input. If it's just a left-click I could virtually divide the playfield and clicking on the left side -> left flipper, clicking on the right side -> right flipper. But testing isn't possible here.

[unclewilly]

I'll test it, just need for someone to send me a windows tablet.

[fuzzel]

lol

[koadic]

I happen to have a windows tablet... a samsung ativ tab 7 (most recent iteration of Samsung ATIV Smart PC Pro 700T) with an i5 processor and intel hd4000, so I could test it out although I would have issues running certain tables...

[toxie]

I guess it could work, here is some useful info on how to detect if mouse events came from touch originally: http://the-witness.n...otally-bananas/

[jimmyfingers]

Next thing you know fuzzel will add ball spin and adjustable physics curves

Ball spin....ball spin... 

 

Still curious with the long path before dx9 / Open GL and real / dynamic environmental lighting options, on whether you think you guys will ever crack open a bit of the physics and maybe see if something like ball spin could be worked out.  I think that's arguably the biggest thing missing on the physics side of VP and would be a game changer to be able to get going in some form.  As I menionted before, there is that odd observable behaviour in the ball decals that makes it look like indeed there is some type of graphical calculation going on regarding spin as you can watch the decals spin around the ball even when the ball is gonig a different direction or standing still / craddled on the flipper (had been hoping that that aspect could maybe be leveraged at least to read some data that the graphics are using and maybe either write it into the code or expose some values for another custom routine possibly - probably the most trigonometric yet!).

 

As always, much appreciation for all the stuff you guys are doing and all kidding aside, a few things on the physics side (like spin and maybe ball weight / density) could be a really nice addition / feature to the progress of VP.  Still, on the kudos side, the additve alpha flashers have been awesome and really have helped created some amazing lighting action - looking back only a couple years ago there was just the beginnings of the alpha flasher which was a game changer of it's own but when I look at the difference with addtive alpha options all flashers (and even the newer GI styles) can make the lighting just look that much more realistic.  Heck, that's why I'm onto hounding you guys for physics now instead

[fuzzel]

sigh...the physics yes I know this area needs some improvement. I would love to improve that if I would ever understand the way how this custom physics engine works...It's a mess without any documentation around...

[DJRobX]

Little bugfix ... if you turn hardware acceleration off, VP will crash if there are any alpha ramps, because of the bolded code:

 

void Ramp::RenderStatic(const RenderDevice* _pd3dDevice)
{    
   RenderDevice* pd3dDevice = (RenderDevice*)_pd3dDevice;
   if (!m_d.m_IsVisible) return;        // return if no Visible

   // dont render alpha shaded ramps into static buffer, these are done per frame later-on
   if (m_d.m_fAlpha && g_pvp->m_pdd.m_fHardwareAccel) return;

 

Elsewhere there is code that skips initialization of the static vertex buffer if it's an alpha ramp, so the above hardware accel check causes it to proceed to try and render to a null staticVertexBuffer.

 

To fix, add the corresponding check so the static buffer is created correctly:

 

void Ramp::RenderSetup(const RenderDevice* _pd3dDevice)
{
   RenderDevice* pd3dDevice = (RenderDevice*)_pd3dDevice;

   rgvInit = GetRampVertex(rampVertex, &rgheightInit, NULL, &rgratioInit);

   solidMaterial.setColor( 1.0f, m_d.m_color );
   habitrailMaterial.setColor( 1.0f, m_d.m_color );
   habitrailMaterial.setPower( 8.0f );
   habitrailMaterial.setSpecular( 1.0f, 1.0f, 1.0f, 1.0f );

   if( !staticVertexBuffer && m_d.m_IsVisible && !(m_d.m_fAlpha && g_pvp->m_pdd.m_fHardwareAccel ))

Edited by DJRobX, 03 January 2014 - 10:39 PM.

[bent98]

sigh...the physics yes I know this area needs some improvement. I would love to improve that if I would ever understand the way how this custom physics engine works...It's a mess without any documentation around...

You guys are very smart. I am sure you can figure it out.

[toxie]

I looked at the code a lot and apart from being able to clean up some of the historical mess and optimize some, its really hard to get what's going on..
What would also help there would be to increase the physics update rate from 100hz to something larger (lag reduction), but even this is not trivial..

[maceman]

Just tried the latest build with Apollo 13. Unbelievable with the balltrails and flashers.

You guys are amazing!!

Love all the new features

Maceman

[sleepy]

Ball Spin. Could that be accomplished by identifying the cross-sectional to the radius of the ball at 22.5 degrees as the fulcrum point of a ball's radius, think in terms of a leverage. Let's say the fulcrum point of a ball is at the first 25% (22.5 degrees) of the ball's radius when the radius is measured from the ball's circumference as the 0 (Zero) degrees starting point to the 25% mark as the fulcrum / end point, and then the spin would be determined when that value of the ball's radius (from 0 to 25% of the outer radius) strikes a glancing collision with an Object at a banking angle of less than 45 degrees, which would provoke an inverse spin powered from a percentage of the ball's .VelY or other .Vel values against the otherwise linear direction when banking off of an Object? Or a vertical spin of same when the ring of a Bumper strikes the ball downward.

 

Kind of like spinning or palming a bicycle wheel or a video game trackball by sweeping across the surface with your hand.

 

Is any of this description clear? Just a thought. 

 

EDIT: The linear banking angle of the ball-to-Object probably needs to be expressed as a Range from 22.5 degrees to 45 degrees Relative  angle since uplane shots and Orbits around the table would stall the ball in a spin on a direct line shot with an angle of less than 22.5 degrees otherwise.

Edited by sleepy, 04 January 2014 - 04:46 AM.

[gtxjoe]

New feature alert! With rev 839 you can throw balls inside the player with your mouse. I liked that feature when I saw it the first time in U3D Pinball. To use this feature you have to check under Preferences -> Editor Options -> "Throw Balls in Player".

When activated a left click will create a ball at the mouse cursor. If you hold the left mouse button and move the mouse the ball will be thrown in that direction when you release the left mouse button. A left click on a non moving ball will reuse the ball instead of creating a new one. A right click on a ball will remove it from the table.

 

Here is a short video showing that feature in action: http://youtu.be/nTqfxRLoT44

 

Edit: Using that feature on already released tables can give you script errors. The reason for this is that most scripts keep track of the created/destroyed balls on the table and if you create/destroy additionally balls you can screw up the script logic. So just keep that in mind

 

Could left click be changed to re-use the active ball on the table if one exists.  If no ball exists then it could create one, and then that would become the active ball (unless of course it gets destroyed). This would be more likely to work on fully scripted tables successfully.

Edited by gtxjoe, 04 January 2014 - 05:26 AM.

[fuzzel]

you can grab a ball with left clicking on it, but you can only grab a non moving ball. Look at the video I used that there.

[kiwi]

Is possible select the height where the ball is created ?
I have a table field 50 units high and the ball is created-deleted
not in the place where I put the mouse pointer, is a bit more up.

 

Thanks

 

Max

[fuzzel]

ok I had a look at the ball physics and I think the spinning calculation is already there. There some magic numbers in the code but the core calculation seems to be correct. I think the ball decals are the problem as they are just hacks to create an illusion of a real ball. I have made a test weeks ago where I replaced the ball with a reall 3D primitive but I didn't check the ball spin. The reason why the ball primitive isn't in the code now is that it can slow down the game play on multiball. One ball has around 200-400 polys and games like Apollo 13 will be unplayable with an extra 5000 polys rolling around
But I think I have to look into that again because you could get ball decals without an extra calculation because of the multitexture support of DX.

Is possible select the height where the ball is created ?I have a table field 50 units high and the ball is created-deletednot in the place where I put the mouse pointer, is a bit more up.
 
Thanks
 
Max

I could add a text field in the debug window where you can enter the height but that would mean all balls would be created at that height.

[arngrim]

Purpose is to throw balls on the fly quickly.

I'm wondering if it is possible to restrict the throwed balls to 1, like when you try to throw a second ball, it destroys the first one before?

[destruk]

I don't know if this issue still exists, but when setting the X/Y/Z ball coordinates VP 'drags' the ball to where you are telling it to be moved to.

Would it be possible to simply not draw the ball at the old location, and then draw the ball at the new location instantly?

[koadic]

I have never noticed any 'dragging' when moving the ball manually in the script by setting the x/y/z coordinates, and I have made use of it a lot especially in tables like Hurricane where I move the ball inside the wheel that way. The only issue I have come across is if I do it when the ball ISN'T locked inside a kicker, as the ball will then have some residual velocity and slightly disrupt the animation.