Posts by hein09

    Dann schlaf doch mal ne nacht drüber, ohne entspannung geht beim programmieren halt nichts :)


    Dinge die mir auffallen:


    - du überprüfst dein String-argument `md` mit zwei separaten if-statements, statt if + else-if + else-mit-fehler
    - du solltest wirklich deine vektor zugriffe mit .at() statt [] machen (und vor allem einheitlich, nicht beides mischen!), exceptions zur programmierzeit tun nicht weh :)
    - mach deine Pixel-klasse von rgb zuweisbar (oder anderweitig kompatible, siehe erster thread) und spar dir da Zeilen


    und dann zu guter Letzt:
    was ist das erwartete verhalten für alle möglichen h/w kombinationen?
    Im Moment gibst du false nur zurück wenn das Bild exakt so groß ist wie gewünscht, ich nehme an um zu signalisieren dass das bild direkt verwendet werden kann.
    Ist aber mindestens eine der dimensionen größer als deine Zielgröße, dann wird zwar c64img nicht gefüllt, aber true zurückgegeben.
    Willst du das so? (Bitte wertungsfrei lesen, kenn ja den Rest nicht :) )


    Aaaaaber ich würde da deine ganzen ifs trotzdem ein bisschen umschachteln:
    - Abbruchkriterium nach oben ziehen, bevor du irgendwelche Variablen verwurstelst, einfach um den Code seinen Zweck besser erzählen zu lassen
    - Damit kannste deinen verarbeitungscode direkt mit deinem leftcols = x; rightcols = y;-Teil zusammenlegen
    - und daaaann nochmal überlegen was passieren soll wenn h>fullh bzw. w>fullw

    die Größe eines C 64-BIldes im Multicolor-Modus (ohne GEOS) steht ja ohnehin von vornherein fest, also kann ich auch einfach rgb c64image[32000]; schreiben... die Pixelpositionen würde man mit Integer- und Modulo-Divisionen ermitteln. Lediglich beim Array mit den im jeweils aktuellen 4 x 8-Bereich gefundenen Farben müsste ich einen Vektor (oder dynamische Speicherverwaltung im C-Stil) verwenden...

    wie wärs denn mit


    Code
    1. std::array<std::array<rgb, 160>, 200> image;

    damit kannste dir dein index-rumgerechne sparen, das hat auch keinerlei laufzeit-overhead.
    Um die aktuellen Farben zu sammeln würde ich dir dagegen fast mal ein std::set<rgb> vorschlagen.
    Da kannste einfach alle Pixel (oder rgb werte) reinstecken, das kümmert sich selbst drum doppelte Werte auszusortieren.
    Generell frag ich mich wozu du Pixel und RGB unterscheidest? Sehe da aus deinem header keine Notwendigkeit für.
    Den Zugriff auf die Werte musste nicht maskieren, dadurch dass du private-member hast wird die klasse nur viel komplizierter und du musst dich um konstruktoren etc. kümmern.
    Bei deinem RGB kümmert sich der Compiler drum.
    Bau dir da noch einen bool operator==(const rgb& l, const rgb& r); dazu, und schieb die member-funktionen deines pixels da rein und du sparst dir viel kopfzerbrechen :)

    Sodala, habs mir gerade mal angekuckt.
    Wenn man den resize(8) in main wieder reinkommentiert läuft das bei mir :)
    Hast du vllt noch eben ein entsprechendes Bild?


    Genereller Tip:
    Nimm für den Anfang durchweg .at() um auf STL-container zuzugreifen.
    Das wirft im Gegensatz zu operator[] immer ne Exception, egal welchen container du nimmst,
    wenn der Algorithmus noch nicht klar ist hilft das ungemein :)

    [...] besser überwiegend in C schreibe [...]

    Aber doch nicht der Vektoren wegen ;)
    Würde zwar zustimmen, dass die da zumindest für dein Targetimage überflüssig sind, aber dazu gibts ja mittlerweile das std::array,
    das sich genauso verhält wie die klassischen C-arrays (die dir in C++ ja auch zur verfügung stehen), nur halt noch kompatibilität mit der ganzen STL obendrauf legen.
    Statt

    C
    1. std::vector<std::vector<pixel>> c64_4x8area;
    2. c64_4x8area.resize(8);
    3. for(auto& vec: c64_4x8area){
    4. vec.resize(4);
    5. }


    dann z.b. einfach

    C
    1. std::array<std::array<pixel, 8>, 4> c64_4x8area;


    Leider grad selber in Windows, drum krieg ich deine Päckchen nicht geöffnet (daraus schließe ich mal dass du zumindest nen vernünftigen Compiler benutzt ;) ).
    Aber mal noch generelle Tips zu dem was du direkt in den Thread gepackt hast:


    Irgendjemand schrob ja schon dass das nach uninitialisierten Variablen riecht.
    Du machst recht viel Zeug manuell, z.b.:


    Code
    1. pixel p;
    2. rgb c;
    3. vector<vector<pixel>> vec;
    4. p.set_blue(vec[i].at(j).get_blue();
    5. c.blue = p.get_blue()
    6. if(c.red == areacols[m].red){}

    Hat dein pixel keinen assignment-operator? wenn der keine pointer oder references als member hat sollte der dir sogar automatisch generiert werden.
    Genauso könntest du einfach eine funktion rgb pixel::to_rgb() einführen, bzw bool rgb::operator==(const rgb&),
    einfach um die vielen manuellen dinge die sich wiederholen zu reduzieren. Weniger Code, weniger Fehler :)


    Wozu denn eigentlich die doppelten casts?
    width = (unsigned short)(unsigned char)ch;
    Da würde doch
    width = static_cast<unsigned short>(ch);
    reichen, oder?


    Was Python betrifft, ist natürlich eine supergeile Sprache und ne ernsthafte Alternative,
    aber wenn du versuchst, mehr idiomatisches C++ zu schreiben ist C++ näher an Python als C ;)
    Alles neuschreiben ist vielleicht auch nicht das beste.
    So schlecht schauts ja alles gar nicht aus, werd unter Linux später mal nachsehen was deine Schleifen eigtl. so alles treiben.

    Ah ok, wusste nicht dass der OSS-support in den libs noch so aktiv ist. Kenns halt nur von der Linux-Seite wo das ja seit 10? Jahren geächtet wird, weil halt^^


    Bin da vom Prinzip ganz bei dir, nur seh ichs net ganz so streng.
    Stabile Interfaces pflegen schön und gut, wenns jemanden gibt der das will und kann.
    Am Ende interessierts den Nutzer aber mehr obs läuft, und das tut Linux halt (zumindest seit ich weg bin von Müll wie Ubuntu und Suse).


    Drum wär ich eigtl. mehr an Praxisberichten interessiert ;) Auf dem Papier liest sich pulseaudio ja auch nice :P
    Funktioniert die ganze Kiste für dich, oder hakts in der Praxis dran dass OSS stiefmütterlich behandelt wird?


    Das mit Lumina versteh ich nicht ganz, was macht das denn so grundlegend anders? Klar, gnome ist urschmarrn, aber bei KDE und XFCE, oder auch LXQT hätte ich jetzt erwartet dass sie sich nicht scheren was da X11 bereitstellt? Eventuell halt abzüglich einiger Komfortfunktionen die sich nicht so schön abstrahieren lassen. Werd aus der Präsentation auch nicht schlauer als der Homepage.

    Um mal dieses ganze hohle Hickhack hier aggressiv zu ignorieren:


    Du (OP) freust dich so, dass FreeBSD immer noch auf OSS setzt. Kann mich noch erinnern dass das damals™, als man unter Linux noch die Wahl hatte auch bei mir nen besseren Eindruck hinterlassen hat.
    Aaaaaaaber: wie siehts denn gerade mit den bösen out-of-tree Anwendungen aus, also halt doch dem Gros an Anwendungen, wird da OSS noch vernünftig unterstützt?
    Einem VLC o.Ä. würd ich unterstellen dass es egal ist, aber selbst bei KDE5 und Gnome3 hätt ich jetzt spontan nicht damit gerechnet. Und wenns dann an Steam geht schon gar nicht.
    Gibts da Kompatibilitätsschichten, wird da was reingepatcht, oder hab ich das falsch in Erinnerung und die Anwendung muss sich gar nicht drum kümmern?


    Und so sehr ich Pulseaudio vom Ansatz her verabscheue, seit das stabil läuft ist Linux-sound deutlich komfortabler noch als unter Windows.
    Kann OSS da auch diesen ganzen Komfortschnickschnack mit frei verschieb-/knüpfbaren Streams und Inputs und Outputs?

    Ist ja auch logisch. warum sollte man einen Windows-Rechner hernehmen um Software für Linux zu entwickeln.Genauso wenig wie andersrum.

    Andersrum ist super :P
    Die plattformübergreifenden Toolkits die die Linux/Unix-welt hervorgebracht hat sind ein Segen.
    FF, Chrome, VLC, alles dank Qt/GTK/SDL/OGL/Schießmichtot, und wenn man sowas vernünftiges hernimmt ists prinzipiell Wurst auf welcher Plattform der Entwickler arbeitet. Genau so wies sein sollte :)

    Wenigstens hat man (fast) immer ein GUI. Besser als Kommandozeilen-Tools, wo auch jedes seine eigenen Parameter hat und seitenlange Man-Pages, in denen leicht verständliche Beispiele anscheinend verboten sind.

    Redest du jetzt von Windows oder Linux? :P
    Für Desktopkrimskrams braucht man schon lange keine Shell mehr, und was darüber hinaus geht find bei MS deutlich umständlicher und mieser dokumentiert, Interface hin oder her...(wobei die Powershell mir da ja spontan recht gibt ;) )


    Aber als Produktivrechner, der einfach nur ohne viel Aufwand und geringen Ärger die täglichen Dinge erledigen soll...

    Genau das! Jahrelange Zuverlässigkeit! Einmal update anschubsen, wann man lustig drauf ist (!!), und die Kiste ist komplett aktuell.
    Lustigerweise sind gerade die Treiber unter Linux für mich zuverlässiger.
    Netzwerk? Besser. Soundkarte? Welten besser. Grafikkarte? Gleich, aber weniger Müll als unter Windows. Und selbst mein Lenkrad hat ootb funktioniert <3


    Was deine Software betrifft:
    Man kann natürlich nicht erwarten, 1:1 dieselbe Software nutzen zu können, je nachdem wie sehr mans in MS ökosystem investiert hat :)
    Ist halt die Frage was man will. Willst du wirklich Visual Studio benutzen? Dann bleibts wohl bei Windows. Willst du nur ne gute IDE? Probier n paar FOSS-Varianten aus, läuft ja auch alles auf Windows.
    Wenn du irgendwann alles auf FOSS umgestellt hast (was absolut kein Problem ist), ist auch der Umstieg kein Problem mehr. Wenn man wirklich umsteigen will, findet man entweder gute bis bessere Alternativen oder Wege die alte Software zum Laufen zu kriegen (WINE ist deutlich besser als sein Ruf). Oder man gesteht sich ein, bei Windows zu bleiben :D

    »Ich will eine Installation von dir!«

    8o:whistling:


    Bei mir sinds seit 8 Jahren fast ausschließlich Linux. Dank Rolling Release sogar in der ganzen Zeit eine einzige Installation gefahren die immer noch sauberer ist als die 3. Windowsinstallation in der Zeit...
    Leider fehlen noch zu viele Spiele (und bei manchen dann auf meiner antiken Kiste die paar Prozent Performance die es unter Windows noch geraaaaade so "flüssig" sein lassen :/ ),
    aber das reicht auch nur um mich alle 2 Monate mal für ein Paar Tage umbooten zu lassen.


    Diese Unproduktivität von Windows passt auf keine Kuhhaut. Mein Beileid an alle, die gerade zum Programmieren Windows brauchen :D


    Das dachte ich auch immer, hat bei meiner Familie damals nur dazu geführt dass niemand mehr den Rechner überhaupt angefasst hat...
    auch ein Erfolg in Sachen Wartung-reduzieren, aber nicht ganz so wie gedacht :D


    Problematischer als Unwissen ist glaub ich das stetige Gefühl sich dem Rechner unterwerfen zu müssen.
    Gerade das ist ja immer der, auch von Fanatikern wie mir ;) beworbene, Punkt überhaupt umzusteigen,
    aber in der Praxis will man doch ganz pragmatisch dass die Software die man sich wünscht läuft, nicht mehr und nicht weniger.


    Die klassischen Distributionen mit ihrer Vielzahl an Repositories die dann doch nicht alles, und vorallem nichts aktuell bereitstellen verkackt immer das "weniger",
    und vergrault damit die nicht ganz so harten Hartnerds, während die ganzen "mehr" Komfortdienste der letzten Jahre am anderen Ende des Spektrums für Unmut sorgt.
    Dann wiederum sind mir kleinere Communities auch wieder lieber als große, scheiß auf das Jahr des Linuxdesktops :bgdev

    Sowas in der Art gibt's in der BSD-Welt auch mit TrueOs -- das basiert immer auf dem -CURRENT Branch von FreeBSD, verspricht trotzdem Stabilität und kommt vorkonfiguriert als Desktop-System. Ausprobiert hab ich das allerdings nicht, ich bevorzuge persönlich eben die "stable" Welt :)

    Die scheinen zwar auch nen stable release zu haben, aber der rolling release schaut doch deutlich aktueller aus als ich dachte...
    Vielleicht doch nochmal ne Chance geben :)


    Los, motiviert mich meine letzte Freizeit verschwenden ;)

    Der Titel hat mich ja schon bisschen erschreckt...


    aber immer schön wenn jemand den BSDs Aufmerksamkeit schenkt!
    Freu mich auf Erfahrungsberichte aus der weiteren Praxis :)


    Persönlich hab ich leider nicht die Geduld, mich mit diesem "stable" Ansatz der meisten Linuxens rumzuschlagen (brauch nen aktuellen C++ compiler...),
    drum ist die Motivation für BSD seit Jahren leider auch sehr gering.
    Wobei zuhause meist nur noch gezockt wird, falls ihr da was berichten könnt... :D

    ¡Hola!


    hans: ja, beim Start rödelt sie kurz, aber danach reagiert sie auf nichts mehr. Hilft dir das irgendwie weiter?


    Hab gerade gecheckt, und ich hab alle drei Dioden.
    Auch mal versucht zu messen, aber iwi keine Ahnung was ich da grad treib :D
    Sicherheitshalber lieber wieder zu gemacht...nehme gerne idiotensichere Hinweise entgegen ;)


    Werd dann die Tage mal Ersatzdioden beschaffen, den Bus ohne zu Testen behagt mir grad auch nicht sehr,
    wenns an denen liegt scheinen sie ja ihren Schutzzweck erfüllt zu haben :D


    Immer noch vielen Dank an alle!

    Hoppla, so viel Enthusiasmus :)


    Vielen Dank an alle, v.a. Gerrit.
    Werd am Feierabend mal sehen ob ich Dioden finde und ob die funktionieren :D


    Andere serielle Geräte hab ich leider nicht...

    Nachdem ich mich gerade endlich wieder daran versuche, den C16 von den Toten zu erwecken, mach ich das gleiche mal mit diesem Thema hier :)


    Habe mittlerweile CPU (unnötigerweise), TED (nötigerweise, Zeichensalat ade) und 7406 (unnötigerweise) getauscht, leider immer noch keine Kommunikation über seriell :(
    Welche Dioden müsste ich denn überprüfen/ersetzen, um endlich mal ein paar Daten auf die Kiste zu bekommen?

    Hoppla, da ist der Schwung vom letzten Mal anscheinend schon wieder verschwungen...
    Dann tu ich trotzdem mal mein anhaltendes Interesse kund :) besser spät als nie :D


    Flocke scheint hier ja wohl nur noch sporadisch reinzuschauen, will vielleicht schonmal jemand der's kann so ne tolle Umfrage machen? (damit wir Flocke wenigstens Zahlen entgegenschleudern können...)
    Aber vielleicht findet sich ja auch jemand der den Raum klar machen könnte?
    Ich würd mich ja wirklich gern mehr einbringen, aber dann wird das frühestens im Mai was :whistling:
    Bis dahin werde ich alle Initiativen großzügig mit meinem Wohlwollen unterstützen :D