Home | Tagebuch | QV | Bilder | Whk->Cpt | Kaokoland | Kontakt

QV Tagebuch



19.06.2008, QV5 Tagebuch

Ich habe beschlossen, den Weg zu QV5 zu dokumentieren. Es erscheint mir logisch, dies als Fortsetzung des Tagebuches zu sehen, welches ich letztes Jahr hier begonnen habe, als ich Deutschland verlassen habe und in Namibia blieb.
Es geht um weit mehr als nur "eine neue Version schreiben".
Dieses Tagebuch ist nicht nur für mich, denn ich habe in der Vergangenheit erlebt, daß es mir in persönlich schwierigen Zeiten immer wieder sehr geholfen hat, alles aufzuschreiben. Es ist auch für Euch, und hiermit meine ich meine Freunde im Schwalbennest und in Niedereschach und die Kollegen bei Touratech, die ja sehnsüchtig auf die neue Version warten.
Ich will Euch teilhaben lassen am Fortschritt, damit Ihr seht wie der Stand ist, wo es gerade klemmt, womit ich kämpfe, was ich so treibe.
Ich will Euren Input, Eure Kritik und auch Euren Applaus (wenns was gibt:)
Es hat mich sehr traurig gemacht, zu erleben, wie frustriert Ihr oft seid, weil ich so weit weg bin und Ihr nichts mitbekommt. Ich hoffe, daß dieses Tagebuch (zusammen mit häufigen Phonecalls ;-), dazu beiträgt, wieder etwas näher zusammen zu rücken und eine geile und würdige QV5 zu machen.

Unabhängig von allen persönlichen Aspekten der Sache ist QV5 auch ein große technische Herausforderung weil es einige neue Features habven wird, die es:

Das größte Feature ist zweifellos die neue Grafik, die komplett auf DirectX9 aufgebaut wird und die klassische Trennung von Kartenarbeit in der planen Draufsicht + zusätzliches 3D-Fenster zum spielen, aufheben wird. Es wird nur noch in 3D gearbeitet, und wenn man die Karte in der "klassischen" Ansicht haben möchte, ist es halt die Draufsicht.

Aber das wichtigste, und gleichzeitig das schwierigste, QV5 wird alle bisher und zukünftig unterstützten Kartenformate ins 3D heben. 3D findet in Echtzeit statt, es sind keine speziell auf 3D vorbereitete Karten nötig.

Softwaretechnisch bin ich vom alten Visual Basic 6 auf das aktuelle Visual Studio .NET aufgestiegen, welches für die nächsten Jahre das Entwicklungspaket in der Windowswelt sein wird (hat MS so beschlossen..) Dies bringt einen Haufen von hohen Hürden mit sich, die zu überwinden sind:


Und jetzt... ?

Ihr werden Euch vielleicht fragen "wann kommt sie denn nun?" Nun, wir haben ja mal Ende letzten Jahres den 1.6.08 beschlossen. Zu dem Zeitpunkt war mir nicht mal ansatzweise klar, wieviel Arbeit es sein würde. Ich wußte auch nicht, das ich auf .Net und DirectX gehen würde. Dieses Datum war nur eine Hausnummer um lebend aus der Besprechung raus zu kommen ;-) Sorry!
Heute weiß ich, dasß es sehr viel Arbeit ist und ich weiß auch, daß ich den richtigen Weg gewählt habe. Ich will kein schnelles QV5 machen, nur um Upgrades zu kassieren, obwohl ich die Kohle dringend bräuchte.

QV5 soll ein Meilenstein sein und daher muß vieles neu gemacht werden.
Aber trotzdem will ich QV5 noch dieses Jahr auf dem Markt haben.

Ich hoffe, daß Ihr mit diesen Seiten etwas anfangen könnt. Ich werde hier regelmäßig reinschreiben und bei größeren Änderungen eine kurze Mail an Euch schicken, daß was neues drin ist.

Viele Grüße
Tom



21.06.2008, der aktuelle Stand

QV besteht aus mehreren Modulen:
Herz ist die qv5.exe, dann Rasterkarte qvmap.ocx, Vektorkarte qvmapv.ocx, Tracking qvtracking.ocx und Events qvevents.ocx.
Angefangen habe ich mit dem neuem "Rasterkarten"-Modul (ich nenne es ab jetzt einfach 3D-Modul), welches das alte komplett erstetzen und auch später die Vektorkarten darstellen wird. Es ist komplett neu in .Net geschrieben und da die Grafik jetzt auf DirectX aufbaut konnte ich nichts aus dem alten Modul übernehmen und muß praktisch alles neu schreiben, d.h. Darstellung von Karte und Markierungen.

Anläßlich des BFU habe ich die Darstellung von Multitracking-Positionen zuerst eingebaut und hier kommt jetzt der Punkt, wo ich nach langen rumprobieren feststellen muß, daß das stufenweise Umstellen auf .Net nicht funktioniert. Die Interfaces zwischen den vb6-modulen und dem neuen 3D-Modul in .Net sind so lahm und instabil (Absicht von MS..?), daß es wirklich keinen Spaß macht.

Ich bin also derzeit dran, die wichtigsten Teile aus der qv5.exe nach .Net zu heben.
Die DEM-Klasse ist schon drüben, und das hat die Performance im 3D schlagartig verdoppelt.. Als nächstes kommt der ganze Kalibrierungskram. Parallel dazu entwickel ich das neue Handling von Markierungen.
Wie auch immer, die qv5.exe muß dann auch .Net und davor graut es mir am meisten....

Morgen läuft das Rennen. Es wird schöne Screenshots mit 40 Mountainbikes in 3D geben.


22.06.2008, Black Forest Ultra Marathon



Der bfu hat zwei Dinge gezeigt, zumindest was qv5 betrifft:

Weil es der allerwichtigstes Teil des 3D-Modul ist, hier mal eine kurze Erklärung, worum es geht.
Das Herz des 3D-Modul ist das Landscape Paging System.

Aus Performance-Gründen ist die Landschaft in Kacheln aufgeteilt. Eine Kachel hat eine feste Größe und besteht aus den Höhendaten und dem entsprechenden Kartenausschnitt als Textur. Die Auflösung einer Kachel ist variabel und hängt von der Entfernung zur Kamera ab. Die ganze Landschaft besteht dann aus vielen, vielen Kacheln, die passgenau zusammengestetzt sind.

Der Algorithmus ist eigentlich einfach.

Bei jeder Änderung der Kameraposition und Blickrichtung müssen die sichtbaren Kacheln und deren Abstand zur Kamera ermittelt werden.
Dementsprechend werden neue Kacheln geladen, bestehende Kacheln in der Auflösung geändert und nicht mehr sichtbare Kacheln nach einger Zeit gelöscht.
Das Problem ist jetzt, daß das Erstellen einer Kachel Zeit kostet. Je nach Auflösung müssen pro Kachel bis zu einige 10000 Höhenwerte aus den DEMs und entsprechend der Zoomstufe der Kartenausschnitt aus der Karte geholt werden. Wenn man sich einen Flug in großer Höhe vorstellt, kommen das schnell ein paar 100 Kacheln zusammen die bei Bewegung der Kamera ständig aktualisiert werden müssen..
Wie das sauber läuft kann man in GoogleEarth schön sehen. Wobei die den Vorteil haben, daß die die Kacheln nicht erst berechnen müssen, sondern alle Kacheln bereits vorberechnet sind. Das spart 90% der Zeit.
Dies kann ich in QV leider nicht machen, da das 3D-Modul ja mit den vorhandenen Karten beim Kunden arbeiten soll.
Ich habe allerdings einen Cache mit vorgesehen. Eine einmal erstellte Kachel wird gespeichert und wenn sie nochmal gebraucht wird ist das dann eine ganz andere Performance.

Das schöne am neuen .NET ist jetzt, daß ich mit mehreren Threads arbeiten kann. Die Steuerung der Kamera und der Bildaufbau sind der Hauptthread, der muß immer sauber und flüssig laufen.
Das Erstellen und Ändern der Kacheln sind weitere Threads, die parallel nebenher laufen. Vorteil ist auch, daß man auf den neuen Dual/Quad-Core Rechnern eine deutliche Performancesteigerung bekomt, da Windows Threads automatisch auf die Prozessorkerne aufteilt.

Z.B. dieser Screenshot enthält 140 Kacheln und 170.000 Höhenpunkte. Es dauert z.Z. 50sec, um ihn von 0 anfangend zu berechnen. Wenn er einmal da ist, kann man mit 50fps über die LAndschaft fliegen. (auf meinem alten Dell).






So, in dieser Ecke bin ich gerade dran, da ist noch viel optimierungspotential und darauf wird alles weitere aufbauen.


17.07.2008, Konvertierung...



Ich habe jetzt eine ganze Menge rübergeholt.
Einige der Karten-Treiber, die Kalbrierung, die DEM-Klasse ist optimiert und richtig schnell jetzt.
Das Landscape Paging System habe ich nochmal überarbeitet, vor allem die Aufteilung auf Threads nochmal geändert. So wie es jetzt ist, bin ich eigentlich sehr zufrieden.
Allerdings werde ich demnächst noch mal die bisher konstante Kachelgröße variablel machen müssen. Speziell für so Riesnkarten wie OpenStreetmaps oder auch unsere großen QBRs wird es die Performance nochmal steigern, wenn die Kacheln zum Horizont hin größer werden. Aber das für demnächst.

Zur Enspannung habe ich zwischendurch immer mal wieder ein paar nette Dinge eingebaut.
Es ist jetzt ein Modul zur Berechnung von Sonne, Mond und Planeten drin. QV weiß also immer, wo was gerade steht am Himmel. Man kann die Beleuchtung an den Stand der Sonne koppeln.. und so bei schlechtem Wetter einen Sundowner am Bildschirm erleben.
Die Positio von Sonne und der Planeten werden korrekt am Himmel angezeigt, ebenso wie der Mond mit den unterschiedlicen Phasen.
Das ganze Modul ist später einfach auf den gesamten Sternenhimmel erweiterbar. Für denn Fall, daß wir im All navigieren müssen eines Tages... :-)

Zur Vorbereitung auf das neue Trackreplay ist ein Modul zur Simulation jetzt fertig. Man kann ein beliebiges Datum/Zeit einstellen und von dort in Echtzeit oder beschleunigt die Zeit laufen lassen.

Eigentlich wollte ich jetzt dran gehen, als nächstes alle Markierungen, also Tracks, Routen und WPs, rüberzuholen. Bin dann aber sehr schnell im tiefen Schlamm der Inkompatibilitäten zwischen vb6 und .net hängen geblieben.
Es hat so keinen Sinn mehr.
Habe schon viel zu viel Zeit damit vergeigt, Probleme zu lösen, die nur deshalb auftreten, weil das Hauptmodul, also QV5.exe immer noch vb6 ist und nur das neue 3D-Modul in .Net ist. Habe also beschlossen, das als nächstes die qv5.exe nach .net muß. Mit .Net-2005 ging es leider nicht. Die Konvertierung hat das zum Absturz gebracht. Bin also gerade dabei, .Net-2008 zu installieren und werde dann wohl die nächsten Tage mit Konvertieren verbringen.


27.07.2008, Konvertierung klappt nicht...



Der Source-Code der qv5.exe läßt sich nicht konvertieren nach .net!
Habs ewig lang versucht, aber der Konverter, der im VS2008 integriert ist, crasht jedesmal nach ewig lang rummachen ohne vernünftige Fehlermeldung.
Ich habe ein Analyse-Tool zur Vorbereitung auf die Konvertierung, und das gibt ein paar 1000 Probleme aus, die vor der Konvertierung gelöst werden sollten.
Speziell einige von .net nicht mehr unterstütze Features von vb6 sollten vorher erstetzt werden.
Dann gibts da noch die Firma artinsoft.com. Der in VS2008 integrierte Konverter ist von denen, aber es ist nur eine Sparversion.
Die haben noch einen "richtigen" Konverter, der es angeblich perfekt kann.
Das Preismodell von denen zieht einem allerdings die Schuhe aus! Wird nach Quellcode-Zeilen berechnet. QV4 hat etwa 200.000 Zeilen, macht dann ca. 60.000,- US$ .... cool ne?

Ich habe also inzwischen beschlossen, daß ich die qv.exe nicht konvertieren werden, sondern parallel die qv5.exe in .net neu aufbaue. Habe einen Weg gefunden, wie beides für die Bauphase gut parallel läuft.
D.h. Ich habe die qv5.exe in vb6 und die qv5map3d.dll in .net. Beide sind jetzt so miteinander verknüpft, daß die exe nur noch die Oberfläche enthält und die ganze Arbeit in der dll abläuft. Und dieser Weg scheint gangbar zu sein.
Stück für Stück wird alle Funktionalität in der .net-dll neu gemacht und aus der vb6-exe entfernt. Habe jetzt das Anzeigen von WPs, Routen und Tracks rübergeholt.
Faszinierend, wie wenig neuer Code nur noch für dasselbe erforderlich ist..:-)

Und das Trackreplay geht schon. Der Screenshot zeigt die Landung von meinem letzten Flug nach D in Frankfurt. Es können 3D-Modelle als Symbol zugeordnet werden. Hier der Air Namibia A340.

Es geht weiter.... noch viel zu tun...


03.10.2008, Konvertierung endlich durch...

Dies ist das nächste und wahrscheinlich/hoffentlich letzte Kapitel der endlosen Story "Konvertierung von vb6 nach .net".
Der letzte Eintrag hier ist 5 Wochen her, der letzte Stand war: "klappt nicht"!

Seitdem ist das 3D richtig schön gewachsen, hat viele nette, neue Funktionen, z.B. einen echten "Verlauf" wie im Browser, was im 3D sehr schön aussieht, wenn man mit einem kurzem Flug zu der Stelle zurückfliegt, wo man vorher schon mal war.

Aber dann kam der Punkt, wo ich einfach die Verbindung zum Hauptprogramm machen mußte.
Und schon gingen wieder die alten Probleme los.
Wieder tagelang rumprobieren....
Wieder Frust ohne ende...
Dazu diese Schultergeschichte, Schmerzmittel, kaum Schlaf...

Und dann, als alle Hoffnung verloren schien, bin ich mehr zufällig drauf gekommen. Es waren 2 ganz bestimmte Controls der Firma Softelvdm, welche die ganze Zeit diese Probleme verursacht haben. Formulare ohne deren Controls liessen sich konvertieren, aber sobald eines der Controls auf einem Formular war, brach die Konvertierung ohne Fehler, ohne Hinweis warum, einfach ab.
Leider benutzt QV diese Dinger auf fast jedem Formular...
Aber das war ein Lichtblick, eine Idee, Hoffnung, vielleicht doch noch konvertieren zu können.
Und tatsächlich, drei Tage, zig emails mit dieser Firma, die zunächt jeden Support ablehnte und 599US$ für Upgrades später ließ sich der vb6-Code dann Stück für Stück tatsächlich konvertieren.

Uff!

Jetzt sind die 4 wichtigsten Module qvmain.exe, map, events und tracking konvertiert. Ich habe eine saubere Projektgruppe im Visual Studio 2008. Kein VB6 mehr, kein Gemurkse mehr, die zwei Welten irgendwie nebeneinander laufen zu lassen.

Ok, Erfolgreiche Konvertierung heißt noch nicht, daß QV5 jetzt auf dem Stand von QV4 komplett in .Net läuft, leider nicht. Es ist noch sehr viel Nacharbeit nötig, um ein paar tausend Compiler-Fehler zu eliminieren. Dies kommt daher, weil vb.net so verschieden zu vb6 ist.
Das ist jetzt einfach Fleißarbeit, bei der mit jedem Schritt auch immer was Neues entsteht.

Aber das Grundgerüst von QV5 steht schon:



Pure .NET :-)

Bis bald.... Tom


21.10.2008, Ein Meilenstein



Zum erstenmal ist das komplette Projekt vollständig in VS2008 als .Net kompilierbar. Xplorer und KArtenfenster laufen mit den Grundfunktionen.
Ich habe sogar schon ein Setup-Projekt und konnte QV5 auf unserem Vista-Rechner installieren.
Und es läuft sogar :-).

Die letzten zwei Wochen habe richtig Spaß gemacht. Das neue VS2008 ist schon Klasse. Soviele schöne, neue Funktionen, die einem das Programmiererleben viel leichter machen.
Vieles habe ich einfach neu gemacht, z.B. die Sprachumschaltung, das Sichern der Einstellungen, das Handling im Xplorer, das komplette Kartenfenster etc. Im Schnitt ist die selbe Funktionalität mit der Hälfte an Code zu machen im Vergleich zu VB6.

But still a long way to go......

Ich bin sogar fast soweit, daß ich mich nicht mehr ärgere, daß ich so lange gebraucht habe, um den Quellcode zu konvertieren und den Fehler zu finden (s.o.), daß ich so lange vesucht habe, vb6 und .net nebeneinander laufen zu lassen.
Das hat locker 3 Monate Zeit gekostet.
Aber diese Erfahrung mußte ich wohl machen.


14.01.2009, Zwischenstand

Die letzten Wochen vergingen mit viel Basis-Arbeit.
Strukturen, Klassen, Interfaces etc. Die verschiedenen Fundamente von QV halt.
Vor allem der Xplorer ist intern komplett neu, was sich jetzt so langsam auszahlt, wenn es an so Angst-Themen geht wie "Aktualisieren aller Fenster nach Ändern von Daten im Xplorer". Dieses Problem habe ich fast aus Versehen so nebenbei gelöst :-). Auch genial ist das Serialisieren von Klassen, auch eine neue Funktion in .NET. Damit kann man den Zustand einer Klasse mit einem Schlag speichern und wieder herstellen.
Besonders hilfreich ist dies bei den Markierungen, auch so ein Riesenthema und dazu will ich jetzt etwas berichten.

Markierungen

Eigentlich dachte ich, ich wäre vor Silvester damit fertig, wollte noch am 32.12 ein Update schreiben, habe dann aber im letzten Moment doch noch feststellen müssen, daß der Teufel im Detail steckt.
Aber der Reihe nach




(c) Tom Flemming, letzte Aktualisierung 24.01.2012