Hello, Guest the thread was called198k times and contains 1600 replays

last post from drazil at the

Heute so gecodet...

    Quote from Goodwell

    Bei so einem Gamejam wär ich echt gern mal dabei.
    Scheint als ob ich derart am Allerwertesten der Welt lebe, dass die alle am anderen Ende des Allerwertesten sind :-D

    Naja es gibt auch viele Online-GameJams, und es gibt z.B. auch den "Global GameJam", der findet dann an vielen Orten (z.B. Hochschulen usw) gleichzeitig statt.


    Oder man hockt sich wirklich mal ins Auto oder in den Zug und betrachtet das ganze einfach mal als einen Kurzurlaub. Unser GameJam ging ja z.B. 2 Tage, wir hatten auch schon welche mit 3 Tagen, also da lohnt es sich dann eigentlich auch mal, eine kleine Reise anzutreten. Eventuell traegt das noch zum Erlebnis bei, denn man sieht einfach mal was anderes, neue Leute, andere Umgebung, usw, das kann einen regelrecht befluegeln und inspirieren, auch die Tage und Wochen danach noch :)

    Quote from ZeHa

    wizball6502 hat uebrigens auch teilgenommen, vielleicht moechte er hier ja auch was ueber sein Projekt erzaehlen (welches uebrigens im Gegensatz zu unserem fuer den C64 ist :) )

    Wie ZeHa schon angedeutet hat, gab es bei diesem (von ZeHa toll organisiertem) GameJam mehrere Themen, weil alle gleich viel Stimmen bekommen haben. Die Themen waren "Enge", "Deep", "Time Shift" und "Retro". Da konnte man sich ein passendes Thema auswählen oder alle irgendwie unterbringen, wenn man wollte. Zu gewinnen gibt es da nichts, es geht rein um den Fun am Experimentieren und auch darum, am Schluss zu sehen, was die anderen Mitstreiter aus den Themen herausgeholt haben. Immer wieder spannend und überraschend.


    Leider konnte ich nicht direkt vor Ort (Bodensee) mit dabei sein, weil ich am Samstagmorgen noch etwas für die Arbeit erledigen musste. Aber man konnte auch Remote seine Werke einreichen, was mir erlaubte, auf diese Weise etwas beizutragen. Aber der Austausch über Discord ist halt nicht dasselbe wie von Angesicht zu Angesicht Ideen auszutauschen.


    Wegen der knappen Zeit war für mich von Anfang an klar, dass ich "nur" ein BASIC 10Liner machen wollte. Das Thema "Deep" hat mich gleich angesprochen und ich habe dabei den tiefen Ozean als Schauplatz gewählt. Zur Geschichte: Du bist ein Apnoe Taucher und gleitest langsam auf den tiefsten Punkt hinab, den du je erreicht hast. Mit dem Ziel, deinen persönlichen Rekord zu brechen. Am Punkt angekommen ist das Glücksgefühl unglaublich. Gleichzeitig spürst die die "Enge" in deinen Lungen und der Weg zurück ist lang. Es geht jetzt im Spiel darum, wieder aufzutauchen und die Luftblasen dabei hinter dir zu lassen. Im Spiel wird dabei dein Konzentrationsvermögen (=Lungenkapazität) auf die Probe gestellt. Die Grundidee zum Spiel habe ich von Super Hexagon bzw. Micro Hexagon, aber das in einen 10Liner zu packen war dann nochmals eine spannende Knacknuss.


    Hier ein Video des fertigen BASIC 10Liners (PUR-80). Das Spiel habe ich "Deep Blue Ascend" genannt:


    [External Media: https://youtu.be/bPHIAZcaN40]


    Und das ist der ganze Code:



    Mit dem Zehnzeiler hatte ich Samstags um 12:00 Uhr Mittags begonnen und war erst um 03:35 Uhr in der Nacht soweit zufrieden, dass ich ins Bett gehen konnte. Am nächsten Tag habe ich dann an der Präsentation gearbeitet, d.h. die itch.io Seite erstellt und das Spiel hinaufgeladen. Die Seite findet ihr hier: https://romwer.itch.io/deepl-blue-ascend-basic-10liner .


    ZeHa hat dann noch einen Bug gefunden, dessen Fix mich noch den ganzen Nachmittag gekostet hatte. Aber das gehört dazu.


    Hier auch noch das Spiel zum Selberprobieren:


    deepblueascend.prg


    ACHTUNG: Das Spiel braucht rund 1.5 Minuten Vorberechnungszeit, bis es spielbar ist. Ich habe das in der Vorgeschichte als "wichtige Entspannungs- und Fokus-Zeit eines Apnoe-Tauchers vor dem gefährlichen Tauchgang" schöngeredet, aber die Wartezeit ist schon etwas lange. Aber ich mach dann mal noch eine PUR-120 Version, die mir erlaubt, eine schnellere Logik für die Vorberechnung der Bubble-Animation anzuwenden.


    Die Geschwindigkeit der Animation habe ich unter BASIC V2 dadurch erreicht, indem ich 14 verschiedene Screen-RAM-Bereiche nutze und so nur den Screen-Pointer ändern muss, um den nächsten Frame anzuzeigen. Der Ausgang in der Bubble sind dunkelblaue Sprite-Blöcke, die ich jeweils an einer der vier Seiten platziere. Solange der weisse Sprite-Block eine Kollision mit den dunkelblauen Sprites auslöst, wird die Kollision mit den Chars ausgehebelt.


    Der Event hat viel Spass gemacht und ohne diesen Anstoss hätte es das Spiel vermutlich gar nie gegeben. Somit nochmals vielen Dank an dich ZeHa.

    Ohne das jetzt gespielt zu haben erinnert mich das an:

    [External Media: https://www.youtube.com/watch?v=SpLgOEsee2k]

    tulan


    Ja, der Style ist aehnlich minimalistisch, aber das hatte auch einen Grund - in einem GameJam ist die Zeit ja begrenzt, daher ist es immer eine gute Idee, sich nur auf die wesentlichen Dinge zu konzentrieren und die komplexeren Dinge so weit es geht runterzuschrauben. Da wir keinen separaten Grafiker im Team hatten, der sich ausschliesslich um die Grafik kuemmern konnte, musste ich das uebernehmen - daher waehle ich in solch einem Fall dann einen Look, der zwar auch auf seine Art und Weise irgendwie "cool" ist, aber auch sehr schnell zu produzieren ist. Denn theoretisch hat man spaeter immer noch die Moeglichkeit, alles nochmal zu ueberarbeiten (ist auch zum Teil geschehen - anfangs waren die Figuren z.B. nicht animiert, und die Baeume sahen "haesslicher" aus).


    Mir ist natuerlich klar, dass Du das nicht negativ meintest mit der Grafik, ich wollte das nur allgemein ein bisschen erklaeren :)


    Es gibt auch Leute, die malen dann z.B. gerne einfach nur Kaestchen und Bloecke. Das mache ich z.B. sehr ungern. Fuer mich soll der Baum schon nach Baum aussehen und das Maennchen auch nach einem Maennchen, daher versuche ich da schon erstmal was "hinzuklatschen" was grundsaetzlich das symbolisiert, was es sein soll. Aber eben so schnell und simpel wie moeglich. Man spart auch Zeit bei der Programmierung - haetten die Figuren z.B. eine komplexere Animation mit verschiedenen Richtungen usw, dann haette man das ja auch alles programmieren muessen. In diesem Falle ist die Animation der Maennchen immer haargenau gleich, da einfach zwischen 2 Frames gewechselt wird. Also profitiert von solch einer Vereinfachung nicht nur rein die Grafikerstellung sondern die Kette setzt sich fort.


    Vereinfachung bei GameJams gibts auch noch an anderen Stellen, z.B. versuche ich immer Ideen zu waehlen, die ohne riesige Levels auskommen. Denn auch sowas zu designen kostet natuerlich Zeit. Am besten ist es, eine Idee zu haben, die mit nur einem einzigen Level funktioniert. Denn weitere Levels kann man spaeter immer noch dazubauen, wenn man Lust hat, oder auch mal zwischendrin, wenn es sich anbietet. Auch bietet es sich an, etwas zu waehlen, bei dem es z.B. nicht mehrere Gegnertypen erfordert, denn die muesste man ja auch alle programmieren, usw.


    Alles in allem hilft einem ein solcher GameJam auch ein bisschen dabei, zu lernen, sich auf das wesentliche zu beschraenken und zielorientiert zu arbeiten, anstatt sich wie so oft ein viel zu grosses Projekt vorzunehmen, das man zwar fuer klein haelt, aber an dem Wochenende dann doch nur zur Haelfte schafft.

    Mittlerweile habe ich jetzt den ganzen Code meines Dockingmodules nochmal umgeschrieben (zumm vierten und hoffentlich letzten Mal). Da die ursprünglichen Funktionen ziemlich undurchsichtig und kompliziert waren hatte ich ja diverse Holfsfunktionen geschrieben die mir das Leben leichter machen sollen. Mit deren Hilfe habe ich es jetzt geschafft auch alle anderen Funktionen zu refactoren. Damit funktioniert jetzt alles so wie es soll, ein paar Bugs sind dadurch auch wie von Zauberhand verschwunden, die vorher schwer zu lösen waren.

    Der Vorteil ist jetzt dass alles sehr modular ist, so wie ich mir das eigentlich vorgestellt hatte. Theoretisch sollte es jetzt auch möglich sein, jeden Aspekt des Dockings durch eigenen Funktionen zu ersetzen wenn man das will. Ob das alles auch so funktioniert werde ich dann morgen sehen, wenn ich das in meiner testapp implementiere.

    Jedenfalls habe ich versucht den Code so zu schreiben, dass der User die Möglichkeit hat bestehende Teile zu ersetzen. Also wenn jemanden nicht gefällt wie ich das Dockingziel markiere, dann kann er auch eine schönere GUI schreiben indem er einfach den Teil ersetzt der für die visuelle Aufbereitung zuständig ist. Da ich eher Programmierer bin und kein Grafiker, ist es derzeit vielleicht nicht wirklich schön, aber es funktioniert. :D

    Wenn dann alles wirklich so funktioniert wie ich das geplant habe, dann kommen als nächstes die Toolbars dran. Das ist wahrscheinlich auch ein grösserer Brocken. Dann fehlen noch die Floating Windows (also dass man z.B. eine Toolbar rausziehen kann in ein eigenes Fenster) und die Persistierung. Ist zwar noch einiges zu tun, aber zumindest sehe ich jetzt Fortschritte. :D

    Quote from tilobyte

    wizball6502 Wusste gar nicht, das Basic so beeindruckend schnell sein kann.

    Ein bisschen Hokus Pokus und technisches Knoff-Hoff ist da ja schon mit dabei ^^. Wie oben beschrieben, berechne ich die Bubble-Animation zuerst vor. Ich habe die Erstellung der 15 Kreise mittlerweile mit einem anderen Ansatz (ohne sin/cos) von 90 auf 30 Sekunden reduzieren können. Dazu gibt es neu ein Ziel plus einen Erfolgscreen. Immer noch ein Zehnzeiler, aber PUR-120.

    Weiter an meinem Beitrag für https://itch.io/jam/retro-platform-jam-5 gearbeitet. Eine Woche ist noch übrig. Da ich wie immer agil plane (also völlig planlos) sieht es im Moment nach einem Miniatur-Project-Firestart mit ziemlich wenig Kampf und wenig Story und überhaupt ganz wenig Allem aus :)


    Es tut mal gut, einfach was Kleines zu basteln. Das hält den Kopf frisch!

    Eigentlich wollte ich mich erst darauf konzentrieren dass ich die Marker implementiere, die für den User anzeigen wo er andocken darf. Dabei habe ich darüber nachgedacht, wie ich es am Besten und Intuitivsten hinbekomme zu unterscheiden ob der User das Fenster in ein Floating umwandeln will oder ob er an ein anderes Fenster andocken will. Jetzt habe ich eine recht elegante Idee gehabt und als ich darüber nachdachte habe ich mir überlegt dass ich die floating Windows vielleicht gleich einbauen könnte. Mit den Hilfsfunktionen ging das recht einfach aber es gab plötzlich seltsame Fehler und Abstürze. Natürlich habe ich erstmal in dem neuen Code gesucht, konnte aber nichts finden. Nachdem ich dann die gute alte Detektivarbeit angegangen bin war der Fehler auch recht schnell gefunden.

    Ich hatte ganz am Anfang, als eine der erstn Massnahmen, vorsorglich zwei Fehler eingebaut. Den Teil hatte ich schon abgehakt, denn der funktionierte ja immer. Dachte ich. Bisher hatte ich ja aber auch nur ein Hauptfenster zum Testen. Durch den Einbau der floating Windows ist das aber nicht mehr der Fall, sondern es gibt jetzt beliebig viele Fenster und damit traten dann plötzlich diese Fehler auf.

    Mittlerweile ist das gefixed, und jetzt funktionieren auch die Floatings wunderbar. Gut es gibt noch einige Bugs die ich ausmerzen muss, aber nichts gravierendes. Das schöne ist aber dass ich durch diesen Schritt dem Endziel deutlich näher gekommen bin, denn ich dachte eigentlich dass die Floatings schwieriger werden.

    Damit fehlen dann nur noch zwei grosse Blöcke, nämlich Toolbars einbauen und die Persistenz, also Speichern und Laden von Layouts. Die Visualisierung muss natürlich auch noch erledigt werden, aber da habe ich zumindest schon ein Vorstellung wie das funktionieren soll.

    Im Winter habe ich eh meistens mehr Lust auf sowas, also hoffe ich ja, dass meine Motivation noch lange genug anhält um das Modul noch fertig zu bekommen. :D Dann könnte ich nämlich endlich anfangen das Modul in meine eigentliche Anwedung einzubauen.

    Ein basic preprozessor.

    Ja ich weiß, es gibt https://github.com/hbekel/bpp

    der ist aber echt unbrauchbar, da sind bugs drin und das Projekt ist tot.

    Ich finde den Ansatz auch garnicht mal so gut, es versucht so viel wie möglich der Sprache zu verstehen, ich gehe da einen anderen weg, ich versuche so wenig wie möglich zu verstehen und das alles nur als text zu betrachten.

    Ich hab ein paar features mehr und ein wenig weniger.

    bei mir gibt's kein scoping, das fühlt sich irgendwie falsch an.

    was ich habe:

    - keine zeilennummern

    - benannte sprungmarken

    - kommentare die nicht im prg landen

    - benannte konstanten

    - hexadezimal und binär notation

    - lange variablen namen

    - include, wahlweise mit dateiinhalt oder die ausgabe eines kommandos

    - leerzeichen wegoptimieren

    - tests

    siehe:

    https://github.com/schorsch3000/baspp

    Ich habe voreiniger Zeit mal versucht ein transparentes Overlay zu programmieren. In der Theorie einfach. Screenshot machen. Über alle Pixel iterieren und den Alphakanal aus dem zu überlagenden Bild einzurechnen, dann neu anzeigen.

    Das wollte ich für mein Dockingmodul nehmen um den User anzuzeigen wo er docken kann. Rot wenn das docken an dieser Stelle nicht geht und Grün wenn man da andocken kann.

    Das hat aber nicht richtig funktioniert, also habe ich dann zähneknirschend auf den Transparenzeffekt erstmal verzichtet und einfach eine undruchsichtige Bar verwendet. Gefällt mir nicht ganz so gut, aber es funktioniert.

    Jetzt hatte ich endlich die Idee wie ich anzeigen kann, wenn man ein Window als Floating erzeugen will, aber das wäre dann ein ziemlich grosses Rechteck, was SEHR hässlich wäre. Also habe ich nochmal versucht einen Transparenzeffekt hinzubekommen. Google hilft da ja ungemein. Die Formel wie man die Farbe berechnet war schnell gefunden und einfach zu implementieren. Und glücklicherweise habe ich auch Beispiele gefunden wie ich in wxWidgets einen Screenshot in eine Bitmap einlese, dann über die Pixel iterieren kann und da ganze dann sakliert um es anzuzeigen.

    Ein wunderbares Beispielprogramm gefunden für den Screenshot. Das hat einwandfrei funktioniert. Noch ein tolles Beispielprogramm gefunden wie man über die Pixel iteriert. Das hat ... nicht funktioniert, obwohl es so aussah. Und noch ein tolles Beispielprogramm gefunden wie man den Skalierungsfaktor berechnet und verwendet. Das hat genauso wenig funktioniert.

    Jetzt habe ich also den ganzen Abend dran rumgebastelt. Vor einer Stunde wollte ich schon frustriert Schluss machen, aber es hat mir keine Ruhe gelassen und ich habe mir den Code nochmal genau angesehen. Nach etwas überlegen und ein wenig probieren hat es dann doch noch geklappt. Beide Beispiele funktonieren überhaupt nicht, so wie es da gezeigt wurde aber da muss man erstmal drauf kommen. Erinnert mich an meine Amigazeit mit den Addison Wesley ROM Kernel Manuals. Da waren auch jede Menge Schnipsel drin, die etwas zeigen sollten aber die meisten haben einfach nicht funktioniert so wie sie abgedruckt waren.


    Auf jeden Fall habe ich jetzt endlich eine Funktion mit der ich zwei Bitmaps transparent übereinanderlegen kann. :thumbsup: Und jetzt kann ich auch in Ruhe schlafen gehen. :D

    Und Morgen werde ich das dann auch für die anderen Anzeigen einbauen, so wie ich mir das eigentlich ursprünglich vorgestellt hatte. :D

    Habe die Tage noch etwas an meinem Special-Interest-Projekt "KanjiCard" rumkorrigiert und -optimiert, den Kram auf Bitbucket hochgeladen und eine Homepage gebastelt.


    Bin jetzt bei 126 Kanji. Also nur muß ich nur noch 2010 Kanji eingeben, bis ich die 2136 Jōyō Kanji in der Datenbank habe (*Hust*).

    Bei meiner jetzigen Geschwindigkeit wird das noch über drei Jahre dauern ;(

    Keine Ahnung, ob ich das durchhalte. Vermutlich eher nicht. Aber der Weg ist das Ziel oder so.

    Bin gerade ziemlich frustriert oder auch sauer. Ich habe ja mein Dockingmodul in Entwicklung und bin mittlerweile recht gut vorangekommen. Die letzte Woche hatte ich darauf verwendet aus dem aktuellen Stand alle mir bekannten Bugs zu entfernen. Das ist mittlerweile auch abgeschlossen und ich wollte zum nächsten Schritt übergehen. Bevor ich das mache wäre jetzt ein guter Zeitpunkt um den wxWidgets Master wieder mal auf den aktuellen Stand zu bringen, damit ich nicht zu sehr hinterher hinke und das letzte Mal ist schon ein paar Monate her. Also habe ich meinen Code rebased und die Hauptlibrary auf den neusten Stand gebracht, getestet und ... es funktioniert nicht mehr richtig. Auf Nachfrage in der Entwicklerliste bekam ich dann den Hinweis dass seit etwa zwei Wochen in wxWidgets für alle Komponenten Doublebuffering aktiviert ist. Das bedeutet scheinbar dass ich "von aussen" nicht mehr einfach in ein Fenster reinzeichnen kann. Genau das brauche ich aber um die Markierung zu zeichnen wo der User andocken will. Jetzt kann ich wieder Zeit reinstecken um eine Lösung zu finden wie ich das umgehen kann und das bremst mich wieder aus. :(

    Wenn das nicht klappt ist das praktisch der Todestoss. :emojiSmiley-35:Dann hätte ich nur die Wahl einen eigenen Fork zu behalten der nicht mehr aktualisiert werden kann weil er auf den Stand vor der Änderung eingefroren ist, was IMO ziemlich witzlos wäre.

    Ich habe ja einen Fork. Aber ich möchte die Unterschiede so minimal wie möglich halten, weil das erheblicher Aufwand ist. Mein Modul ist ziemlich unabhängig, das sollte also im Idealfall so funktionieren dass man das Original wxWidgets nimmt und dann mein Modul dazu packt, ohne viel Aufwand. Noch besser wäre es natürlich wenn ich das Modul in den offiziellen Tree rein bekome, aber da bin ich eher skeptisch. Wenn ich einen Fork habe, muss ich ja ständig dem Haupttree hinterher laufen. Und es wäre schon schön wenn ich nicht der Einzige bleibe der das Modul vielleicht nutzt, da senkt ein Fork durchaus die Akzeptanz.

    Ja, das mit Fenster drüberlegen um renzuzeichnen hatte ich auch schon mal, aber das macht andere Probleme die nicht so einfach zu lösen sind. Ich werde mal versuchen direkt auf den Desktop zu zeichnen. Das hatte ich vorher schon so, aber auch das hat wieder Probleme gemacht, weswegen es so wie ich es jetzt implementiert hatte wunderbar funktioniert hat.

    Ich hatte vor ca. einem halben Jahr einen Patch für wxWidgets eingereicht den ich brauche um mein Dockingmodul zu unterstützen. Dieser Patch ist nicht spezielle für mein Modul, sondern eine allgemeine Verbesserung die auch von anderen sinnvoll genutzt werden kann. Damals fand ich den Prozess sehr mühsam bis der Patch endlich akzeptiert und aufgenommen wurde (immerhin wurde er aufgenommen :) ). Obwohl ich durchaus verstehe dass die Maintainer nicht jeden Patch einfach so aufnehmen können.

    Es gibt auch noch einen zweiten Patch in einem anderen Bereich, den ich ebenfalls noch brauche, aber damals hatte ich keine Lust dafür wieder mehrere Wochen zu verplempern um das rein zu bekommen, also habe ich mich darauf konzentriert erstmal mein Modul weiter zu machen. Mittlerweile habe ich so ziemlich alle Fehler beseitigt die ich so gefunden habe. Bevor ich jetzt weitermachen wollte, habe ich dann beschlossen endlich den zweiten Patch hinter mich zu bringen. Diesemal war es aber um einiges einfacher, weil die Maintainer meinen Patch als nützlich angesehen haben und angemerket haben dass man den dafürverwenden kann um einen Workaround zu schreiben für ein Problem dass in einer Microsoft Library exisitert (was ich dann auch gemacht habe). :D Jedenfalls wurde der Patch heute in den Master gemerged und damit kann ich mein Dockingmodul unabhängig vom Master halten, ohne dass ich dafür einen Fork machen muss. Wenn mein Modul irgendwann aufgenommen werden sollte (was ich hoffe), dann brauche nichtmal das. Aber zumindest kann ich trotzdem auf der offiziellen Version aufbauen wenn das halt nicht passieren sollte.