2087 replies to this topic

[Ark Malmeida]

Really outsanding work mukuste!  It's incredible that you've been able to get a table playable at a good frame rate in such a short period of time - can't wait to see where this goes next!

 

 

 

 

[mukuste]

mukuste,

 

what kind of rig are you testing it on (what cpu, memory, os, graphic card)?

 

great work, please stay with it! we all love it

 

It's a Dell laptop, about 2 years old, Win 7 64bit, with some Intel i7 quadcore CPU, 8 GB RAM and an Nvidia 540M GPU. Most desktop GPUs that you might have should perform better than this laptop. You can use this chart to get an idea how fast your card is: http://www.tomshardw...iew,3107-7.html (higher up is better, search for 540M to see where my card places).

 

I might release a first DX9 test version over the weekend, just to get an impression how compatibility and initial performance measure up so far. No promises, though.

Edited by mukuste, 07 February 2014 - 01:59 PM.

[boiydiego]

+100000

did you try to inject monster bash killer edition into the dx9 vp9 version? i wonder how many fps it runs, and compared to vp9 dx7 version

 

yes want to know that to it is shitty gameplay at the moment !!!! please if you take a test table take the new monster bash high version FS !!!

 

TAKE MONSTER BASH KILLER EDITION , TAKE MONSTER BASH KILLER EDITION pleaaase ;-)

 

thx in advance

Edited by boiydiego, 07 February 2014 - 03:00 PM.

[The Loafer]

Ok, let's be careful with the words ok? The new MB does not have shitty gameplay. I know what you meant is bad performance but jts not one and the same and not fair to UW and this can only lead to derailment of this thread,

Mukuste: that would be great, I would recommend though disabling the save portion so people don't start tweaking tables. I am sure that at the point you are at, lots of changes are coming that would negate anything "build" with this version in a short time. I am no programmer but deal with people who code, so I think you know where I am getting at , but just a suggestion of course. It may be too difficult to disable saving for example.

... In saying that I am turning the big 50 in a short time and I would consider it a heck of a birthday present if you did lol

Glad I took the day off to rest and surf VP sites today, very fulfilling day lol

[jimmyfingers]

Please do not disable the save - I disagree that that should be removed from an initial test version.  Far from wanting to release any table with the first DX9 build, I (and imagine others) will be testing and playing around a lot with it and having to retype code or reconfigure table objects each time because save is disabled will be a huge and unnecessary time waster. 

 

I do agree that nobody should really start building / releasing any tables with this very early version (probably even any initial DX9 / VP10 builds) whenever it arrives, but that can even be moderated at the forum level and Noah (and other site admins) can remove posts about VP10 tables if it really came to that. 

 

People are going to be handcuffed testing if they can't save their own testing environment (tables).  From someone that has done a hell of a lot of experimenting with VP, please do not do such a thing as disable the save.

[The Loafer]

My thoughts were based that this possible release was to test for performance issues, nothing more. Of course from an author point of view I appreciate where your post comes from Jimmy.

[mukuste]

The point would definitely only be to see if it even runs on people's PCs, and get some idea about performance (which will still improve a lot as we optimize more). I don't think people would have any reason to start developing tables for this version since there are no new features, it's just the plain old VP with a new renderer. So from this point of view I don't think it will be necessary to disable saving, and jimmyfingers makes a good point for why it shouldn't be.

 

Let me put this another way: this will NOT be a "VP10 beta" or anything of the sort. It's purely a renderer test.

Edited by mukuste, 07 February 2014 - 06:26 PM.

[The Loafer]

Very cool, hope this happens but no pressure on you sir!

[AaronShupp]

I am still blown away by how fast you're moving. Bravo, friend!

[mukuste]

I have a nasty problem right now, I can't start any tables which use VPM in fullscreen mode. If I try I get the dreaded "Machine terminated before initialized" error message. I can't even figure out where that message is coming from, is it a .vbs script, is it in VPM? If anyone can shed some light that would be hugely appreciated.

 

EDIT: Ok, at least found where it happens, it's in VPM itself. Still have no idea why though

Edited by mukuste, 07 February 2014 - 09:49 PM.

[LoadedWeapon]

Well crazy amazing work so far!!!      I cant wait to test it out... Goodluck on the progress I know alot of people looking forward to this.. Thanks so very much Mukuste..

[unclewilly]

I believe that error occurs when you run a table or tables too many times without closing the editor and restarting it.

I get this error when developing tables. It is a vpm error I think

[Slydog43]

Try a machine reboot also, I have had strange things happen after running many tables many times.

[mukuste]

Thanks for the comments guys, I tried rebooting but still the same... I'm a bit lost right now. Can't really debug this since I can't compile the VPM source code. Will probably have to postpone VPM fullscreen support until later.

[atarian]

I had the machine terminated error on one or two recent tables and although it doesn't make sense the fix was too export some large images from the table, resize them and re-import them - I think that was suggested as a fix in another forum and it seemed to work. Although I don't know the technical reason for this could it be that the error is related to something with video memory running out (ie: in fullscreen) and this somehow causing VPM to crash?

Edited by atarian, 07 February 2014 - 10:38 PM.

[luvthatapex]

Try a smaller vpm table. I get that error if any of the graphics are larger than 1024x2048 (thats with my two 2gb nvidia cards!)

 

 

I have a nasty problem right now, I can't start any tables which use VPM in fullscreen mode. If I try I get the dreaded "Machine terminated before initialized" error message. I can't even figure out where that message is coming from, is it a .vbs script, is it in VPM? If anyone can shed some light that would be hugely appreciated.

 

EDIT: Ok, at least found where it happens, it's in VPM itself. Still have no idea why though

[htamas]

Just to test if it helps, you could also try to limit texture dimension either to 2048 or 1024, perhaps it fixes the issue.

[DJRobX]

A comparison of MB in both vp9.2 and the current dev vp directx 9 version would be cool, but I suspect there's lots of bug hunting and optimizing before he is ready for those types of tests..

 

After seeing what happened when I switched from Win7 to XP (45fps to 500+fps on the same hardware), I too am very curious about this.    The running theory is that poor DX7 support in the driver is the culprit.   Even if the visuals are buggy, it would be interesting to see if we lose the massive discrepancy in frame rates between XP and Win7 for this table.   On my system, the Win7 slowness seems to impact tables with 3d primitives added to it the most.

[mukuste]

Ok, I found a partial workaround for the VPM fullscreen problem. If I set "ddraw" to 0 in the table's VPM registry settings, I can get it to run. So it's again that ugly DirectDraw rearing its head. The problem is that then the table runs, but the DMD is nowhere to be seen as it seems to be in the background. I thought that there was a recent fix for this but it doesn't seem to work in this case. Still, this is good to know and really narrows down where we have to look for the problem in the future.

[toxie]

In the near future we should do the rendering of DMD and segments with VP anyhow, as the quality of vpm is really not that good anymore. And the unity branch of vpm already has all the necessary interfaces for that.