Jammer-Thread

[Jonathan]

Harald Hoppelhase ist fertig, also hab ich nochmal den Landvogt mit dem aktuellen Stand der Engine kompilliert und gerade eine Stunde lang gespielt. Hab nebenbei ca. 30 ToDo-Punkte aufgeschrieben, das meiste echt Kleinigkeiten. Viel davon ist Usability, der Spieler soll mehr relevante Informationen besser angezeigt bekommen. Es war, was das angeht, tatsächlich gar nicht schlecht das Ding mal fast ein Jahr lang nicht mehr anzufassen und dann wieder "frisch" reinzukommen. Das gibt mir einen besseren Blick, wie neue Spieler das ganze vielleicht erleben werden und ob sie Probleme haben werden zu verstehen, was sie tun müssen.

Insgesamt war ich aber ziemlich happy, eigentlich. Klar, es ist nur ein unfertiges Hobbyprojekt, ABER: Ich hab eine Stunde lang meine Siedlung gebaut und wachsen gesehen und es fühlte sich wie ein richtiges Aufbauspiel an. Alles irgendwie in kleiner und mit vielen Ecken und Kanten, aber prinzipiell funktioniert es und macht Spaß und motiviert. Wenn da jetzt eine ordentliche Ladung Polishing drauf kommt, dann wird das tatsächlich ein richtig nettes, kleines Spiel. Als Einsteiger wird man vielleicht 2-3 Stunden brauchen (hoffentlich bleiben Leute so lange dran) aber das ist ja vielleicht genau die Portion Aufbauspaß die man sich mal übers Wochenende oder an 2-3 Abenden unter der Woche gönnen will, ohne sich gleich für ein 80 Stunden Endlosspiel in Anno 1800 verpflichten zu müssen. Ich freue mich richtig darauf, es fertig zu machen :)

[Schrompf]

Da freu ich mich doch. Aber warum dann im Jammer-Thread? Verklickt?

[Jonathan]

Ja :D

Das gehörte in Anti-Jammer. Hatte gedacht, dass es zu emotional und zu substanzlose für ein Update im Projekt-Thread ist, wollte es aber gerne trotzdem teilen und es ist auch wirklich legit Anti-Jammer :)

[Alexander Kornrumpf]

Video-Titel in meinen Youtube-Empfehlungen:

"How Creating ZIPFolders for Windows almost got me FIRED from Microsoft!"

Mein erster Gedanke: And it fucking should have. Was für eine bescheuerte Idee.

[Krishty]

Jetzt lag der Schrott unwartbar rum, wurde aber nach 20 Jahren endlich ersetzt. (Hab’s nicht ausprobiert)

Davon ab hat Dave Plummer aber ganz coole Sachen für Microsoft entwickelt, z. B. den guten alten Task Manager. So wie ich’s verstanden habe, war es auch nicht seine Idee, das in Windows zu integrieren, sondern er hatte es als Add-On entwickelt und verkauft.

[Alexander Kornrumpf]

Der eine oder die andere erinnert sich vielleicht noch an die Diskussion über Bluetooth Headsets (Forensuche nach "Jabra").

Nun das Jabra (ca. 300€, for the record) hat sich über die Zeit physisch in Einzelteile aufgelöst. Zuerst wortwörtlich eine Woche nach Ende der Gewährleistung laut Händler (Amazon) ist eine "Nase" im Milimeterbereich abgebrochen und dadurch die Ladestation praktisch unbrauchbar gemacht, dann hat sich so nach und nach der Bezug der Kopfhörer selbst in Wohlgefallen ausgelöst.

Ich habe dann ein Gerät eines anderen, ehemals namhaften Herstellers bestellt und da war, Überraschung, kein Bluetooth-Dongle bei. Das Dongle von dem Jabra hat sich wiederwillig gepairt, aber so richtig stabil wirkte das alles nicht. Es wollte außerdem mit einem Handy gepairrt werden und dann hätte man es über eine App konfigurieren können. Hatte ich nicht wirklich Lust dazu.

Dann also heute die Probe auf's Exempel und das erste Mal in einen Call damit. Mein Team bereichtet es klang in etwa wie Stand 2005.

Entschieden dass ich keine Zeit habe das zu troubleshooten, zurückgeschickt, Modell mit Kabel bestellt. Hätte ich mal auf euch gehört.

[NytroX]

Mein Tipp (falls man "on-ear" möchte, die trotzdem gut abschirmen): JLab Go Work 2nd Gen
Bluetooth alles dabei, Kabel auch (USB-C, kann zum aufladen und auch "live" benutzt werden), und keine Jabrafakte im Funksignal, gerichtetes Mikro mit Hardware Rauschunterdrückung, Mute-Schalter am Kopfhörer den die Gegenseite nicht hört (kein "klicken") und der die gängigen Protokolle unterstützt, damit die Software (z.B. MS Teams) das auch mitbekommt - der Mute-Status wird synchron gehalten!
Und auch günstig (ca. 50€), für den Preis macht man nix falsch, das Headset hängt mMn die meisten 250€ Dinger locker ab.
Achja - sowas wie Multipoint-Pairing kanns natürlich auch. Wer das nicht probiert hat weiß nicht wie ein gescheites Headset aussehen kann ;-)
(Aber man muss unbedingt auf das "2nd Gen" achten, das erste war totale Grütze :-)

[Krishty]

char foo[3] = "foo"; ist gültiges C, aber nicht gültiges C++.

Wie schade. Ich habe ständig Strings, die keine abschließende Null erfordern (in Lookup-Tables und so) und da wäre das wirklich nützlich.

[Lord Delvin]

Bei mir gibt's keine Nullterminatoren, weil mich die immer gestört haben und es zu ineffizienter Stringverarbeitung einlädt. Allerdings ist das erstaunlich oft im Weg, wenn man C-APIs integrieren will.

Bei den Headsets würden mich die konkreten Lösungen interessieren; mein Jabra löst sich auch schon auf.

[Alexander Kornrumpf]

Ich werde eventuell morgen nach einem Meeting genaueres zu berichten haben, aber der erste Eindruck von dem Modell mit Kabel ist dass es anscheinend eine Schallbrücke vom Kabel in das innere des Höhrers an sich gibt. Man bewegt also den Kopf, das Kabel, das hilfreicherweise eher so richtung Schulter geführt ist, reibt am T-Shirt und das hat man dann schön direkt auf dem Ohr. Das war doch früher nicht so? Oder habe ich das nur in der kabellosen Zeit vergessen? Was machen die Leute die sowas designen eigentlich beruflich?

[Lord Delvin]

Ich habe ein Jabra mit kabel und das hört man nicht; die davor hat man auch nicht gehört.

[Mirror]

Ich habe eben meinen Rechner neu installiert und musste den ASUS-Treiber-Installer starten. Nach einer gefühlten Stunde war er bei 80% für den Mainboard-Treiber. Ich habe dann die Geduld verloren und einfach neu gestartet. Was problemlos funktioniert hat, war die Werbung, alle paar Sekunden ein neues Banner ( hat sich aber auch wiederholt ). Schlimm genug das Visual Studio 2019 unter Windows 11 immer nach dem Beenden meine CPU auffrisst (rechentechnisch). Ich fasse Letzteres als Gängelei auf, mir eine neuere Version zuzulegen. Schlimm...

[Jonathan]

Schnell mal eben auf das letzte Element in einem vector Zugreifen? Einfach mal .end() dereferenzieren. Achnein, das zeigt ja auf das Element hinter dem letzten, natürlich muss man einen reverse Iterator benutzen, damit es funktioniert. Ist ja kein Problem, dann dereferenziert man eben einfach .rend()! Und weil der Debug-Build ewig zum laden braucht wird den ganzen Tag über auch nur der Release-Modus getestet und dann sucht man den Fehler eben in dem Mathe-Teil, der irgendwas semi-kompliziertes mit dem Wert aus dem letzten Element berechnet. Und schon wisst ihr, wie mein Nachmittag war :)

Um es kurz zu erklären: Als ich dann doch den Debug-Build mal gestartet habe (lustigerweise bloß, weil ich den Wert einen temporären Variable anschauen wollte, der im RelWithDebugInfo nicht verfügbar war), ist mir dann auch direkt aufgefallen, dass rbegin() korrekt gewesen wäre. Weil das letzte Element eben doch das erste ist, wenn man rückwärts geht...

[TomasRiker]

Schnell mal eben auf das letzte Element in einem vector Zugreifen? Einfach mal .end() dereferenzieren. Achnein, das zeigt ja auf das Element hinter dem letzten, natürlich muss man einen reverse Iterator benutzen, damit es funktioniert.

Nächstes Mal nimm lieber .back(), das gibt dir eine Referenz auf das letzte Element.

[Jonathan]

Der gog Launcher lädt automatisch ein über 1 Gig großes Update herunter, obwohl das Netzwerk als "Metered Connection" eingestellt ist - weil ich mit einem Handy Hot-Spot mit begrenzten Datenvolumen verbunden bin.

Das ist einfach ziemlich unprofessionell. Leute müssen verstehen, dass Internet in der Praxis keine unbegrenzte Ressource ist und ihre Software entsprechend schreiben. Für eine Firma dieser Größe ist das ziemlich peinlich....

[Schrompf]

Hab mein Handy (und mich) im See versenkt. Das allein war schon ein bissl lebensbedrohlich, aber die Nachwirkungen sind nochmal anstrengend. Mein Handy hat es zuerst gut weggesteckt, aber hat jetzt schrittweise immer mehr Funktion eingebüßt, bis gestern schlussendlich Touch im Ganzen versagte. Und nun steh ich da... neues Handy ist teuer, aber es ist zumindest nur Geld. Aber die Banking-App... Steam-2FA... die ganzen Arbeits-OTPs... Rücksetzcodes für diverse Zugänge, von denen ich damals nur jeweils ein Handyfoto gemacht habe... boah, ist das zum Kotzen. Mal gucken, ob der gute alte Reis was reissen kann, dass ich zumindest die Zugänge an ein Neues übertragen kann.

[Jonathan]

Ja, single point of failure ist ein richtig dummes Konzept. Akzeptiert aus Bequemlichkeit und weil es im Schnitt jeden nur alle paar Jahre oder so trifft. Aber ist es das wirklich wert?

Ich hab mein Handy vor einiger Zeit mal verloren. Beim Radfahren aus der Tasche gefallen (dumm, aber passiert halt). Lange gesucht, nicht gefunden, hatte mich aber an ein Kehrfahrzeug der Stadtreinigung erinnert. Also schnell da mal anrufen. Ah, geht ja nicht, hab kein Telefon mehr. Also EMail geschrieben, die Antwort kam nach 3 Tagen, man könnte da jetzt leider nix mehr machen. Bahn Fahren? Fahrplan kannste dir schön zuhause raussuchen und merken, du siehst ja an der Bushalte nicht, wann der nächste RE fährt. Ticket? Na hoffentlich funktioniert dein Drucker noch... Ach übrigens, hast du überhaupt noch eine normale Uhr um unterwegs zu wissen, wie spät es ist?
Ticket kaufen? Braucht ggf. Freigabe der Banking App. Alternativ am Automaten kaufen? Erstmal raussuchen, wo die blöde Bankkarte abgeblieben ist, läuft ja heute auch alles über die elektronische Version im Handy. Leuten sagen, dass es nix wird / man später kommt? WhatsApp funktioniert nicht ohne Handy. Signal gibt nach ne Woche (oder so) ohne Handykopplung den Dienst auf. Sicherheit und so. Nur Telegram tut noch, weil all deine Daten unverschlüsselt irgendwo auf einem dubiosen Server im mittleren Osten liegen. Yay! Wie viele Telefonnummern kennst du übrigens noch auswendig? Ist ja auch egal, hast ja eh kein Telefon mehr.

Neue SIM-Karte? Ja, wird dann in gut 2 Wochen per Post zugestellt. Bis dahin kannst du dich eigentlich ins Bettchen kuscheln und Cartoons glotzen, weil vom normalen Leben biste ja recht effektiv abgeschnitten...

Und warum der ganze Quatsch? Weil Generationen an Menschen zu blöde sind, sich vernünftige Passwörter auszudenken. Früher konntest du dich mit deiner ICQ Nummer und deinem Passwort auf jedem Gerät anmelden und loslegen. Klar, machste das im Internetkaffee und vergisst dich abzumelden, dann haste ein echtes Problem. Aber die alternative ist jetzt eben, dass alles bequem und einfach und ein wenig sicherer ist, aber all das auf Kosten des Single-Point-of-Failure. Muss ja nur mal blöd runterfallen, das kann jeden jederzeit treffen. Und das müsste einfach nicht sein.

[Lord Delvin]

Mein neustes Hobby: die Implementierung des C++ Exceptionhandlings zu lesen. Es fühlt sich an, als hätte man sich mal zu Intel Itanium ABI Zeiten Gedanken darüber gemacht, wie sowas funktionieren könnte, dann hatte man 'ne gute Lösung hat sie nicht wirklich implementiert, nicht wirklich dokumentiert und es stört eigentlich auch keinen, weil es außer C++ und Ada eigentlich auch keine Sprache gibt, die da irgendwas wirklich richtig macht. Brrrrrr.

[Jonathan]

Python hat Exceptions. Was ist an denen falsch? Alles kaputt?

[Lord Delvin]

Python und Java sind GC sprachen, die konzeptionell und in aller Regel auf einer VM ausgeführt werden. Das hat jede Menge Konsequenzen. Gerade der GC Teil führt dazu, dass man sich nicht überlegen muss, wie die Speicherverwaltung funktioniert. Exceptioninstanzen zu leaken oder double free hat genau dieselben Konsequenzen wie bei allem anderen auch, nur dass es da schwerer richtig zu machen ist. Soweit ich den CXAKram verstehe ist das thread local storage mit reference counting und jeder Menge seltsamer Regeln für genau die hässlichen Fälle, die entstehen, wenn man die Exception nicht versteht oder Speicher verwalten muss oder eine Exception im Handler kassiert.

[NytroX]

Exceptions sind super - mal sehen wann die Welt das merkt.
Sie kommunizieren klar den "intent" und verhindern, dass man (wie in Go) vor lauter Errorhandling den Code nicht mehr lesen kann (das war doch ursprünglich mal der Gedanke dahinter).
Die Implementierung in C++ ist halt nur Grütze, aber das hat ja nichts mit Exceptions an sich zu tun - es spräche ja nichts dagegen Exceptions intern über Rückgabewerte (std::expected) zu implementieren und "try/catch/throw" usw. nur als Syntactic Sugar zu haben. Dann hat man auch keine Probleme mit Lifetimes, double-free usw. und einen GC braucht man dafür auch nicht.
Zig macht das ja schon fast.

[Lord Delvin]

Ich finde Exceptions auch super, sonst würde ich mir den Kampf nicht geben. Ist schon wirklich das unlustigste, was ich bisher gemacht habe. Grenzwertig komplex und man kann keinen Fragen und mit niemandem drüber reden, weil jedes Detail irgendwie wichtig ist.

Das intern über Status/Either/Error zu machen verursacht halt im regulären Code verteilte Kosten, insbesondere wenn nicht dauernd alles explizit deklarieren will, weil man immer ein Statusfeld mitführen, prüfen und propagieren muss. Dass man's im Code nicht sieht bedeutet nicht, dass es nichts kostet.
Hoffe mein Typprüfungsbenchmark ist bald durchgelaufen; da kann ich dann auch noch was zu versteckten Kosten erzählen. Tatsächlich scheint der Benchmarklauf Stromkosten zu verursachen, von denen man auch ein Steak kaufen könnte. Das Problem ist aber eher die Hardware so lange am Stück nicht zu benutzen :-/

[Chromanoid]

Keine Ahnung, ob das irgendwie schwer zu machen ist, aber könnte man die Verantwortung über den Speicher nicht prinzipiell dem geben, der die Exception fängt. Wenn in der Exception drin steht, wie man sie abräumt, dann sollte das doch recht entspannt sein. Klappt natürlich nicht, wenn man an irgendwelchen Kompatibilitätsgeschichten mit anderen Techniken interessiert ist... ich glaube nur mit Rückgabewerten wird man da nicht glücklich, kann aber sein, dass ich da zu verseucht von GC Sprachen bin.

[NytroX]

Das intern über Status/Either/Error zu machen verursacht halt im regulären Code verteilte Kosten

Ja, stimmt. Das ist das größte Problem daran. Allerdings verursachen Exceptions das auch - einfach weil der Compiler plötzlich aufhört, Cross-Function Optimierungen zu machen.
Für mich sieht ein
int f(int a, int b) throws c halt immer automatisch aus wie
void f(int* ret, c* ex, int a, int b)
Das macht übrigens auch die Rückgabe schneller als ein Rückgabewert. Aber der Compiler macht das meist schon alleine, und muss es in einigen Situationen auch tun nach dem neuen C++ Standard. Jai macht das auch so, weil schneller.
Nachteil ist aber hier: mehr Argumente bedeutet ggf. mehr Register Usage beim Aufruf - und damit ggf. auch auslagern auf den Stack, was es dann wieder langsamer macht.

Also wie mans macht, es hilft alles nichts. Irgendwie muss man die Fehler mitbekommen und behandeln, die perfekte Lösung ist noch nicht gefunden :-)

https://www.open-std.org/jtc1/sc22/wg21 ... 1947r0.pdf

Da drin wurde der Sache schonmal auf den Grund gegangen. Ein paar interessante Auszüge:

Schemes that consider an exception throw as just an alternative return path was considered different: not C++ exception handling

=> Dummer Kommentar von mir: ÄÄh, warum? ;-P

simply demonstrating that a throw is slower than a return does not demonstrate a violation [of the zero-overhead principle]

=> returns sind also schneller

Alternative schemes based on “markers” in stack frames were tried early on, but their performance was deemed inferior

=> Tabellen-basierte Abarbeitung ist also relativ optimal für Exceptions ohne Rückgabewerte.

In Summe ist das soweit ich weiß immer noch Stand der Dinge.
Siehe auch hier der Talk von Herb Sutter: https://www.youtube.com/watch?v=ARYP83yNAWk&t=1200s

Wenn ich also eine Programmier-Sprache entwerfen würde, dann würde ich die schnellste aktuell bekannte Methode verwenden, die auch die Compiler noch gut optimieren -> Rückgabewerte (bzw. mit Syntactic Sugar).
Natürlich kannst du auch neue Wege gehen - im Paper steht auch dass es für den tabellenbasierten Ansatz durchaus noch Optimierungspotenzial gibt.

Würde mich auf jeden Fall interessieren wie es am Ende bei dir aussieht :-)
Zu den versteckten Kosten auch, finde ich super spannend was du da findest :-)

[Lord Delvin]

Es ist Sommer. Fünf Tage gemessen und man sieht wann die Sonne schien:

Zum Glück sticht das, worums ging so deutlich raus und der Fehler hält sich soweit in Grenzen, dass man's selbst bei den effizienten Lösungen verwerten kann. Alles was ich bei der Diss gelernt habe vergessen :-/
Jetzt muss ich nur den ganzen R und LaTeX Kram von früher zum Laufen bringen, dann kann ich was hübsches Zeigen, mit Farben und statistischer Signifikanz und so. Ich brauch 'n Assistenten :D

[Jonathan]

Ich mache ja gerade mit Tessellation rum und vieles funktioniert jetzt auch schon sehr gut. Aber wie so oft eskaliert wieder alles und ist am Ende schwieriger als gedacht.

Baustelle 1: Shadowmapping. Die lokale Auflösung hängt ja jetzt von der Kamera ab, und die ist für die Shadowmap einfach anders. Am naheliegendsten wäre es wohl, auch für die Shadowmap die Auflösung anhand der Render-Kamera zu bestimmen. Dafür muss ich aber zunächst ein paar Sachen im Renderer umschreiben, aktuell war das Shadow-Map pass im Wesentlichen ein Rendern mit anderer Kamera, jetzt brauche ich dafür zwei. Hmg. Ansonsten könnte ich aber auch darüber nachdenken, ob "identisches Mesh mit späterem Rendering" wirklich die beste Lösung für die Shadowmap ist, oder man nicht vielleicht doch eigentlich etwas anderes haben will. Meinungen?

Baustelle 2: Physik. Bisher basierte das auf dem Render-Mesh, ich hatte irgendwann mal für Bullet ein Heightmap-Terrain mit einem Mesh-Terrain verglichen, und das Heightmap-Terrain war um Größenordnungen langsamer. Jetzt hat aber mein neues Terrainmesh eine sehr niedrige Auflösung (wird ja schließlich später tesselliert) und die wird gerade für die Physik benutzt und das sieht gar nicht gut aus. Physik sollte ja vermutlich nicht von der Kameraposition abhängen (manchmal aber ggf. schon, kann man auch mal drüber nachdenken), das wäre aber auch sowieso zu kompliziert für jetzt, also muss ich mir jetzt eine sinnvolle Auflösung für die Physik aussuchen und hab dann halt 2 unterschiedliche Meshs. Ich hoffe, dass das nicht irgendetwas kaputt macht und Objekte nicht ständig im Boden stecken oder schweben...

Das sind beides keine unmöglichen Probleme, aber braucht halt doch alles Zeit bis es vernünftig eingebaut ist. Hmg.

[Schrompf]

Ha, ich erinnere mich gut, dass ich genau das ShadowMap-Problem damals schon bei den Splitterwelten hatte. Und ja, die LODs anhand der wirklichen Zielkamera zu bestimmen scheint mir immer noch die einzige Lösung zu sein. Sonst kriegst Du Selbstschattierung bei konkaven Krümmungen, und das sieht nicht aus.

Wir haben damals aber ne (Designer-gesteuerte) LOD-Zusatzentfernung erfunden, wo man z.B. für Charaktere einstellen konnte, dass beim ShadowMapping immer das LOD für +20m Entfernung eingesetzt werden soll. Alle Meshes hatten bei uns LODs, und die Wunsch-LOD wurde vorab anhand der Entfernung zur Kamera bestimmt. Mit der Zusatzentfernung konnte man für einzelne Meshes bestimmen, dass da für's ShadowMapping, Planar Reflections und sonstige immer z.B. 20m draufgeschlagen wurden. Aber das musste halt der Mensch von Fall zu Fall entscheiden, und für Terrain haben wir das aufgrund der Artefakte nie eingesetzt.

Und die Physik: wir haben immer die höchste LOD-Stufe für den Kollisions-Mesh genommen. Dann kriegst Du evtl. Eindringen oder Schweben auf größere Entfernungen, aber lieber dort als direkt vor der Kamera. Dass ne HeightMap so viel langsamer als ne TriangleSoup sein soll, kann ich mir aber ehrlich nicht vorstellen. Woher sollte das kommen? Die HeightMap müsste jederzeit ne Dreieckskollision outperformen. Vielleicht irgendwelche Scalings übersehen oder Preprocessing Steps nicht vorgenommen?

[Jonathan]

Danke, ich mach mal weiter und berichte.

Dass ne HeightMap so viel langsamer als ne TriangleSoup sein soll, kann ich mir aber ehrlich nicht vorstellen. Woher sollte das kommen? Die HeightMap müsste jederzeit ne Dreieckskollision outperformen. Vielleicht irgendwelche Scalings übersehen oder Preprocessing Steps nicht vorgenommen?

Ja, das klingt falsch. Aber gut, vielleicht ist "Capsule / Heightmap" - Physik aus irgendeinem Grund schwieriger als man zunächst denkt? Ist Jahre her, dass ich das eingebaut habe, damals gabs extra eine Bullet-Heightmap Klasse dafür, die hab ich benutzt und dann hat das Spiel geruckelt. Irgendwo im Internet stand glaube ich auch, dass die nich so dolle sei. Hab dann auf Triangle-Mesh umgestellt und das lief direkt super flüssig. Seit dem Hab ich es nie wieder angefasst, zu viel anderes zu tun.
Vielleicht war das damals noch in Entwicklung. Vielleicht würde heute alles besser funktionieren. Vielleicht muss ich nur mal die aktuellst Bullet-Version runterladen und alles wäre gut. Vielleicht bedeutet das Update aber auch, dass ich 2 Tage lang rumfummeln muss, bis alles wieder läuft und dann ist doch nix besser, weil aktuell ja auch alles funktioniert und ich habe wieder nur Zeit verschwendet, die ich in sinnvolle Features hätte stecken können. Oh well :D

[Schrompf]

Ich kann die Situation nachempfinden :-) Zum Thema "sinnvolle Features" würd ich aber sagen: du brauchst dafür doch gar kein Bullet? Für Deinen Städtebauer würde doch eine Funktion ausreichen, die aus der Heightmap die Höhe an einer Stelle interpolieren kann?

[Jonathan]

Hab doch nochmal nachgeschaut, hier sind 2 ähnliche Diskussionen:

https://github.com/bulletphysics/bullet3/issues/2032
https://pybullet.org/Bullet/phpBB3/viewtopic.php?t=8755

Scheinbar geht es hauptsächlich ums Raycasting, was ich aber ausgiebig benutze.

Zum Thema Bullet: Das ist ein wenig aus Bequemlichkeit gewachsen, ist ja die selbe Engine wie z.B. fürs Zombiespiel (oder Harald, hahaha). Damals, bei "Das Volk und der Turm" waren alle Gebäude noch Kugeln, was schlimm war, wenn man ein Feld neben einer Scheune anklicken wollte. Damals hatte ich kein Strahl/BB Test, Kugeln testen ging einfach schneller einzubauen. Das war aber dann so schlecht, dass ich danach direkt Bullet eingebaut habe, und schon hatte ich alle Tests, die man sich wünschen kann. Unter anderem muss man ja auch um Gebäude zu platzieren einen Pickray/Heightmap Test machen.

Bisher wurde die Heightmap im Wesentlichen beim Laden in ein Mesh konvertiert, dann ist alles immer einheitlich (wenn auch nicht immer optimal, natürlich). Das würde ja beispielsweise auch erlauben, in manchen Fällen komplexe Landschaften oder Höhlen zu haben, auf denen man trotzdem noch ganz normal bauen kann, etc.. Weil in der Spielmechanik halt alles Raycasts in eine Bullet-Physiks-World sind und ich testen kann, was immer ich will. Na, mal schauen wie viel davon beim Umbauen jetzt übrig bleibt ;)