In Boulder Dash laufen die Figuren auch blockweise, aber trotzdem scrollt alles flüssig. Finde das auch schwach.
Posts by peiselulli
-
-
Display MoreCode
- uint32_t convert(uint32_t in)
- {
- static uint32_t or_array[32]
- = { OUT31, OUT30, OUT29,OUT28,OUT27,OUT26,OUT25,OUT24,
- OUT23, OUT22, OUT21,OUT20,OUT19,OUT18,OUT17,OUT16,
- OUT15, OUT14, OUT13,OUT12,OUT11,OUT10,OUT09,OUT08,
- OUT07, OUT06, OUT05,OUT04,OUT03,OUT02,OUT01,OUT00};
- uint32_t out = 0;
- while(in != 0)
- {
- int leading_zeros = __builtin_clz(in);
- in -= 1 << (31-leading_zeros);
- out |= or_array[leading_zeros];
- }
- return out;
- }
Teste mal sowas ...
-
Ich habe bei mir einen Rasperry Pi2 (der war noch über) als SMB Server ans Netz an die Slim angeschlossen und einen NTFS Stick im Rasperry. Das hat 2 Vorteile :
- Laden ist schneler als mit USB 1.1
- NTFS kann mit Dateiner größer 2GB.
Alles noch mit RO gemountet, damit das Gerät einfach ausgeschaltet werden kann, und alles läuft super ...
-
Ich habe damals beim Donkey Kong auch den Score rechts eingeblendet. Allerdings habe ich den Rahmen noch als Spielfläche benutzt.
-
Leider bisher noch nicht
-
Quote
* wenn man langjährig bestehende Emulationsfehler der 1541U ignoriert
Achja, wäre schön, wenn es noch einen Fix für die 1541 U1 geben würde ... sniff ...
Aber mit den illegalen Opcodes hatte es der Gideon eh nie, kann mich an die Abstürze bei seinem FPGA C64 und Donkey Kong Arcade erinnern ... -
Wer benutzt schon IDEs ? Ansonsten benutze ich den Doppelpunkt aus denselben Grund wie Enthusi ...
-
Quote
c) Auch spätere Spiele mieden oft das Ram im IO-Bereich $d000-$dfff, weil es schwerer zugänglich war
Das macht diesen Bereich ideal für Zeichensätze und Sprites ! Das ist dann $01 sowas von egal ....
-
Wahrscheinlich haben sich die Leute in Braunschweig den Verhau A1000+Sidecar als er fertig war einmal genauer angeschaut und gemeint, das ginge auch eleganter
Könnte sogar sein, dass das die Initialzündung für den A2000A war. -
Laut englischer Wikipedia kam das Sidecar 1986, der Amiga 2000 erst 1987.
-
Meiner Meinung nach ist die erste Entwickung der Brückenkarte das Sidecar für den A1000, das fällte hier ein bisschen durchs Raster ...
-
Die Sache mit dem fehlenden Disketten war auf anderen Workstations - bei SUN z.B - auch üblich. Aus dem oben genannten Grund mit der Synchronisierung der Daten.
-
Ich habe das Buch nur auf Papier
-
Naja, 3 Wochen Basic, dann Assembler gelernt, dann Flaschbier gecodet, dann 1986 Amiga 1000, dann 1993 486 DX2 und Linux und die alten Kisten ein bisschen aus den Augen verloren. Zwischendurch ein paar kommerzielle Spiele Vom ersten C64 existiert nur noch das weitest unbestückte Mainboard, der war ziemlich hinüber . Dann kam 2006 mit dem DTV die alte Faszination wieder, ein Arbeitkollege war (und ist noch) Teil von TRSI und den Rest gibts auf der CSDB
-
1984, im Mai habe ich meinen ersten C64 vom Konfirmationsgeld gekauft. Eine Datasette konnte ich mir noch dazu leisten, mehr war nicht drin.
Bis dahin exakt meine Geschichte
-
Ser.No.WG A 4632 (Made in W.-Germany) ... Ist das alt ? Die CIAs waren bis vor kurzen auch noch Goldene (die goldenden habe ich funktionierend weggepackt) ...
-
Quote
VSP brauchen wir hier eher nicht, da bei Boulder Dash sowieso der ganze Screen für jedes Frame neu erstellt wird. Es wird ja nicht nur gescrollt, sondern es können jederzeit beliebige Veränderungen im virtuellen Screen stattfinden.
Die Idee wäre ja, den Screen ÜBERHAUPT nicht zu kopieren, sondern den Logik-Screen so aufzubauen, dass er direkt dargestellt werden kann ! Das ginge dann nur mit VSP ...
-
Man kann die Zeilenzahl von dem Charset mit ein paar Tricks auf 8x16 hochstellen. Habe ich in dieser Demo gemacht, und zwar fast am Ende der letzten Seite ("Profis machen das so"). Als "Dreckeffekt" bekommt man dann 80 Bytes Differenz zwischen diesen Zeilen, daher kann man mit VSP, ohne zu kopieren, von links nach rechts scrollen (habe ich in der Demo auch gemacht) . Mit "line-crunching" könnte man dann ohne zu kopieren auch in Y Richtung scrollen (hab ich in der Demo NICHT gemacht
) .Dann könnte man, ohne zu kopieren, das Videoram über den ganzen Screen scrollen.
Farberam müsste man dann noch umkopieren, aber nur 500 Bytes pro Screen-Durchlauf. Farben im Farbram wären dann aber nur im 8x16 und nicht im 8x8 Raster veränderbar.
-
spart ein Byte
Am Ende von Projekten sucht man IMMER solche Stellen, um noch ein paar Bytes für die letzten Fixes reinzukriegen. -
Beim Init zum Beispiel
ldx #$ff
lda #$7f
sta $dc0d
sta $dd0d
lda $dd0e,x ;ack
