MAXimum customizations [WIP]

[SheenBR]

thats really good, when are you going to release a beta ver? is it done by dll or pure asm modifications?

 

[Ávila]

Amazing !
No more words.

 

[bobsobol]

PS.2 can we do something to speed up packet sending & receiving, (to 1ms )? PT is doing it too slow, can it have FPS speed?

Okay... it took seeing your next post to understand that. You should note that both FPS and packet send is considerably reduced when PT is not they foreground window.

You can remove this limitation (I have done) but it would not be very advisable.

Check calls to

You must be registered to see links

. The routine in question checks the result against the clients main window handle (hWnd) and if they match, it uses

You must be registered to see links

and (IINM)

You must be registered to see links

to delay the thread from updating.

This stops PT from hindering the responsiveness of the foreground window. It's not too bad if you've switched to Notepad or Calc, or even MSN... but if you've switched to another PT client, or are even playing Pac-Man while your Personal Shop is waiting to sell up, PT can considerably degrade the performance of the system running at full speed.

In short... I wouldn't worry about what you are seeing, unless that delay is too annoying even when you are using two PCs attached to your server.

At which point... the delay in the server processing your packet and passing the information on the the next player also comes into the equation, and what you do with the client won't make any difference.

I think the server does also take notice of the network speed setting that you can see in the clients launcher... and most of us never bother to set it on the server.

The default is middle-low I think. (one up from the slowest, and therefore two down from the fastest) But if you increase this, you also increase the bandwidth requirement of your server system, and degrade performance in high user situations.

 

[SheenBR]

I always hated that delay, now its gone *_* thank you bob
I just changed a JE to JMP acctualy

 

[bobsobol]

Yea... actually, I did "reduce" it, as something "in-between". I think that is in Butchered for some time. For example a 15 or 30fps cap for background window is neither here nor there when you aren't in combat. (I hope you don't MSN while fighting)

It's also enough to give other tasks a time-slice at least that frequently, and that's responsive enough not to see type-lag in Word.

33ms sleep will give approx 30fps max.

 

[SheenBR]

why is bad to remove that lag?

 

[bobsobol]

Because if you don't lag the game when it's minimised and you do something else processor intensive... you absolutely thrash your CPU. XD

It's not hard to imagine why that delay was implemented, and if you run two PT clients with it completely off, you will see the problems it causes.

If you try playing Oblivion in a window while PT is in the background and the background Sleep() is disabled you will really struggle.

 

[SheenBR]

but sandurr has removed it in RealmPT... have you seen it? maybe he has done it using another method?

 

[bobsobol]

Maybe, or maybe he doesn't care for people who want to play Oblivion while they wait for their personal shop to sell up.

I should state that when I say "trash the CPU" I don't mean it will pop (overheat / burn out) or anything. I just mean you are "throwing good cycles after bad". The common sense says that if you are Atl-Tabbed away from PT, you don't care if it is updating very slow (you may have it obscured by another window, or minimised to the task bar, and then you really wouldn't notice at all) but you almost certainly will notice if web pages take forever to load, and Word is lagging entire sentences behind what you are typing.

I know I type pretty fast. Not quite as fast as I read, but certainly faster than I can speak. Still I have managed this while running PT in a background window.

It's also worth remembering that TV is only about 25 - 30fps (SD) and HDTV and most PC monitors max out at 60fps. (high end gaming or HTPC screens can cope with 120 / 150 maybe even 175... I've still never seen one running though) So the question could easily be... why doesn't PT implement this all the time?

I don't think PT takes any notice of the "VSync". (you see that as an option in many games) This delays the page flip until the monitor has rendered the whole of the last one, and prevents "tearing". However, it also avoids over stressing the CPU, and GPU. If I knew how to implement that alongside the existing PT code, I would program "when not the foreground window, wait two VBlanks before continuing".

As ever, I don't care to look too closely at Sandurrs' code, unless he has shared it with us publicly. Certainly, his client feels faster, and seems to affect other processes even less than jPT clients I've tried. They (to my tests and my eye) tend to be the smoothest and produce the least load of any of the official clients.

 

[Vormav]

For some reason I strongly disagree with you bobsobol
and the reason for that is I just test it!

On one PC I'm running server, 2 clients, wii game on emulator in HD, dungeon siege 3 (I don't have oblivion installed... only this crap =P) and I am writing this.
My CPU usage did not pass 20% and every game/emu took 2 threads (I have 8 on 4 core CPU). 5 GB of ram is eaten alive... but CPU don't want to sweat

I hooked DDraw (also foreground and background window and few others) and I think Sandurrs doing it similar way. It works great! As if you turned off all your menus in game (F11). I can work on it when I finish this project but there is not need to add DX9, all we need it DDraw hook.

Also I don't see any more or less packets send so I don't think this have any effect on server, but I noticed one thing, PVP is closer to "real time".

PS. Correct me if I did something wrong with my testing.

 

[bobsobol]

Sounds okay. I haven't compared the comparison between packets and frames, and I certainly would have no idea how to "hook DDraw". I'm getting closer to understanding the COM API for DirectX than I was when I started poking PT in sore places though. XD

When I reduced the Sleep(), and when I skipped the entire GetForgroundWindow() stuff... I struggled to type in notepad, let alone do anything else, so your method clearly has considerable benefits. However, I don't see any greater speed-up tapping F11, and I do by disabling all the 2D UI (HUD or WHY) and leaving the text in place.

I can certainly kill the PT client frame rate by patching it with

You must be registered to see links

though. XD (Text renders awesomely, but game is not playable)

Back to packet timing. I believe that there is one or more threads allocated to packet send. Each has a Sleep() or similar API associated with it, and a critical section object.

The method I think is being employed (debugging around thread change and critical objects often leads to a threadlock or other crash) is that the thread goes idle by means of a sleep, leaving the game to get on with what it's doing until it's time for a packet of this type. Then the critical object is signaled, (I'm not sure what the Microsoftees for this is, but they are basically an object-oriented Mutex unlike anything in any other OS, just to be awkward) so any other thread which tries to do anything with the memory the packet dispatching thread is working on becomes suspended. The packet is created in a memory buffer (which I'm not sure if it creates and destroys every time a packet is to be dispatched or just creates and keeps present... I suspect they just use the threads heap or such) encoded and passed to WinSock to send out.

The the thread cleans up, releases the critical section and returns to it's Sleep().

There are a few places which perform this same basic task in a couple of different ways. I don't really understand them, but I can kinda identify them.

Same way as with frame rate, it's simple and safe enough to reduce the Sleep() time.

If all your clients are doing it, you need to allow for that in your server bandwidth though... especially if the server spits out a packet to anyone nearby any player when ever they send it a packet.

Would be nicer if changing a clothing item, or starting / stopping / turning would trigger the packet generation, and the time-out only applied if you are stood still doing nothing... so the connection remains in "keep alive".

Unsurprisingly, I'm pretty sure it doesn't work the "nice" way. :

 

[Vormav]

Try FRAPS with FPS overlay, I just got results

On best video settings and resolution while standing and doing nothing:
Visible inventory: ~25 FPS
Invisible inventory: ~65 FPS! (F11 as admin)

Intro for both ~75 FPS with turned on login/pass screen.

I was not able to test apps that have directDraw hooker (sounds strange) since they work only in window mode and I don't know how reliable their FPS counter is. But it gave me from 30-50 <_< (it felt faster).


If you standing and doing nothing PT keep sending that you standing and doing nothing on XYZ position, you look like that and that, wen you move, PT will send that you moved. I never seen PT not sending anything for longer than 1 sec...

_________________________________
OK about hooking stuff:
There is a cool "windower" called D3DWindower it can do some magic with old DX1-7 and newer.

DL it and try some different configurations, you should see visible speed, 2 maybe 3 times faster and less lag, timeout on your chat window will show up less times too.

Also you can add it to PT imports like I did:
DL:

You must be registered to see links

extract it to your KPT folder and edit hook.ini (yes hook not hotuk =P):
F:\MyPTClient\TKPT\game_2006_NO_XTRAP.exe=game_2006_NO_XTRAP

SubModule0=F:\MyPTClient\TKPT\D3dHook.dll

change them to your path.

Don't forget about:
Width=1152
Height=864


and just start game_2006_NO_XTRAP.exe

PS. best to test in in BC. Two clients with sound ON and when you hit someone you there will be only 1 sec delay. Before I had to wait even 4 or more...

__EDIT__
I forgot about ptReg.rgx
Turn off your window mode there:
"WindowMode" "OFF"

 

[SheenBR]

which functions are you hooking exactly? I thought it'd be the source code but I think its some kind of component you downloaded...

 

[Vormav]

This app have only source for its GUI.
You have to find what speeding up PT and reverse engineer functions in this DLL. Somehow adding everything to PT imports don't speed it as much.
But it help PT to work faster.
I don't plan to work on it anytime soon so I will be glad if anyone would do it.

________________________________________________________________

I nearly done fixing fighter, all items are compatible with each other.

BUT there is a problem I can't edit hands in last armor (tmbB17.smd; they are even in 16, 15 and 18). Non of them work. It look like there is a problem with *MESH_NUMTVERTEX or MESH itself.
Mesh look a little broken (hands only) after conversion and it cause incorrect uvw map :/ This will crash MAX so you need to remove
*MESH_NUMTVERTEX NUMBER
*MESH_TVERTLIST {
[...]
}
or convert it to editable poly.

Rendering it as it is will give error:
Object <TAHB21> has a mesh with invalid texture vertex indices - can't render

Those hands are a bit irregular, right hand look like uvw map did not took spikes.

Worst case scenario is that I will have to remake those hands or those hands are not going to be included.

I will try to PM Sandur now (UserNameHere2, if I am correct) but I don't know if he takes bug reports or if it can be fixed.

---------- Post added at 08:36 PM ---------- Previous post was at 07:46 PM ----------

'K FS check and ready to launch (without gloves from da125 for now )
I will make movie when I clean mess I made ...and make interactions with Mech. Probably Prs/Mage will be more interesting than this

 

[SheenBR]

if you can tell me which functions you changed the values with those hooks, I could try to work on it, I saw the .ini but there are too many functions patched, am I right? I dont think PT uses all of them.. you know what I mean?
The oly call to a DDRAW API I found was "DirectDrawCreate"

 

[Vormav]

Download

You must be registered to see links

Play with options and check what speeding up PT.
You can even use "proxy" dll to load this dll.
Once you find best configuration rewrite functions that are hooked.
I don't have any deep tests of it so you are a bit on your own =P

 

[SheenBR]

I cant make it work, I add my game to the list, click in the Play button, then I try to open my game, but it just closes I've traced it before and I know the error is right after the _InitD3D call, that TEST EAX,EAX.
EAX is 0, then some error ocurred then the RET is called and my progam exits the main routine and stops in a beautiful ExitProcess lol

 

[Vormav]

All your settings need to be on FULL SCREEN so it can make WINDOW.
ptReg, hotuk.ini need to run game.exe in full screen mode.
Also copy this app and files into your main game folder.
Don't press play |>

My configuration:

 

[SheenBR]

it worked now, I'll see what I can do.

 

[bobsobol]

I have had the same immediate quit to desktop when I've tried DirectX windowers or Fraps FPS counter on PT clients. PT is so badly coded against DirectX.

The readme says it's a DX7 to DX9 wrapper I believe, and it looks like it. The DirectX9 APIs probably do run faster, and will certainly make more use of 2D graphics acceleration and underlying GDIPlus functions. (a big problem with font rendering)

Another problem with DirectX exported functions is that they are ActiveX (Component Object Model) APIs, so only the Object instantiation function needs to be exported. Every other function (method or property) is exported by the object handle passed back to the application, and invoked by COM manipulation of the object represented by that handle.

Back on topic. I'm looking forward to the release... if the only problem is with the UV map of hands, I suspect they could easily be re-created manually. Even I have some experience of manipulating UV maps when I've been skinning other peoples models. (that's close enough to the 2D work to be something I can do)