Functions in Dll

[SheenBR]

Hello. I'm currently moving to a dll these functions:

PtReg sub
Window Creation
and that Ver: xxxx too.

I made Ver: xxx with a different color

And ptreg is 100% working though. I'm just making a few adjusts and then share with you. I accept critics and more ideas too.

 

[Vormav]

I like that, PT is becoming more and more MODULAR.
We all should do that from the beginning so by now we would have game.exe in pure C. I think that bobsobol declared somewhere that he will rewrite SOUND function into C, but my eyes might play tricks on me.

 

[SheenBR]

I think we should rewrite it, and use DX9. xD

I think it shouldn't be too hard, I mean, only the window creation and replace the TextOutA functions, right?

---------- Post added at 08:54 PM ---------- Previous post was at 08:37 PM ----------

As you can see, I moved the location of the text, and then created a custom font to it.

 

[bobsobol]

I think that bobsobol declared somewhere that he will rewrite SOUND function into C, but my eyes might play tricks on me.

Nope. Butchered 4 is already using replacement for Registry and hotuk.ini and ptreg.rgx from C++ DLL.

Sound I had hacked in as Assember pulling in pre-built DLLs, and I'd rather make a DLL in C that could call in one of many DLLs to do this.

DirectX 9 requires someone who already knows how to reverse the DirectX 3 - 5 (plus GFX chipset detection in DX7) blended that PT is written in first. :

 

[SheenBR]

So, its hard to upgrade the dx in game?

 

[bobsobol]

Similar attempts have been made with other games. The most successful that I know of is

You must be registered to see links

which updates Morrowind from DX8 to DX9. He quite clearly states that it wouldn't have been possible if the APIs of DX8 weren't so close to those of DX9, or worthwhile if the performance increase between the two weren't so large. (and he is a RCE'er I would gladly kneel before shouting "We're not worthy. We're not worthy!")

The problem is compounded by the fact that the PT client is clearly written (originally) in C (not C++) for

You must be registered to see links

along with the fact that it uses WSock32.dll (dumped after Win3.x) and not WS2_32.dll, by ordinals (dumped after Win3.x) and not by export name, and uses KERNEL32.DLL calls _lwrite, _lclose, _lcreat, GetPrivateProfileIntA, GetPrivateProfileStringA, WritePrivateProfileStringA. (all

You must be registered to see links

, and frequently pointless after 16-bit Windows) This indicates that PT was also written for Windows 3.x (or NT 3.x at most) and has been botched to work on newer Windows versions and had bits of C++ added (C++ is always C compatible after all) to support DirectX (at all) in the most expedient (not the most compliant) manner possible.

DirectX 7 is fully supported by Wine, VirtualBox and VMWare, but the PT client fails miserably. However, the DirectX 5 conformance analyser cannot find less that 2000 errors in the DirectX API calls used in PT. The one for DirectX 9 falls over after the first 25,000 errors in it's code.

The fact that PT works at all is quite a miracle.

I would say that our best bet is to do away with anything which creates the screen / window, and modifies the DIB that it creates. (IE if you disable window creation, and the DDraw initialisation, and any code which causes the game to crash is wrong, and needs disabling.)

Then, work out how to tell a wrapper (like

You must be registered to see links

,

You must be registered to see links

or

You must be registered to see links

) what is going on in the game world, and update it's scenes. Leave them to work out the compatibility issues with DirectX 14 or OpenGL 9 whatever. XD

Short of that... making it compatible with ANY SINGLE existing version of Microsoft DirectX would be nice... since it's not DX3, DX4, DX5, DX6, DX7, DX8, DX9, DX10 or DX11 compatible code. And uses some features which where dropped after DX3, and some which where not present until DX7. :s (I've not looked into it deeper than this, because it truly is a complete mess)

It's just hacking together bit's and pieces from each of the API sets, and somehow... against all odds... it works. IF you are using only Microsoft official OS and libraries and signed MSHIDD drivers. (most OpenSource DirectX hardware accelerated drivers don't work with PT either)

So I guess it is relying heavily on undocumented, and unsupported side effects of the backwards comparability features Microsoft expose in each release of DirectX.

Oh... and BTW:-

It's not illegal to use TextOutA() even in DirectX 10, and even directly onto it's surface. (Blitz Max code does this quite often) Though I believe there are some limitations it it's interpretation of Anti-Aliasing and Kerning.

However, use of any of the APIs with "A" (ANSI text) at the end of them have been "depreciated" in any OS from Windows 2000 onwards.

They are replaced with code which does an ANSI to WideChar conversion on the parameters passed, and then passes them on to the "W" equivalent for backwards comparability only.

Microsoft did make claims that those APIs would be dropped with the release of project Longhorn (which became Windows Vista) but that didn't actually happen, and would have made over 70% of existing Windows software unusable. So I guess that claim was

You must be registered to see links

to get us to pull our socks up and stop using these old APIs.

Spoiler

Unfortunately, storing string constants as WideChar or WCharT data types doubles the space they take in our executable. If Unicode was supported as UTF-8, and not UTF-16LE (WideChar) then the proposition would be more attractive to Win32 developers I think

 

[Vormav]

Sound I had hacked in as Assember pulling in pre-built DLLs, and I'd rather make a DLL in C that could call in one of many DLLs to do this.

Some hint what functions exactly are responsible for sound? Address in Butchered would be nice.
Also what would be best codec (and container) to play move in PT window?
Simplest to handle would be the best ...I guess =P

 

[bobsobol]

Seem to be missing my labels (probably different Olly build replacing the .UDDs), and it was KPT 2428 I modified and would be able to recreate offsets for.

I'll have to dump the disassembly from the Original and the moded versions.

I imported BASS.dll, and added the BASS mod extensions at least AAC and WMA playback. I'll get the source out as a "Development" and explain why I now think (although it worked) it was the wrong way to do it.

Right now I'm working hard to get a program that will update Export tables correctly, and generate them from the "Names" list in Olly... so those Labels can be packaged with Butchered, and dumped from the Exe before P-Servers distribute to players.

If Exports from the game.exe make things easier for thinks like writeGlobalField... which I suspect they may, as you could look up the addresses rather than programming them in your C files... then there may be some cause to keep "some" of the exports in a distribution. But I'd leave that up to individual P-Servers. It's more important that Devs have access to as clearly documented, and as easily customisable a client as possible, from my point of view.

I can manually "walk" the PE headers and find, and read the PE import and export tables in a Hex editor now, but making the changes manually is very hit and miss. (for me, who has this dyslexic head for numbers)

Exports (rather than imports) is slightly off-topic so I'll spoiler:-

Spoiler

Current progress MakeEAT analysing Butchered4.exe

MakeEAT analysing it's self.

Built with the GCC toolset, clearly, and back in my home country of freeBASIC.

If you notice that almost every executable you have has 0x10 RVA Directory pairs, and Butchered4 only has 0x0E, that's just a little more optimising on my behalf. The last 2 pairs aren't used. Ever. It doesn't save space, but may save a few micro-milliseconds loading time. Yea, probably overkill, but I'm having fun, pushing some limits.

I'm going to check you have added a new section with enough space to store the exports, and the right securities, offer to merge them with existing exports, and I think the third parameter can be replaced with the address of a section of your choosing to save remembering where you added a section.

No point to release yet, as it's strictly in read only mode till I'm sure I'm reading all the right information in the right way. Write code is laid out as pseudo-code, and mostly in my head.

I don't see a need to add code to add a new section, as there are so many good and proven tools for doing this already.

The text file which is the second parameter is basically a CSV processed from copying the "Names" table from Olly... I do it in MadEdit, but I can see a desire for a program to make such a text file from the clipboard.