Hallo :-) Ich wollte hier eine erste Preview meines Grafiklibaries für den Attiny85 und ein kleines unfertiges Betriebssystem veröffentlichen. Die Version sollte primär als Preview gesehen werden, ich freue mich auf konstruktives Feedback und werde das einarbeiten. Grundsätzliche Features des Systems: Grafiklibary für den Attiny85/45, Darstellung von Layern, einer Konsole, Sprites und einer algorithmischen Ebene. Multitaskingbetriebsystem mit komprimiertem virtuellen Ram, und Swap ins Flash, unfertiger Netzwerkstack über Infrarot, ich habe meine IR-Diode gegrillt und warte noch auf Nachschub, der Code ist an dieser stelle also sicher nicht richtig lauffähig wegen der Portkonfiguration die sich vermutlich noch mit dem USI für den I2C beißt. Code zum Empfang von Netzwerkpaketen muss noch integriert werden. In allen Beispielprogrammen ist das Betriebssystem größtenteils abgeschaltet, man sollte diese Veröffentlichung hier also primär als Grafiklibary sehen. Das Multitasking und Swapping des Betriebsystems ist aber getestet und sollte funktionieren. der ISR-Funktion ist akut noch nicht zu trauen, ich werde das aber geradeziehen sobald meine neuen Dioden und TSOPs ankommen. Dank geht an diverse nützliche Beiträge in diesem Forum, insbesondere an den Entwickler von "GOS", und an den Entwickler dieses Libaries: Beitrag "SSD1306/1309 Library zum Darstellen von Text auf OLED Displays" Bei dem Libary sind 15 Demoprogramme enthalten die die Funktionalitäten demonstrieren. Hier ein Youtube Video der Grafikdemos. https://www.youtube.com/watch?v=WNJQXsJqSbM Grüße :)
So und jetzt mit Account hier noch eine kurze Beschreibung der Demos (steht aber auch im Youtube video und drunter): #1 Diagram In dieser Demostration zeichnen wir 2 Ebenen eine Ebene wird berechnet, das Diagram, eine weitere Ebene wird drüber geblendet, diese Ebenen haben jeweils Helligkeitswerte von 0 bis 63 werden zusammen addiert und dann mit Fehlerstreuung auf schwarz weis konvertiert #2 Alien Dieses Beispiel zeigt subtraktives Blending, und Textdarstellung, es werden 3 Ebenen gezeichnet, eine Textebene, über ihr eine berechnete ebene mit einem Grafikeffekt, und eine Bildebene, die Bildebene wird von der darunter liegenden Ebene subtrahiert. #3 Flexgrid Im Flexgrid Beispiel werden benutzerdefinerte Fonts gezeigt, der Systemschrift werden 6 Zeichen hinzugefügt und mit ihrer Hilfe wird eine Animation auf der Konsolenebene gezeichnet, darüber liegt ein Grafiklayer #4 Will it Bend Das "Will it Bend" beispiel zeigt einen klassischen Grafikeffekt, ein sich verbiegender Quader wird allein über die Berechnungsebene gezeichnet. #5 Oszilloskop Das "Oszilloskop"-Beispiel zeigt die Erstellung von Benutzeroberflächen. Ein simuliertes Oszilloskop mit einem Mauszeiger wird dargestellt. Darunter wird eine Textebene ausgegeben. #6 Alleycat "Alleycat" demonstriert die Nutzung von Konsolen und Animationen durch Umschalten von Layern. Es ist praktisch ein "Hello World"-Beispiel. #7 Plasmastern "Plasmastern" zeigt Fading-Effekte und einen berechneten Plasma-Grafik-Effekt. #8 Spaceship "Spaceship" demonstriert additives Blending und Rauschen durch Zufallszahlen. #9 Wobble "Wobble" zeigt die Manipulation von Layern on-the-fly. Während der Dekodierung des Layers wird eine Sinuswelle über dessen y-Position gelegt. #10 Origin "Origin" ist ein klassischer Copper-Effekt. Eine Grafik wird ausgegeben und jeweils spaltenweise manipuliert. Dadurch ergibt sich eine Fullscreen Animation. Zusätzlich wird eine Textebene angezeigt. #11 Face Value "Face Value" zeigt einen zeilenweisen Grafikeffekt. #12 Boing Ball "Boing Ball" demonstriert die Verschiebung von Layern und die Nutzung von Color-Keying. #13 3D Engine Die "3D Engine" stellt einen rotierenden Würfel dar. Primär wird das Zeichnen von Linien demonstriert. #14 Crossfade "Crossfade" liest direkt Daten aus zwei Ebenen, um damit eine Überblendung zwischen zwei Grafiken zu realisieren. #15 Raycaster "Raycaster" ist der Port einer simplen Raycasting-Engine für den PC. Eine Engine dieser Art wurde auch in original "Wolfenstein 3D" genutzt. Quelle der Engine, siehe Sourcecode.
Görg Pflug schrieb: > Hier ein Youtube Video der Grafikdemos. Und warum muss man sich dazu so eine hektische und nervige Musik anhören?
über Geschmack kann man ja bekanntlich streiten, den Ton bei Youtube abschalten ist aber relativ einfach!
library library library library library library library library library library library library library library library library library library library library library library library library library library library library library library library library library library library library library library library library :-)
Görg P. schrieb: > über Geschmack kann man ja bekanntlich streiten Bei diesem deinem "Geschmack" sprichst du Bände über dein Gemüt ....
Sowas gab es 1985 auch für den C64. Das sind jetzt 37 Jahre her. Wo ist die Innovation?
ein wesentlich flexibleres Rendering ist möglich, beispielsweise kann man eben Grafiken und Linien über den Text zeichnen... siehe auch der Ram verbrauch ist sehr gering, je nach aktiviertem Featuresatz, der Raycaster braucht beispielsweise 56 Byte statische Variablen, und ca 90 Byte Stack. siehe auch: Beitrag "Re: SSD1306 Library zum Darstellen von Text auf OLED Displays"
:
Bearbeitet durch User
OMG schrieb: > Und warum muss man sich dazu so eine hektische und nervige > Musik anhören? Könnte man mit Jerry Lee Lewis übertönen. mfg
PittyJ schrieb: > Sowas gab es 1985 auch für den C64. Das sind jetzt 37 Jahre her. > Wo ist die Innovation? Ich finde das wahnsinnig, das das auf einem IC mit 8 Pins läuft. Mich beeindruckt das!
das Library ist übrigens auf Github "umgezogen", wurde geputzt, unterstützt jetzt mehrere Konsolen mit Scrolling und Zoom, und als zusätzliche Platform den Arduino. https://github.com/GoergPflug/AttinyStreamGfxApi
Gibts ne reale Anwendung dafür? Zoom hab ich auf solchen Mini-Displays irgenwie nie vermisst, und ich kann mir gerade auch keine Anwendung vorstellen, wo ich sowas brauchen könnte.... Wozu soll das gut sein? Übrigens hat die Chip-Größe nix mit der Gehäuse-Größe zu tun. Ein ATMega328 dürfte sich da nur unwesentlich von einem ATTiny85 unterscheiden. Wenn du auf "klein" stehst, beschäftige dich lieber mit SMD!
:
Bearbeitet durch User
Wenn Du das wirklich für andere Leute benutzbar machen möchtest, musst Du jede Funktion mit Parametern, Rückgaben und guter Beschreibung (sowie ggfs. Beispiel) dokumentieren. Die Musik ist Geschmackssache, wenigstens mal nicht so langweilig, dürfte von mir aus auch Hardtechno sein ;-)
Angehängte Dateien:
-
6c5b9o.jpg
71 KB
Oh Mann, hört ihr euch eigentlich selbst zu? Wo ist die 37 Jahre alte Lib, in C geschrieben, die sich auf verschiedenen Plattformen nutzen lässt? @Görg: Auch wenn ich gerade keine Anwendung für Grafikdisplays habe, finde ich es gut, dass du dein Beispiel teilst. Das Video ist dabei sehr nützlich und sagt mehr als 1000 Worte. Danke!
Andreas D. schrieb: > Ich finde das wahnsinnig, das das auf einem IC mit 8 Pins läuft. Mich > beeindruckt das! Da kannst du mal sehen, wie leistungsstark sogar die ganz kleinen Mikrocontroller geworden sind. Ich finde das auch immer wieder faszinierend.
Görg P. schrieb: > So und jetzt mit Account hier noch eine kurze Beschreibung der Demos Wo liegt denn für mich der "Nährwert" dieser Libs ? Braucht man dass ?, versäume ich da was ? Hey, für Spielereien ist das Smartphone weit besser geeignet!
Hier läuft ja das µC-Net mal wieder zur Hochform auf. Warum muß der TO hier schon wieder derartig runtergemacht werden? Wen's nicht interessiert, wer keine Verwendung dafür hat oder wer meint das er es besser könne muß es sich ja nicht antun, sollte dann aber auch die Griffel still halten. Ich finde es gut wenn hier einer seine Arbeit teilt, auch wenn ich da wohl keine Verwendung dafür haben werde.
Zeno schrieb: > Warum muß der TO hier schon wieder derartig runtergemacht werden? Wen's > nicht interessiert, wer keine Verwendung dafür hat oder wer meint das er > es besser könne muß es sich ja nicht antun, sollte dann aber auch die > Griffel still halten. Du bist ganz schön anmaßend! Es muss wohl noch gestattet werden, Dinge zu hinterfragen, zu mal wir uns hier in einem technisch orientierten Forum befinden. Zeno schrieb: > Ich finde es gut wenn hier einer seine Arbeit teilt, auch wenn ich da > wohl keine Verwendung dafür haben werde. Ich frag mich ob es für dich nicht besser wäre Kochkurse auf YT anzuschauen.
ikannix schrieb: > Zeno schrieb: > Du bist ganz schön anmaßend! Es muss wohl noch gestattet werden, Dinge > zu hinterfragen, zu mal wir uns hier in einem technisch orientierten > Forum befinden. nein, ikannix, du bist anmaßend. hast du schon was sinnvolles beigetragen? in diesem Thread bestimmt nicht. Und auch eine Spielerei ist sinnvoll, weil man damit Programmieren lernen kann. Manche können halt nur meckern, wenn andere was machen. > Zeno schrieb: > Ich frag mich ob es für dich nicht besser wäre Kochkurse auf YT > anzuschauen. Ich frage mich, ob es für dich nicht besser wäre, die Tastatur wegzuwerfen...
ikannix schrieb: > Du bist ganz schön anmaßend! Es muss wohl noch gestattet werden, Dinge > zu hinterfragen, zu mal wir uns hier in einem technisch orientierten > Forum befinden. Ach ich bin anmaßend - ja wenn Du meinst. Hier wurde nichts hinterfragt, aber der TO wurde mehr oder weniger dumm angemacht, so wie ich gerade von Dir. ikannix schrieb: > Ich frag mich ob es für dich nicht besser wäre Kochkurse auf YT > anzuschauen. Anmaßend ist hier nur einer und der kannix. Wolfgang hat es ja auch schon auf den Punkt gebracht.
ikannix schrieb: > Görg P. schrieb: >> So und jetzt mit Account hier noch eine kurze Beschreibung der Demos > > Wo liegt denn für mich der "Nährwert" dieser Libs ? > Braucht man dass ?, versäume ich da was ? > Hey, für Spielereien ist das Smartphone weit besser geeignet! Dein Nick zeigt, wess‘ Geistes Kind Du bist. Armselig. @Görg P. – tolle Sache 👍
Mal abgesehen von der fragwürdigen Musikhinterlegung (Die vermutlich dem Alter und gewünschter Hintergrunduntermalung beim proggen/coden für den Flux oder so geschuldet ist??). Sind Überblendeffektr nicht so der Renner. Ein simuliertes UI mit zeigen einzelner Menüelemente wäre deutlich interessanter. Und wie man es dann programmtechnisch verwaltet, welche Resourcen es auf dem Controller benötigt... Der Würfel geht in diese Richtung. Beachtliche Arbeit!! Hab sowas mal auf einem 8051 machen müssen.
Abdul K. schrieb: > Beachtliche Arbeit!! Hab sowas mal auf einem 8051 machen müssen. Was denn ? Bevor man hier seinen Geltungsdrang freien lauf gibt, sollte man sich mal schlau machen und nicht nur so tun :-( Ein 8051 mit 12 MHz Clockfrequenz und einer entsprechenden Befehlszikluszeit von ca. 1uSec - Das muss mir erst mal einer erklären.
Wolfgang R. schrieb: > Ich frage mich, ob es für dich nicht besser wäre, die Tastatur > wegzuwerfen... Zuerst schmeißt du aber dein Lötkolben weg - dann reden wir weiter. Wenn ich mir deine "Museums" Beiträge auf deiner HP anschaue - dann ist es bei dir mit der Innovation nicht weit her. Schon klar dass dich so ein Beitrag gleich vom Hocker haut :-))
dieses forum wird immer besser, hut ab! zeigt ganz gut warum bei uns nix mehr geht, wird zeit das die überheblichen besserwisserischen alten? säcke endlich mal bei seite gehen.......
genervter schrieb: > wird zeit das die überheblichen besserwisserischen alten? > säcke endlich mal bei seite gehen....... Hm ? Ich tippe mal auf Zeno (der Anmaßende), Wolfgang (der Museumsdirektor) , Abdul (der 8051 Versteher), .....
ikannix schrieb: > Zuerst schmeißt du aber dein Lötkolben weg - dann reden wir weiter. > > Wenn ich mir deine "Museums" Beiträge auf deiner HP anschaue - dann ist > es bei dir mit der Innovation nicht weit her. Schon klar dass dich so > ein Beitrag gleich vom Hocker haut :-)) Ja, ich habe hunderte von Beiträgen aus allen möglichen Gebieten der Elektronik auf meinen Webseiten aufbereitet, das ist mit der Retroelektronik ein schöner Ausgleich zu meiner Arbeit als Elektronikentwickler, da hab ich nämlich genug moderne Technik jeden Tag. Außerdem versuche ich in diesem Forum ab und an Leuten zu helfen, die technische Fragen haben. Und ich finde es toll, wenn sich jemand die Mühe macht, technische Dinge aktiv zu durchdenken, das muss ja nicht immer gleich sinnvoll sein... Und was machst du so, außer anderer Leute Arbeit zu diskreditieren?
ikannix schrieb: > genervter schrieb: >> wird zeit das die überheblichen besserwisserischen alten? >> säcke endlich mal bei seite gehen....... > > Hm ? Ich tippe mal auf Zeno (der Anmaßende), Wolfgang (der > Museumsdirektor) , Abdul (der 8051 Versteher), ..... ikannix, der Schwätzer mit fehlender Sozialkompetenz...
genervter schrieb: > wird zeit das die überheblichen besserwisserischen alten > säcke endlich mal bei Seite gehen Bist du sicher, dass der Nachwuchs ohne die Ü40 Generation übernehmen kann? Auch die Corona Generation, mit ihren geschenkten Zeugnissen (ich weiß wovon ich red, ich habe Kunder)? Und die Arduino Maker? Vielleicht schätze ich das falsch ein, aber ich denke, dass die alten Meckersäcke nicht ganz Unrecht haben.
genervter schrieb: > dieses forum wird immer besser, hut ab! zeigt ganz gut warum bei uns nix > mehr geht, wird zeit das die überheblichen besserwisserischen alten? > säcke endlich mal bei seite gehen....... Sorry, wenn ich Demos sehe, die 1985 schon auf einem C64 mit <1MHz liefen, dann frage ich mich, wo der Fortschritt 37 Jahre später ist. Ein ATTiny gibt es mit 20 MHz, also 20 mal mehr Power. Und der C64 hat die Musik noch selber gemacht. Das hat nichts mit alten Sack zutun. Das ist mehr die Unwissenheit der Jugend, die jeden kalten Kaffee noch feiert.
Wolfgang R. schrieb: > Und was machst du so, außer anderer Leute Arbeit zu diskreditieren? Nix, weil ikannix :-)
Stefan ⛄ F. schrieb: > Vielleicht schätze ich das falsch ein, aber ich denke, dass die alten > Meckersäcke nicht ganz Unrecht haben. Mit was nicht Unrecht haben ? Haben wir immer so gemacht machen wir weiter so ?
Kann mand das nicht irgendwie bei Projekten und Co. ablegen? (bevor alles wegen Schlaumeier im Nirvana verschwindet?)
ikannix schrieb: > Mit was nicht Unrecht haben ? Dass sie manche Dinge besser wissen. Nicht jeder und nicht immer, aber im Schnitt habe ich durchaus das Gefühl, dass die Menschen in diesem Land hier immer dümmer werden.
@Görg: Beeindruckendendes stück software. Ich finde es spannend mit wie wenig Ressourcen das auskommt. GOS kenne ich auch recht gut, hab mal ein ähnliches OS geschrieben (nano OS, zu finden hier im Forum). Gruss tobi
Ich hätte da mal eine Frage zum Code..... In os_task_switch()
1 | stack_pointer = SP; |
2 | SP = stack_pointer ; |
Hat das einen Sinn? Wenn ja: Welchen? Sicherlich ist mir klar, dass du dir den gerade aktiven SP merken willst/musst. Aber das erklärt nicht das hin und her.
Stefan ⛄ F. schrieb: > ... aber > im Schnitt habe ich durchaus das Gefühl, dass die Menschen in diesem > Land hier immer dümmer werden. wenn ich so überlege - stimmt eigentlich ! 😎
Görg Pflug schrieb: > Angehängte Dateien: > AttinyGfxEngineAndOs.zip (44,6 KB) Echt geil! Jede Menge Sourcecode in Header-Datei. Ja genau so macht man das, da zeigt sich der wahre Profi. Passt auch zum Gemüt des "Musik"-Liebhabers wie er sich im Demo-Video zeigt.
das mit dem SP ist eine Nachlässigkeit, dort habe ich wohl vergessen etwas zu löschen was früher mal drinn war. Das Multitaskingbetriebssystem ist an sich eher ein "Nebenprodukt", ich habe es nicht ohne Grund aus der akuten Version auf Github komplett entfernt, schlicht weil es eher ein Experiment ist und es wohl dafür keine sinnvoll Verwendung geben dürfte, man ist auf kleinen Kontrollern schlicht mit anderen Konstruktionen besser dran wie mit preemtivem Multitasking und Swappping. Sinnvoll nutzbar dürften primär die Grafikfunktionalität sein, weil sie einige Probleme umschifft die andere Grafikbibliotheken auf dem Attiny haben, insbesondere das es eben mit nur 512 Byte Ram unmöglich ist den Bildschirminhalt zu puffern, eine regelmäßig auftretende Anforderung die schwer umzusetzen ist ist die Darstellung von Diagramen die von Text überlappt werden. Das geht mit den anderen verfügbaren Bibliotheken nur sehr schwer, man kann den Bildschirmspeicher nicht per I2C zurück lesen, das ist eine Einschränkung des SSD1306, und für einen Framebuffer fehlt das Ram. Ich würde also auf die Version auf Github verweisen, in der alles entfernt wurde was nicht wirklich sinnvoll nutzbar ist.
:
Bearbeitet durch User
"lieber" OMG, Header only Libraries sind durchaus verbreitet, und es macht in diesem Fall Sinn, durch diese Konstruktion optimiert GCC weit besser wie wenn man den Code in andere Dateien auslagert, der Effekt ist sehr real.
Ich kann die ganzen negativen Vibes hier auch nicht nachvollziehen, da wird auf dem Autor wegen der Musik (!!!) die er zu seinem Video gewählt hat rumgehackt und "mangelnde Innovation" beklagt. Hackt ihr auf jedem auch so rum der ein Board-Layout "zum review" hier irgendwo postet? Da ist auch "keine Innovation" vorhanden wenn zum 100sten mal ein Steuerungsboard designed oder "irgendwas mit LEDs" gemacht wurde. Es mag nicht besonders innovativ sein, aber sowas kann durchaus als Programmierübung gut sein und als Basis für eigene Projekte. Wenn es dann irgendjemand anderes danach wiederverwerten kann, weil er genau sowas sucht, ist es doch völlig i.O. All diese ach so "innovativen" Leute, die aus fertigen Codeschnipseln anderer Leute was zusammenbasteln sollten sich mal überlegen, wo sie denn ohne diese wären.
Görg P. schrieb: > in der alles > entfernt wurde was nicht wirklich sinnvoll nutzbar ist. Mit der Grafik.... Es war schon nur das os, was für mich von Interesse war/ist. Dem entsprechend kann ich mit deinem Rat: > Ich würde also auf die Version auf Github verweisen, Nicht ganz soviel anfangen. Ja, swap in den Flash, scheint mir auch nicht recht sinnvoll. Ja, es gibt Alternativen für kleine AVR z.B. ProtoThreads ö.ä. Aber dennoch hat das präemptive auch seinen Reiz
Das swappen ins Flash ist auch schwer zu debuggen, der AVR-Simulator scheint Bugs zu haben, ich hatte davor eine Routine die probiert hat Umschaltungen der Bits von 1 auf 0 zu minimieren, und die den Schreibbereich verschiebt wenn Speicherzellen ausfallen, auf dem Controller funktioniert sie wunderbar (zumindest hoffe ich es, Ausfälle konnte ich aber auf dem Controller noch nicht beobachten, das Flash scheint erstaunlich robust zu sein), auf dem Simulator wird nach jedem zweiten "flashen" Müll ins Flash geschrieben, sogar wenn man von Hand im Memory Viewer Daten ins Flash schreibt um den Ausfall durch Abnutzung zu simulieren.
ikannix schrieb: > Hm ? Ich tippe mal auf Zeno (der Anmaßende), Wolfgang (der > Museumsdirektor) , Abdul (der 8051 Versteher), ..... Du bist auch ganz schnell ganz alt mein Lieber! Einem Original 8051 Grafik beizubringen, die auch nur halbwegs so schnell ist, daß man nicht beim Zeichnen zusehen kann, ist echt ne Aufgabe. Noch dazu wenn der LCD-Controller ein T6963C ist. Und das es ein 8051 war, lag schlicht am Arbeitgeber. Zu der Zeit war ich Z80 und 68K Fan. Ein anderes Projekt für den 8051 wurde dann für den 80C166 neu übersetzt und lief sofort mit Faktor 8000 schneller. Da staunte ich auch. Über die Arbeit habe ich doch gar nicht gemeckert, sondern nur über die Darstellung dieser.
Wegen dem Betriebssystem, ich werde es getrennt nochmals veröffentlichen, sobald meine IR-Dioden und TSOP angekommen sind, ich habe leider nur einen TSOP und keine IR-Diode, deswegen kann ich den Netzwerkcode nur testen indem ich eine weisse Diode "voll draufscheinen" lasse, dann funktioniert es. Deswegen ist auch nur der Sendecode enthalten, der Empfängercode für die Netzpakete läuft akut noch auf einem Arduino. Ich will die IR-Netzwerkfunktion aber richtig implementieren, leider scheinen die Dioden sich in China im Lockdown zu befinden. Deswegen wird sich das verzögern und ich stelle erstmal die Grafikfunktionalität fertig.
Interessantes Projekt. Ich nehme an, du hast ein VRAM im SRAM angelegt und manipulierst dieses direkt und lädst das ganze dann neu auf das Display? Das habe ich früher auch so gemacht. Allerdings geht das leider nur genau mit diesem OLED, da es praktischerweiser einen Modus bietet, mit dem man mit nur einem Byte direkt 8 Pixel ändern kann. Sobald du aber auf Farbe gehst, hast du direkt 16 Bit pro Pixel und dann wird das a) richtig langsam ohne Assembler und b) kommst du mit dem SRAM der tinys und auch megas nicht mehr hin.
Schlachte doch ne alte TV-Fernbedienung.
Nein, ich arbeite komplett bzw fast komplett ohne Puffer im Ram, die einzigen vorhandenen Puffer sind folgende: Speicher für die Konsole(n) bei 16x8 wären das 128 Byte, wenn die Konsole/n abgeschaltet sind auch diese Puffer nicht vorhanden. ein optionaler 64 Byte Puffer für das Halftoning, ohne diesen Puffer ist die Qualität des Halftonings schlechter. die Displayroutine "synthetisiert" das komplette Bild on the Fly, sie weis wann sich jeweils die angezeigten Objekte (Sprites/Layer) ändern werden, zusätzlich ruft die Displayroutine einen Callback auf, mit dem man für jede X/Y Koordinate einen Helligkeitswert zurückgeben kann. Die Bibliothek arbeitet "intern" immer auf 6 Bit Helligkeitswerten. Diese Strategie reduziert den Speicherverbrauch auf das absolute Minimum.
:
Bearbeitet durch User
Na wenn du das ohne VRAM hinbekommst, dann solltest du direkt mal eine Farb-Demo veröffentlichen. Bin gespannt, wie das aussieht. Gibt auch gute TFTs für wenig Geld. Gib mal bei Ali ein "TFT 320x240". Mit dem ollen "SW und dann noch nichtmal Graustufen"-OLED wirst du nicht lange deinen Spass haben.
Wolfgang R. schrieb: > Und was machst du so, außer anderer Leute Arbeit zu diskreditieren? Er kannix, außer pöbeln. Ist wahrscheinlich einer dieser dynamischen Jungspunde, die alles besser wissen, aber nichts auf die Reihe bekommen wenn's ernst wird. Dabei vergessen die oft das mit dem "alten Kruscht" seinerzeit mal die Grundlagen für die Moderne geschaffen wurden. Insofern schön das es Leute gibt die so etwas für die Nachwelt erhalten.
Das hier ist doch wieder einmal Egoismus pur. Wenn "mich" das nicht interessiert, ist das für "nichts und niemanden" zu gebrauchen, sondern nur unsinnige Verschwendung "meiner" Zeit. Denn "ich" muss das ganze Zeug lesen und dann noch mehrere Kommentare mit Beleidigungen unter der Gürtellinie abgeben.
Zeno schrieb: > Ist wahrscheinlich einer dieser dynamischen Jungspunde Solche Sprüche kenne ich eigentlich nur von abgehalfterten, abgeloosten Röhren-Gruftis. Muss ich dich da dazu zählen?
Netzwerker schrieb: > Das hier ist doch wieder einmal Egoismus pur. Ganz ruhig, das waren nur wenige Einzelpersonen. Wir sind auch nicht alle Nazis nur weil im Kreml ein einzelner austickt.
Das Video ist übrigens bei Hackaday angekommen.
PittyJ schrieb: > Sorry, wenn ich Demos sehe, die 1985 schon auf einem C64 mit <1MHz > liefen, dann frage ich mich, wo der Fortschritt 37 Jahre später ist. > Ein ATTiny gibt es mit 20 MHz, also 20 mal mehr Power. Und der C64 hat > die Musik noch selber gemacht. [ ] Du hast Ahnung vom C64. Der hatte mit VID und SID zwei überaus clevere ASICs, die sich um SEHR Viel Arbeit beim Thema Video und Sound gekümmert haben. Ohne die wäre der C64 nciht mal ansatweise so leistungsfähig. Wo sie diese ASICs im AVR?
Könnte der Bresenham und Sprite-Kollisionserkennung in Hardware?
Abdul K. schrieb: > Könnte der Bresenham und Sprite-Kollisionserkennung in Hardware? Ob es der C64 konnte weiß ich nicht, der Amiga aber sicher. Ich vermute mal, daß der VIC keinen Bresenham konnte, ggf. aber Sprite-Kollision.
Ja, Sprite Kollisionen konnte der C64 in Hardware erkennen. Ich meine mich zu erinnern, dass er auch Kollisionen mit einer auswählbaren Farbe im Hintergrund-Bild erkennen konnte.
Stefan ⛄ F. schrieb: > Ja, Sprite Kollisionen konnte der C64 in Hardware erkennen. Ich meine > mich zu erinnern, dass er auch Kollisionen mit einer auswählbaren Farbe > im Hintergrund-Bild erkennen konnte. Absolut, das konnte bzw. kann er :-) Und der Hintergrund konnten wimre sowohl Zeichen als auch Pixel einer Bitmap sein. Alleine das in Hardware zu realisieren stelle ich mir schon relativ komplex vor (inklusive überlappende Sprites etc.) und in Software würde das auch einige Taktzyklen kosten. Und das bei jedem Bildrefresh.
:
Bearbeitet durch User
Es gibt ein Update... ich bin jetzt übrigens auf version 0.9 unterstütze zusätzlich alle AVR-Arduinos, gefüllte Vektorgrafik, Zeichnen von Kreisen, und Videocompression https://www.youtube.com/watch?v=pep0TOAl7SM sowie einen "Interleavemodus" für das I2C, ich mische die I2C-Ausgabe unter die Berechnungen, dadurch sind sie praktisch umsonst, weil eben nicht mehr gewartet werden muss auf den I2C. 3D Grafik ist 500% schneller, normale ca 30%. https://github.com/GoergPflug/AttinyStreamGfxApi Grüße :-)
es gibt eine weitere Iteration des ganzen, diesesmal mit der Unterstützung von hardwarebeschleunigtem 3D auf dem SSD1306 für AVR Arduino, allerdings noch etwas alpha, und eben unbekannt wie weit die Features wirklich von allen Displays unterstützt werden, es ist noch etwas Forschung nötig. https://www.youtube.com/watch?v=IJkiNY2OHoY Grüße :)
:
Bearbeitet durch User
Görg P. schrieb: > es gibt eine weitere Iteration des ganzen, diesesmal mit der > Unterstützung von hardwarebeschleunigtem 3D auf dem SSD1306 für AVR > Arduino, allerdings noch etwas alpha, und eben unbekannt wie weit die > Features wirklich von allen Displays unterstützt werden, es ist noch > etwas Forschung nötig. > > https://www.youtube.com/watch?v=IJkiNY2OHoY > > Grüße :) Wenn das immer noch auf einem AtMega läuft, bin ich offiziell beeindruckt!
:
Bearbeitet durch User
es ist ein Mega2560, aber es würde auch auf dem Attiny85 laufen vermutlich etwas schlechter, die Codegröße ist ziemlich klein für das 3d, aber die fehlenden Multiplikationen machen natürlich die Mathematik teurer.
:
Bearbeitet durch User
Ich hab mich vor ein paar Jahren auch mal an Animationen auf dem Display versucht, das dann aber nicht mehr weiter verfolgt. https://www.youtube.com/watch?v=RE9Cm6moHj4
Görg P. schrieb: > es gibt eine weitere Iteration des ganzen, diesesmal mit der > Unterstützung von hardwarebeschleunigtem 3D auf dem SSD1306 für AVR > Arduino, allerdings noch etwas alpha, Nette Spielerei, wenn man die Grafik nur um der Grafik Willen betreibt. Ich habe 2020 einen Aufbau mit einem A*Nano und SSD1306 gemacht, der per ADS1115 Spannungen messen soll und diese zyklisch auf eine SD-Karte schreibt. Werte und Status sollen am OLED angezeigt werden. Das war eine Bruchlandung, weil die OLED-Libraries (Adafruit oder u8g8) dermaßen viel RAM fressen, dass es für die Hauptaufgaben nicht mehr ausreicht. Ich habe später eine Lib gefunden, die nur Text kann und ansonsten eher dusselig ist, aber wenig Ressourcen braucht und das Gerät damit endlich zum Leben bekommen. Mein Standpunkt ist klar: Man braucht etwas, was sparsam mit dem Speicher umgeht! Grafikspielchen mögen nett sein, aber dafür ist Arduino nicht die passende Basis.
Manfred P. schrieb: > Mein Standpunkt ist klar: Man braucht etwas, was sparsam mit dem > Speicher umgeht! Grafikspielchen mögen nett sein, aber dafür ist Arduino > nicht die passende Basis. Das basiert zwar auf Arduino-Hardware aber sicher nicht auf Arduino-Software. Wenn man sowas machen will schreibt man das selber, und dann kann das sehr wohl sparsam wie auch performant zugleich sein. Diese ganzen Arduino-Librarys können zwar scheinbar alles, nur leider nix davon richtig....aber das ist ja nichts Neues.
Görg P. schrieb: > es gibt eine weitere Iteration des ganzen, diesesmal mit der > Unterstützung von hardwarebeschleunigtem 3D auf dem SSD1306 für AVR > Arduino, allerdings noch etwas alpha, und eben unbekannt wie weit die > Features wirklich von allen Displays unterstützt werden, es ist noch > etwas Forschung nötig. > > https://www.youtube.com/watch?v=IJkiNY2OHoY > > Grüße :) Top. Find ich geil und mir gefällt die Musikauswahl. Da kickt direkt die Demonostalgie rein!
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.