Matrix (WARNING: Math Ahead!)

[Vormav]

I know how to create bold or italic font >.> I'm talking about extracting information -> which text is bold...

 

[microamazing]

hmm, i see now, well, there is some info when the bold is called, u can take it, is hard to say when i don't know how you do your changes.

 

[SoyEdu]

sry to post this but did u notice that we are all Administrators and Bobsobol is banned?? what is going on??

 

[DarkKnightH20]

@Vormav -- Nice work!

sry to post this but did u notice that we are all Administrators and Bobsobol is banned?? what is going on??

April Fools joke

 

[SheenBR]

hmm, i see now, well, there is some info when the bold is called, u can take it, is hard to say when i don't know how you do your changes.

There is no need to know how he did it, I guess he just made a function wrapper.

He wants to identify wheter the HGDIOBJ is a font object, and if it is bold or not. Am I correct? If yes, I guess you should look for the HFONT structure, identify the return value of the createfont API, this way you could get the HGDIOBJ and check if it is a font object and then check if the font is set to be italic/bold and then reproduce it using your bmp engine ?

 

[Vormav]

Thanks Sheen,

LOGFONT font;
GetObject( hgdiobj, sizeof(font), &font);

and I have it: font.lfWeight

I trated hgdiobj as structure before =P
I will finish this when I find more time.

 

[Vormav]

Anyone have positive experience with "DetectInputCodepage"? (

You must be registered to see links

)

I'm planing to implement it to take full advantage of UTF-16. I'm converting pt's mbcs to utf16 and I was wondering if I could automatize process for all languages instead of using one code page.

 

[bobsobol]

Windows MBCS has been upgraded, internally to UTF-16LE, PT isn't actually written in MBCS, or it would have been upgraded too. It is written in a single-codepage, with each different version assuming a different ANSI code-page. The fact is that because East Asian languages have more than 255 characters for even a basic textural representation, they use UTF-8 style escape codes for Multi-byte characters, even in an 8-bit ANSI characters.

AppLocal would provide the automatic translation at runtime, any other translation would have to be made at compile-time. (unless you simulate the AppLocal API patching)

 

[Vormav]

Sorry, I meant DBCS and SBCS.
e.g. "서버에 접속중..." contain DBC "서" and SBC "."
I'm converting this to UTF-16 using CP949... I was planing to automatize this process. If you use CP949 on Chinese or Japanese clients with C or J strings you will get mess.

 

[bobsobol]

If you use CP949 on Chinese or Japanese clients with C or J strings you will get mess.

Correct, and that's why you get a mess with Korean, Chinese or Japanese clients on any system whose default language is not the appropriate language for those clients. (more so than you do using a Spanish, English or Portuguese client on a system whose default language is not that of the client... English is reasonably negligible, because we use so few accents)

All AppLocal does is patch all the "A" variants of the base system APIs (those depreciated ANSI ones) to act as if they where operating on Windows with a different default language.

All the ANSI APIs are now wrapped to their "W", (Wide) or Unicode equivalent anyway. The wrappers expand ANSI strings, based upon the default codepage, to a full UTF-16 one before passing it on.

As for the MBCS, SBCS, DBCS thing, I had to re-check my terminology. Codepage 949 (Korean) is not (SBCS or DBCS), it is MBCS. The same is true for ANSI versions of Chinese and Japanese.

The difference is that every character in SBCS is a single byte, and every character in DBCS is two bytes, where in MBCS characters may be 1, 2 or (particularly in Chinese) even 3 bytes for the less common characters. The same is true in UTF-8, but AFAIK UTF-16 is always DBCS or 16-bits per character.

You should be able to use int MultiByteToWideChar(UINT CodePage, DWORD dwFlags, LPCSTR lpMultiByteStr, int cbMultiByte, LPWSTR lpWideCharStr, int cchWideChar); passing the correct codepage for the input, regardless of the result from GetACP();.

 

[Vormav]

Than I would have to intercept whatever function app locale is using, look like a bad scenario.

MultiByteToWideChar was giving me very strange results, if there where any so I end up using libiconv to convert between code pages and UTF-16BE and I unlike applocale I can change encodings on the fly if I need to.
For now I'm leaving manual encoding.

In PT Korean letters are composed of 2 bytes and mixed with ASCII so string is mixture of DBC and SBC, UNICODE char 서 is taking 3 bytes in UTF-8 while in PT is taking 2 (CP949 or EUC-KR). AppLocale changes are not done in PTs textout... they are done somewhere after that.

What would it take for PT to accept UNICODE characters in chat? That would be win-win scenario for us since everyone could type whatever they like and everyone else would see letters from all over the world.


BTW: Releasing MOD now ~Almost finished tutorial.

 

[bobsobol]

What would it take for PT to accept UNICODE characters in chat? That would be win-win scenario for us since everyone could type whatever they like and everyone else would see letters from all over the world.

Well, you'd either need to half the number of characters you can type in one message, or increase the size of a chat packet.

For Unicode input, without IME installed separately by users to allow them to input in a language other than that of the default program, you would need to recompile to source as a Unicode PE. (more accurately, re-link it, but linking is based on the codepage of the compiled binary) Alternatively, you would have to transmit the local codepage along with a chat message, get the server to convert that to Unicode, and then back to the local codepage of receiving users. Any characters typed by the sender, which are not part of the receivers locale will be lost.

 

[Vormav]

Thanks bob, it look like manual code page selection is the only way out for PT.

I tried some code page detection but results... see for yourself:

TextOutA(hdc=0x08170800, nXStart=552, nYStart=528, lpString=0x005eda88 ( 서버에 접속중.... ), cchString=27)
cp: Shift_JIS lang: ( ja ) confidence: 10
cp: GB18030 lang: ( zh ) confidence: 10
cp: EUC-JP lang: ( ja ) confidence: 10
cp: EUC-KR lang: ( ko ) confidence: 10
cp: Big5 lang: ( zh ) confidence: 10

TextOutA(hdc=0000000000, nXStart=1200, nYStart=949, lpString=0x0018fcf0 (Ver: 1.98.9), cchString=11)
cp: ISO-8859-1 lang: ( da ) confidence:98
cp: ISO-8859-9 lang: ( tr ) confidence:60
cp: UTF-8 lang: ( - ) confidence:10
cp: Shift_JIS lang: ( ja ) confidence:10
cp: GB18030 lang: ( zh ) confidence:10
cp: EUC-JP lang: ( ja ) confidence:10
cp: EUC-KR lang: ( ko ) confidence:10
cp: Big5 lang: ( zh ) confidence:10


Not even close XD

I was using

You must be registered to see links

.

 

[bobsobol]

I still think that

You must be registered to see links

should return the correct default codepage. (the one the user is typing in)

It may be best to store it in server memory at login, so that each client has an associated "ANSI" codepage.

The only other alternative I can imagine would be reading from the registry... but the keys are not guaranteed to remain constant across Windows versions, where a documented API should.

 

[Vormav]

But that's not what I want XD I need "string" code page.

I gave up on that anyway, PT is too old for stuff like that. I will add dynamic code page change either by in-game '/command', s.cut or UI.
This is only a problem when client is in language other than 'inglish', rare scenario I must say.

 

[microamazing]

@Vormav , i was think when i sleep today , you add some new function in pt... so, maybe you can add Shadow Effetc too?? or Light ???
thats will be a Graph think =P

 

[Vormav]

Well, something like shadows in old DX6 are not an easy task. Maybe if I had DX6 SDK with examples than Maybe I would be able to do this... Maybe

So far I fixed blur problems (first 3 bug/issues on the list), speeded up PT even more by removing some GDI functions and now I'm thinking about adding 2 language options; maybe there will be something more in R2 version.

 

[SheenBR]

No sources? : You can send only to me if you want lol

 

[Vormav]

I lost hope in sharing because of someone... I will release source one day. For now I will not allow any leaks, mostly because I don't want to see someone else patching bugs and not reporting them. RZ don't share Brazilian forums mentality so newcomers need to adjust to us and not other way around.

 

[bobsobol]

I'm sorry to hear that. Open repositories rock for getting bugs found and resolved.

As to "shadows" PT already supports all the latest and most amazing hardware 3D shading and light casting techniques made available in DX6. I think OpenGL, at the time, had some nicer techniques available, but hardware at the time rendered such techniques at 6 - 10 fps fullscreen. (it looked neat on a GL Teapot in a window though)

There is some form of Phong / Gourad shading, which smooths corners off and draws shadow (darker surfaces when facing away from the light) on the objects and (a very new, and highly advanced feature) the shadow beneath players, and NPCs was added as PT came out of beta. (IMS, it was originally an option, as the FPS hit was pretty hard on some GFX cards)

So.... again, perhaps you'd like to rewrite the entire 3D engine for a different DirectX version without the source code? XD

Actually, if you can "hook" into the render, you may be able to get a depth map render which would allow you to apply DoF and faux ray-cast shadows as a SM2.0 shader after-effect? IMHO it's highly unlikely though.