Ist ein Weilchen her seit ich das letzte mal etwas gepostet habe, aber mich gibt es immer noch.
Meine lange Inaktivität liegt daran, dass ich die letzten 3 Wochen Prüfungen hatte und vorher natürlich jede Menge zu lernen hatte. Für viel anderes hatte ich keine Zeit.
Jetzt sind die Basisprüfungen an der ETH durch und ich habe 3 Wochen bis das Semester wieder beginnt, auf welches ich mich btw. bereits freue.

Im nächsten Semester werde ich dann auch als Hilfsassistent tätig sein und eine Übungsgruppe der Mathematiker/Physiker leiten. Das heisst dann Übungen leiten, Übungen korrigieren und wahrscheinlich sehr viele Fragen beantworten. Ich werde sicher noch meine eigene Seite entsprechend erweitern, um Informationen für meine Tutorlinge (wie nennt man die überhaupt politisch korrekt?!) bereitzustellen. Auch auf diese neue Erfahrung freue ich mich, was auch unter anderem daran liegt, dass man an der ETH für einen solchen Job nicht schlecht bezahlt wird.

Bis es aber soweit ist geniese ich mal noch das nichts-tun-müssen-aber-trotzdem-die-Finger-vom-PC-nicht-lassen-können. (Informatikstudenten werden wissen was ich damit meine. )

So long!Keine Kommentare | Kommentieren

Das arbeiten mit der WinAPI stellt sich nicht immer als einfach oder sehr benutzerfreundlich heraus. Das liegt unter anderem sicher auch daran, dass es sehr viele Wege gibt wie man etwas erledigen kann. Dann den einfachsten zu finden bedarf es oftmals das ausprobieren sämtlicher Möglichkeiten.

Ein erster Versuch
So ähnlich ist das auch mit dem rotieren von Bitmaps. Man sollte meinen, dass so etwas einfaches, wie die Rotation einer Bitmap relativ simple zu machen ist. Falsch gedacht! Ein erster Ansatz führt zu XFORM, mit dem man eine 2D Rotationsmatrix beschreibt, welche dann für eine Blitoperation mithilfe von SetWorldTransform benutzt werden kann. Das funktioniert auch gut, wenn man nicht all zu hohe Ansprüche hat. Falls aber der Wunsch aufkommt einen anderen Ursprung als Links Oben für die Rotation zu nehmen, dann kommt man da relativ schnell zu Problemen.

Ein anderer Weg
Glücklicherweise gibt es ja aber Alternativen und die gilt es zu finden. Netterweise lässt sich eine Funktion PlgBlt (genialer Name, nicht?) finden, welche laut Beschreibung eine Bitmap in eine andere kopiert und das zwar anhand von einem selbst definiertem Parallelogramm. Das klingt doch schon sehr gut. Man kann also eine Bitmap beliebig komisch in eine andere reinpassen. Das können wir für eine schöne Rotation missbrauchen. Nun gilt es jetzt aber einmal überhaupt rauszufinden, wie wir denn die Rotation der Ecken machen müssen. Doch hier hilft uns der erste Ansatz bereits sehr gut. Mit einer 2D Rotationsmatrix fällt einem das sehr leicht. Um jetzt nicht gleich mit Matrizen um uns zu werfen, können wir die Transformation auch gleich mit 2 Gleichungen machen, welche sogar in dem Beschreib zu XFORM zu finden ist.

[x',y'] rotate ( x, y, rotation ) { x' = x*cos(rotation) + y*sin(rotation) y' = -x*sin(rotation) + y*cos(rotation) }

- Unbekannt -

Wenn wir jetzt aber genau das gleiche benutzen, wie auch XFORM, warum sollen wir uns dann die Mühe machen überhaupt alles selbst zu implementieren? Ganz einfach, weil du mich noch nicht ausreden (/schreiben) lassen hast! Das schöne daran etwas selbst zu implementieren ist ja, dass man auch noch Platz für weitere Sachen hat. Und wir können somit die ersehnte Verschiebung des Koordinatensystems einfach erreichen. Das einzige, was wir dazu tun müssen ist die ursprünglichen Koordinaten um den Vektor des neuen Koordinatensystems verschieben. Machen tun wir das ganz einfach, indem wir vor der Rotation den Vektor abziehen und am Ende wieder dazu addieren.

[x',y'] rotate ( x, y, rotation, center ){ x -= center.x y -= center.y x' = x*cos(rotation) + y*sin(rotation) y' = -x*sin(rotation) + y*cos(rotation) x += center.x y += center.y }

- Unbekannt -

Et voilà. Jetzt haben wir eine beliebige Rotation eines Vektors um einen beliebigen Punkt.

Jetzt gilt es nur noch das ganze schön zu verpacken und das ganze ist fertig. Wie sich heraus stellt ist der Pseudocode bereits sehr nahe am wirklichem Code:

struct vector2d {
 int x;
 int y;
};
 
void rotate (vector2d src, vector2d& target, float rot, vector2d center ){
 src.x -= center.x;
 src.y -= center.y;
 
 target.x = (int) ( src.x * ::cos ( rot ) + src.y * ::sin ( rot ) );
 target.y = (int) ( src.x * -::sin ( rot ) + src.y * ::cos ( rot ) );
 
 target.x += center.x;
 target.y += center.y;
}

Das ganze dann noch genau für die Funktion PlgBlt anzupassen ist mehr eine Fingerübung und erfordert ein wenig mehr (trivialen) Code und darum lasse ich das hier im Blog. Es kann aber in dem Demoprojekt angschaut werden, wie man das machen könnte. Um das ganze für sein eigenes Projekt zu benutzen ist es wahrscheinlich am besten die Idee zu benutzen und dann den Code an die eigenen Bedürfnisse anzupassen.

Hier gehts zum Download es VS Projektes.

Fazit:
Ich hoffe ich konnte ein paar Leuten helfen das Rotationsproblem zu lösen, denn standardmässig wird auf SetWorldTransform verwiesen und wird auch als das Mittel für die Rotation in der Dokumentation genannt, aber es ist meiner Meinung nach viel zu unflexibel. Die Lösung mit PlgBlt funktioniert sehr zufriedenstellend und liese sich noch beliebig an weitere Bedürfnisse anpassen.
Keine Kommentare | Kommentieren

Alle, die einmal ein wenig länger in einem Forum aktiv war kennen das Phänomen des Crosspostings (oder für die Usenet Generation Multiposting).

Konkret geht es darum, dass ein Fragesteller ein und dieselbe Frage in mehreren (unabhängigen) Foren stellt. Dies ist Moderatoren oftmals ein Dorn im Auge und sie sperren den Thread, was bei anderen Usern dann wiederum auf Unverständnis stösst.

Doch Crossposting scheint ein Thema zu sein, wo manche (viele) Leute einfach aufgehört haben zu denken. Crossposter, wie auch die Leute, die es anprangern, denn die scheinen nicht zu begreifen, worum es eigentlich geht. Wie so oft ist crossposting nicht gleich crossposting und das vergessen manche Leute eben.

Wo ist das Problem?
Stellt euch vor, dass ihr in der Schule oder der Universität von jemandem etwas gefragt werded und als ihr genügend Luft geholt habt um Antwort zu geben läuft diese Person davon und frägt jemand anderen. Nicht sehr angenehm, oder?

Genau das gleiche passiert in Foren, wenn jemand Crosspostet. Oftmals geht der Fragesteller gar nicht auf die Antworten der Forenuser ein, sondern möchte nur die einfachst mögliche Antwort (Bei meinen Foren wäre das meistens fertigen Code) und daher werden gleich mehrere Threads in verschiedenen Orten aufgemacht. So ein Vorgehen ist einfach nur rücksichtslos und unverschämt gegenüber den Leuten, die sich Zeit nehmen eine Antwort zu geben und da manchmal richtiv viel Zeit investieren (Habe auch schon >1 Stunde ein Beispielprogramm gebaut).

Ein weiteres Problem ist, dass die Informationen, die nötig sind um ein Problem zu lösen nicht mit allen beteiligten Personen geteilt werden. Jemand, der sich Gedanken um ein Problem macht, der ist oftmals auch daran interessiert bessere oder einfach nur andere Vorangehensweisen zu sehen. Somit profitieren nicht nur die Leute, die die Fragen stellen, sondern auch die, die lediglich mitlesen oder auch aktiv helfen. Nicht selten kommt es auch vor, dass zu einem Problem viel mehr Antworten entstehen, als dass man am Anfang vermuten könnte und das kann dann für den Fragesteller sehr mühsam werden überall mithalten zu können.

Wo sind die postiven Seiten von Crossposting?
Offensichtlich gibt es aber auch durchaus gute Gründe für Crossposting. Wenn man wieder argumentiert, dass Informationen durch die Interaktion enstehen, dann kann man daraus folgern, dass je mehr Leute beteiligt sind der Gehalt höher ist, wobei natürlich Quantität nicht gleich Qualität ist, aber das ist wieder ein anderes Thema. Crosspostings können somit die Interaktion zwischen Foren fördern, welche sonst keinen Kontakt hätte und der Fragesteller hat mehr Antworten und Meinungen auf seine Frage.

Wie man richtig Crosspostet
Da wir jetzt wissen, wo genau der Knackpunkt bei Crossposts liegt, können wir herausfinden, wie man seine Frage richtig verteilt. Es gibt meiner Meinung nach 2 Arten von Posts in einem Forum. Die erste ist die konkrete, wo es ein Problem zu lösen gibt und oft nicht viel für die Lösung fehlt, wobei die andere Art eher dazu gedacht ist Meinungen oder Best Practise einzuholen. Wie man bei ein wenig nachdenken schnell merkt eignet sich die eine Art besser für einen Crosspost, während die andere eher unerwünscht ist.

Wenn man also ein konkretes Problem hat und das in einem zu dem Thema mehr oder weniger kompetenten Forum postet, dann kriegt man da üblicherweise innerhalb eines Tages eine qualifizierte Antwort und daher ist ein mehrfaches posten in verschiedenen Foren eher ungeeignet, weil das schlichtweg unnötig ist, wenn sich da mehrere Leute bemühen und man ggf. das eine Forum dann vergisst die Antwort zu posten, welche im anderen Forum entstand.

Bei der anderen Art von Frage eignet sich ein Crossposting schon eher, weil es dort oft nicht _die_ Lösung gibt und es interessant ist sehr viele Meinungen zu lesen, welche man nicht unbedingt mal kommentieren muss und daher ein allfälliges Vergessen auch nicht so tragisch wäre.

Jetzt wissen wir welche Art von Themen man verteilt fragen kann, aber wie soll denn das explizit gehen im Gegensatz zu single threaded (einmal nicht im Zusammenhang mit Prozessoren ) Fragen?

Das wichtigste ist (und das habe ich leider bist jetzt praktisch noch nirgends gehsehen), dass man bereits am Anfang des Posts in allen Foren mitteilt (und verlinkt), dass es in anderen Foren ebenfalls den gleichen Thread gibt und dazu noch die Begründung, warum man denkt, dass man es in mehreren Boards nachfrägt. Somit wird das Problem der Informationsverteilung elegant umgangen und alle haben die gleichen Möglichkeiten weitere Meinungen zu lesen.

Selbstverständlich kann man, wenn einem in dem einen Forum in realistischer Zeit (min. 1 Woche) nicht geholfen wird, seine Frage auch in anderen Foren stellen, aber dann bitte auch wieder die Foren miteinander verlinken, damit niemand etwas verpasst (es gibt auch Leute, die durch eine Suchmaschine zufällig auf die gleiche Frage kommen und wenn dann trotz einer existenden Antwort diese nicht gefunden werden kann ist es sehr ärgerlich).

Fazit
Trotz der eher schlechten allgmeinen Meinung von Crossposts haben sie ihre Daseinsberechtigung, aber man merkt sehr schnell, dass sie oft gar nicht nötig sind, weil in einzelnen (auch kleineren) Foren viele Antworten entstehen können und weitere Meinungen redundant sind. 1 Kommentar | Kommentieren

Diesmal gibt es eine kleine Projektvorstellung, welche von eine Kollaboration der Informatikstudierenden und dem AMIV handelt.

Zuerst mal vorweg:
BASTLI ist ein Ort an der ETH, wo man sich mit allerlei Gebastel im Elektronikbereich befassen kann. Man kann dort löten, schrauben, kleben, verkabeln usw. Dies dient nicht nur der praktischen Erfahrung, sondern auch zum Spass. Der BASTLI hat auch hin und wieder einmal ein Projekt und im Moment (seit 2009) arbeiten ein paar Leute an BIRD, einem interaktiven Dancefloor für Partys.

Doch was hat das ganze mit mir zu tun? Nein, ich arbeite nicht, wie man vermuten könnte an BIRD selbst, sondern ich mache einfach bei einem kleinen Wettbewerb mit, wo es darum geht ein Programm zu schreiben, welches dann das Board steuert. Zur Verfügung gestellt wird ein Java Framework, mit welchem sich die Platten sehr einfach steuern lassen.

Abgabetermin ist der 4 Juni um 23:59 (also in etwa jetzt ) und zu gewinnen gibt es einen Digitec Gutschein im Wert von 250.- CHF für den ersten Platz, eine Lötstation auf dem zweiten Platz und 2 Bausätze für die nächsten Plätze.
Leider sind die Platten noch nicht ganz Fertig (4/8 Modulen fertig) und daher wird der Gewinner erst im nächsten Semester bekannt gegeben.

Da es auf der Hälfte der Module noch nicht wirklich gut aussieht beschränke ich mich auf ein paar Screenshots der ganzen Animation aus der PC Emulation.

Man findet in meiner Einreichung alles, was man an einer guten Party findet:

Feuer:

Musik:

und Spiele:

Doch es gibt noch vieles mehr. Ich werden möglicherweise ein Video erstellen, wo man dann einen kompletten Durchlauf (oder zumindest einen möglichen) sieht.

In dem Sinne wünsche ich meinen Konkurrenten viel Glück. Sie werden es brauchen!

//EDIT 5.6.10, 00:05
Für die, die das Framework haben gibt es hier mein Java File. Es ist lediglich eines, über 2500 Zeilen lang und nicht wirklich sauber. Hat viele Formatfehler, weil ich es mit inkompatiblen Editoren bearbeitet habe. Es hat auch noch Bruchstücke drin, welche nicht genutzt werden und auch andere Stil/Code technische Mängel sind mir durchaus bewusst, aber wegen der knappen Zeit habe ich es ignoriert.

Das Framework gibt es hier. Falls ihr es nicht zum laufen bringt einfach mich kurz anhauen, dann helf ich. 2 Kommentare | Kommentieren

Heute bin ich mal wieder auf eine Eigenheit von C++ (oder besser des Standards) gestossen. Und das möchte ich jetzt kurz vorstellen.

Bekanntes:
Es geht im wesentlichen über Vorhersagbarkeit von nicht initialisierten Variablen innerhalb einer Klasse. Wie allgemein bekannt ist, werden POD Datenmember (int, float, char usw.) nicht einfach so initialisiert.

struct foo
{
  int n;
};
...
foo f;
cout << f.n; // Wert von n ist undefiniert

Man muss sich also mit einem Konstruktor behelfen, um solche Variablen auf einen konsistenten Wert zu bringen.

struct foo
{
 foo () : n ( 0 ) {} // Initialisierungliste
 int n;
};
...
foo f;
cout << f.n; // 0

Man mag sich jetzt fragen, warum das nicht der ganze Speicherbereich für eine Objektinstanz am Anfang mit 0en gefüllt wird. Die Antwort ist (ohne Garantie) in der Performance zu finden. Ein solches ausnullen kostet Zeit, die man nicht unbedingt bereit ist zu zahlen.

Was kommt hinter dem Horizont?
Soweit so gut. Bis jetzt haben wir aber noch keine neue Erkenntnis gewonnen und es sollte alles bekannt sein.
Wir können uns jetzt aber die Frage stellen, wann ich von der ersten Version unserer Klasse dennoch etwas über die Werte sagen kann, wenn das Objekt initialisiert wurde.
Wenn wir uns diese Frage stellen, dann müssen wir uns unweigerlich über die verschiedenen Arten von Objekten in C++ Gedanken machen. Es gibt Objekte mit:

• statischer Lebensdauer
  
• automatischer Lebensdauer
  
• dynamischer Lebensdauer

Ich gehe jetzt stillschweigend davon aus, dass der Leser mit den letzten beiden Varianten vertraut ist. Doch was ist das erste? Der Standard definiert das sehr einfach:

All objects which neither have dynamic storage duration nor are local have static storage duration.

- ISO/IEC 14882 3.7.1/1 -

Das heisst, das alles, was nicht dynamisch angefordert wurde oder lokal deklariert wurde statisch ist. Darunter gehören Variablen, welche ausserhalb von Klasse und Funktionen deklariert werden und natürlich Variblen, welche als statisch markiert worden sind.

Doch zurück zur eigentlichen Frage. Was können wir für die verschiedenen Objekttypen über die Werte einer Instanz unserer Klasse aussagen?
Auch hier möchte ich wieder den Standard zitieren:

Every object of static storage duration shall be zero-initialized at program startup before any other initialization takes place.

- ISO/IEC 14882 8.5/6 -

Das gibt uns jetzt etwas an die Hand, womit wurd unsere Frage beantworten können. Was zero-initialized im Einzelfall bedeutet wird unter 8.5/5 geregelt. In obigem Fall heisst das einfach, dass die Datenmember auf 0 gesetzt wird. Wir können also folgenden Schluss ziehen:

struct foo
{
  int n;
};
 
foo f;
 
int main ()
{
  foo f2;
  cout << f.n; // 0
  cout << f2.n; // undefiniert
}

Interessant, was für eine kleiner Unterschied undefiniertes Verhalten hervorrufen kann. Dass das schlimme Folgen (wie z.B einen Vulkanausbruch ) nach sich ziehen kann merkt man oft, wenn man mit anderen Einstellungen kompiliert (Debug vs. Release ergeben da meist unterschiedliche Startwerte).

Fazit:
Wir wissen jetzt, dass es bei statischen Variablen eine zusätzliche Regelung gibt, was die Initialisierung des Speicherbereiches anbelangt. Nichts desto trotz sollte man sich auch in vollem Bewusstsein dessen nicht darauf verlassen, weil schnell eine Variable vom globalen in den lokalen Scope geschoben wird und dann sofort undefiniertes Verhalten hervorrufen kann. Good practise ist es immer Konstruktoren zu schreiben und dort (wenigstens) die POD Typen einen Startwert zu übergeben. 2 Kommentare | Kommentieren