2087 replies to this topic

[arngrim]

where is the donate button

[mukuste]

where is the donate button

 

Haha No need for that. The community has given me so many great tables to play for free, so I can at least give back in this way.

[toxie]

Major milestone: after hacking away at dozens of compiler errors in the most brutal fashion, I can now compile VP under DX9! Furthermore I can start it up and create a table. Starting the player still crashes for various reasons which I'm mostly aware of, so that is expected, but so far so good.

 

cool, so now for the "fun" part.. 

[hotdp]

I have had the impression that a DX9 version would take years and years to do. But it sounds like it is progressing very fast.

 

What is different? Are you just super hardcore or what has changed? :-)

[GSGregg]

Hey---I just noticed what your 'favorite pinball' is---excellent choice!

 

(Psssst! Got any friends who might want to try getting Ball-Through-Flipper out of VP8? 

Oh, okay---never mind!) Great to have you involved; thank you!!

 

GSG

[mukuste]

I figure this is a good time to ask the other developers for their opinion on texture management.

 

As I'm sure you're aware, the current system immediately loads each new texture into a DirectDraw surface as it's brought into the editor. The player then just uses these surfaces for rendering. In addition, GDI HBITMAP versions are created on an as-needed basis when the editor wants to show textures (on walls, for instance).

 

Now we can't use this model with D3D9 anymore since the D3D device is only created once the player starts up, so we can't create D3D textures when only the editor is running. So my idea was to create a new class, say MemoryTexture or similar, which just stores the plain 32bit texture data plus some metadata (width, height, etc). From this "master copy", the player can upload D3D textures to video memory when it starts up (perhaps some TextureManager class should keep a reference to all currently loaded textures). Also, GDI bitmaps can easily be created from this plain memory representation. The only downside is that this would mean that we potentially store THREE copies of a single texture (plain memory, HBITMAP, and one in video memory) at certain points in time, although I think it's probably not that big of a deal. Also this could be mitigated by having the texture manager destroy all HBITMAPs when the renderer starts, meaning that we would have at most two copies of any texture at any given time. The editor will recreate the HBITMAPs as needed, as it already does.

 

The only other way I can think of is to have device-independent HBITMAPs as the "master version" of each texture, this would save the plain memory master copy of the texture. But I'd rather not subjugate myself to yet another Microsoft-specific data structure if I can avoid it, especially if it comes within a framework as awkward as GDI.

 

Opinions? Other ideas? Let me know.

 

-------

 

@GsGregg: You mean some bug in VP8? Do people still use that?

Edited by mukuste, 27 January 2014 - 01:17 PM.

[fuzzel]

Yeah the texture management is crazy in VP. What about loading textures in the editor only if the user activates 'Display Image in Editor' and when you press play destroys all images and let the player handles the textures for himself? This horrible GDI framework is damn slow and it doesn't matter if the user has to wait a second after pressing 'Display Image...' because of loading the image. With this approach you only have one copy of the texture in memory and player/editor handles them on their own and wouldn't waste additional memory if the user just want to play a table.

Keep in mind that the player needs all textures even if they are not assigned to any object. You can change the texture from within the script especially if all objects are dynamic in DX9

[mukuste]

>  What about loading textures in the editor only if the user activates 'Display Image in Editor' 

 

To my understanding this is already the case, since the editor calls EnsureHBitmap() on any texture which it wants to display, which creates the HBITMAP version for the editor to use (if it doesn't yet exist). Right now, it creates this HBITMAP version from the DD surface, which serves as the "master copy" of the texture.

 

> and when you press play destroys all images and let the player handles the textures for himself?

 

That's basically what I was suggesting above. To let the player create its own textures, it needs to know where to get their data, and my suggestion for this was to store the image data in a plain C++ array. You seem to be suggesting a model where we don't need this array, but I don't understand where the player would take the texture data from then?

Edited by mukuste, 27 January 2014 - 02:04 PM.

[toxie]

I have had the impression that a DX9 version would take years and years to do. But it sounds like it is progressing very fast.

 

What is different? Are you just super hardcore or what has changed? :-)

 

he just has no fear of the conversion. fuzzel and me were just too reluctant with just tearing everything apart so far and wanted to get VP9 "feature complete" first.

i hope this project will work out in the end.

 

 

As for the textures: i would basically also vote for a master array of textures (plain and simple RGB(A) storage), and then an on demand version for the editor (which is also skipped if VP directly launches into the player via the command line/external launcher) and a video memory upload for the player.

This way there will be multiple copies of stuff, but at least only twice the memory maximum, and also only on host and not on the gfxboard, where memory is usually more sparse.

 

I also wonder about optional pre-compressed textures. Would be nice to support them, but what about displaying these in the editor then?

Edited by toxie, 27 January 2014 - 02:50 PM.

[fuzzel]

+1

[mukuste]

I'll keep with my idea then, it seems.

 

What about making the editor use downsized versions of the textures if they are big? I think image quality isn't the biggest concern there?

[fuzzel]

Well yes but the details are important for placing the elements on the table

[mukuste]

And what have we here?

 

In case you didn't recognize it, this is our humble default table. I will concede that there are some minor graphical errors still to be ironed out, but apart from that, the game is absolutely playable!

Attached Files

•  2014-01-27 20_33_31-Visual Pinball Player.png   154.54KB   27 downloads

Edited by mukuste, 27 January 2014 - 06:40 PM.

[fuzzel]

cool flippers

[Slydog43]

what would you say are your chances for completing this huge task?  I don't want to discourage you, but others have tried.  I know its early, but you might have an idea if it is still possible, looks like your going gangbusters!  Thanks

[mukuste]

what would you say are your chances for completing this huge task?  I don't want to discourage you, but others have tried.  I know its early, but you might have an idea if it is still possible, looks like your going gangbusters!  Thanks

 

Right now I'm very optimistic that I will manage. I know the picture must look disheartening to a non-developer, but I was actually very happy when I saw that. It proved to me that the initialization and render loop are working. Basically, the heavy lifting is done. From here on out, all that is left to do is to fix bugs, then re-enable the features that were disabled, and optimize. These are now all small, incremental things. We took the leap: we are in DX9 land now.

 

Basically, I know why most of the things in that screenshot look like that, and I know how to fix them. (Bar the weird flippers, but that's probably a simple index bug.) Another way to put it is that, if you look back at my little roadmap, we are in step 4 of 4 already.

Edited by mukuste, 27 January 2014 - 07:24 PM.

[fuzzel]

very very nice progress mukuste. If this works out as expected we could have a first DX9 beta version around eastern if nothing bad happens

[mukuste]

At this point I should say that I already love this community. All the encouraging comments here, as well as the super nice messages that are flooding my inbox... you guys rock! Special thanks to Grizz who made me this avatar I'm trying on for size right now.

[toxie]

haha, very cool first pic..

 

looking forward to the next pics, if you progress at this rate then we will have the first beta even earlier, just give us some time to release 9.2.1 first..

[mukuste]

There, this is better. Knew it had to be some minor thing.

 

 2014-01-27 22_21_44-Visual Pinball Player.png   80.79KB   90 downloads