Posts by ZeHa

sieht nett aus und ich finde auch die Musik ganz cool

Retrofan Das war ein Witz, aufgrund der passenden Vorlage. Mir ist es eigentlich ziemlich wurscht wer welches Handy hat, selbst wenn es von Apple ist.

Quote from oobdoo

Weil vielleicht die Frage aufkommt warum es ein Apple geworden ist.

Es stellt für mich den besten Kompromiss dar.

Ja, Apple ist immer ein Kompromiss...

CSDb ist auch nicht ausschlaggebend, da das die Scene Database ist, eher wuerde man es bei Gamebase64 finden. Da ist es aber auch nicht, und da kommt der Verdacht auf, dass das vielleicht ein Spiel ist, das zwar im Prospekt angekuendigt wurde, aber letztendlich nie released wurde.

Und ein Googlen nach c64 "catch 23" bringt auch schon folgendes zutage:

https://www.gamesthatwerent.com/gtw64/catch-23/

Dort steht, dass es immerhin eine Amstrad CPC und Spectrum-Version gibt.

Ich finde Handy-Groessen sind relativ. Klar wollte man frueher unbedingt ein moeglichst kleines, aber inzwischen haben die Zeiten sich geaendert und man moechte viel Bildschirm. Mein erstes Smartphone war auch superkompakt, aber ich habe dann auch parallel irgendwann ein Tablet benutzt. Als ich dann ein groesseres Smartphone hatte, lag mein Tablet in der Ecke. Zudem wird das Verhaeltnis von Bildschirm und Gehaeuse ja auch immer kleiner, sodass ein grosser Bildschirm nicht zwingend auch ein grosses Geraet bedeuten muss. Und in meine Hosentasche wuerde ich auch 2 oder 3 solche Handys reinkriegen, wenn es drauf ankaeme. Also daher - alles relativ und oftmals viel zu sehr von Gewohnheit gepraegt.

Ich werde einfach mal das Huawei P30 in den Raum. Das habe ich seit paar Monaten, ist nicht mehr ganz das neueste Modell, aber es macht echt tolle Fotos (sofern das einem wichtig ist - mir schon) und auch ansonsten kann ich mich bisher nicht beklagen. Einen Klinkenanschluss gibts zum Glueck auch noch (Achtung, es gibt auch ein P30 Lite und P30 Pro, da ist es evtl anders). Zudem wird es noch mit Google-Diensten ausgeliefert. Und man duerfte es inzwischen fuer unter 400 EUR bekommen.

Quote from BlondMammuth

Quote from 0xdeadbeef

Ich weiß zu wenig über den Atari um sagen zu können, wozu er der Blitter genau gebraucht hat. Aber zunächst mal ist der Blitter ja auch nichts anderes als ein spezialisierter DMA. Er kopiert Bitmuster von A nach B, hat aber halt noch die Möglichkeit, dabei ein zusätzliches Bitmuster reinzurechnen. Das kann man zum Maskieren von Grafikobjekten benutzen oder halt für anderen Schnickschnack. Der Atari hatte wohl irgendwelches "Halftone-RAM", das mit dem Blitter genutzt werden konnte. Oder so.

So oder so ist ein Blitter architekturell (!) jetzt auch nichts völlig anderes als mein spezialisierter DMA. Also Bandbreite sparen wird man damit zum Beispiel auch nicht.

Und wenn man wirklich nur einen Bildschirmspeicher hat (was ja durchaus ein diskutabler Ansatz ist und wie erwähnt auch mein erster Vorschlag hier im Thread war), dann hat es sich halt mit Hardware-Scrolling. Bzw. man müßte beim Bewegen von Objekten nicht nur die Pixel an der alten Position mit dem Transparenzindex überschreiben wie in meinem Vorschlag, sondern die Pixel der Hintergrundbitmap restaurieren. Und das gleiche natürlich per se auch bei jedem Hintergrundscrolling oder Tile- bzw. Zeichensatzanimationen - was bei einer unabhängigen Bildschirmebene halt nicht nötig wäre.

Auch wenn man meinen Grafik-DMA-Vorschlag ablehnt: ein unabhängiger Bildschirmspeicher für bewegte oder (bezüglich des Scrolling) statische Objekte wäre an sich schon eine riesige Erleichterung, weil man sich dann nämlich nicht mehr um das Restaurieren des Hintergrundes kümmern muß, wenn man Objekte verschiebt. Das ganze restliche Konzept sollte nur zeigen, wie man mit dieser Grundidee einen DMA-Zugriff aufbohren könnte, um sowas ähnliches wie HW-Sprites zu bekommen.

Display More

Eine Laien-Frage dazu: Ein Sprite ist ein beweglicher winziger "Bildschirm", der über einen anderen gelegt wird, und dabei bitweise verschoben werden kann. Ein so beschriebener Layer ist ein riesiges (bildschirmgroßes) Sprite, das man in vielen Fällen nicht bewegen kann. Warum nicht die Konzepte verheiraten und grundsätzlich in verschiedenen Größen Bildschirmbereiche definieren, die man übereinander legen und bitweise positionieren kann?

Display More

Sowas gibt es soweit ich weiss beim Gameboy, dort gibt es sog. "Windows", die man uebereinander schieben kann, vor allem um z.B. ein Pausen- oder "Kontext"-Menue reinzuschieben oder die Punkteanzeige darzustellen. Ist an sich keine schlechte Idee sowas zu haben, vielleicht sogar nicht ausschliesslich fuer Spiele sondern auch fuer alle moeglichen anderen Anwendungen. Aber ob das ein sinnvoller Ersatz fuer Sprites waere? Keine Ahnung, muesste man sich Gedanken machen...

Quote from DJ SID

Ach wenn ich ein Coder wäre..... Würde stumpf eine Turbokarte mit REU vorausetzten. Und mir wäre es egal, ob andere mich dafür verurteilen würden. Da muß man sich ein dickes Fell wachsen lassen.

Naja das kann man so und so sehen...

Wenn Du ein Coder bist, dann willst Du vielleicht dass Dein Zeug auch viele benutzen und nicht nur diejenigen, die ein "hochgezuechtetes" System haben. 18 Millionen potentielle C64 vs. eine handvoll... (gut ich uebertreibe hier jetzt absichtlich etwas )

Oder aber Du moechtest halt aus einem gewissen sportlichen Ehrgeiz heraus Dich in die Standard-Specs pressen... man denke nur mal an das Spiel Sam's Journey, welches auf einem handelsueblichen C64 laeuft. Wer weiss, ob die Resonanz genauso gross gewesen waere, wenn man dafuer eine SuperCPU oder eine REU gebraucht haette... ich sage mal nein

Deshalb ist das eigentlich cool, dass man den Turbo-Modus einstellen kann von der Geschwindigkeit her. Das geht ja mit der SuperCPU auch nicht oder?

Ich halte den Turbo-Modus tatsaechlich fuer sinnvoller als eine SuperCPU-Emulation. Grund: Fuer die SuperCPU gibt es nur eine handvoll Applikationen und nur 1 Spiel. Von einem Turbo-Modus profitieren aber eine Menge Spiele, die eigentlich fuer den normalen C64 gemacht wurden (z.B. so 3D-Spiele wie Test Drive, Driller, usw, aber jetzt auch neue Beispiele wie die Super Mario Bros-Portierung).

Konnte man besagte Spiele damals mit der SuperCPU beschleunigen? Oder haetten diese dafuer speziell angepasst werden muessen? Da kenne ich mich nicht aus.

Im Prinzip kann es maximal eine Verzoegerung von 1 Frame geben - naemlich wenn der Joystick direkt zu Beginn des Bildaufbaus gedrueckt wird und das Programm/Spiel den Joystick erst nach dem Bildaufbau auswertet und dann ins naechste Bild einfliessen laesst. Das ist aber keine Verzoegerung in dem Sinne, sondern das ist ganz normale Programmlogik wie sie bei jedem Spiel vorkommt. Der Bildaufbau geschieht beim echten C64 ja synchron zum Rasterstrahl, also wird das Signal ja live rausgegeben waehrend es erzeugt wird und sofort vom Rasterstrahl auf den Bildschirm geschrieben. Es gibt also faktisch keine "Verzoegerung" wenn man einen echten C64 an einem Roehrenmonitor betreibt.

Alles was nun in irgendeiner Weise moderner ist, also mit Framebuffern oder Input-Buffern, Encoding und Decoding, Upscaling und weiss der Geier, kann nur langsamer sein.

Das U64 hingegen ist wieder wie ein echter C64, da das Signal genauso "live" erzeugt und rausgeschrieben wird. Zumindest wenn man es am analogen Ausgang abgreift. Am HDMI-Ausgang habe ich aber keine Verzoegerung feststellen koennen, als ich mein U64 mal parallel an einem 1084S und an meinem Beamer betrieben habe. Sah exakt gleich aus. Allerdings kann es sein, dass mein Beamer das Signal schneller frisst als jetzt ein moderner TV mit Pipapo. Oder es war tatsaechlich 1 Frame Unterschied und den habe ich dann wohl nicht bemerkt. Aber wie ein PAL-Signal technisch ueber HDMI uebertragen wird und ob dabei irgendwas gebuffert wird (ausser vielleicht dass das Bild in einem Rutsch uebertragen wird anstatt zeilenweise aufgebaut), weiss ich nicht.

C64 mit Röhrenmonitor hat 0 ms Verzögerung

Hehe eigentlich soll es gerade durch seine Einfachheit überzeugen aber ich verstehe dass die Kinder das vielleicht noch nicht verstehen

RexRetro "Hardwarebeschleunigung" in dem Sinne, dass man nicht das gesamte Bild in Software aufbauen muss, also in Form einer Bitmap, wozu nämlich die CPU alles erledigen muss (in Form von Software). Deshalb Hardwarebeschleunigung, weil ein Stück Hardware diese Aufgabe übernimmt und dabei die CPU entlastet. Ich denke da sollte es keine Probleme geben mit den Begrifflichkeiten.

Sprites, Tiles und HW-Scrolling sind schlicht und einfach Hardwarebeschleunigung. So wie auch heute die Grafikkarte den Bildaufbau uebernimmt, damit die CPU nicht so viel zu tun hat. Klar, es gab mal eine Zeit wo das nicht so ueblich war (ich sag jetzt mal grob die 486er-Zeit, da war die Rechenleistung hoch genug um alles, was man damals so darstellen wollte, in Software machen zu koennen). Aber davor und jetzt auch danach wieder ist es halt ueblich, Grafikberechnungen von einem separaten Chip erledigen zu lassen, damit die CPU solange was anderes machen kann.

Hmm nee das sehe ich anders. Klar kann man das nutzen und auch anpassen, aber dann hat man halt eine angepasste Version von TIC-80. Wenn man hier was eigenes konzipieren will, nach eigenen Vorstellungen, und mit einer eigenen Zielsetzung (die bei TIC-80 womoeglich eine voellig andere war), dann sollte man auch was eigenes bauen.

Es gibt hundertzigtausende Dinge. Ich persoenlich nutze sehr gerne Python und Pygame. Leider ist auch Pygame nicht perfekt.

Und was das Thema Einstieg eingeht: PICO-8 ist definitiv einfacher zu coden als Python mit Pygame. Ich habe mal einen Vortrag drueber gehalten, da kannst Du zwei aehnliche Spiele sehen (zugegeben, sie sind nicht GLEICH, aber trotzdem sieht man, dass es in PICO-8 einfach deutlich schneller geht als mit Pygame, zumal man hier nicht nur den Code hat sondern auch direkt alle Ressourcen integriert sind und ueber einfache Indizes angesprochen werden). Es ist einfach doch nochmal was anderes.

Und nein, ich sage nicht dass PICO-8 grundsaetzlich BESSER ist als Python/Pygame.

Wer sich den Vortrag mal ansehen will (ca. die ersten 25 Minuten)

Los gehts ab 2:30 ca nee eher ab 4:50

DivZero deshalb soll die "Retrokiste" ja hier eine Bruecke schlagen und eben kein C64 sein, sondern eher etwas, was noch einfacher zu bedienen ist als Python mit Pygame.

Was ich z.B. grad auch wieder nicht verstehe (oder bemaengle, falls es wirklich nicht geht): Ich kann im Sprite-Editor auch direkt 16x16 zeichnen statt 8x8, aber im Map-Editor kann ich keine 16x16-Tiles plazieren.

Quote from Retrofan

Quote from ZeHa

Allerdings finde ich die integrierten Tools zum Teil schon wieder "too much".

Ich habe mir den TIC nun auch installiert und damit etwas herumgespielt, also Beispiele verändert etc. Was ist an den Tools anders als beim PICO? Aus meiner Sicht ist das eine extrem ähnliche IDE.

Die IDE ist natuerlich schon aehnlich, aber sie bietet halt mehr Funktionen und damit auch mehr Steuerelemente, und ich finde sie schon wieder deutlich weniger intuitiv. Bei PICO-8 wusste ich sofort wo ich klicken muss, hier muss ich mich schon wieder "einarbeiten". Klar, das ist absolut gesehen kein Ding, weil einarbeiten muss man sich ja letztendlich ueberall. Aber ich vergleiche es jetzt hier speziell mit PICO-8 weil ich PICO-8 in dieser Hinsicht fast schon fuer genial halte. Das liegt aber auch an dem reduzierten Funktionsumfang.

Auch finde ich es zweischneidig dass man bei TIC-80 gleich mal in 3 verschiedenen Sprachen coden kann. Klar, eigentlich ist das gut, weil somit erleichtert man direkt mal den Einstieg fuer diejenigen, die schon in einer dieser Sprachen coden koennen, aber es hat eben auch schon wieder was verwirrendes fuer totale Einsteiger.

Wie gesagt, ich vergleiche es hier direkt mit PICO-8, welches ich aufgrund seiner Reduziertheit auf das absolute Minimum fuer genial halte und damit auch fuer so einsteigerfreundlich.

Hier fuer alle mal zum Mitgucken, diese beiden Videos haben recht nette Spiele mit drin:

Sowas auf nem dedizierten Retro-Rechner coden zu koennen mit ner handvoll Zeilen... das waere schon was echt cooles. Ich glaube ich muss mir generell TIC-80 mal genauer ansehen...