Posts by Endurion

In den meisten Spielen wird mit Pseudo-Floats gearbeitet, d.h. 16-Bit-Werte, bei denen ein Byte quasi den Nachkommawert enthält. Bei diversen Projektil-in-freie-Richtung-beweg-Code verwende ich so etwas wie Bresenham. Da wird mit reiner Integer-Arithmetik gearbeitet und erhält trotzdem fast frei drehbare Linien.

Was mrsid bereits erklärte.

Ich mache mir die Kollisionsabfrage damit etwas einfacher. Da eine Prüfung nur bei einem genauen Anliegen an der Zeichengrenze gemacht wird, gibt es den extra Zähler für den Abstand zum Übergang.

Der Autor sagt im Artikel: Die Richtschnur von Linux und FOSS ist, "gute Software zu machen". Es geht nicht um"Windows-ersetzende Software herstellen". Später auch, Linux ist kein Ersatz für Windows.

Warum erzählt dann jeder zweite Hinz hier und anderswo (Echokammer Heise-Forum z.Bsp.), wechsel doch zu Linux, wenn es ja offenbar nicht als Ersatz gedacht ist? Da haben ein paar mehr den Artikel nicht verstanden?

Arghh, danke für die Rückmeldung. Ich doof. Das war ein anderes neues Feature und wieder habe ich geschusselt.

Neue Version 6.3.2 ist hochgeladen, sorry!

Da ich beim Debuggen einen Fehler korrigiert habe, greift jetzt eine Default-Einstellung, so dass das Debuggen nicht mehr richtig klappt.

Bitte entweder das neue Executable herunterladen (Version zeigt jetzt 6.3.1) oder in den Projekt-Eigenschaften den Wert für Debug Start Address auf 0 setzen (steht vermutlich auf 2049. "Apply" klicken nicht vergessen!

Sorry!

Last Ninja - F-Tasten für Inventory

Das wäre was. Mein C64 wurde damals einfach so verkauft

Meine ganzen selbstprogrammierten BASIC-Spielchen weg. Falls mal irgendjemand etwas von "Contravision" findet, das war ich!

Klasse, vielen Dank!

Beeindruckend

Sehr schräg finde ich die Syntax für Methoden, weshalb das? (auto FunktionsName() -> Rückgabetyp)

Ich habe nur mal kurz überflogen, weil ich liebend gerne eine Emulations-Engine in C64Studio reinbauen möchte. Ich habe mal selbst einen Emulator angefangen, aber das ist ja nicht so ganz trivial.

Spaßhalber auch mal den VICE-Code mit C++/CLR erstellt, aber dann fehlen mir einfach Details, wie ich den Code anwerfe.

Der RemoteMonitor von VICE ist halt leider nur eine Krücke, und das fliegt mir immer wieder mal um die Ohren.

Besteht denn evtl. die Chance, da eine Art reine Emulations-Library mit Debug-Interface umzusetzen? Es sieht ja zumindest so aus, als wäre das ohne Weiteres schon möglich.

Oh, sieht meine Tests dann hinfällig, wie es aussieht? Auch gut

Ich komme nicht so oft dazu, meinen C64 aufzubauen und damit rumzuspielen.

Solange man die Abtippen kann, oder aus dem Heft ausschneiden

DreamLoad soll auch mit SD2IEC laufen, ich muss das mal testen.

Da muss ich echt sagen, ich bin erstaunt, das selbst die Listings vom Vorjahr noch nicht von Laxity gecrackt und ver-intro-t wurden. Auf GB64 sind die auch nicht gelandet.

Quickshots hält man mit zwei Fingern gespreizt oben, bewegt die über den Mülleimer und lässt los!

Da ich den Joystick am Gehäuse in der Hand halte, bevorzuge ich den "The Arcade", der passt im Gegensatz zum Competition Pro nämlich wirklich in eine Hand.

Ich kann nochmal versuchen, ob ich den Socket-Aufbau beschleunigen kann, es hat ja offenbar mal funktioniert. Es bleibt halt leider bei einem timing-kritischen Ablauf, das kann immer wieder mal daneben gehen.

aitsch : Aua, das sieht schlecht aus für VICE 2.4. Das Problem ist Timing; C64Studio benutzt den Remote Monitor von VICE. C64Studio kann erst ansteuern, wenn die Socket-Verbindung aufgebaut ist. Leider läuft der Emulator aber bis dahin schon ein paar Schritte und ist über die Einsprungadresse hinaus. Beim C64 geht das gut, da dessen Startroutine bis zum BASIC etwas länger dauert, beim VC20 ist das ratzfatz durch.

Wenn vorher ein Breakpoint erreicht wird, geht das Monitor-Fenster von VICE auf; und ab da ist es mit Remote-Monitor leider vorbei.

Ich habe dafür einen Feature Request gestellt, der hilft natürlich bei der 2.4 nicht mehr.

Ein möglicher (hässlicher) Workaround: Einen späteren Code nehmen; oder vorne eine Warteschleife einbauen.

Ah, den Punkt hatte ich übersehen. Da schaue ich mal, was das sein kann. Das sollte auch mit der 2.4 tun.

Eine Versionsnummer sollte ich da mal reinbauen, dann könnte ich das machen. Ist eine Idee, hab ich irgendwie nicht dran gedacht

Wieso Abschied von 2.4? Das sollte alles ab 2.3 soweit laufen.

Billige Methode: Bild auf 12x21 Pixel zusammenrechnen lassen (ohne Antialiasing) und dann wieder auf 24x21 Pixel verbreitern. Dann aber dringend Hand anlegen, da geht sonst einfach zuviel Detail verloren.

Nee, im Gegenteil. Vielen Dank für's so ausführlich beschreiben!

Jetzt bin ich ein bißchen zwiegespalten. Ich tendiere dazu, für neue Projekte die DebugStartAddress mit 0 vorzubelegen, so dass alles klappt.

Ist der Wert 0 (bzw. nicht gesetzt), dann wird eine halbwegs sinnvolle Kernal-ROM-Adresse benutzt, damit nicht alle Breakpoints schon beim RAM-Test zuschlagen.

Das ist natürlich jetzt unglücklich für bestehende Projekte, die alle mit 2049 angelegt wurden (wobei 2049 eh Blödsinn ist, da in der Regel ja noch ein BASIC-Starter da liegt)

Kann man da mit leben?