[Source] Multilanguage

11/18/2014 17:16 WurstbrotQT#16
Quote:
Originally Posted by Pumaaa View Post
Was programmierst du sonst so? Java?

Sowas zu sagen ist ein Witz.

Ein Switch Statement dass die Werte so setzt wie sie kommen ist einfach nur unnötig.

Und natürlich ist es im Vergleich zu der anderen Version Performancelastig.

Es fällt nur nicht auf weil das Ding nicht bei jedem Frame durchrennt.

Nur weil die Compiler besser werden heißt es nicht dass Programmierer dümmer werden dürfen.

Sowas kommt dann dabei raus:

[Only registered and activated users can see links. Click Here To Register...]

Und dann ohne default, damit auch SQLInjections direkt möglich sind :)
Ich habe nie behauptet dass das good practice ist, nur dass es in dem Fall, wie du auch selbst schon erörtert hast, nicht performancelastig ist.

Und ja, auf der Arbeit muss ich auch in java programmieren, aber das eher selten, sonst eher C# oder C++ ;)

Ich habe mich nicht wirklich mit dieser ganzen mikrooptimisierung auseinandergesetzt aber soweit ich weiß ist es in dem spezifischen fall nur 1-2 prozessorzyklen langsamer weil der stack einfach um den geswitchten wert erhöht wird, aber was weiß ich schon.
11/18/2014 18:50 Pumaaa#17
Ich sage ja nicht dass du oder irgendwer sonst hier ein schlechter Programmierer ist,

mir geht es allein um die Attitüde.


Die Aussage "Es ist nicht optimal, aber das spielt keine Rolle" finde ich ziemlich gefährlich, da sich soetwas stark auf den späteren CodingStyle auswirken kann.

Gerade weil der Code nicht von einem Super1337 Pro geschrieben wurde finde ich WaneTrain's Anmerkung passend, denn Sie hilft dem Threadersteller seinen Code evtl. in Zukunft zu verbessern.
11/20/2014 00:44 BinayFlyff#18
Eine Switch abfrage ist doch auf Compilier ebene genau das gleiche wie eine IF-Abfrage?

switch(x)
case y: a=0
case z: a=1
default: a=0

cmp x,y
mov a,0
cmp x,z
mov a,1
mov a,0

So müsste der das doch umsetzen?! (ka davon)
Bei WaneTrain seinem code wäre es einfach ein:

mov a,x

Also hätten wir 2 bis maximal 5 mal soviele Rechenschritte. OK Für den Prozessor sind das evtl. makrosekunden. Aber mach das im ganzen source an 10.000 stellen und wiederhole diese 10.000 Stellen 100.000x (vllt tackert ne while endlos durch?!).
Dann hast du 2.000.000.000 bis maximal 5.000.000.000 unnötige Rechenschritte.
11/20/2014 14:05 WurstbrotQT#19
Quote:
Originally Posted by BinayFlyff View Post
Eine Switch abfrage ist doch auf Compilier ebene genau das gleiche wie eine IF-Abfrage?

switch(x)
case y: a=0
case z: a=1
default: a=0

cmp x,y
mov a,0
cmp x,z
mov a,1
mov a,0

So müsste der das doch umsetzen?! (ka davon)
Bei WaneTrain seinem code wäre es einfach ein:

mov a,x

Also hätten wir 2 bis maximal 5 mal soviele Rechenschritte. OK Für den Prozessor sind das evtl. makrosekunden. Aber mach das im ganzen source an 10.000 stellen und wiederhole diese 10.000 Stellen 100.000x (vllt tackert ne while endlos durch?!).
Dann hast du 2.000.000.000 bis maximal 5.000.000.000 unnötige Rechenschritte.
Das kommt auf den switch an. Da die Werte hier jeweils pro case inkrementiert werden kann der Compiler das besser umsetzen (stackpointer erhöhen) als wenn es sich nur um random werte wie 1 3 9 100 etc handeln würde.

Siehe hier http://en.m.wikipedia.org/wiki/Branch_table
11/20/2014 14:59 Мentus#20
Wir wissen alle, das die Switch-Anweisung unnötig ist.
Aber was macht ihr hier eigentlich für einen Aufstand?

Quote:
Originally Posted by Pumaaa View Post
Gerade weil der Code nicht von einem Super1337 Pro geschrieben wurde finde ich WaneTrain's Anmerkung passend, denn Sie hilft dem Threadersteller seinen Code evtl. in Zukunft zu verbessern.
Du tust gerade so, als ob durch eine Switch-Anweisung die FPS im Client droppen würden.

Man sollte die Methode von WaneTrain nur dann verwenden, wenn man sich sicher ist das der Pointer wirklich vorhanden ist. Ansonsten bringt dir auch deine beste Performance-Programmierung nichts, weil der Client sonst abkackt.


@WaneTrain
Man sollte auch die Klammern richtig setzen, du castest (eindeutscht ischör) schließlich nicht den Int der durch GetCurSel() zurück gegeben wird, sondern einen Pointer der Klasse CWndBase(?) der durch GetDlgItem zurückgegeben wird, zu CWndComboBox.

PHP Code:
g_Option.m_chMultiLang = ((CWndComboBox*)GetDlgItem(WIDC_COMBOBOX1))->GetCurSel(); 


.. niemand programmiert perfekt.
11/20/2014 23:45 Wanetrain#21
Quote:
Originally Posted by Мentus View Post
Wir wissen alle, das die Switch-Anweisung unnötig ist.
Aber was macht ihr hier eigentlich für einen Aufstand?



Du tust gerade so, als ob durch eine Switch-Anweisung die FPS im Client droppen würden.

Man sollte die Methode von WaneTrain nur dann verwenden, wenn man sich sicher ist das der Pointer wirklich vorhanden ist. Ansonsten bringt dir auch deine beste Performance-Programmierung nichts, weil der Client sonst abkackt.


@WaneTrain
Man sollte auch die Klammern richtig setzen, du castest (eindeutscht ischör) schließlich nicht den Int der durch GetCurSel() zurück gegeben wird, sondern einen Pointer der Klasse CWndBase(?) der durch GetDlgItem zurückgegeben wird, zu CWndComboBox.

PHP Code:
g_Option.m_chMultiLang = ((CWndComboBox*)GetDlgItem(WIDC_COMBOBOX1))->GetCurSel(); 


.. niemand programmiert perfekt.
Tut mir leid, mein Fehler.

Du kannst aber grundlegen drauf Scheißen ob der Pointer Vorhanden ist, da der Client sowieso derber Dreck ist und Abkackt sobald GetDlgItem fehl schlägt.

Wenn man darauf gehen will das jeder Pointer immer Valid ist kann man gleich das Programmieren sein lassen, da dies nicht immer der Fall sein wird.

Quote:
___:0040E275 mov eax, [ebp+arg_0] ; //=> DPID
___:0040E278 push eax
___:0040E279 mov ecx, [ebp+var_4] //=> AR
___:0040E27C push ecx
___:0040E27D mov ecx, [ebp+var_18] //=> THIS
___:0040E280 call sub_421D50
___:0040E285 jmp loc_40FB03 ; jumptable 0040DEA3
Das ist EIN (!) Case in der OnSnapshot Funktion, nun rechnest du nur noch 2 Pushes evtl. weg, dann ja..

Quote:
mov ecx, [ FFFFFF ]; //=> Pointer zu Option Class
mov edx, [ ecx + FF ]; //=> Offset zu Multi Lang
Das sind 2 Haupt sachen die schonmal bei JEDER Case anwensend sind, dann kommt davor EIN jmp, in jeder case, da er es aber in einer Switch Case bereits drin dürft ihr gleich mal das Doppelte rechnen.

Heißt eine ganze case entspricht:

Quote:
mov ecx, [ FFFFFF ];
mov edx, [ ecx + FF ], 1; ( oder 0, jeh nachdem what.. )
jmp FFFFFF;
Der jmp ist das "break" was dich zu dem Open Message Box bringt, anschließen kommt wegen der 1. Switch noch ein jmp zum ganzen ende, aus der Switch Case.

Prinzip hier nicht viel, dennoch recht lustig.

Ach und Mentus, die ober OnSnapshot funktion kommt im übrigen aus der Forsaken Neuz, dürftest auch mal was machen (ischör) :p

Mfg. :3
11/21/2014 12:38 Мentus#22
Quote:
Originally Posted by Wanetrain View Post
Tut mir leid, mein Fehler.

Du kannst aber grundlegen drauf Scheißen ob der Pointer Vorhanden ist, da der Client sowieso derber Dreck ist und Abkackt sobald GetDlgItem fehl schlägt.

Wenn man darauf gehen will das jeder Pointer immer Valid ist kann man gleich das Programmieren sein lassen, da dies nicht immer der Fall sein wird.


Ach und Mentus, die ober OnSnapshot funktion kommt im übrigen aus der Forsaken Neuz, dürftest auch mal was machen (ischör) :p
Das mit der Klammer kann jedem passieren.

Man kann definitiv nicht darauf "scheißen" ob ein Pointer vorhanden ist.
Mein Client Ingame Crasht nicht, wenn ich vorher das Control Abfrage. Das sind 2 Zeilen mehr + kein Crash.
Ich sag es mal so; Das Window Control muss vorhanden sein, sonst hat das Fenster nicht die volle Funktion. Deswegen ist es da noch verständlich so zu handeln, aber in anderen Situationen ist so etwas Gift für die Programmierung.



Ein Pointer muss valid sein, deswegen überprüft man sie. Wenn man sie trotzdem verwendet ist ende mit der Anwendung, sei es der WorldServer oder der Client oder auch andere Anwendungen.


Quote:
Originally Posted by Wanetrain View Post
Ach und Mentus, die ober OnSnapshot funktion kommt im übrigen aus der Forsaken Neuz, dürftest auch mal was machen (ischör) :p
.. und nun :D?
11/23/2014 14:09 Serenity-.#23
Bei mir kommt beim compilen bei dieser zeile ein undeclared identifier.

if( s.Load(szFile ) == TRUE )
11/24/2014 14:47 alfredico#24
I don't understand why I have to login in-game to change the game language, do it properly and add an option in game launcher, it ONLY takes a few minutes...
11/24/2014 15:25 Pumaaa#25
Quote:
Originally Posted by Мentus View Post
Das mit der Klammer kann jedem passieren.

Man kann definitiv nicht darauf "scheißen" ob ein Pointer vorhanden ist.
Mein Client Ingame Crasht nicht, wenn ich vorher das Control Abfrage. Das sind 2 Zeilen mehr + kein Crash.
Ich sag es mal so; Das Window Control muss vorhanden sein, sonst hat das Fenster nicht die volle Funktion. Deswegen ist es da noch verständlich so zu handeln, aber in anderen Situationen ist so etwas Gift für die Programmierung.



Ein Pointer muss valid sein, deswegen überprüft man sie. Wenn man sie trotzdem verwendet ist ende mit der Anwendung, sei es der WorldServer oder der Client oder auch andere Anwendungen.



.. und nun :D?
Wobei er schon zu einem gewissen Punkt mit den Pointern recht hat, der Client hält teilweise nur zusammen weil diverse Dinge im Mempooler landen und Pointer auf (eigentlich) gelöschte Objekte noch vorhanden sind :D

Wenn man den Mempooler entfernt kann man durchaus auf diverse Programmierfehler stoßen, ist vielleicht ganz lustig.

Die Switch case Anweisung im DpClient habe ich mittlerweile auch ersetzt,
was für mich der ProgrammingFail 2k14 ist ist dass die NPC Dialoge ( Die Say/Speaks von den NPCs die in Flaris sichtbar sind ) jedesmal als Chat übertragen werden - und die Texte sind ja nicht gerade kurz.

Nutzloses Networking dass das ganze auch noch extrem unpraktisch für Multilanguage macht.
01/11/2015 21:45 Sakurax3#26
Bekomm immer diesen Error, hab meiner Meinung nach aber alles drin.

Code:
2015/ 1/11   21:39:58   GetDlgItem : nID=928 not Found.

2015/ 1/11   21:39:58   Jan 11 2015 19:53:38 6 rCnt=1

Neuz.exe caused an EXCEPTION_ACCESS_VIOLATION in module Neuz.exe at 0023:0052F9A1, CWndBase::GetClientRect()+0017 byte(s), c:\users\source\_interface\wndbase.cpp, line 1975+0008 byte(s)
resdata.h


resdata.inc: