1. Crillion (c64games/phpseiten/spieledetail.php?filnummer=1317)
2. Mr Robot (c64games/phpseiten/spieledetail.php?filnummer=3661)
3. Kikstart 2 (c64games/phpseiten/spieledetail.php?filnummer=94)
4. Little Computer People (c64games/phpseiten/spieledetail.php?filnummer=312)
5. Mayhem in Monsterland (c64games/phpseiten/spieledetail.php?filnummer=612)
dann brauche ich auch keine Versionen meines Emulators dafür anzubieten.
Konsequenter wäre es wohl. Aus Erfahrung kann ich sagen, dass die gute alte Sitte, überhaupt keine binaries anzubieten, auch für befremdliche Reaktionen sorgt. Bei coreboot überlassen wir den "Kundenkontakt" denen, die Nerv dafür haben, da werden auch manche grantig weil es nichts "offizielles" gibt...
Aber immerhin hat man sich keine Arbeit gemacht, für die man angepflaumt wird, und es gibt auch keine Verwirrung, ob die binaries funktionieren.
Es ist auch völlig schnurz.
Es widerlegt die Aussage, dass eine Kollision angeblich erst dann stattfindet, wenn die Pixel der Sprites gemalt werden. Die Sichtbarkeit ist unerheblich. Wichtig ist die Position der Sprites.
Richtiger wäre wohl "wenn die Pixel gemalt würden": dem Dokument auf zimmers.net zufolge, das ich hier irgendwann verlinkt habe, gibt es engines für Vordergrund, Hintergrund, den Rahmen und jedes Sprite, die für jedes Pixel bestimmen, ob und was sie an der Stelle malen würden und dann eine Priorisierung, was davon auf dem Bildschirm landet. Wenn zwei Spriteengines sagen, sie hätten was beizutragen, werden deren Kollisionsbits gesetzt.
Display MoreHa, ich wusste das sowas kommt.
Das ist nämlich seit Jahren das angebliche Totschlag-Argument, jeglicher Kritik am VICE.
Immer wieder dieser alte Spruch, nach dem Motto "der Emulator ist kostenlos ... bla bla ... sei froh, dass er überhaupt kostenlos angeboten wird ... bla bla ... du musst dankbar sein, dass du ihn nutzen darfst (und es wahrscheinlich auch noch gut finden, wenn er unter Windows dauernd abstürzt) ... bla bla ... was kostenlos ist, darf nicht kritisiert werden ... bla bla ... da der Emu kostenlos ist, kannst du keinen Support erwarten und darfst nicht nachfragen, wenn der Emu auf deinem Windows-Rechner Probleme macht ... bla bla"
Es ist immer wieder die alte Leier, die man kaum mehr hören kann *lol* und die, so kommt es mir vor, inzwischen eigentlich auch mehr von manchen wenigen User immer wieder gebracht wird, als vom VICE Team selbst, weil ich denke dass da diese Meinung so gar nicht mehr vorherrscht. Bin mir sicher, dass auch 99% der kostenlos angebotenen, allgemeinen PD-Software (egal ob Spiel oder Tool), von den jeweiligen Machern vor dem Release ein paarmal durchprobiert wird, ob sie nicht vielleicht immer wieder abstürzt oder sonstige, sofort auffallende Bugs zeigt?
Mir geht nicht wirklich ein, dass sich da angeblich keiner finden lässt, der die Windows Versionen des VICE vor der Veröffentlichung einmal durchtestet. Kann doch eigentlich nicht sein. Was hab ich schon durchgetestet beim Denise und beim HOXS und hier beim VICE soll sich niemand finden lassen? Und ich frage mich auch, wo das Problem ist, dass sich einer aus dem Entwickler-Team, einen Windows-PC zulegt (reicht ja schon ein ganz billiger eigentlich). Sie könnten ja sogar noch zu einer Spenden-Aktion vorher aufrufen notfalls, wenn man selbst rein gar nichts investieren will. Da würden sicher auch viele etwas spenden (ich eingeschlossen). Und wenn von hunderten Nutzern, um die 80 oder 90 Stück, auch nur 3,- EURO jeweils geben würden, hätte man das Geld schon zusammen, um sich ein billiges Windows-Teil irgendwo hinzustellen und eigene releaste Sachen vor der Veröffentlichung auch mal testen zu können.
Wenn solche Probleme in einer Veröffentlichung auftreten, ist das ein ziemlich deutlicher Hinweis darauf, dass die Entwickler selbst kein Windows verwenden.
Warum sollten die dann irgendeinen Aufwand auf sich nehmen, eine Plattform zu unterstützen, die sie nicht interessiert?
Einen Psion Port pflegen die ja auch nicht, nur weil ich gern einen hätte. Wenn ich das will, muss ich halt selbst Hand anlegen.
Die hatten dafür auch eine spezielle Bezeichnung - ich weiß nur nicht mehr welche das war.
Spezieller als BASICODE?
Eine Verzögerung von einem Screen wäre ja eine fünfzigstel Sekunde. Die Frage ist, wann genau das Kollisionsregister aktualisiert wird. Wenn der Rasterstrahl eine bestimmte Position erreicht? Oder wenn er sie zum zweiten Mal erreicht?
Soweit ich die Beschreibung verstehe, werden die Bits gesetzt, sobald der VIC-II an der Stelle ist, wo die Kollision auftritt. Also: für jedes Pixel auf dem Screen: gucke, was gerendert werden soll. Wenn mehrere Sprites dran sind (oder Sprite + Hintergrund), setze das entsprechende Bit.
Daraus könnte eventuell was für detect werden, wenn es 1/50 Sekunde dauern darf (plus Overhead). Grobe Idee:
1. Bereite einen Puffer vor
2. Speichere aktuelle Rasterzeile
3. Solange man nicht "einmal rum" ist (also die Rasterzeile anders war und wieder gleich der gespeicherten wird):
3a. Lies das Kollisionsregister. Wenn es eine Kollision gibt, speichere sie weg. (zum Beispiel 256 byte Puffer mit $d01e als Index, Platzprobleme ignoriere ich hier mal)
check könnte dann im Puffer gucken, ob die entsprechende Kombination gesetzt ist oder nicht.
Das wäre immer noch nicht perfekt, weil bei sehr knappen Situationen mehrere Kollisionen in eine zusammengefasst werden könnten (der VIC ist arg schnell), aber das Risiko sollte damit deutlich kleiner sein, alle Kollisionen werden erfasst und die Laufzeit wäre planbarer (halt immer ungefähr 1 Frame).
Ich hab festgestellt, dass der VIC auf das Kollisionsregister erst beim zweiten Impakt reagiert
Bei mir reagiert das Kollisionsregister meistens erst bei der zweiten oder dritten Abfrage. Ich glaube das hat nichts mit der Anzahl der Kollisionen/Impacts zu tun, sondern ist einfach zeitabhängig.
(aus http://www.zimmers.net/cbmpics/cbm/c64/vic-ii.txt)
Von daher gibt es eine Verzögerung von bis zu einem Screen. Das macht natürlich auch Experimente wie "paarweise aktivieren und gucken, ob das Register triggert" sinnlos, weil die Sprites dann einige Frames lang durchflackern würden. Weitere Kollisionstests müssten dann über die Koordinaten der Sprites vorgenommen werden, was natürlich unscharf bleibt, wenn man nen Haufen Sprites mit komplizierten Formen hat, die mehr-oder-weniger überlappen und man wissen will, genau welche zwei von denen überlappende Pixel haben.
Die Dateien mit "[A] ...." müssten glaube ich Animationen sein.
https://www.c64-wiki.de/wiki/Amica_Paint#Inhaltsverzeichnis nach zu urteilen wohl eher Ausschnitte.
Falls also ausser Frank irgendjemand diese Dateien hat, die er mal auf Github und anderen Plätzen veröffentlicht hatte, wäre ich durchaus neugierig. Immerhin basieren diese ja auf vielen meiner Ideen und insbesondere dem angepassten CP/M BIOS dazu.
Die BOM unter https://github.com/kneehighspy…mmodore%20C64%20V0.3.xlsx enthält einen Xilinx XC95144XL-7TQ100C, von daher würde ich mal davon ausgehen, dass der Rest des Repos ebenfalls das neue Design beschreibt?
(Im Übrigen ist DL2DW laut einiger Quellen ein Dirk W., kein Frank)
Kannst Du von der Webpage die "Downloads" (zB Gerber Files, BOM) tatsächlich downloaden? Ich schaffe das nicht ...
Selbst wenn man sich die richtigen URLs für die Dateien aus dem Code zieht, kommt man nur auf "403 Forbidden". Dass jede der Dateien 0 Zugriffe zählt, ist daher nicht verwunderlich.
War angeblich auch nötig, weil Commodore Australia gedroht haben soll, jeden einzelnen Z80 aus dem C128 rauszulöten, bevor sie dort in den Verkauf gehen, weil Z80 ja mal so gar nicht geht.
Wie verhindert man das? Die Kiste startet nicht mehr ohne!
Es gibt irgendwo eine ausführliche Beschreibung vom Startvorgang des C128. Wenn ich mich richtig erinnere, dann gibt es technische Gründe dafür, dass der C128 zunächst mit dem Z80 startet.
Wenn du eine Quelle für die Australien Geschichte hast, gerne mal posten.
Zu den Australiern hat Bil Herd was auf Reddit geschrieben: "We didn't tell management that we had built in the Z80 until it was too late to stop us. We got a telex from CBM Australia telling us that they would "personally" open the C128's and remove the Z80s if we insisted on shipping with it, which just made us want it more."
Die Reihenfolge ist wohl eine etwas andere (der Z80 war schon eingeplant), aber die Australier waren über den Z80 wohl nicht sonderlich glücklich - die Drohung, ihn auszubauen, inklusive.
Das ist bei Zugriff auf die D64 während Vice noch läuft, oder? Da sehe ich das auch häufiger, während das Verzeichnis in ordentlichem Zustand ist, wenn Vice beendet wurde. Da gibts wohl irgendeinen Cache in Vice, der die Schreibzugriffe verzögert.
Tja und außerdem einen Z80 aber nur für CPM.
Tatsächlich ist der Z80 die erste der beiden CPUs im C128, die aktiv wird.
War angeblich auch nötig, weil Commodore Australia gedroht haben soll, jeden einzelnen Z80 aus dem C128 rauszulöten, bevor sie dort in den Verkauf gehen, weil Z80 ja mal so gar nicht geht.
Wie verhindert man das? Die Kiste startet nicht mehr ohne!
Ich war erstmal mit meiner Masterarbeit befasst, aber das Thema ist so gut wie rum. Da kann ich mir ja langsam wieder den verrückten Hüpfer angucken.
Ich würde auch echt gerne selbstgebaute Levels für die diversen Spiele, die einen Editor beinhalten, auf der DT vorfinden. Da verweise ich z.B. auf Shadow Switcher, Gotcha!, Platou, Lode Runner oder Blagger...
Ich schätze, ich sollte Crazy Jumpman mal fertig fixen, das hat nämlich auch nen Leveleditor 
Ihr macht mich Feddich.
DAO, DOA, ODA ?
RTS RTC ?
Sfn
DOA - Dead On Arrival
RTS - Return To Sender
BASIC Themenhefte wären cool: "Western auf dem Commodore", "Sci-Fi auf dem Commodore"...
Der Forum64 Game Jam: 1 Wochenende, 1 Motto, 1 Themenheft als Ergebnis?
Weil es kein Basic-Programm ist.
Die meisten Spiele sind auch keine BASIC-Programme. Und trotzdem kann man sie mit RUN starten.
Die liegen dann halt auch bei 2063 oder so, statt bei 33095. Ist für eine BASIC-Erweiterung etwas unpraktisch, wenn sie dort rumliegt, wo das BASIC Programm hin soll.
Wenn du willst, schick tsb.obj durch irgendeinen Packer, der dir daraus ein Programm mit BASIC-Start baut und die Daten an Ort und Stelle legt, bevor dorthin gesprungen wird. Exomizer oder so.
Im Digital Retro Park hab ich vor ein paar Wochen ein ähnlich funktionierendes Spielzeug mit 4 Stufen aus Plastik gesehen. Es war auch gut in Gebrauch.
Mir wurde mal gesagt, dass die deswegen so schnell waren weil sie eben nicht die einzelnen Produkte eingetippt haben sondern nur die Preise
Könnte auch Plus gewesen sein, mit den Nummern. Da ging das auch ziemlich flott voran. Ich habe jedenfalls schon oft gehört, daß Kassierer sich früher viel mehr Nummern merken mussten. Heute kommt das ja praktisch nur noch bei Sachen zur Anwendung, die an der Kasse gewogen werden.
An Bons, wo einfach nur Preise drauf standen, und man deshalb überhaupt nicht nachvollziehen kann, was man gekauft hat, erinnere ich mich aber auch noch. Gut möglich, daß das die von Aldi waren.
Aldi Nord vs Aldi Süd. Ich glaube, Süd hat Preise getippt und sich auf 10 Preisgruppen beschränkt, Nord hat Produktnummern gehabt, die haben ja auch früher angefangen, ihre Produktpalette zu erweitern.
