Jump to content



Photo
* * * * * 12 votes

Dev thread: Road to DX9


  • Please log in to reply
2087 replies to this topic

#1 mukuste

mukuste

    Pinball Fan

  • VP Dev Team
  • PipPipPipPip
  • 854 posts

  • Flag: ---------

  • Favorite Pinball: Centaur

Posted 24 January 2014 - 11:24 AM

The official VP 9.9.0 has been released in the meanwhile! Go download that instead:

http://www.vpforums....showtopic=26226

 

-------

 

Downloads: Test1Test2Test3Test4Test5Test6Test7Test8Test9Test10Test11Test12Test13Test14Test15RC1

 

Table upgrade guide for DX9: https://github.com/c...e-Upgrade-Guide

DX9 table compatibility spreadsheet (thanks to gtxjoe): https://docs.google....EPwri8/viewform

 

 

----------- The post below is now out of date ---------------------

 

 

I decided to start a new thread to give people an idea what exactly I'm doing, as well as some kind of ongoing progress report.

 

What I'm trying to do, as some of you already realized, is to port VP to DX9. This is kind of the easiest target to shoot for, because it's still roughly similar in interface to DX7, but has much better driver and hardware support on modern machines. In particular, we have to get rid of DirectDraw, for which support is very spotty nowadays. The hope is that this will fix many of the compatibility issues that are plaguing VP right now, as well as give us better performance in certain aspects. Also it will give us access to cool features like shaders and so on, but that is for the future.

 

I know that I'm not the first to try my hand at this, but I'm kind of stubborn about this and won't give up until I have crashed and burned myself ;)

 

Road map

 

The general plan is like this:

  1. Get rid of all DirectDraw-specific functionality. In particular, this means that we must change the rendering of all moving objects like flippers, bumpers, spinners and so on from the current sprite-based technique to full 3D rendering. This will cost us some performance upfront. I hope that in the long run we can recoup most of that loss by the better hardware support in DX9 as well as optimization.
  2. Abstract the interface to the renderer. Right now, many places in the code refer to DX7-specific structures and methods. The idea here is to make as much of the codebase API-independent by providing an abstract renderer interface, so that all the DX-specific code is localized in just a few classes. This will also help immensely if, down the road, a port to, say, DX11 or OpenGL is desired.
  3. Once we have all our ducks in a row, so to speak, switch out the core rendering classes for DX9 versions. Hopefully, with a well-abstracted renderer, this will not be terribly intrusive. Of course, issues will certainly arise, but it should be nothing that's insurmountable.
  4. After this crucial step, the period of re-integration can start: put features back in which had to be disabled to make the jump, optimize all the render calls, do an overall clean-up pass over the code.

In order not to disrupt the mainstream VP development, I've started doing this in my own repository, separate from the official VP repo. You can have a look at it here: https://github.com/c-f-h/vpinball. My hope is that, once a proof-of-concept of the DX9 engine is up and running, this code can be integrated as a branch into the official VP repository and the other devs will maybe offer valuable support in the important step 4. This could form the basis for an eventual VP10 release, if the other devs deem it a good starting point.

 

Progress on step 1

 

The following objects have been converted to dynamic 3D rendering:

  • Flippers
  • Bumpers
  • Spinners
  • Gates
  • Plunger
  • Slingshot
  • Drop targets
  • Kickers (though they render a bit glitchy at the moment)
  • Lights

Still to do (might have missed some):

  • Textboxes
  • DispReel

A few are remaining, but this is in general an easy process and I can do a few per day when I put my mind to it. I'm doing this in a very brute-force way, basically just copying the stuff which was previously rendering into sprites into a per-frame dynamic render method. Typically, this is extremely inefficient. Make no mistake: performance is horrible at the moment. However, I have decided to put off all optimization until after the switch to DX9, both to get a DX9 proof of concept ASAP and because the performance characteristics will be different anyway, making it pointless to optimize for DX7 at this point.

 

UPDATE: Only a few three two are left, those are substantially harder though since they use more sprite functionality. I might just disable a few of them initially, just to get to the meat and potatoes of the actual port sooner.

 

Progress on step 2

 

I've also started on step 2, i.e., creating an abstract renderer interface. I've already ripped out many of the DX7-specific types and replaced them with generic typedefs. In many places, though, the structure of the code is still very particular to DX7 and will need to change. One particular area of trouble will be texture management, which will probably have to be rewritten in large parts. The other big thing is the initialization code, which works completely differently in DX9. I hope that this change can be localized, though.

 

UPDATE: I have a pretty good picture of how the rendering should be structured now. I'll have the RenderDevice, which already existed in the original code, deal with all the API-specific stuff, and all the classes that are built on top of it (most importantly Pin3D, Player) should only use its abstract interface instead of actual DirectX methods. I made good progress towards that goal today, the Pin3D class, which was the main offender, is now fully abstract. I had to disable a few features to get there however (AA, Stereo 3D). These ought to be put back in again in the reintegration phase. Texture management is still giving me a headache.

 

UPDATE 2: I made major steps here. Barring a few exceptions (basically the objects listed in step 1), all the API-specific code is now contained in three classes, namely RenderDevice, Texture and the legacy PinDirectDraw. I'm still not sure what to do with the latter, eliminate it completely or repurpose it into a general texture manager. Speaking of it, I also did major changes to the texture management code, eliminating heaps of duplicated code (I have to say this part of VP was an unholy mess before; entire functions existed in two, often subtly different versions) and cleaning up interfaces.

 

Progress on step 3

 

Baby steps. Since the interface is now solidifying, I started implementing a few methods of the RenderDevice in a DX9 version, just not to have to do all of those at once when the switchover starts. I don't compile this version yet though, since mixing D3D7 and D3D9 headers won't go down well.

 

UPDATE: The DX9 RenderDevice is maturing, the majority of methods is already implemented. I've also added a build switch which is used to choose between the legacy DX7 and the DX9 renderer. It doesn't compile yet on DX9 because of dependencies in other parts of the code (again, mainly texture management), but the DX9 RenderDevice class does compile at this point already. While I was at it, I also used the opportunity to do a clean-up pass over the general renderer interface, renaming methods, throwing out unused arguments and so on. It's definitely a lot cleaner now.

 

-----------------

 

That's all so far. I'll try to keep this thread updated as I go along, and hope to engage in discussions with the other devs here as to the best way of proceeding on the harder questions. Also if you have any questions or suggestions I'd be happy to hear them!


Edited by mukuste, 01 May 2014 - 06:38 AM.


#2 unclewilly

unclewilly

    sofa king.....

  • VIP
  • 5,047 posts
  • Location:Baltimore, Maryland

  • Flag: United States of America

  • Favorite Pinball: tz, tom, big hurt, who dunnit



Posted 24 January 2014 - 11:51 AM

Awesome. If there is anything I can do to help let me know.
Testing, providing 3d meshes for objects. Anything I can do

"it will all be ok in the end, if it's not ok, it's not the end"
 
Monster Bash VP10 WIP https://dl.dropboxus... (vpx)WIP15.vpx

uw2.gif


#3 JohnnyDoe

JohnnyDoe

    Enthusiast

  • Platinum Supporter
  • 238 posts

  • Flag: Sweden

  • Favorite Pinball: White Water

Posted 24 January 2014 - 12:39 PM

Although I'm not a programmer, this is really exciting to read about.

Thank you for your efforts mukuste.



#4 zany

zany

    3D Beer Drinker

  • VIP
  • 1,644 posts

  • Flag: Sweden

  • Favorite Pinball: Medieval Madness



Posted 24 January 2014 - 12:40 PM

Mukuste...this is awesome news, and very much needed!
Keep upp the fantastic work!!!!



#5 kruge99

kruge99

    Pinball Wizard

  • VPF Staff
  • 3,901 posts
  • Location:Markham, Ont.

  • Flag: Canada

  • Favorite Pinball: Black Knight, High Speed and Pin*Bot



Posted 24 January 2014 - 01:14 PM

I'm really excited about this!  One thing that might be over looked (and I hope that a programmer can clarify & verify this question) doesn't vpinmame rely on directdraw to put the "mame" interface on the screen?  ie: won't vpinmame require an update too?

 

 

Best Regards,

Todd.


[proud owner of a Williams Solar Fire]

- It's called "The American Dream" because you have to be asleep to believe it.
George Carlin
- Truly great madness cannot be achieved without significant intelligence.
Henrik Tikkanen
- "Reality check, Michelle, Talk about composure, Total lack of. He's a man-- About-- 12 Feet Tall--"
Carrie Kelly
Posted Image

#6 zany

zany

    3D Beer Drinker

  • VIP
  • 1,644 posts

  • Flag: Sweden

  • Favorite Pinball: Medieval Madness



Posted 24 January 2014 - 01:29 PM

Kruge...if so...what about the Unity3D version of VPinMame!??!



#7 bent98

bent98

    Pinball Fan

  • Members
  • PipPipPipPip
  • 1,077 posts
  • Location:NY

  • Flag: United States of America

  • Favorite Pinball: Roadshow, Haunted House, Safe Cracker

Posted 24 January 2014 - 01:47 PM

This is great news. Will be exciting to see your progress! Thank you for you dedication and time on this project.

#8 faralos

faralos

    VPF Veteran

  • Members
  • PipPipPipPipPipPip
  • 7,838 posts
  • Location:Eastern Pa,USA

  • Flag: United States of America

  • Favorite Pinball: Flash (Williams) 1979, Flash2 Updated




  • Trophies:

Posted 24 January 2014 - 02:17 PM

9.2 at the present time does not run well at all on my computer

 will this redo make it easier or less memory intensive?

 I mean 9.2 runs but the pins made with it don't due to all the newest do dads in vp

so will this revision make it run better/faster with less memory draw?


"Don’t let the noise of others’ opinions drown out your own inner voice.
And most important, have the courage to follow your heart and intuition.”
----Steve Jobs


#9 mukuste

mukuste

    Pinball Fan

  • VP Dev Team
  • PipPipPipPip
  • 854 posts

  • Flag: ---------

  • Favorite Pinball: Centaur

Posted 24 January 2014 - 02:20 PM

I'm really excited about this!  One thing that might be over looked (and I hope that a programmer can clarify & verify this question) doesn't vpinmame rely on directdraw to put the "mame" interface on the screen?  ie: won't vpinmame require an update too?

 

 

Best Regards,

Todd.

 

That's a very good point. Since PinMAME is a separate project, I haven't looked into it at all. My (shaky) understanding is that only the table scripts interact with PinMAME, but the VP engine itself doesn't call into it. Since it has its own window, I would hope that they can coexist, and since it usually only renders a small picture, I would expect it not to be a performance problem.

 

Does anyone know if its developers can be reached here? Maybe they overlap with the VP developers? It would certainly be good to ask them. I would expect that it has only a thin output layer which could be easily upgraded to a more modern API.

 

I will keep this in mind, thanks for the heads up!


9.2 at the present time does not run well at all on my computer

 will this redo make it easier or less memory intensive?

 I mean 9.2 runs but the pins made with it don't due to all the newest do dads in vp

so will this revision make it run better/faster with less memory draw?

 

That is hard to say. It depends a lot on your hardware. In general, the video card will have to work harder in the DX9 version, but presumably much more will be able to be done in hardware. So if you have a reasonably recent video card, I would expect tables with many dynamic elements to run better then, but I can't promise anything.


Edited by mukuste, 24 January 2014 - 02:17 PM.


#10 toxie

toxie

    VPF Veteran

  • VP Dev Team
  • PipPipPipPipPipPip
  • 5,659 posts
  • Location:berlin, germany

  • Flag: Germany

  • Favorite Pinball: AFM

Posted 24 January 2014 - 02:30 PM

VPinMame compatibility: This will not be an issue. Unity Pinball already uses it, and most likely we will end up with something similar they use, i.e. VP will directly manage the DMD or LCD segment output code natively. Especially as DX9 will support shaders, the quality of segments and dots will be much higher then (and i guess even speed, given that the interaction of VP and VPM rendering is so fragile nowadays).

 

Apart from that, great inititative mukuste, i hope you won't be turned off after a while. And please make sure that you merge the changes happening in VP trunk once in a while (as long as these are relevant, i.e. non-rendering specific).



#11 faralos

faralos

    VPF Veteran

  • Members
  • PipPipPipPipPipPip
  • 7,838 posts
  • Location:Eastern Pa,USA

  • Flag: United States of America

  • Favorite Pinball: Flash (Williams) 1979, Flash2 Updated




  • Trophies:

Posted 24 January 2014 - 02:33 PM

I have a crap video card it is a radeon x1300 series with only 256 megabytes

 guess I gotta trash one of the other towers I own for the Nvidia one then install it onto this one

thanks  for your fast reply!!


"Don’t let the noise of others’ opinions drown out your own inner voice.
And most important, have the courage to follow your heart and intuition.”
----Steve Jobs


#12 mukuste

mukuste

    Pinball Fan

  • VP Dev Team
  • PipPipPipPip
  • 854 posts

  • Flag: ---------

  • Favorite Pinball: Centaur

Posted 24 January 2014 - 03:08 PM

VPinMame compatibility: This will not be an issue. Unity Pinball already uses it, and most likely we will end up with something similar they use, i.e. VP will directly manage the DMD or LCD segment output code natively. Especially as DX9 will support shaders, the quality of segments and dots will be much higher then (and i guess even speed, given that the interaction of VP and VPM rendering is so fragile nowadays).

 

Apart from that, great inititative mukuste, i hope you won't be turned off after a while. And please make sure that you merge the changes happening in VP trunk once in a while (as long as these are relevant, i.e. non-rendering specific).

 

Good news about VPM, thanks for clarifying.

 

I absolutely keep the repository up to date with the SVN one! If you have a look on GitHub, I have three branches:

  • master: this is just the mainstream version of VP, no changes by me. I pull it regularly from the official repository to keep it up to date.
  • fixes: these are small, backwards compatible changes and improvements over master. In my opinion, these could be applied to the official SVN at any time without breaking anything, so if you are interested, I can send you a patch now and then.
  • dev: this is where the heavy lifting and breaking changes happen.

Both of the development branches are regularly brought up to date with master, so that they don't diverge from the SVN more than necessary.



#13 toxie

toxie

    VPF Veteran

  • VP Dev Team
  • PipPipPipPipPipPip
  • 5,659 posts
  • Location:berlin, germany

  • Flag: Germany

  • Favorite Pinball: AFM

Posted 24 January 2014 - 03:13 PM

sounds perfect to me, cool..



#14 fuzzel

fuzzel

    spaghetti code

  • VP Dev Team
  • PipPipPipPipPip
  • 2,818 posts

  • Flag: Germany

  • Favorite Pinball: yes I have

Posted 24 January 2014 - 03:54 PM

Mukuste, nice progress so far :) You're right on the texture management this one has to be rewritten for DX9 and this will interfere with a lot of aspects in VP. But if you managed to abstract the render interface this should be an easy step.



#15 Practicedummy

Practicedummy

    Multi-Level Madman

  • Platinum Supporter
  • 2,683 posts
  • Location:Indiana

  • Flag: United States of America

  • Favorite Pinball: I like multi-level pinball the most


  • Trophies:

Posted 24 January 2014 - 08:50 PM

This will be huge once your project is completed. I am hoping that other programmers may have some time to help on this becoming a reality. This may open the door for more people to be interested in VP and also maybe create more table authors in the process. :D


Edited by Practicedummy, 24 January 2014 - 08:51 PM.

I could have been smart, but I never learned anything by being smart!

 

 


#16 Joe

Joe

    Pinball Wizard

  • VIP
  • 2,336 posts
  • Location:60016

  • Flag: United States of America

  • Favorite Pinball: New Stern ones

Posted 25 January 2014 - 02:01 AM

VPinMame compatibility: This will not be an issue. Unity Pinball already uses it, and most likely we will end up with something similar they use, i.e. VP will directly manage the DMD or LCD segment output code natively. Especially as DX9 will support shaders, the quality of segments and dots will be much higher then (and i guess even speed, given that the interaction of VP and VPM rendering is so fragile nowadays).

 

Apart from that, great inititative mukuste, i hope you won't be turned off after a while. And please make sure that you merge the changes happening in VP trunk once in a while (as long as these are relevant, i.e. non-rendering specific).

what about building the Vpinmame into the VP code? will that be any better? any faster? Better to keep them on there own?

 

64bit builds?

 

what about open GL / moving off of windows only stuff?


Edited by Joe, 25 January 2014 - 02:02 AM.


#17 DJRobX

DJRobX

    Pinball Fan

  • VP Dev Team
  • PipPipPipPip
  • 941 posts
  • Location:Valencia, CA

  • Flag: United States of America

  • Favorite Pinball: F14 Tomcat

Posted 25 January 2014 - 05:58 AM

> what about building the Vpinmame into the VP code? will that be any better? any faster? Better to keep them on there own?

 

The method Unity is using is the shortest path.   Might as well start there, there's a lot of other work to do.

 

> 64bit builds?

 

DX9 port is needed first in order for this to happen, as DDraw isn't supported in 64 bit.

 

> what about open GL / moving off of windows only stuff?

 

He describes abstracting the renderer, which would be a gateway to OpenGL support.    The VBA scripting is one big enemy to portability.    Could consider adding a Mono script engine, but VPinball wasn't born to be a portable program, this would be a huge undertaking. 


Edited by DJRobX, 25 January 2014 - 05:59 AM.


#18 mukuste

mukuste

    Pinball Fan

  • VP Dev Team
  • PipPipPipPip
  • 854 posts

  • Flag: ---------

  • Favorite Pinball: Centaur

Posted 25 January 2014 - 09:57 AM

 

64bit builds?

 

what about open GL / moving off of windows only stuff?

 

 

Glad you asked, actually the first contribution I made to VP was an x64 compatibility patch. This means we can already compile VP for x64, we just can't play tables yet because of the DDraw issue. So when the DX9 port comes to fruition, an x64 version will be basically for free (I hope). The only thing that needs replacing is the music player library, but that should be easy (I'm looking at BASS here).

 

OpenGL would definitely be possible. However, in my current push, I'm still keeping some D3D-specific stuff, constants and data structures, as long as they are not D3D7-specific. This is to cut some corners and speed up the process. So some more work would have to be done there, but it's an option down the road.

 

The real question however is how big the benefit would be. As DJRobX already remarked, portability is not an option at this point. The scripting is done completely via COM, which is tied deeply into Windows internals. The editor, too. So that would be another major initiative.


Edited by mukuste, 25 January 2014 - 10:07 AM.


#19 bent98

bent98

    Pinball Fan

  • Members
  • PipPipPipPip
  • 1,077 posts
  • Location:NY

  • Flag: United States of America

  • Favorite Pinball: Roadshow, Haunted House, Safe Cracker

Posted 25 January 2014 - 01:25 PM

Would it be possible to integrate b2s support into vp natively?

#20 mukuste

mukuste

    Pinball Fan

  • VP Dev Team
  • PipPipPipPip
  • 854 posts

  • Flag: ---------

  • Favorite Pinball: Centaur

Posted 25 January 2014 - 01:29 PM

Would it be possible to integrate b2s support into vp natively?

 

Sorry, I'm still learning the lingo. What is b2s?