Posts by Hoogo

Eine PC-Tastatur, die wie ein C64 aussieht!

Nicht ganz so Hammer wie der andere Kurzfilm, aber schön dicht am Spiel.

Da hab ich lustige Erinnerungen an das Zocken mit Kollegen auf der Arbeit, lustige an Duke und schockierende an Blood. Aber hauptsächlich haben wir damals Duke gezockt.

Vor Urzeiten hatten wir mal über sowas diskutiert. Es ist weniger Aufwendig nicht ganz frei verschiebbar zu denken, sondern nur in Schritten von 256 Bytes. Du brauchst sonst komplette 16bit Addition für das Verschieben, aber was ist, wenn im Programm die loBytes nicht vorhanden sind?

Und Verschiedene um 256 Bytes ist einfach, dazu assemblierst Du 2mal an verschiedene Adressen und vergleichst die erzeugten Programme.

Revolution 1979

Eine Geschichtsstunde zur Iranischen Revolution 1979.

Spielerisch ist es Multiple-Choice Gespräche führen, beschränkt herumlaufen und Dinge anklicken, und dabei dann das eine oder andere historische mit Erklärungen zu bekommen. Dazu ein paar Minigames, grafisch schlicht.

Kein Spaß-Spiel, eher zäh, mit Zeitdruck bei den Multiple Choice Antworten, aber als Geschichtsstunde sehr interessant.

Quote from -trb-

oder das Diskformat des Originals wurde geändert (z.B. um einzeln kopierbare Dateien zu haben)

Ich hatte mal ein bisschen Kontakt zu AVT und wurde mal gebeten, mir ein Spiel anzugucken und "die Files sichtbar zu machen" Das Original schien eine Art von Heureka Sprint genutzt zu haben, und irgendwie hat es für mich überhaupt keinen Sinn gemacht, daraus wieder die Original-Files zu machen.

Aber es scheint jedenfalls ein Thema gewesen zu sein.

Ist zwar nun ziemlich OT, aber wie könnte ein 8Bit ARM aussehen? Wäre so ein gedachter Chip in der Nähe der Grenzen, die auch ein 6502 aushalten musste?

Wie schon erwähnt, ich halte das nicht für ein Marketing-Gimmick.

BCD war bei den großen Mitte der 70er noch kein Exot, sondern ganz normal.

So, wie mal PCs mit Diskettenlaufwerk normal und das Weglassen revolutionär waren.

Quote from berni

Ist sicherlich eine Möglichkeit. Bei meinem Programm dürfte das kaum einen Vorteil bringen, da es nur addiert, wenn ich mich recht erinnere - ich hab' mir den Sourcecode bislang nicht angeschaut. (An was ich mich zu erinnern glaube: Für jede zu multiplizierende Zahl wird eine Multiplikationstabelle durch sukzessive Addition erstellt, und dann einfach für jede Ziffer der entsprechende Wert nachgeschlagen und zum bisherigen Ergebnis addiert (mit entsprechendem Versatz natürlich).)

Reingeguckt und in eine Textdatei "ausgedruckt" hab ich ihn. Aber ich bin leider auch nicht mehr so fit darin, durch fremden oder alten Code durchzusteigen (bzw. ist meine Geduld schon nach 60 Sekunden aufgebraucht)

Ich erinnere mich, dass ich damals in Multicolor 3 Stacks verwendet hatte:

- Wo bist Du

- Wohin gehst Du

- Woher kommst Du.

Der "Woher kommst Du" war nötig, um mit Mustern und Zufall zu füllen.

Quote from Hoogo

Ich hatte da auch noch den Gedanken, dass man erstmal alle Primfaktoren sammeln und neu zusammenstellen könnte. Könnte auf Prozessoren mit Mul-Befehl nützlich sein, aber ich sehe grad nicht, wo das auf dem C64 nützlich wäre.

Noch ein bisschen drüber nachgedacht, und ich habe das Gefühl, dass sich das auch am C64 lohnen könnte. Zumindest beim Multiplizieren mit KB-Großen Binärzahlen.

Aus den Faktoren lassen sich andere zahlen zusammenstellen, die 8/16 Bit besser ausnutzen oder weniger 1Bits enthalten.
3, 7 und 11 haben zusammen 8 gesetzte 1Bits, was entsprechend viele Shifts und Additionen mit der großen Zahl bedeutet.

Multipliziert ergeben sie 231, die Zahl hat nur 6 gesetze Bits, was 2 Additionen spart.

Ist jetzt die Frage, wie man die Original-Faktoren am besten zerlegt und wie man die hübscheren, neuen Faktoren findet.

Quote from enthusi

Und BCD ist doch im kaufmaennischen Bereich zu Hause? Sauberere Rundung etc.

Früher schon. Was ich da heute im SQLServer und so finde, money und decimal, sind Binärzahlen mit festem Komma.

Quote from Krill

Aber es wurde dennoch als Verkaufsargument eingebaut, vielleicht, weil das wohl auf diversen Ausschreibungs-Checklisten eben auftauchte.

Ich kenne es aus Cobol und dem EBCDIC-Code der alten Großrechner. Amerikanische Rechner haben glaub ich recht lange nicht richtig binär, sondern im 10er-System gerechnet, und das hat sich dann über Cobol, EBCDIC und IBM lange gehalten (meine Vorstellung davon). Aus der Perspektive der 70er finde ich das sehr vernünftig.

Ich hab noch ein bisschen gegrübelt, wie man Fakultät schnell berechnen könnte.

Zumindest die Anzahl der 00 am Ende würde ja Multiplikationen sparen. Oder alle Primfaktoren 2 könnten entfernt werden, wenn man binär rechnet.

Ich hatte da auch noch den Gedanken, dass man erstmal alle Primfaktoren sammeln und neu zusammenstellen könnte. Könnte auf Prozessoren mit Mul-Befehl nützlich sein, aber ich sehe grad nicht, wo das auf dem C64 nützlich wäre.

Quote from FRauANtje

Wir hatten mal bei ner mathe-plympiade die frage, wieviele Nullen 99! am ende hat

Aber das konnte man noch logisch lösen - also ohne ausrechnen

Genau.

Quote from Tobias

Was man so findet, müsste das Bild ja ein UFLI sein, oder?

Also nach meinem bisherigen Verständnis ne Mischung aus Hires-FLI und Sprites.

Ich glaube ja. Ich habe die Namen der ganzen Special-FX-Grafiken nicht mehr so genau verfolgt.

Quote from Tobias

Hires hat keinen Hintergrund, oder? Nur die beiden Farbram-Farben.

Woher kommt also der Hintergrundlayer? Welche Auflösung hat er?

Hab ich selber gebastelt

Quote from Tobias

Das sind (6?) x-pandierte, gecrunchte ("unendlich" in y-Richtung) Hires-Sprites? Also entweder Farbe oder druchsichtig.

Ja.

Quote from Tobias

Der Vordergurnd ist augenscheinlich Hires. Wie kann man die Eigenschaft "transparent" definieren? Hintergrundfarbe = transparent? Aber Im "Hintergrund" (unterster Layer) sind ja immer andere Farben drin. Und Hires hat ja nur 1 bit pro Pixel.

Das ist eine Einstellung für die Sprites, ob sie vor oder hinter dem Vordergrund erscheinen sollen.
Im alltäglichen Spiele-Geschehen sind sie üblicherweise komplett vor der Grafik. Also in Layern ausgedrückt:
- Ganz oben Sprites

- Darunter die Grafik, ohne weitere Unterscheidung zwischen Vorder- und Hintergrund.

Und wenn die Sprites so eingestellt sind, dass der Vordergrund Prio hat:
- Vordergrundpixel. Was nicht Vordergrundpixel ist, ist "transparent", dort kann Sprite oder Hintergrund erscheinen.

- Sprites

- Hintergrund-Pixel.

Und Pixel für Pixel durch das Bild geguckt:

- Wo Vordergrund-Pixel zu sehen ist, da ist kein Hintergrundpixel, und das Sprite ist (ganz lokal für diese Stelle) egal.

- Wo Sprite zu sehen ist, ist kein Vordergrundpixel, und Hintergrund ist egal.

- Wo Hintergrund ist, da ist Hintergrund und nichts anderes.

In den ersten Versuchen, die 3 Ebenen als 3 Bilder darzustellen, hatte ich Blau für die Stellen verwendet, die egal sind.

Sieht aber unlogisch aus, alle Ebenen erscheinen irgendwie Hires.

Darum die andere Darstellung: Alle Sprites weg, alle Vordergrundpixel gelöscht (=0), übrig bleibt ein Hintergrund. Der existiert technisch so gar nicht im Bild, denn das Bild HAT ja Vordergrundpixel. Aber in der Summe ist es egal, ob egal jetzt blau oder Hintergrund ist, und so sieht es logischer aus.

Oh ja, unter den Alten gehört Cosmi dazu.

Und Synapse! Fort Apocalypse, Blue Max...

Und Br0derbund nicht vergessen:

Lucasfilm und Rainbow Arts sind mir neben Epyx in guter Erinnerung geblieben.

Aber das waren schon die späteren 80er.

Quote from ivettaB

höre aus euren antworten das ich den Photoshop nehmen sollte ...

Wieso?

Ich hab kein Gimp zur Hand, aber ich bin sicher, dass man auch damit ein TrueColor-Bild mit einer bestimmten Palette reduzieren kann.

Und für die Palette machst Du einen Screenshot im Vice und pickst Dir dann im Gimp die 16 Farben raus.

Nimm einfach das Programm, mit dem Du Dich am besten auskennst.

Suche die Paletten-Dateien und probiere, ob Gimp sie einfach laden kann.

Wenn nicht, dann machst Du im Vice einen Screenshot der Palette ohne weitere Gimmiks und machst die Palette aus dem Bild.