|
|
|
|
|
|
|
| | Zitat von csde_rats
Probier mal mit u vor dem "wäs. Ist ja Python 2...
Unicode in der Windows-Konsole ist allerdings grundsätzlich verbuggt, aber daran liegt es hier m.E. nicht.
| |
Geht auch nicht. Also Kurzfassung: Ignorieren, da nur im Terminal so?
|
|
|
|
|
|
|
|
|
|
|
Das ist sehr wahrscheinlich, jo. Iirc gibt es da ca. drei Kategorien für Fehler: 1. andere CP im Terminal gesetzt als erwartet 2. Font kann die Zeichen nicht 3. CP warumauchimmer nicht erkannt 4. ??!"?$"?"!?"
Probiers mal in IDLE, da sollte alles passen.
|
|
|
|
|
|
|
|
|
|
|
|
Ja, da geht's. Okay, dann egal. Danke!
|
|
|
|
|
|
|
|
|
|
Ich glaube, PlaTec klappt!
There are no save points when it comes to ladies, honey.
|
|
[Dieser Beitrag wurde 4 mal editiert; zum letzten Mal von Wraith of Seth am 06.07.2014 20:01]
|
|
|
|
|
|
|
|
|
Ich muss jetzt nur die generierten Daten-Dumps in brauchbare Bilder umwandeln...
| |
| Code: |
if (dump_topography) {
const float* map = platec_api_get_heightmap(world_id);
std::ofstream out;
char filename[64];
sprintf(filename, "platec_%d.dump", rand());
out.open(filename, std::ios::out | std::ios::binary);
out.write((const char *)map, map_side*map_side*sizeof(float));
out.close();
printf("Heightmap dumped into %s\n", filename);
dump_topography = 0;
}
} |
|
Wie wandel ich das sinnvoll wieder in eine Bilddatei um? Letztlich ist das ja "fast" brauchbar: Quadratische Bilddatei, Helligkeitswert irgendwie pro Pixel gespeichert. Das kann doch nicht so schwer sein, das irgendwie als SW-Bitmap zu laden...
Gentlemen. You can't fight in here. This is the War Room!
|
|
|
|
|
|
|
|
|
|
|
Das mit den ITler-gerechten Problembeschreibungen musst du wirklich noch lernen 
Also:
-Du willst Daten von A nach B mittels Medium C transportieren
-A zeigst du uns... teilweise
-C ist wohl der Dump
-Wie sieht B aus?
Ich würde spontan sagen, dass, damit C eine Nützlichkeit erfährt, du auch noch map_side speichern solltest.
Und dann machst du die Datei auf, liest map_side aus, holst Speicher, liest map_side*... aus der Datei in den Speicher und machst (platec_api_get_heightmap)^-1
|
|
|
|
|
|
|
|
|
|
|
Ich bin doch ein DAU+1 (aka ich kann Grundfunktionen, aber alles andere DAU-artig).
Die Kartengröße kenne ich (512, 1024... ...kann man händisch an der Dateigröße ablesen). Insgesamt ist die Karte dann z.B. 512*512 Pixel groß. Die API selbst übersteigt mein Verständnis, da passiert komisches Klassenzeug. Ich "verstehe" halt die Idee von "float* map" - soweit ich das richtig verstehe, sollte das ja in irgendeiner Weise die Höhe jedes Pixels wiedergeben, in Form eines Floats. Nur wird der halt komisch auf Chars gecastet. Und ich weiß nicht, wie ich das Ergebnis dann wieder in irgendeine für ein Grafikprogramm lesbare Bitmap/RAW/whatever umwandel.
imagej und gimp wissen nichts damit anzufangen, was dann in der jeweiligen *.dump landet.
Lorem ipsum dolor sit amet, consetetur
|
|
|
|
|
|
|
|
|
|
|
Jo, weil das kein Grafikformat ist.
out.write((const char *)map, map_side*map_side*sizeof(float));
-> das wird nur deswegen auf const char * gecastet (was unsauber ist, aber bei dir gehts eher ums funktionieren  , weil out.write nur Bytes (=char*) kennt.
So in der Art:
float *map = new float[map_side*map_side];
in.open(...
in.read((char *)map, map_side*map_side*sizeof...);
(platec_api_get_heightmap)^-1 (... map);
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von csde_rats am 06.07.2014 20:32]
|
|
|
|
|
|
|
|
|
Ich habe aber doch keine (...)^-1. Bzw. die Frage ist, wie ich das konstruiere.
Ich fürchte fast, ich muss diesen Lauri persönlich annerven...
...ich hätte btw nie gedacht, dass ich mal froh bin, Finnisch zu können:
| |
| Code: |
/* Miten nykyisen opengl-mainin koodit refaktoroidaan tänne?
* parametrien tarkistus, kommentit eli dokumentointi, muuta? */ |
|
Du gewinn den Nobelpreis und halt den Schnabel
|
|
|
|
|
|
|
|
|
|
|
|
Wo finde ich denn die platec Docs?
|
|
|
|
|
|
|
|
|
|
|
...docs...?
Manchmal kann man ein wenig was aus den Kommentaren erraten. Gerade die plate.cpp und so sind halbwegs gut kommentiert...
You need a reason to live! You don't need excuses to die!
|
|
|
|
|
|
|
|
|
|
|
|
Ich bin ja C++ Noob, aber holt der Entwickler da wirklich einen float pointer der aber offenbar auf einer char array zeigt? Wtf?
|
|
|
|
|
|
|
|
|
|
|
Kann man machen. 
Die Idee dahinter ist quasi, dass du die Daten byte-weise in den Speicher liest und nicht in Blöcken von 4 Bytes. Für die Interpretation als Float-Wert ist das durchaus äquivalent.
Du solltest je nach Plattform natürlich sicherstellen, dass die Werte im Speicher in der gängigen Endian-Konvention vorliegen.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von I-Bot am 07.07.2014 9:41]
|
|
|
|
|
|
|
|
|
|
Klingt für mich nach unnützem C Performance Voodoo, der einen dann zwei Jahre später gehörig in den Arsch beißt. Vor allem weil es beim sschreiben von ein paar Bytes auf einen Permanentspeicher ja auch unglaublich wichtig ist, dass die Daten schnell aus dem Speicher kommen. So eine Festplatte ist schließlich enorm schnell!
|
|
|
|
|
|
|
|
|
|
|
Also, dass das jemand aus Performance-Gründen macht, habe ich noch nie gehört. Eher aus einer obskuren Form der Bequemlichkeit. Ob das Lesen/Schreiben der Daten performant ist, hängt von der Implementierung der Funktionen ab.
Und wenn man es richtig macht, sollte es einem auch nicht in den Arsch beißen. Wie gesagt, es ist durchaus in Ordnung dir einen 4 Byte großen Buffer zu nehmen, ihn mit Werten zu füllen und dann als Float zu interpretieren. Wenn du weisst was du tust geht das. Oder eben ein Float zu nehmen und per memcmp mit einem 4 Zeichen char-Array zu vergleichen.
/Edit: Aber ja, die Frage nach der Wartbarkeit ist dann natürlich nicht beantwortet.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von I-Bot am 07.07.2014 10:50]
|
|
|
|
|
|
|
|
|
| | Zitat von Achsel-des-Bösen
Klingt für mich nach unnützem C Performance Voodoo
| |
Etwas, was man in C++ unter allen Umständen vermeiden will. Die Abwärtskombabilität und Kompabilität mit C ist zwar einerseits eine große Stärke von C++ (zumindest wird das immer wieder behauptet), andererseits allerdings auch ein riesiger PITA.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von cms am 07.07.2014 11:15]
|
|
|
|
|
|
|
|
|
Ich freue mich sehr auf den Moment an dem Rust stabil* genug ist um es tatsächlich zu benutzen. Das wird ganz großartig und dann fange ich auch mal an Sachen in Low-Level Code zu schreiben.
(*: Nicht das Rust zu abstürzen neigen würde. Aber im moment wird noch so viel an der Syntax geändert das man seinen Code sehr häufig anfassen muss um diese Änderungen mitzumachen. Sobald sich 1.0 nähert wird das aber nicht mehr passieren und dann wirds toll!)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Auf Rust 1.0 freue ich mich auch. Aber momentan erfreue ich mich so sehr an C++14, dass mir andere Sprachen fast egal sind.
|
|
|
|
|
|
|
|
|
|
|
Das machen v.a. Leute, die die formatted Funktionen (out << value) nicht kennen.
Manchmal ist es allerdings okay, einfach Binärdaten aus dem Speicher in eine Datei zu kotzen. Bei Floats aber nur, wenn man sich definitiv sicher ist, dass der Kram nur auf dieser Maschine gelesen wird.
Komplexere Datenstrukturen (hier nicht der Fall) will man aber m.E. mit einer richtigen Serialisierungsbibliothek angehen. Die können dann meistens auch platzsparendere und portable Binärformate schreiben, was nicht so ganz nichttrivial ist.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von Oli
Why not go?
| |
Go und Rust haben unterschiedliche Zielsetzungen. Go ist immer Garbage Collected was es automatisch für eine Reihe von Dingen rausnimmt (Echtzeit, viele Embedded Dinge, ...). Rust Ansatz über lifetimes und automatische malloc/free ist da besser geeignet.
Ferner bietet Go keine Möglichkeit zum direkten Speicherzugriff. Rust hat das Problem elegant gelöst indem man unsafe Blöcke deklarieren kann, wo alles erlaubt ist. Darüber kann man einfach seinen "gefährlichen" Code wegkapseln. Außerdem raubt der "halten wir die Sprache möglichst simpel"-Ansatz von Go viele Features wie z.B. keine Generics.
Go zielt mehr in die Richtung der Scriptsprachen (Python, Ruby, etc.) wärend Rust C ersetzen möchte.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Achsel-des-Bösen am 07.07.2014 12:49]
|
|
|
|
|
|
|
|
|
| | Zitat von csde_rats
Komplexere Datenstrukturen (hier nicht der Fall) will man aber m.E. mit einer richtigen Serialisierungsbibliothek angehen. Die können dann meistens auch platzsparendere und portable Binärformate schreiben, was nicht so ganz nichttrivial ist.
| |
SQLite As An Application File Format
An SQLite database file with a defined schema often makes an excellent application file format. Here are a dozen reasons why this is so:
- Simplified Application Development
- Single-File Documents
- High-Level Query Language
- Accessible Content
- Cross-Platform
- Atomic Transactions
- Incremental And Continuous Updates
- Easily Extensible
- Performance
- Concurrent Use By Multiple Processes
- Multiple Programming Languages
- Better Applications
[...]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
NetCDF/HDF5! DAS KANN ICH!
|
|
|
|
|
|
|
|
|
|
|
|
na endlisch kann der Junge mal wat
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von Oli
In other news: | | Dear Mr. Oli,
The Journal of Applied Physics has received a paper on Modified transport model considering neutral condition for organic semiconductors. As an expert in this field, would you be willing to review this paper and provide your comments? | |
So ein bisschen schmeichelt mir das ja schon. Aber da ich leider kein "Experte" auf dem Gebiet bin, werde ich es wohl ablehnen.
| |
Das paper ist so schlecht. Sprachlich ist es schon an der Grenze des Verständlichen, die Physik ist irgendwie keine mir bekannte und die fitten ihre ziemlich smoothen experimentellen Daten mit 5 freien Parametern ohne physikalische Bedeutung.
Hätte ich es mal nicht gemacht.
/e: Eingereicht vor >40 tagen. Ich nehme an, da wollte niemand.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Oli am 07.07.2014 14:10]
|
|
|
|
|
|
|
|
|
Das sind die Reviews, die mein Chef mit besonderer Vorliebe weiterreicht ... jedesmal wenn ich eine "vertraulich" E-Mail bekomme, weiß ich schon, dass er mal wieder nach Gründen sucht ein Paper abzulehnen
|
|
|
|
|
|
|
|
|
Ups.
|
Ich so: Ja, ein Vortrag über nicht-inertiale Bezugssysteme und entsprechende Effekte (Coriolis-, Euler-, Zentrifugal-Kraft, Sagnac-Effect, Thomas-Präzession, Lense-Thirring-Effekt) ist ein guter Vortrag für das Fachschaftspublikum. Jetzt habe ich die dritte Folie voll mit Definitionen, damit man weiß, was überhaupt "Rotation" und "beschleunigt" in der SRT bedeutet. Ich glaube, nach dem Foucaultschen Pendel werden am Donnerstag Köpfe platzen.
Setz dich an des Tisches Mitte, nimm zwei Bücher, schreib das Dritte!
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von Wraith of Seth
Ich so: Ja, ein Vortrag über nicht-inertiale Bezugssysteme und entsprechende Effekte (Coriolis-, Euler-, Zentrifugal-Kraft, Sagnac-Effect, Thomas-Präzession, Lense-Thirring-Effekt) ist ein guter Vortrag für das Fachschaftspublikum. Jetzt habe ich die dritte Folie voll mit Definitionen, damit man weiß, was überhaupt "Rotation" und "beschleunigt" in der SRT bedeutet. Ich glaube, nach dem Foucaultschen Pendel werden am Donnerstag Köpfe platzen.
Setz dich an des Tisches Mitte, nimm zwei Bücher, schreib das Dritte!
| |
Wenn du das schon so voraussiehst, wieso versuchst du nicht einen Publikumsfreundlicheren Ansatz? Ich kenne deine Vorträge natürlich nicht, aber wenn die nur ein bisschen so sind wie die Forenposts, stelle ich sie mir viel zu abgehoben vor.
@Rufus: Wow. 
|
|
|
|
|
|
|
|
| Thema: pOT-lnformatik, Mathematik, Physik XVI ( Ship painting activities ) |
