1394 replies to this topic

[Pin-Pete]

White wall with Eala's Nitro Ground Shaker is still on.

Edited by Pin-Pete, 16 September 2013 - 09:05 PM.

[fuzzel]

It's getting harder for me to test the last 5 or so revs as VP crashes quite often when I hit PLAY table. I need to save the table now when just changing simple code for B2S.Server and hide DMD so I don't have to do it again after crash. When working on a table and making 2 minor changes, I don't like to save over my other version and I don't want a new save with each play test.

 

I really like the latest revs and thought maybe this would be a good point to stop adding new stuff, get a nice stable optimised version and then release a VP 9.16 or maybe even go to VP10 so we can really differentiate VP8, VP9 from  VP10 as this newest rev is miles away from the first VP9 release. Then proceed from there with new additions and new revs.

You're right. The latest revisions didn't introduce any new features. It's just cleaning up the project from old non used code and files. The only thing we want to achive is: speed and fixing the latest bugs. It seems that some "improvements" of the lastest revisions aren't that good for the compiler and produced "slow" and unstable code. Please check rev 665 it should be back to normal. The next revision will be evil as it is 666

White wall with Eala's Nitro Ground Shaker is still on.

Yep! Will fix it asap...this one was introduced with rev 645...

Edited by fuzzel, 16 September 2013 - 09:50 PM.

[htamas]

 The next revision will be evil as it is 666

 

That should be the official 9.16 release

[toxie]

We could go for a 9.1.666 (like doom 1 did :-) )

[htamas]

We could go for a 9.1.666 (like doom 1 did :-) )

 

Excellent idea

[Bob5453]

I used rev 673 for about 2 hours last night and had no crashes while working in the editor and hitting Play to test table. thanks toxie.

Edited by Bob5453, 19 September 2013 - 05:10 PM.

[unclewilly]

Don't know if you can answer this or not.
Do you guys have any idea of the performance hit if a lot of primitives are used.

The reason I'm asking is I have made some new pop bumpers that consist of 4 primitives.

They are basically the fp pop bumper meshes imported and textured. They are pretty sweet with the bumper ring and post animating. And the caps are alpha transparent.

The reason I'm asking is the table I'm working on will have a lot of primitive toys and befor I get to far into it is like to have an idea if I'm gonna need to scrap some to make up performance

[ICPjuggla]

It seems at least for me and my set up and testing, when a lot of primitives are used, I see quite a bit of slow down and stutter. :-(

[oooPLAYER1ooo]

yeah same here scott im not sure what the magic number is but when using say like 20 it gives extreme slowdown

[fuzzel]

That's another good example why DX7 sucks Let's say you have 1000 polygons for a primitive and if you have 20 of them you have 20000 polygons each frame. Together with blitting the areas which were pre rendered you have stalls on you graphics card. It all depends greatly how much other stuff is used e.g. alpha ramps. I'm afraid you have to try it out. A simple rule like "don't use more than 5 primitives" doesn't exist.

[toxie]

Yup, as soon as we can get rid of the infamous "region updates", and rendering everything/each frame from scratch, all these limitations should vanish, too..

[unclewilly]

That's ashame. Cause these pop bumpers are sweet.
I'll post a video in the next few days.

I assume we are a long way off from removing the region updates?

That may be ok as the pace I'm working at, probably won't see either of these tables till next year sometime.

Sometimes real life sucks
Thanks for the info and the work you guys are doing on vp

[toxie]

Removing region updates must come in combination with switching to DX9, i guess, so this will be where the development builds will suck majorly for some time. 

 

Also it has to come in combination with breaking some backwards compatibility, simply because the region updates and how they -exactly- are implemented are often abused for certain effects.

[unclewilly]

I'd rather have to fix older tables to get direct x 9.

Thanks toxie

[maceman]

As a 'potential' solution to UW's primitive question......Is there a way to implement "Instances" of Primitives rather than copies in VP?

 

I do not know the work involved, but I do know that the idea works. It was first implemented by Alias Wavefront some 15 or so years ago and was a lifesaver to animators at the time including myself. The basic concept is that you only make one primitive model. You make it as small in poly count as possible. Then once it is perfect, instead of copying it many time and thus duplicating the poly and adding work to the processors, you make an 'instance' of the object.

Instance is the term alias uses and it may be called other things, but it is the technology we are most interested in. How does this instance work to dupicate the shape without needing the poly's?

This link may be a bit complex for some, but for our Dev's it should be clear enough

http://misterdi.cgpo...e/instance.html

More on instances: http://download.auto...umber=d30e22204

 

This is the main concept I am proposing, but I have no idea if or how it could actually work in VP at this point. but thought i'd mention it regardless.

Cheers,

Maceman

Edited by maceman, 20 September 2013 - 03:33 PM.

[fuzzel]

actually that's not the problem. DX7 does a lot of things in software where newer versions of DX are using shaders. The next problem is that for doing the region updates DX has to flush the render pipeline and then it moves the region arround. Todays DX versions are fast because you do a lot of stuff in parallel and that's what we want to use in the future too. The "only" problem is that we have to rewrite the render engine completely to just get the same things we have today but a lot faster and with more possibilities to add new stuff to VP.

[ICPjuggla]

fuzzel, is it possible to move the Drawing order box to a different location?

 

It was much nicer to be able to see colors & formatting and position at the same time wile building, it saves some clicking and time during the building process.. :-)

[jimmyfingers]

Toxie / Fuzzel, will the move to DX9 allow us to do other things like potentially add ball spin physics?  Or is any physics element totally separate from the DX9 work / rendering engine build?  Even if it's totally separate, does going to DX9 at least open the door for physics changes that may one day include some detection / calculation for ball spin? 

 

Alternatively, do you think there would ever be a way of assessing / facilitating some type of ball spin in VP's current realm / state considering that it seems it actually happens to some degree graphically at least regarding the ball decals.   You can occasionally see the ball travelling normally / straight along a vector, but the decal will be spinning around an apparent other axis than the ball is travelling.  I was wondering if we could capture that data somehow that's spinning the graphic for the decal and utilize it to actually affect the physics of the ball from the rotational elements being applied to the decal rendering. 

[unclewilly]

How far off are we from begining to work on rewriting the render engine.

Don't take this as me rushing you guys. Just curious

[fuzzel]

fuzzel, is it possible to move the Drawing order box to a different location?

 

It was much nicer to be able to see colors & formatting and position at the same time wile building, it saves some clicking and time during the building process.. :-)

Hmm I could add another window for that...maybe another floating window not a modal one...

Toxie / Fuzzel, will the move to DX9 allow us to do other things like potentially add ball spin physics?  Or is any physics element totally separate from the DX9 work / rendering engine build?  Even if it's totally separate, does going to DX9 at least open the door for physics changes that may one day include some detection / calculation for ball spin? 

 

Alternatively, do you think there would ever be a way of assessing / facilitating some type of ball spin in VP's current realm / state considering that it seems it actually happens to some degree graphically at least regarding the ball decals.   You can occasionally see the ball travelling normally / straight along a vector, but the decal will be spinning around an apparent other axis than the ball is travelling.  I was wondering if we could capture that data somehow that's spinning the graphic for the decal and utilize it to actually affect the physics of the ball from the rotational elements being applied to the decal rendering. 

Well out first step is to port the render engine to DX9. The complete physics engine is a little miracle (well at least for me atm)

How far off are we from begining to work on rewriting the render engine.

Don't take this as me rushing you guys. Just curious

I think we can start in the near future. All the latest changes are more or less a preparation to make the porting a bit easier, and to get a better understanding how the code works (well at least for me )

But as I said earlier: It turned out that porting the engine step by step towards DX9 didn't work. We have to jump in at the deep end and rewrite the engine not completely but big parts of it. If we start to do that I suppose we

won't release a VP9.17+ version with new features. And maybe we can release a VP10 under DX9 in some months, maybe next year (keep fingers crossed)

Edited by fuzzel, 20 September 2013 - 11:03 PM.