PT Speed UP

Too bad, I guess RaGEZONE Priston Tale community will have to build their own PT SPEED UP .dll without cheating ;)

lol

Well... we could still "cheat" a bit.

We are reverse engineers after all. There is no reason we cannot reverse this DLL. But I can't say that would be any easier than just working out the DirectX code anyway.

The worst part about either project is that it's an awful lot of work for any one dev, and I can't think of a good way for a "team" of devs to work on it collectively. (suggestions on a post-card :wink:)

I am not sure if this is a lot of work (its just one directdrawcreate).
I think I know what I did in first post. In full screen mode PT use GDI? and I forced window mode after going to full screen.
When you hide all menus and txt in full screen mode you will see only 5 frames difference (vs unhide) but in window mode its like 30!

Well. I still can't get accurate FPS stats in PT no mater what I do.

Actually, PT refreshes the DirectDraw surface tens of times between each actual change. And most DirectX FPS counters take an update or flip operation as being a "frame" which doesn't actually apply in PT. :/: May well explain 249fps. :wink:

Quote:

---

Originally Posted by Vormav

I am not sure if this is a lot of work (its just one directdrawcreate).

---

As I said, it's not. That's the only library call, but all the DirectX code has nothing to do with that, or DDraw.dll, but only to do with the D3Dwhatever.dll calls that aren't even given exports to look up, because they are COM object methods and (functional) properties.

The one thing that DirectDrawCreate() does do, is wrap PTs DirectX calls to what-ever version of DirectX you have... hence why I can't even say the name of the DLLs that actually do contain the unnamed (except in the DirectX SDK headers) APIs which do the actual work.

Stick memory breakpoints on all the DirectX DLLs which are loaded into PT as it runs, and see how many times Olly stops with the EIP inside them. Each one of those is a true DirectX API that needs understanding. :wink:

I see, damn I would love to see real reflection and transparency in PT.

Still not sure why FPS giving you so wrong values. Maybe try using D3Dwhatever FPS counter (shows FPS on title bar)?

No, I'm just saying that any FPS counter which assumes every time PT refreshes the display is 1 frame, will produce "wrong FPS". PT doesn't *change* the display every time it updates it, as any other program should. So DirectX and Fraps display is not the actual frame rate of PT. (this I know for sure)

What PTs actual frame rate is, and how much it differs from that figure is anyones' guess.

Under Olly, my Butchered client can update the display 15 - 45 times per time it actually changes the geometry in the scene or anything in the UI. I suspect it does this less when running outside the Debugger... but it's hard to tell then.

How do I know? I found the DirectX API which updates the display, put a breakpoint on it, so it would fall to Olly each time it is called.

It would stop at that point over and over again, and nothing changed on screen. ^_^ If you deliberately corrupt the screen buffer before that API is called you can see DirectX redraw exactly the same display over the top of the corrupted one... but as far as I'm concerned, a frame update which is displaying the same image with no animation or change of any kind is no frame update at all.

It's like when you watch Animé, and it's an OVA so it's released at 25 / 30 FPS, but the frames of the animation are actually only 12 / 15 FPS, so you get frames doubled... only in PT they could easily be 45 identical frame updates before anything changes.

So if D3DWindower is forcing PT to change the display every time the frame updates, that would make the game run smoother without increasing the perceived FPS, as measured by anything external.

I also found the routine which updates the geometry, BTW. And if you set a BP on that routine, then the display does update one frame each time Olly breaks execution.

One speed-up I was planning was going to be to set a sort of flag. Change a DWord, or just 1 bit in it to 1 each time the geometry is altered, then simply quit from the display update routine if that flag isn't set, and reset it (to 0) each time the frame update routine completes.

Then FPS count would be true as well. :wink: (I never got around to it though, and I don't know how easily I will find those points again)


--- EDIT ---

Oh yes... as we where going through this discussion, I realised that if I used a DWord to store the result of GetSystemTime() each time the geometry is updated, I could calculate how many miliseconds has past since the laste geometry update (real frame) and use that to display a frame rate in the F11 console... trouble is, F11 reduces your frame-rate considerably. :(:

Thanks for clearing fog for me :)

I have FPS counter in eyes so I will notice when PT is running faster and after pressing F11 everything is so fast and smooth, no mater how many monsters I spawn its still constant speed, its even better than full screen mode.
But when I press F9 in F11 mode (text on top and no inventory) I don't fell any slowdown.

Ahh. I have the opposite. When that overlay, which tells where I am (X, Y, Z) what I'm targeting, how many monsters are within visible range, how many players and NPCs etc. That's when it slows down. Also, Fullscreen slows down game considerably compared to Window. XD

Opening inventory or chat has little effect. And no effect at all if I simply proxy TextOut() API. At which point F11 makes no difference to game speed when anything is open. ^_^ Play is as fast and smooth is if large map is open, but without the landscape geometry fsck ups. XD

This leads me to conclude that TextOut() is my major slow API, and I know MS document it as being a wrapper API which provides simpler (but less capable) syntax for DrawText(), and that DrawText() is wrapped by DWM to WPF when that is enabled, which in turn uses DirectX. XD

But that DWM is disabled in Fullscreen... therefore, no DirectX, and DrawText() must go by GDI. (not even GDIPlus)