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?

    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!

    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.

    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.

    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?