IT-Talents.de Code Competitions

[BurnerR]

NOTE: Aber du hast Recht... das muss der Fehler sein, ich setzt mit dem "if" ja den Zähler auf 0 und nicht 0 + xPixelPerCell für maxX, dann ist der in der Tat negativ...

Um ganz genau zu sein (oben hatte ich es noch falsch geschrieben), j wird ja nicht negativ. Die Bitfolge, welche das signed int "maxX - xPixelPerCell" repräsentiert wird vom compiler als unsigned interpretiert (siehe Zweierkomplement) und dann j zugewiesen.

 

[theSplit]

@KaPiTN: Kein Problem - du hast ja auch genau die richtigen Stellen hervorgehoben, BurnerR hats dann auch nochmal exakt formuliert, von daher war das gar nicht falsch... waren GENAU die richtigen Problemstellen!

Aber auch der Part den du hervorgehoben hast, ich habe zwar das richtige machen wollen, aber "maxY" wurde ja IMMER mit erhöht - Fehler. Da erst die Breite komplett geparst/gescannt wird, dann erst "maxX" auf "= xPixelPerCell" setzen und dann ebenfalls in der Y Achse erhöhen um eine "Bildpixelareal" tiefer im Bild fortzuführen.

Ich hab da mal etwas gebaut* (Video), klappt "sehr geil".... aber es gibt da noch ein paar Probleme, einmal mit unterschiedlichen Auflösungen (der Bildinhalt verrutscht) wenn das Bild nicht X / Breite der Zellen hat, ich hab aber schon eine Idee dazu und auch wenn das Bild weniger als 1x1 Pixel zum ermitteln gibt - also mehr Zellen da sind, als es echte Pixel im Bild gibt. Aktuell breche ich dann den Vorgang ab wenn weniger als 1.0 Pixel zu Verfügung stehen, da die Analyse ja nicht zielführend wäre mit 0.34 Pixel pro Zelle. Wobei, das könnte man dann ja auch "skalieren" (irgendwie).

Und natürlich hab ich auch im "pixelData" Access noch einen Fehler entdeckt, ich wandere ja linear von oben links nach unten rechts, heißt wenn wir bei Pixel 5000 sind und das Bild 6000 hat, muss vom Offset die 5000 abgezählt werden, da wir nicht "j + (i * imgWidth)" allein verwenden können, da wir außerhalb des Bildes zugreifen. Richtig ist hier nochmal "i" abzuziehen.

*Allerdings, das Bild, hat einen Abmessung von 2500x2500 und ich arbeite mit 250x250 Zellen (im Beispielvideo)

@BurnerR: Stimmt, ich hatte auch schon einmal gehört dass das letzte Bit bei mögliche positiven wie negativen Werten für das Vorzeichen verwendet wird. Allerdings kannte ich den Begriff "Zweierkomplement" dazu nicht! Im Grunde sagt der ja dann "nur" das das Vorzeichen Bit abgeschnitten bzw. als Wert interpretiert wird, oder?

 

[BurnerR]

@BurnerR: Stimmt, ich hatte auch schon einmal gehört dass das letzte Bit bei mögliche positiven wie negativen Werten für das Vorzeichen verwendet wird. Allerdings kannte ich den Begriff "Zweierkomplement" dazu nicht! Im Grunde sagt der ja dann "nur" das das Vorzeichen Bit abgeschnitten bzw. als Wert interpretiert wird, oder?

Die Idee ist, dass bei signed Datentypen das erste Bit immer das Vorzeichen angibt.
1000 binär kann also je nach Interpretation 8 oder -8 im Dezimalsystem sein.

Prinzipiell könnte man ja auch so zählen:
1000 = -0
1001 = -1
1010 = -2
...
0000 = 0 <- hier sieht man schon ein Problem, es gibt die Null zweimal
0001 = 1
0010 = 2
....

Abgesehen von der doppelten Null ist damit aber nicht ganz so schön zu rechnen. Daher nummeriert man stattdessen mithilfe des Zweierkomplements, da ist dann
1000 = -8
1001 = -7
...

Unabhängig von der Sache mit dem Zweierkomplement wird ein C/C++ Compiler bei "unsigned int j = -1" die zu -1 gehörige Bitfolge der Variable j zuweisen und entsprechend vorzeichenfrei interpretieren.

 

[theSplit]

Unabhängig von der Sache mit dem Zweierkomplement wird ein C/C++ Compiler bei "unsigned int j = -1" die zu -1 gehörige Bitfolge der Variable j zuweisen und entsprechend vorzeichenfrei interpretieren.

Klingt logisch. Hätte mich auch gewundert wenn das Vorzeichenbit dann nicht zum "unsigned" Wert mit dazu genommen wird. Schließlich wäre die "Interpretation" ja so, das der Wert ohne ein Vorzeichen dargestellt wird und somie statt nur 7 + signed Bit alle 8 Bit für unsigned verwendet werden.

Würde ich spontan auch so machen da wir ja zum Datentyp "kompatibel" zuweisen.

Vielen Dank für den Round up

 

[KaPiTN]

@theSplit:

Ich mußte heute Mittag an Dein Feature denken. Und weil ich ja manchmal neugierig bin, Habe ich gerade mal kurz etwas ausprobiert, wie das aussehen könnte:


Spoileralarm?

Spoiler

 

[Roin]

@KaPiTN: Sehr interessant. Nur eine Sache fällt mir auf... Bei mir wird angezeigt, dass da Video 959MB hat.. Dabei sind es 959kb... Irgendwas ist da kaputt?

 

[KaPiTN]

Hier das gleiche. Da mußt Du Eraser zu Picflash befragen. Support-Thread

Das Video hat auf meiner Platte 937kb.

 

[theSplit]

Wieder ein neues Feature eingebaut... und ein neues Preview Video:

Ich setz es mal bewusst in einen Spoiler!

Spoiler

Eine History Recording Funktion:


Funktioniert so ziemlich geil, allerdings hab ich noch nicht geschaut wie viel Speicher in bei dem ganzen Rekording der "History" verbrate... allerdings werden nur relevante Zellen einbezogen. Und nicht alle!
Jedenfalls kann man so zwischen der Entwicklung der Zellen navigieren und diese begutachten.

Das Playback in der Geschichte erfolgt auch aus selbiger. Es wird nichts mehr berechnet dann.

 

[Roin]

@theSplit:
Ok das finde ich ziemlich geil gemacht von dir.
Da werde ich nicht mithalten können - ich mache dieses Mal vermutlich aber auch nicht mit - Zeitmangel und so...

 

[KaPiTN]

@theSplit:

Spoiler

Funktioniert Dein Malen auch bei schnelleren Mausbewegungen?

 

[theSplit]

@KaPiTN:

Sagen wir so, ab einem gewissen Punkt bekommt das "Fenster" nicht mehr den "Event" der Lib übergeben(?), also da gibt es schon "Aussetzer" - allerdings muss man die Bewegung sehr sehr sehr schnell ausführen.
Aber gute Frage durch was das limitiert wird - oder ob mein Programm nicht hinterherkommt die Events sauber abzufragen oder wie hoch die Polling Frequenz ist für den "Event", durch die Lib.

Wenn ich keine künstliche Pause/Delay reinnehme geht es aber sehr sehr flüssig.

 

[KaPiTN]

@theSplit:

Das ist ein allgemeines Problem bei Events. Ich hab das oben in #254 im Spoilerschon angedeutet.
Aber kein unlösbares.

 

[theSplit]

@KaPiTN: Also, ich kann ja im Grunde über die Lib nur das Abfragen, was diese auch übergibt.
Ansonsten müsste man vermutlich noch tiefer in die systemspezifische Programmierung oder hardwarenahe Programmierung gehen, oder?

 

[KaPiTN]

@theSplit:

Ich kenne Deine lib nicht.

Ich nehme einen Event der Maus und male dann auf dem graphics-Objekt.

system.drawing.graphics

 

[theSplit]

@KaPiTN: Ja, so in etwa mache ich das auch...

Spoiler

das Zeichen realisiert Cairo und das Mouse-Handling, "MousePressed, "MouseMotion" übergibt SDL mit Koordinaten relativ zum Fenster und etwas mehr an die Anwendungen. Diese werden dann übersetz in einen Array Index und die Zelle wird "live" geschalet, das Rendering kommt dann an andere Stelle wo auch das Board gezeichnet wird.

 

[KaPiTN]

Gut. Dann solltest Du mit einfachen Mitteln die Lücken verhindern können, ohne tiefere Systemkenntnisse.

 

[theSplit]

@KaPiTN: Also das Problem ist glaube ich nicht die Singalverarbeitung, SDL sammelt die "Events" in einer Queue, die dann abgearbeitet werden können, wie das intern funktioniert kann ich dir nicht sagen. Aber es sollte eigentlich nichts verloren gehen auf direktem Wege. So fern die Maus an einer Stelle "erfasst" wurde und gedrückt gehalten ist.

---

Hab eben noch schnell was gebaut:

Spoiler

[STATS] https://www.picflash.org/picture.php?key=XQ8767&action=show

Zugegeben, noch nicht 100% das, was ich mir glaube ich vorgestellt habe, aber es komm ganz nah dran.... und erfüllt seinen Zweck.

Die Stats kommen komplett aus der History.

 

[KaPiTN]

Die MouseMotion Events kommen vom OS in einem gewissen zeitlichen Abstand. Wenn ein weiterer Event feuert und die Maus ist weiter weg von der Stelle des letzten als eine Zelle groß ist, dann hast Du mindestens eine Zelle übersprungen.

 

[theSplit]

@KaPiTN: Ich glaube aber, die "relative" (zurückgelegte) "x und y" Werte (zwischen zwei MOTION Events), würden nur bedingt helfen, sonst würde man bei einem Sprung von x30 und y50, bei 10 mal 10 Pixel Zellen 3*5 (breit undhoch) gleichsamt "malen", ist ja nicht direkt im Sinne des Erfinders. Jedenfalls wüsste ich nicht direkt, wie sich das aktiver schalten lassen lässt, außer man erspart sich alles andere und läst das Fenster "aktiv" (Threading), währen ein andere das "Zeichen"/Rendering und die Logik übernimmt, um die Reaktionszeiten zu verkürzen? Aber im Grunde bin ich mit der Reaktionszeit mehr als zufrieden, damit der Fall den du beschreibst eintritt, muß man schon "herumschwirren" mit der Maus mit wirklich "hohem" Tempo - ich glaube das ist bei so etwas wie Photoshop aber auch nur bedingt anders

----

Mal wieder ein kleines "Gimmick/Extra" eingebaut, kam mir heute morgen die Idee, da dachte ich, ich setzt das mal um, basiert auf dem vorheringen und erweitert das nur in einer evtl. nützlichen Methode.

Spoiler

 

[KaPiTN]

Ich glaube aber, die "relative" (zurückgelegte) "x und y" Werte (zwischen zwei MOTION Events), würden nur bedingt helfen

Ich habe ja keine Lösung beschrieben, sondern nur das Problem erklärt.

Die Lösung ist, wie bereits erwähnt, eher einfach und hat nichts mit Reaktionszeit oder aktiver schalten zu tun.