letzter Beitrag von oobdoo am
Wichtig ist nur, dass JEDER, der mit seiner Kamera Fotos macht, vor dem 1. Foto auf seiner Kamera das Datum und die Uhrzeit prüft und ggf. korrekt einstellt, damit in den Fotos die Exif-Daten korrekt abgelegt werden.
Oder man fotografiert als erstes eine als richtig gehend bekannte Uhr und bestimmt so den Offset?
Oder man fotografiert als erstes eine als richtig gehend bekannte Uhr und bestimmt so den Offset?
Das hätte den charmanten Nebeneffekt, dass man Problemen mit UTC/Lokalzeit aus dem Weg geht.
Oder man fotografiert als erstes eine als richtig gehend bekannte Uhr und bestimmt so den Offset?
Wie soll das gehen bei einer unbekannten Anzahl der Kameras mit dem jeweils 1. Foto zu einer völlig unterschiedlichen Zeit mit einer (worst case) jeweils unterschiedlichen Uhrzeit ?
Um einen Offset zu bestimmen, müßte man mit allen Kameras zur gleichen Zeit 1 Foto machen und dann die könnte man aus der richig eingestellen Kamera und den Anderen die exif-Offsets berechnen.
Oder hab ich was vergessen ? Ich kann gerad nicht folgen 
EDIT: aaaahhh, nu fällt der Groschen 
Ein Foto von einer Uhr ! Ja, das geht natürlich aber das hat folgende Nachteile:
1. man muß jedem Fotografen hinterherlaufen, damit er die gleiche Uhr fotografiert - imho der gleiche Aufwand als den Leuten zu sagen, daß sie ihre Uhrzeit richtig einstellen sollten - hierbei kommt es ja nicht so sehr auf "Sekundengenau" an ....
2. man muß bei der Bilderserie jedes Fotografen später manuell den Offset-Wert festlegen/ in eine conf schreiben, was bei vielen Fotografen in Arbeit ausarten kann und die Vorteile eines schnellen script-processing deutlich abschwächt.
3. es ist auch eine erzieherische Maßnahme, dass bidde jeder Foto-Hoschi einfach sein Werkzeug korrekt einzustellen hat - ein "Wink mit dem Zaunpfahl" sozusagen 
... nicht den faulen Leuten (durch meinen Arbeitsaufwand) immer die Arbeit abnehmen 
Das hätte den charmanten Nebeneffekt, dass man Problemen mit UTC/Lokalzeit aus dem Weg geht.
so: feel free to enhance the script 
Nix besonderes bisher. Aber alle 1-Byte Befehle kann ich schon im Z80 Disassembler auswerten. Mal schauen wohin die Reise gehen wird. 
Nix besonderes bisher. Aber alle 1-Byte Befehle kann ich schon im Z80 Disassembler auswerten. Mal schauen wohin die Reise gehen wird.
ListView oder Grid verwendet?
ListView oder Grid verwendet?
Ich habe mit FlowLayout rumgebastelt.
Hier mal etwas, mit dem ich wertvolle Lebenszeit verschwendet habe....
Die ToDo Liste ist noch lang
So langsam geht es vorran. Nachdem ich die anderen Tage viel mit dem DataGridView gebastelt hatte, u.a. um die Zeilen bunt zu bekommen, habe ich es heute geschafft, die DGV mit einer hohen Geschwindigkeit darzustellen.
Das Zauberwort ist "Paging. Vom Prinzip her war mir klar wie das funktionieren soll, aber ich wußte zuerst nicht wie man das bei einem DataGridView umsetzen soll.
Nach vielem 
und die Lösung. 
DataGridView.RowCount
DataGridView.FirstDisplayedScrollingRowIndex
Da ich die Menge an Zeilen vorher weiß, schreibe ich bei DataGridView.RowCount die Anzahl rein. 1-2 Sekunden später sind alle Zeile im DGV vorhanden, aber noch ohne Inhalt.
Dann berechne ich über DataGridView.FirstDisplayedScrollingRowIndex die Position innerhalb meiner Daten und füge dann die Werte ein.
Damit das nicht bei zum wiederholten mal passiert, setze ich noch ein Flag.
Oder so ähnlich. Heute so gefrickelt wäre passender.
Aha
oobdoo: Erklär' doch mal kurz, was dieses 'DataGridView' tolles ist. Google macht mich da auch nicht viel schlauer . Was kann es, was Excel/Access nicht können z. B.?
Hab' mir die Tage auch was gebastelt. Eine 'BASIC-Erweiterung' für z. B. FruttyMan (jaaa..., ich bin noch dran...):
Ein "PRINT AT" mit Richtungs- und Wiederholungs-Funktion. Passt in 92 Bytes. Farbcode kommt aus der aktuellen Cursorfarbe (im Screenshot halt manuell geschaltet). Die letzten beiden Werte können auch weggelassen werden - dann wird halt nur einmal an X/Y geprintet.
Bisserl Verilog für das z80 Modul.
oobdoo: Erklär' doch mal kurz, was dieses 'DataGridView' tolles ist. Google macht mich da auch nicht viel schlauer
Hab' mir die Tage auch was gebastelt. Eine 'BASIC-Erweiterung' für z. B. FruttyMan (jaaa..., ich bin noch dran...):
Mit einem DataGridView kann man prima verschiedene Daten tabellarisch darstellen.
Einiges geht auch mit anderen Steuerzeichen, aber ein DataGrid ist genau für dieses Zweck gemacht worden.
Es ist im Umgang aber komplexer für den Programmierer.
Ich arbeite gerne mit Excel, gerade weil man da prima tabellarisch alles Mögliche anstellen kann.
Nur einen Z80 Disassembler wollte ich mit Excel nicht versuchen. Das wäre bestimmt machbar, aber nur mit massiven Einsatz von VBA.
Und zwischen dem Editor vom VBA und VS liegen Welten zwischen.
Besser erklären kann es Syshack nachher, wenn er in Australien aufgestanden ist.
'BASIC-Erweiterung' für z. B. FruttyMan? 
Es ist im Umgang aber komplexer für den Programmierer.
Wieso komplexer? Ich finde es viel einfacher. Gerade das Gefummel mit GUI Masken und Tab-Auswählreihenfolge erspart man sich damit und das Handling von Rows/Columns ist sehr einleuchtend.
Zum DGV:
Viele Programme, die mit einer GUI Daten darstellen müssen, damit der User diese anzeigen und editieren kann, zeigen diese recordweise, also ein Datensatz auf einmal, in einer Maske am Bildschirm an.
Das hat Vor- und Nachteile. Ein Nachteil ist, dass man nicht mehrere Datensätze gleichzeitig sieht (ok, es gibt auch Kombinationen von Masken und Grids, wo der Bildschirm z.B. zweigeteilt wird). Das braucht man oft, wenn z.B. etwas sucht, oder zwischen den Datensätzen vergleichen will und sich schnell einen Überblick der Daten verschaffen will.
Auch ist gutes Maskendesign immer aufwändig und wenn zusätzliche Spalten an Informationen dazukommen, muss man das Design erweitern. Beim Grid hat es einfach entsprechend diese Spalten zusätzlich, die eingebunden werden, ohne dass man am GUI was anpassen muss. Wir verwenden bei unseren Tools in der Firma fast auschliesslich Grid auch für die Dateneingaben, gerade weil es oft User aus Finanzabteilungen sind, ist das Excel-ähnliche Aussehen schnell kapiert (und wichtig: akzeptiert).
Der DGV ist quasi ein UI Äquivalent zu einer Tabelle. Es wird auch auch deshalb verwendet, um Daten aus einer Datendank oder datenbankähnliche Strukturen anzuzeigen (z.B. auch CSV, XML Dateien).
Ich verwende es oft um z.B. 10'000e Records darzustellen. Es ist, je nach Art des Handlings (und des Herstellers, ich verwende die Grids von Infragistics) schnell und ist optimiert für das Handling grössere Datenmengen.
Typischerweise verwendet man es in .NET mit einem DataSet und DataTables und einem DataAdapter für das verlinken der Tables zum DGV. Wenn das Grid (Fremdhersteller...) das unterstützt, kann man auch hierarchische Daten damit darstellen ("Nested Grid"), z.B. wenn man 1:n oder sogar 1:n:m Relationen hat (Beispiel: Kunde-->Rechnung-->Rechnungspositionen).
Das Paging wird gebraucht, damit man nicht sinnlos warten muss, bis 1000e Datensätze geladen werden müssen, obwohl man am Bildschirm nur einen Bruchteil davon sehen kann. Man lädt nur scheibchenweise, was gerade benötigt wird (Grids von Fremdherstellern machen das auch automatisch).
Der DGV ist aber nicht auf reine alphanumerische Inhalte beschränkt. Man kann die Zellen auch mit anderen GUI Elementen darstellen bzw. einbetten, wie z.B. Checkboxen oder Bildern (Odo macht das in seinem GDV auch mit eigenen Controls, AFAIK).
In den frühen Windows Zeiten hatte Microsoft keine vernünftigen Grid Controls, da musste noch die Listbox herhalten oder man musste auf Drittanbieter ausweichen (deshalb bei mir Infragistics, habe die seit 2004). In Visual Basic (Classic) wurden dann Grid-Controls gebundelt und mit .NET hat MS auch ein brauchbares Grid, eben das DGV.
Wieso komplexer? Ich finde es viel einfacher. Gerade das Gefummel mit GUI Masken und Tab-Auswählreihenfolge erspart man sich damit und das Handling von Rows/Columns ist sehr einleuchtend.
Das DGN kann mehr, daher komplex. Würde man sowas selber programmieren wollen, dann wäre das für mich komplizierter.
Der DGV ist aber nicht auf reine alphanumerische Inhalte beschränkt. Man kann die Zellen auch mit anderen GUI Elementen darstellen bzw. einbetten, wie z.B. Checkboxen oder Bildern (Odo macht das in seinem GDV auch mit eigenen Controls, AFAIK).
Ich habe im DataGrid keine eigenen Controls eingebaut, sondern nutze dafür die Image-Eigenschaft einer Zelle. Mit selbstgebastelten Controls hatte ich vorher experimentiert, war dabei aber auch auf Probleme gestoßen, so das ich mir das DGV nochmal angeschaut habe.
Stammt eigentlich aus den 80ern, aber heute habe ich die Laderoutine für den Zeichensatz entfernt und die Daten direkt im Programm untergebracht.
Meine Jugendsünde nennt sich "Harrigans Coup".
Der Dieb Hurrikan muss eine bestimmte Anzahl von Geldsäcken einsammeln. Dabei muss er ggf. Wände wegsprengen, wofür er eine begrenzte Anzahl Bomben hat.
Hat er seine Aufgabe erfüllt, muss er schnell nach Hause (H) - und weiter gehts im nächsten Level.
Gesteuert wird mit den Cursortasten, die Bombe mit B ausgelöst.
Ist wie gesagt eine Jugendsünde und hat sicherlich allerlei Bugs - wer Spaß am verfeinern und spielen hat - hier ist es...
Es gibt keine Jugendsünden. 
Macht für ein BASIC Spiel schonmal einen guten Eindruck.
Und es wäre ein guter Einstiegt für Dich, das nach 6510 zu konvertieren. 
Oh, Danke! Die Verschieberoutine des Zeichensatzes ist allerdings schon in Assembler. In Basic dauerte mir das zu lange...
Nach einiger Zeit kommt ein OUT OF MEMORY ERROR. Das ist ein Stack-Überlauf, da einige Unterprogramme nicht per RETURN, sondern mit GOTO 2, GOTO 1000 oder GOTO 1005 (Hauptschleife) beendet werden.
Oha! Das sollte sich beheben lassen. Danke!
Gesendet von meinem CBM 3032 mit gemischten Gefühlen.
Den Harrigan find ich recht gelungen. Wer mit Computronic- und Homecomputer-Listings aufgewachsen ist, weiß sowas zu schätzen. Hat echt Charme.
Harrigan sieht schon recht gut aus. Erinnert mich an Robot 3.5 vom C16. Hier der Link zum Spiel: http://plus4world.powweb.com/software/Robot_3_5
Ich hab mich gestern an ein neues Projekt gewagt und natürlich heute auch gecoded bzw. bin natürlich noch dran ^^.
Arbeitstitel lautet BASIC Balloon Breaker und wird erstmal nur für den Commmdore Plus/4 erscheinen. Eine Portierung könnte es auch für den C64 geben. Aber eins nach dem anderen.
Links Alpha 1 und rechts Alpha 2 Phase
Die Aufgabe besteht darin, alle Balloons zum Platzen zu bringen ohne das der (Computer-) Gegner den Spieler schnappt. Klingt erstmal nach Bombjack, ist es aber nicht wirklich da ich hier die Level so aufbauen möchte, daß man mit ein wenig Logik rangehen muss. Auf die Idee brachte mich eigentlich mein vorheriges Portierprojekt Frutty Man. 
Das Spiel befindet sich derzeit in der Alpha 2 Phase, Updates dazu poste ich immer auf meiner Homepage oder bei Plus/4 World. Falls auch hier Interesse besteht, kann ich das ja in einem seperatem Thema hier bei Forum64 posten.
