yes i not use the "/" in "OpenGL / D3D" sorry good would change old textures models graphic for news effects .Quote:
Originally Posted by percy
Printable View
yes i not use the "/" in "OpenGL / D3D" sorry good would change old textures models graphic for news effects .Quote:
Originally Posted by percy
well... as the people say... we "can't" change the dx mode... but... we can do anything about it???
i just trying to use logic...
when u press f11 the lags goes.
so... there's anything we can do about it.
F11 is the button that shows only you right? removing chat and all the user interface?
Well, as I've said previously, the way PT render texts is too slow compared to what we can do now.
If you want to make it disappear, you would have to rewrite the engine and change the way PT render fonts, using bitmap fonts, or load the font directly from the ttf file.
The lag probably comes because of the text lines ammount to render, images, players etc. when you press F11 most part of it is gone, thats why you notice some improvement.
F11 do not show only me... but as u did they make hp bar ... chat... and many things go away... and that pic i show in the topic is the functino who is call whe u press F11.
inside it u can see all those references for "d3d..." ...
all those call's...
"ecx+24" and "ecx+28" ... afther it have a pic function.
u can ignore it... just make a jump in this... and ur game does show "CHAT"... or... "hpbar" or "skills" ...
and lags does go away... but.. if u nop some of those "ecx+24"... and group some calls... u REALY SEE the lags became goes...
so man.... i can't ignore it...
the teory is good but... in the pratice we see the diference... i keep thinking.. there something we can do about!
ecx+24 and ecx+28 are calls to DirectX. This is how it works:
Code:
g_pDirect3D = Direct3DCreate9(D3D_SDK_VERSION);
g_pDirect3D->CreateDevice(D3DADAPTER_DEFAULT, D3DDEVTYPE_HAL, hMainWnd,D3DCREATE_SOFTWARE_VERTEXPROCESSING, &PresentParams, &g_pDirect3D_Device);
in the last line, instead of CALL DirectX.CreateDevice , it will be something like CALL ECX+number
ECX will hold the pointer of LPDIRECT3D9. In olly, you can see it will be full of function pointers. thats why ECX+number, always ECX +4, ECX + 8 because a function pointer is an integer, which means 4 bytes.
You shouldnt remove those codes, instead, you should rewrite the entire engine.
hmmm ... tnks... now i can see something...
sheen
when u say
"
LPDIRECT3D9 g_pDirect3D = NULL;g_pDirect3D = Direct3DCreate9(D3D_SDK_VERSION);g_pDirect3D->CreateDevice(D3DADAPTER_DEFAULT, D3DDEVTYPE_HAL, hMainWnd,D3DCREATE_SOFTWARE_VERTEXPROCESSING, &PresentParams,&g_pDirect3D_Device);"
D3DADAPTER_DEFAULT<<<< u can change it right???
i think ... maybe... the game cant 'see' the adapter when u are using this old engine in dx11 ( windows 7 )
so... maybe we can force to do it ???
changing just the parameters of CreateDevice wont work, because the structures will change, forcing you to change the rest of your code.
your reply make sense, RPT used DX7 and sheen quote that the others PT, using DX6 ;)Quote:
Originally Posted by microamazing
do tests relocating in a new table of DX... and continuing flux's code!
and too create news references in news effects or others that you is adding.
Hugs Sheen and JP!.
it isnt that simple, just relocating dx table... there isnt any directx table o_o
no specifically a table, but, a relocation of codes ^_^Quote:
Originally Posted by SheenBR
only change location of code, and continue flux same not references, and in end code, return the code or function
so you can jobbing better ^_^
and the adapter where we make it load?
OMG WOT alert!
Okay... most people in this discussion seem to have forgotten to "search". Many of us have been over this topic several times before, and you are simply repeating things we've already discussed.
People who contributed to earlier discussions:①Vista and 7 render PT faster than XP... when in a window and DWM (typically noticeable by the glass effect, but that can be turned off while DWM is still active, removing tearing and much other redraw flicker in regular windows) is enabled, and slower when fullscreen, or if DWM is disabled / not active.Spoiler:
DWM is turned off automatically with official builds, and when a "fullscreen" application is running to avoid incompatibilities. It's actually the blit of the "loading" banner when PT is in a window which triggers temporary DWM disable. Remove that loading banner (as my Butchered client does) and DWM (and glass effects) continue just fine. Then, in a window, PT performs better in Vista and 7 than it does on the same hardware in XP. It was AirBourne who noticed this, and Moons who found a very short modification to stop it. IMS (correct me if I'm wrong, I'm going from memory)
②Pressing F11 disables all 2D operations. This stops the HUD and text being displayed. I suspected that GDI was being used for 2D blitting (it certainly is for the loading bar, but I've still not tracked down the rest of the HUD [Heads Up Display, or the UI which overlays the 3D camera view]) and that would make all of that stuff very slow. (CPU bound with no GPU acceleration) However, Vormav pointed out that simply disabling the TextOut() API will produce most of that performance increase. On my system, I would say that it accounts for about 80 - 90 percent of the increase from pressing F11.
How can you try that? Load the client in Olly, go to the import section and find the TextOut() API label that Olly has filled in. (you can list references, find TextOut() and follow back from there if it's easier for you) Point that to a SUB ESP,14 : RETN somewhere in the main PE. (You may find one, or you should certainly be able to find a cave big enough for those two op-codes and 1 small operand) If you do that right, you will be typing blind, as all text in the game will not be displayed.
It is worth noting, at this point, that the ClearType font rendering engine has become more complex (and CPU intensive) in Vista and 7, compared to XP... If you turn off font smoothing (or even use a bitmap font like terminal) in both XP and 7, how does the speed compare then? (I'm guessing it's pretty close, and possibly in favour of 7) Also, if you are using an x64 bit Vista or 7 OS, then you should also remember that your API calls are being made from a "virtual" 32-bit application, out to 64-bit OS APIs. That will incur a context switch delay.
③PT was (seems to have been) written with the DirectX 6 SDK, and seems to have been ported from something older. (WinG / DX3, I'm not sure ... and possibly it was always DX6, but from someone who knew DX3 / WinG better and CBA to read the DX6 documents. XD) Official PT distributions are *now* built against the DirectX7 SDK, but still have some DX6 *style* code in them. (DX6 and DX7 SDKs are compatible, where DX8 & 9 require more source modification, and DX10/11 you may as well port your source to OpenGL, from what I've heard)
④Vista ships/shiped with DX10, and 7 with DX11. They are *NOT* directly backwards compatible. Each version of DirectX comes with "wrapper" functions to interpret old software calls to modern functions. You can produce a DirectX wrapper over OpenGL, as Wine does on Linux, however, most OpenGL drivers on Windows are only wrappers to DirectX. That would mean you are advocating wrapping from DirectX 7 to OpenGL to DirectX 11 ... which is going to be more efficient than wrapping from DX7 to DX11 how? :wink:
DirectX versions:Some terminology. There are, indeed, tables of DirectX API calls, and their correct name refers to them as such.Spoiler:rPT implemented sprite / texture fonts (iD3DFont? I'm guessing) to render hardware accelerated text blits rather than the software based vector render of GDI TextOut(). :wink: This is a massive help, and a DirectX 9 API. Sandurr, IMS, suggested that this was about all he could remember actually upgrading from DX7 to DX9. I suspect that even GDI bitmap blits would be faster than truetype spline rendering with cleartype hinted anti-aliasing. :lol:Spoiler:
⑤Believe me, the DirectX initialisation code has correctly identified my gfx hardware for the last 4 or 5 graphics cards I used in PT. Why it still has those "special case" cards which it checks for during initialisation, I'm not entirely sure. But then I have no idea what functionality they, or their drivers may be missing since I've not followed the digital-speed-freek forums of custom-build and overclockers in years and years. The ID string returned by modern PCIE cards is much larger than the one this old PCI/AGP code is designed to handle... but it doesn't matter because it is only looking to *exclude* a few old cards which do produce the shorter string.
⑥Finally, (and I think this is something I've only really understood recently while working through C and ASM DirectX programming tutorials) a DirectDraw surface is the only acceptable device context render target for DirectX 6/7. (I'm not sure about 8, but it's discouraged in 9 and not possible in 10 / 11 where D3D provides the back engine that DDraw is wrapped to) Therefore, the first step to using DirectX is (was, in DX prior to 8/9 ish) always getting a handle to DirectDraw... even if you only want Direct3D. In DX6, DirectDraw was the parent class for Direct3D. (I hope that's the right OOP terms here, I do so hate them) So the SDK automatically created a DirectDraw object, of type Direct3D when you initialised DirectX for 3D work.
with quoted for me in old posts. use your knowledge in pascal, create a dll for this, or if you prefer assembly,Quote:
Originally Posted by microamazing
only use references old, e continue your flux and repeating, only return in end code.
try use the new DX when you call new references to look if the right ^_^.
Hugs.
You guys are not understanding... for the last time: this isn't just as simple as make a jump, add new codes, and then go back to where we were. Graphics Engine is something complicated, it would take probably weeks to translate everything.
@jvfl
hmmm i see now... tnks
@bob...
nice tips about textouta...
but... man, if the problem is in PT2d functions... like load some images... there something we can do about ?