Seite 62 von 70
Re: Anti-Jammer-Thread
Verfasst: 19.07.2021, 13:29
von Krishty
Ich habe für meine Domain eine Catch-All-Adresse definiert –
*@ krishty.com leitet weiter an
webmaster@ krishty.com. Die Wirkung ist, dass ich alle Mails bekomme, die an falsche Adressen geschickt werden (so lange die Domäne stimmt).
Das erspart Leuten, die mir schreiben wollen, Stress. Manche tippen
ifno statt
info, einige copy-pasten die Adresse von der Website mit einem Buchstaben zu wenig oder mit einem Satzzeichen zu viel, usw.
Gestern habe ich recht überrascht zur Kenntnis genommen, dass jemand in meinem Namen einen Google-Workspace-Account angelegt hat. Er hat dafür eine imaginäre Adresse
@krishty.com angegeben. Normalerweise verschwindet Googles
Willkommen zu Workspaces!-Mail damit als unzustellbar, aber durch Catch-All landete sie in meinem Postfach.
Ich habe nach einigen Minuten googeln tatsächlich
Google-Kundenservice gefunden (oh die Ironie!). Sie haben tatsächlich innerhalb von 24 Stunden zurückgerufen.
Die Dame hat mir erklärt, dass ich wohl nichts zu befürchten hatte, denn der Fake-Account konnte die Domain nicht verifizieren. (Offenbar wollte er das tatsächlich über meine Domain laufen lassen, aber kam nicht in den Webspace. Meine Server-Logs sehen sauber aus.) Der Account wird in 30 Tagen regulär auslaufen und das Gmail-Konto, das mit dem Fake-Account verknüpft ist, wird gelöscht.
(Ich habe einfach mal versucht, mich mit der Fake-Adresse bei Google anzumelden, und bei
Passwort vergessen wurde mir gemeldet, dass das Konto mit einem gmail-Konto verknüpft ist, das mir nicht gehört und rein zufällig wie meine Domain heißt.)
Anti-Jammer:
- Ich finde Catch-All-Adressen nützlich. Wer eine Domain hat, sollte eine Catch-All einrichten.
- Ich bin froh, starke Passwörter zu verwenden (wenngleich ich an der Einzigartigkeit feilen sollte).
- Ich bin froh, dass es bei Google doch sowas wie Kundenservice gibt.
- Ich bin froh, dass sie mein Anliegen verstanden haben und regeln konnten.
Jammer:
- Die Dame hat sich nicht vergewissert, dass mir (dem Typ am Telefon) auch tatsächlich die Domain gehört. Das klingt, als könne man auf Zuruf friedliebende gmail-User über den Support anschwärzen und ihre gmail-Konten löschen lassen, nur weil sie irgendwo eine Trial-Registrierung nicht abgeschlossen haben.
Re: Anti-Jammer-Thread
Verfasst: 27.07.2021, 15:51
von Jonathan
Ist euch eigentlich bewusst, wie großartig dgVoodoo ist?
Ich zocke ja gerne mal ältere Spiele. Leider laufen viele davon nicht mehr gut, und in der Regel liegt das an irgendwelchen Grafikproblemen. Vielleicht ruckeln 2D Spiele furchtbar. Oder die Auflösung wird nicht richtig angepasst. Oder die Farben sind total kaputt. Oder es stürzt gleich ganz ab. Aber echt viele Spiele laufen mit dgVoodoo wieder wunderbar, einfach ein paar dlls in den Spielordner kopieren, vielleicht noch kurz ein paar Einstellungen anpassen, schon kann es losgehen. Noice. Im Vergangenen Monat habe ich damit Anno 1503, Kao the Kangaroo, Sheep und Gruntz wieder ans Laufen gebracht. Sehr cool.
Re: Anti-Jammer-Thread
Verfasst: 27.07.2021, 17:51
von Krishty
Stimmt; dem muss ich noch einen Post
hier widmen!
Re: Anti-Jammer-Thread
Verfasst: 03.08.2021, 06:22
von joggel
Ich bekomme erst jetzt mit wie toll Kindle ist <3
Re: Anti-Jammer-Thread
Verfasst: 15.08.2021, 14:14
von NytroX
UTF-8 in Windows.
Until recently, Windows has emphasized "Unicode" -W variants over -A APIs. However, recent releases have used the ANSI code page and -A APIs as a means to introduce UTF-8 support to apps. If the ANSI code page is configured for UTF-8, -A APIs operate in UTF-8.
[...]
CP_ACP equates to CP_UTF8 only if running on Windows Version 1903 (May 2019 Update) or above [...]
https://docs.microsoft.com/en-us/window ... -code-page
Also mal getestet:
Code: Alles auswählen
int main(void) {
//Set and check code page
auto codepage = ::GetConsoleOutputCP();
if (codepage != CP_UTF8) {
println("Unsupported. Codepage is not UTF-8. It seems like your Windows is too old.");
return 1;
}
println("Привет, мир!");
return 0;
}
Code: Alles auswählen
D:\Projects\UnicodeTest> UnicodeTest.exe
Привет, мир!
D:\Projects\UnicodeTest>
Funktioniert.
Einfach so.
Mit der alten cmd.exe.
Unfassbar.
Re: Anti-Jammer-Thread
Verfasst: 15.08.2021, 18:51
von Schrompf
Wow, cool. Aber die MinVersion lässt mich doch zaudern. Heißt das jetzt, auf den Standard-Win10-Möhren des Großteils der Nutzer kann ich das nicht machen?
Re: Anti-Jammer-Thread
Verfasst: 15.08.2021, 19:33
von Krishty
Da der Kernel auch weiterhin mit UTF-16 arbeitet, fängt man sich bei vielen Systemaufrufen zusätzliche Konvertierung ein. Es gibt auch einige Aufrufe, die in der W-Variante nicht fehlschlagen können, in der A-Variante aber schon (kein Speicher zur Konvertierung der String-Parameter).
Ich halte UTF-8-Everywhere für ausgemachten Schwachsinn und empfehle, möglichst das native Encoding der Plattform zu nutzen.
Re: Anti-Jammer-Thread
Verfasst: 16.08.2021, 11:24
von smurfer
Nachdem Gaia Missions etwas enttäuschend war, bin ich von Carrier Command 2 begeistert. Für mich immer noch mit die beste Mischung aus Simulation, Strategie und Action, wie im Original von 1988. Zusammen mit HighFleet der wiederbelebten Marke Microprose freue ich mich über Nostalgie und über Spiele, die nicht dem typischen Einheitsbrei von heute entsprechen.
Re: Anti-Jammer-Thread
Verfasst: 16.08.2021, 12:12
von Krishty
In der Tat; habe letztens noch den Trailer gesehen.
Die neuen MicroProse-Spiele sind alles coole independent-Titel, keine riesigen AAA-Produktionen. Sie suchen auch Indie-Entwickler mit Spielen in fortgeschrittener Entwicklung und bieten Hilfe bei der Fertigstellung an. Wenn mein Flugsimulator mal weiter ist (in 20 Jahren), frage ich bei ihnen an.
Re: Anti-Jammer-Thread
Verfasst: 16.08.2021, 14:11
von smurfer
Ich bin gespannt, bis dahin ist dann der Markenname Microprose wahrscheinlich beim dritten Besitzer (Krishty?) ;)
Gibt sicherlich auch berechtigte Kritik an den Titeln, aber alles in allem bin ich sehr überzeugt. Steam-Kritiken sind z. T. grotesk (eher was für den Jammer-Thread): "Zu teuer, hat ja nur 1GB" oder "Schlecht, keine Survival-Mechaniken in 2021"...
Re: Anti-Jammer-Thread
Verfasst: 24.08.2021, 14:42
von Krishty
NytroX hat geschrieben: ↑15.08.2021, 14:14
UTF-8 in Windows.
Until recently, Windows has emphasized "Unicode" -W variants over -A APIs. However, recent releases have used the ANSI code page and -A APIs as a means to introduce UTF-8 support to apps. If the ANSI code page is configured for UTF-8, -A APIs operate in UTF-8.
[...]
CP_ACP equates to CP_UTF8 only if running on Windows Version 1903 (May 2019 Update) or above [...]
https://docs.microsoft.com/en-us/window ... -code-page
Also mal getestet:
Code: Alles auswählen
int main(void) {
//Set and check code page
auto codepage = ::GetConsoleOutputCP();
if (codepage != CP_UTF8) {
println("Unsupported. Codepage is not UTF-8. It seems like your Windows is too old.");
return 1;
}
println("Привет, мир!");
return 0;
}
Code: Alles auswählen
D:\Projects\UnicodeTest> UnicodeTest.exe
Привет, мир!
D:\Projects\UnicodeTest>
Funktioniert.
Einfach so.
Mit der alten cmd.exe.
Unfassbar.
Zweieinhalb Anmerkungen:
- Funktioniert nicht mit einem voll gepatchten Windows Server 2019, weil zu alt.
- Es reicht nicht, dass das Zielsystem das unterstützt – auch das System, auf dem kompiliert wird, muss das unterstützen. Falls der Quelltext nämlich nicht gerade mit Byte-Order-Mark abgespeichert wurde oder explizit /utf8 übergeben wird, interpretiert Visual C++ den Quelltext in User Code Page. Wo CP_ACP != CP_UTF8 bewirkt das, dass der String zu ??????, ???! kompiliert. Übrigens ohne Warnung! Yay für Build-Server mit anderem Update-Stand!
- println() in C++, what :)
Re: Anti-Jammer-Thread
Verfasst: 29.08.2021, 02:06
von NytroX
1)
Ja, stimmt, ist nix für ältere Systeme. Aber irgendwann muss man halt mal mit Abwärtskompatibilität brechen und es richtig machen.
Ich weiß, du hälst nicht viel von UTF8-Everywhere, aber ich arbeite mit Web-Services und irgendwo muss ich da ne String-Konvertierung reinbasteln.
Stimmt auch, dass es viele Funktionen gibt, die dann halt intern konvertieren. Aber dann brauch ichs nicht zu machen, ein Bug weniger bei mir :-)
std::codecvt ist halt auch fürn Allerwertesten weil die ganzen Facetten für UTF-8 nicht drin oder buggy sind. Bleibt noch der MultiByteTo...-Krams, und der ist auch nicht gerade schön und Windows-spezifisch. Sollen sie bitte selbst machen im Windoof, wenn sie keine gescheiten Interfaces anbieten :-P
Ich möchte halt den Großteil des Codes Plattformunabhängig halten, da passen mir manuelle Konvertierungen nicht so gut ins Bild.
Was ich aktuell entwickle dauert noch bis zur Fertigstellung und dann schreibe ich halt "mindestens Windows 11" drauf und der alte Quatsch kann mich mal ;-)
2)
Visual-wie? Brauch man das? "Ist das Kunst, oder kann das weg?" :-P
Ich benutze "g++ -finput-charset=UTF-8 [...]", da klappts auch mit den Nachba... ääh... source-files.
CP_ACP != CP_UTF8 ist bei mir übrigens der Fall. "if (codepage != CP_ACP)" ist true. In der M$-Doku steht, dass bei meiner Windows-Version das eigentlich gleich sein sollte, aber nein, natürlich nicht. Keine Ahnung warum. Aber es geht irgendwie trotzdem, wichtig ist, was GetConsoleOutputCP zurückliefert. (Vielleicht was mit den mingw Headern schief, aber da sind CP_ACP und CP_UTF8 harte #defines mit unterschiedlichen Nummern - wie sich da ab einem bestimmten Windows plötzlich was dran ändern können sollte ist mir schleierhaft...)
3)
Ups :-)
Die ist von mir, das war Code ausm Projekt den ich vereinfacht hatte zum Verständnis. Es gibt halt keine einfache Funktion für ne Ausgabe in C++; ich will keinen komischen iostream der stateful ist und ich will auch keine %irgendwas-Interpolation die eh immer ungefragt schief geht, weil irgendeiner das falsche Kürzel benutzt (meistens natürlich ich :-P). Einfach mal ein gescheites Interface, bitte :-)
Re: Anti-Jammer-Thread
Verfasst: 29.08.2021, 09:15
von Lord Delvin
Für die komischen "%irgendwas-Interpolation" Strings gibt es mittlerweile Compilerwarnungen, die ganz gut funktionieren ;)
Re: Anti-Jammer-Thread
Verfasst: 29.08.2021, 10:23
von Tiles
Puh, grade Armorpaint kompiliert. Die Onkels machen es einem ja echt schwer. Da wird einfach der letze Schritt nicht erklärt wie man denn eine Standalone hinbekommt. Da musst du noch die Exe in einen anderen Ordner packen nach dem kompilieren, die funktioniert an ihrem Platz wo sie erstellt wird nicht. So kann man seine User natürlich auch dazu bewegen doch die kommerzielle Version zu kaufen. Gut dass es Google gibt. Jedenfalls habe ich nun wieder eine Software mehr mit der ich überhaupt nicht zurecht komme :D
Re: Anti-Jammer-Thread
Verfasst: 30.09.2021, 18:04
von D-eath
Angebot für einen Umzug bekommen. Abgesehen davon, dass der Kollege, der alles "aufgenommen" hat, einen Kurs in Kundenumgang hätte bekommen sollen, bestand das formale Angebot aus einer Zahl und einer langen Liste an AGBs, die jegliche Fehler auf den Kunden abwälzen.
Keine Infos darüber, ob Kartons geliefert werden, kein Hinweis auf Haltverbot und alles schön pauschal.
Tja, da weiß man, wo die vielen positiven und doch immer recht ähnlichen Bewertungen herkommen: gekauft.
Re: Anti-Jammer-Thread
Verfasst: 30.09.2021, 20:44
von Krishty
Mit dem Jammer-Thread verwechselt? Oder feierst du die Erkenntnis? :D
Re: Anti-Jammer-Thread
Verfasst: 30.09.2021, 21:14
von D-eath
Ich lache drüber ob dieser Traurigkeit.
Re: Anti-Jammer-Thread
Verfasst: 09.10.2021, 08:38
von joggel
Ich finde es sehr schlau von glm eine Funktion
length zu nennen, die die Anzahl der Komponenten einer Matrix zurückgibt.
Diese Matrix war in meinem Fall
glm::vec3 =>
myVec.length()
Naja, hätte ich mir den Rückgabetyp angeschaut wäre ich vlt darauf gekommen, oder das
static beachtet. Aber unter
vec3::length() vermute ich spontan etwas anderes^^
Edit:
Verdammt! Anti-Jammer mit Jammerthread verwechselt...
Re: Anti-Jammer-Thread
Verfasst: 15.10.2021, 18:16
von Lord Delvin
Hab' gerade gelernt, dass man in Eclipse Trigger Breakpoints setzen kann, die andere Breakpoints aktivieren.
Gibt es für Java (oder C++; brauche ich bestimmt auch mal) eine Möglichkeit Breakpoints zu definieren, die nur dann verwendet werden, wenn man sowieso schon im Step-Modus durch das Programm läuft?
Ich kann doch nicht der einzige Mensch auf der Welt sein, dessen Code generisch, rekursiv und komplex ist :)
Re: Anti-Jammer-Thread
Verfasst: 22.11.2021, 01:02
von Krishty
MSBuild (also das Standard-System hinter Solutions und Projects, wenn man mit Visual Studio arbeitet) braucht fünf bis sechs Sekunden, um mein Projekt neu zu kompilieren.
Ninja braucht weniger als zwei.
Visual C++ mit MSBuild braucht über 20 Sekunden, um mein Projekt für x86/x64/Debug/Release zu kompilieren.
Ninja braucht drei(!!!).
What the actual FUCK
Ich habe monatelang erfolglos Header-Abhängigkeiten optimiert, obwohl der Flaschenhals MSBuild war :-O
Re: Anti-Jammer-Thread
Verfasst: 22.11.2021, 23:16
von Krishty
Kurze Erklärung, was da abgeht:
Visual Studio hat keine parallelen Builds. Sie haben nur parallele
Compiler.
Mein Projekt baut in fünf Schritten: Erst werden die HLSL-Shader kompiliert (weil die C++-Dateien das Kompilat verwenden). Dann werden die C++-Dateien kompiliert. Dann wird eine Assembler-Datei kompiliert. Dann werden die Ressource-Dateien kompiliert (Icons, Versionsinformation) und schließlich die EXE gelinkt. Abgesehen von HLSL und Assembler dürfte das der typischer Ablauf eines C++-Builds mit Visual Studio sein. (Je nach Einstellungen kommt noch der Manifest-Compiler dazu, oder mehrere Ressource-Schritte, usw.)
Und ganz genau so führt Visual Studio/MSBuild das auch aus: Einen Schritt nach dem anderen, und immer erst warten bis der Vorherige fertig ist! Die C++-Dateien werden zwar alle parallel kompiliert (sofern sie die selben Compiler-Einstellungen nutzen!), aber das entscheidet der C++-Compiler intern. Die HLSL-Shader werden fast komplett seriell kompiliert, weil sich ihre Compiler-Einstellungen unterscheiden (das eine ist ein Pixel-Shader, das andere ein Vertex-Shader, …) und der Compiler deshalb mehrfach aufgerufen werden muss.
Während MSBuild die vierte HLSL-Datei zum Kompilieren schickt, langweilen sich elf CPU-Threads zu Tode.
Auftritt Ninja: Ninja packt jede Datei in einen eigenen Job. Es beginnt mit HLSL. Während die paar Dateien als parallele Jobs kompilieren, schnappt es sich die Ressource- und Assembler-Dateien, weil die
nicht davon abhängen, und kompiliert die schonmal. Sobald sich der erste Kern langweilt, werden C++-Dateien eingeschoben. Und sobald der Linker als finaler serieller Schritt startet, macht Ninja das gleiche schonmal mit Dateien aus den anderen drei Projekten.
(Make würde es genau so tun, wenn es meinen Code denn kompilieren könnte. Kann es nicht, weil ich Leerzeichen im Namen habe, und das für Linux-Entwickler so exotisch ist wie mit Frauen zu sprechen.)
Ich bin echt baff,
wie schlecht MSBuild implementiert ist. Und die wagen sie es,
uns mit solchen ETW-Auswertungs-Apps zu beschäftigen, während bei kleinen Projekten das meiste seriell abläuft! Und für große Projekte haben sie MSBuild mit Solutions sowieso aufgegeben – dafür haben sie ja jetzt CMake-Support, der Ninja als Backend nutzt.
Re: Anti-Jammer-Thread
Verfasst: 05.12.2021, 12:05
von Lord Delvin
Code: Alles auswählen
[error] @ test/mar.tyr from 37:26 until 37:36
[error] could not realize access with expected type (Ref[HeapPointer[S]], T) : void
[error] note: a viable alternative might be:
[error] HeapPointer[S].new(this : Ref[HeapPointer[S]]) : void
[error] note: a viable alternative might be:
[error] HeapPointer[S].new(this : Ref[HeapPointer[S]], initial : S) : void
[error] note: a viable alternative might be:
[error] Object.new(this : Object) : void
[error] note: a viable alternative might be:
[error] S.new(this : S) : void
[error] note: a viable alternative might be:
[error] T.new(this : T) : void
Erster Gedanke: wie hab' ich die Overloadresolution jetzt schon wieder kaputt gemacht? Tatsächlich hatte ich bei der Vererbung im Testpaket einfach nur die Vererbungsbeziehung falschrum gemacht.
Mein Compiler kann meine Sprache einfach besser als ich :-)
Re: Anti-Jammer-Thread
Verfasst: 13.12.2021, 20:38
von Matthias Gubisch
Ich habe ein Monster erschaffen...
Angefangen hat es damit dass ich ständig die Synchronisation in meiner Vulkan Engine irgendwo verbockt habe, und ich Knoten im Hirn hatte von den ganzen Layout Abhängigkeiten für Image Resourcen.
Zum Glück haben sich schlaue Leute auch über dieses Problem schon Gedanken gemacht, und ich bin neben anderen Resourcen auf diesen Artikel gestossen:
http://themaister.net/blog/2017/08/15/r ... deep-dive/
und dachte mir cool das will ich auch haben und hab mal ganz unbedarft lostgelegt.
5 Wochen, ca. 3.5k Lines of Code und viel Haareraufen später: Es läuft :) : ) :)
Hat zwar im Verlgleich zu dem original aus dem Artikel noch ein paar Einschränkungen, aber bis auf die Tatsache, dass ich noch keine Resourcen aus vorherigen Frames unterstütze kann ich mit den fehlenden Features aktuell gut leben und kann mich mal wieder so netten Dingen wie Beleuchtung und Schatten widmen ;)
Re: Anti-Jammer-Thread
Verfasst: 14.01.2022, 07:53
von D-eath
Zahn Nummer 7 ist zu sehen, endlich ist die Unruhe, die schlechten Nächte und das Geschrei der letzten Tage wieder etwas besser :D
Re: Anti-Jammer-Thread
Verfasst: 31.01.2022, 06:17
von joggel
Ich schreibe meine Scopes jetzt nicht mehr so:
sonder so:
Ich fühle mich so progressiv 🤗
Re: Anti-Jammer-Thread
Verfasst: 03.02.2022, 21:52
von Krishty
Compiler-Warnungen sind awesome. Ich habe den Quelltext eines 25 Jahre alten AAA-Spiels in die Hände bekommen; rund eine Million Zeilen C und Assembler. Allein durch das Kompilieren mit einem modernen Compiler sind um die zehn Bugs aufgefallen – von Crashes bis zu „Gegner stehen blöd in der Ecke rum“.
Ich muss echt nur die Compiler-Warnungen durchgehen, und die Bugs purzeln und purzeln.
Nützlich waren auch die Run-time Checks von Visual Studio (/RTsu). Die sollen eigentlich Stack Buffer Overflows erkennen, aber sie stoppen die Ausführung auch, wenn ein Funktionsprolog ein Register nicht korrekt wiederherstellt. Den Typo im Assembler hätte ich sonst wahrscheinlich Jahre suchen müssen, und die resultierenden Crashes zeigten sich nur als Heisenbugs in optimierten Builds.
Weitere Lektionen: C ist so viel langlebiger als C++. Bei C++-Codebases muss ich immer mit einer Woche rechnen, sie überhaupt ans kompilieren zu kriegen – weil irgendwelche Randfälle im Präprozessor, bei Templates, oder in Argument-dependent Lookup heute anders behandelt werden als früher. Visual-C++-Projekte aus den 00ern sind da am schlimmsten. Aber C? Da war der einzige Fehler mit einem 25 Jahre neueren Compiler(!), dass man seine Variablen nicht mehr round nennen darf, weil C99 eine Standard-Funktion gleichen Namens eingeführt hat.
Außerdem ist es Gold wert, seinen Code mit mehr als einem Compiler zu kompilieren, wenn auch nur sporadisch. Die Codebase hier wurde sporadisch mit vier Compilern gebaut (GNU C Compiler, Borland Turbo C, Visual C++, Watcom C Compiler), und das hat alle Portabilitätsprobleme im Voraus erledigt.
Letztlich ist es ebenso Gold wert, alle SDKs dem Repo beizulegen. Das DirectX-5.0-SDK von 1997 kann ich noch im Internet Archive finden, aber bei vielen anderen SDKs (insbesondere proprietären, deren Lieferanten mittlerweile bankrott gegangen sind) schreit das sonst nach Rewrite der ganzen Komponente.
Re: Anti-Jammer-Thread
Verfasst: 03.02.2022, 22:16
von Jonathan
Hachja - ich wäre ja echt sehr dafür, dass man gesetzlich vorschreiben würde, dass Quellcode von Software die nicht mehr gewartet wird veröffentlicht werden muss. Weiß nicht ganz, wie man das umsetzen würde (wenn eine Firma pleite geht findet sich ja im Zweifelsfalle niemand, der den Code aufbereitet und veröffentlicht), aber es ist irgendwie ein absolutes Unding, dass Kulturgüter einfach so für immer verschwinden. Es gibt ja eine Reihe kommerzielle Spiele deren Code später veröffentlicht wurde und aus so vielen sind wirklich tolle Projekte entstanden und das sollte halt die Regel und nicht die Ausnahme sein.
Re: Anti-Jammer-Thread
Verfasst: 03.02.2022, 22:27
von Krishty
Total!
Re: Anti-Jammer-Thread
Verfasst: 03.02.2022, 23:22
von starcow
Eine Million Zeilen? Ich meine DOOM hätte um die 40'000 und Quake III um die 300'000 - also aus dem Jahr 1999.
Echt so viel?
Re: Anti-Jammer-Thread
Verfasst: 04.02.2022, 00:04
von Krishty
Direkt gezählt ca. 830k; 200k (ins Blaue geraten) können wir für die beiligenden SDK-Header abziehen. Ja; ist ein Brocken.