if I replace all the TextOut(GDI) functions to DrawText(user32.dll), would that make any difference?
coz sandurr said pt is bad in some POV because it uses GDI to render text.. DrawText is not GDI, is it?
if I replace all the TextOut(GDI) functions to DrawText(user32.dll), would that make any difference?
coz sandurr said pt is bad in some POV because it uses GDI to render text.. DrawText is not GDI, is it?
Yes, it would make a difference, but it is still GDI. TextOut() is a wrapper for DrawText(). If you trace it you can see it rearranging the parameters and passing them on.
DrawText() allows more control over the text display; bounding boxes, text wrapping etc. But that means it takes more parameters. User32 is all GDI... unless it's patched by some higher code like DWM.
Basically anything that will work on a window / form / dialogue (whatever term your IDE uses) is a GDI API. They all work by manipulating a DCs DIB which is obviously slow. (A DIB is meant to be retargetable to any image renderer... 2, 4, 8, 15, 16 bit Display, Chunky / Plainer, RGB, BGR, YUV, CYM, CYMK, HSL display, even a HAM compressed display! Printer, Plotter etc.)GDIPlus was the first attempt to do something about this ancient API which is still a key cornerstone in the Windows Castle. The problem is that everything else is built on-top of it. It's what draws Windows, Buttons, Scroll Bars, and everything else. GDIPlus will use hardware accelerated functions to do the drawing and then apply the result to the DC. So it's a bit faster. If you can use DirectX or WDM then you have access to Hardware accelerated texture surfaces.Spoiler:
Essentially, DWM (Desktop Window Management, or Compozitioning) places every window on such a surface and hooks all the GDI APIs to use acceleration. It breaks the ability to replicate resolution independent versions of DCs on a Plotter or such... but that facility is almost never used, and much of the information placed on most DCs is resolution dependent anyway. Compressed textures (now usually YUV 4:2:2 or such) will not be replicated at uncompressed quality any more either... but that's rarely used and even less frequently desirable.
I'd have to do something like this then:
Direct3D Text
?
Yup... that was one API I looked at. I couldn't figure out how to patch into the DirectX instance PT is using... but I think you have made some progress on that already. ^_^
lol, I wish =p
directx is VEEEERY "out" of programming knoledge =p
If I could just solve the tons of error I get just after including the header d3dx9.h , I would only need to get the offset that PT stores the 3D Device and make some "hijacking" with c++. I think, cant test it. but I read something, and I saw that even this function uses a bit of GDI
maybe I am wrong, but wouldnt that be pointless? why would I patch the textout to this function if it still uses gdi? gdi in this case is better?
Yes... you can't. The resolution is to include d3dx6.h or d3dx7.h... DirectX source isn't particularly backwards compatible. The binary executables you produce are.
It's kind of like trying to compile C++ in a C# compiler. It really doesn't work out that well until you have practically re-written it.At least that's what 3D programmers tell me.
Having said that, there are some 2D DirectX examples which have remained pretty much the same since DX3 and still exist in the SDK.
I found something thay may be useful to change the text rendering.
Re-Volt Source: C:/Dev/Re-Volt/rvPC/Track Editor/TrackEdit/text.cpp Source File
here is just the text.cpp, but you can easily navigate thru all the files, and it seems to use BMP fonts. for what I read in sandurr's create device code, its the same interface, so maybe it'll fit.
Reply With Quote
) The advantage of Windows 1 over OS/2 1 (you could think of MS OS/2 v1 as Windows NT v1 if you like) was that Windows 1 didn't need an 80286 CPU and would still run on an 80806 / 80186. The advantage of OS/2 was that it used HPFS (IBMs successor to FAT and the predecessor of NTFS) and was much more secure and stable, properly multi-tasked, didn't need DOS and used less memory if you had the glorious and power hungry 80286 processor required. ^_^ At that time... I didn't, but the company I worked for had 1... it was a noisy beast with a heatsink and fan on the massive 17Mhz 24-bit CPU and millions of 8-bit TTL RAM chips on the motherboard to provide the massive 2Meg of RAM. What a beast. 
It even had the "Turbo" button on the front, to slow the CPU down so it could run traditional DOS applications without going so fast you couldn't see what they where doing. XD