Beiträge von jojo1

    Die N64 Referenzanleitung schreibt:


    N64 Programming Basics


    N64 game applications are written in the C or C++ programming language. However, an N64 game program is structured somewhat differently from a general C language program.


    Different Programming Styles


    In the flow of an ordinary C program, each process executes sequentially to ensure that no processes are executed simultaneously. However, in the flow of an N64 C program, several processes may execute in parallel; that is, although they are not executing simultaneously they are executing together by taking turns -- pausing and restarting.


    The flow of an ordinary C program continues as if one person is doing the whole job by completing several tasks in a series. The N64 C program flow continues as if several people are working on different parts of the job at the same time by sharing the tools. Because of this, you must design your N64 game programs carefully to manage all the workers and to manage the tool sharing process.


    .. und auch :


    No main() Function in N64 Programs


    A typical C program starts from the beginning of the main() function and proceeds by calling library functions or originally defined functions.


    An N64 C program, on the other hand, has no main() function. The boot function (a function specified in the spec file) begins the processing. The boot function, however, may or may not call all the other functions the program uses. After providing various initializations and settings, the boot function may turn control over to a thread that takes charge of the main part of the program


    Deshalb hab ich auch kein main() Aufruf ;))



    Greets,

    Hey Hellton,


    danke erstmal für deine Antwort!


    Ja war ein Tippfehler, meinte C++.


    ich habe jetzt erstmal guAlignF rausgeschmissen, jetzt scheint es ein wenig besser zu laufen. Bin grad nicht am PC, ich poste dann den vollen Code + Header.


    Compiler ist gcc, IDE ist Borland.
    Zielplattform ist der N64, welcher sowohl C als auch C++ versteht.




    Greets,

    Hallo Leute,


    hoffe das gehört hierher


    ich versuche eine Art OS für den N64 zu entwickeln. Eine fortschrittlichere IPL-ROM vom 64DD halt. Funktioniert auch sehr gut.


    Ich habe aber beim Anwenden einer Audiosequenzwiederholung in C+ ein Problem:


    Ich gehe ganz genau nach Plan vor, um eine MIDI-Sequenz in den N64-Buffercache zu laden, jedoch hängt er sich mitten in den Sequenzen auf und springt ins Errorlevel.
    Liegt es am Code?
    Hab hier den Code, vielleicht kann mir jemand helfen?


    Code im Anhang :D



    Greets,

    Sorry, hab übersehen das in dem Thread was gepostet wurde xD Ne, hab sogar 2. Im Diskmodus kann man zusätzliche Quests von Disk laden, ich versuch momentan das mit Reverse Enginiiering herauszufinden. Es sollte damit sogar möglich sein HiRES Texturen zu laden. Der Aufbau des DDs ist auch nicht sonderbar kompliziert - ein 242-er Chip und ein ZIP-Laufwerk. Ich wollte damit sagen, das der DD verlorenes Potenzial ist.



    Greets,

    Hallo :D


    Ihr habt sicher schon vom Nintendo 64 Disk Drive gehört - eine CD-Erweiterung für den 64 PAL Progressive.
    Ich habe oft gelesen, das der DD angeblich eine Enttäuschung wäre - für mich z.B nicht. Für mich ist er die beste jemals erschiene Erweiterung für eine Spielekonsole, zumal man Zelda Ura und die ZUSATZDISK zu MM nicht vergessen sollte (Beide nicht erschienen, bei Interesse kann ich aber Screenshots machen bei denen sich das Game im Disk-Modus befinden)
    Die Screenshots mache ich z.B mit dem unbekanntesten und genialsten Dumping-, Extension und Debuggingtool "Clausos Debug System". Man kann eigenen Code einfügen, dadurch müsste es möglich sein eigene Quests einzuprogrammieren z.B.


    Was ist eure Meinung zum DD oder zu den nie erschienenen Zeldaextensions oder zur Quest-Idee ^^? Top or Flop?


    Greets,

    Hallo Leute,


    ich hab vor kurzem mit dem Debugging von Majoras Mask mithilfe einer auf Ebay gekauften Debug-Cartridge begonnen. Die Cartridge wurde wenige Tage nach dem offiziellen Release von MM beschrieben, also gehe ich davon aus das die den Stand der Releaseversion hat. (Sieht nicht spektakulär aus, unbedruckte Cartridge halt). Jedenfalls treten dort einige ziemlich lustige Sachen auf, die ich in der Release-Version nie so gesehen habe :D
    Ich will hier (wenn ich darf, ansonsten löschen) die Funktionsweise der Cartridge beschreiben. (Bin übrigens ein Feind von Emulatoren & Roms)


    Man benötigt 4 Controller, einer muss ein Memory Pak enthalten, und ein Expansion Pak muss wie im Release vorhanden sein.


    Jeder der Controller erledigt unterschiedliche Debug-Modi, wie ihr sicher schon aus der anderen Debug-Version wissen werdet. Es gibt Gameshark-Codes, womit man z.B den Audio-Debugger aktivieren kann, man kann ihn aber auch durch gezielte Speichermanipulation aktivieren. Das Spiel erleidet dabei keine messbaren FPS-Einbrüche.


    Jetzt will ich auch mal auf einen Bug eingehen:
    -- Wenn man den Zeitfluss auf 1 setzt (Environment-Controller) und die Ballade des Kronos spielt, erhält man die Meldung "Nichts geschieht.." obwohl die Zeit normal weiterläuft. (Ich bin, so denke ich nach langem Googeln, der erste der diese Sache entdeckte).
    Grund ist das die Ballade einen Wert aktiviert der 2 enthalten muss, oder 3. Wenn sie diesen nicht erhält, kann sie die Verlangsamung nicht ausführen, der Hex-Wert wird nicht ausgelesen und dadurch kommt dann die Meldung.
    Bei Retail - Majoras Mask tritt dies nur auf wenn ein unerwarteter Fehler oder Unlesbarkeit auftritt.


    Solltet ihr Interesse haben gehe ich gern näher auf dieses Thema ein :)


    Greets,