C-Kurs, Abend 6 - Verbesserungsvorschläge


    • skoe
    • 27943 Aufrufe 83 Antworten

    Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

    • Wobei das ja nur ein Beispiel war. Was mich mal interessieren würde, wäre ein Test (evlt. mit timer), wie man bestimmte Programmstrukturen in C für den cc65 "formen" sollte. (siehe Beispiel mit Speicher kopieren, oder auch Zugriff auf structs, u. a.)

      ausser dem was so in der doku steht gibts da leider nicht viel das man so als allgemeingültigen tip geben kann... oft hängt das ergebnis sehr vom konkreten code ab. da hilft im zweifelsfall nur sich den generierten code anzusehen und mal ein paar denkbare varianten auszuprobieren.

      eine sache die glaube ich nicht im handbuch steht: lokale "unsigned char" variablen als "static" deklarieren (vorsicht, an der stelle nicht vergessen was der unterschied zwischen "auto" und "static" ist). das produziert dann oft besseren/kürzeren/schnelleren code als wenn die variablen auf dem softwarestack liegen. bei 16bit typen lohnt es sich meiner erfahrung nach dann schon nicht mehr selbiges zu tun.
    • ThomBraxton schrieb:

      Mich würde der Zugriff auf die C64-Ressourcen interessieren. Wie man Farben setzt und wie man mit Sprites umgeht. Falls das überhaupt möglich ist.

      Aber auch andere Grafikzugriffe (Linien, Boxen) oder Musik über C wäre doch toll....


      Musik mit dem CC65:

      frank-buss.de/c64/sid-test.html

      Ist nicht ganz so sauber wie das Beispiel von Skoe, wo z.B. "VIC.rasterline" verwendet wird, was in einer CC65 Header-Datei als entsprechende Struktur und Variable definiert ist, aber ist vielleicht für Anfänger gar nicht schlecht, da man nur C können muß, um den Code zu verstehen, und nichts von den CC65-Libraries und Includes zu kennen braucht.
      So Long, and Thanks for All the Fish!
    • Kennt jemand eine gute Dokumentation der Grafikfunktionen für den cc65-Compiler? Überhaupt würde mich ein gutes Handbuch zu diesem Compiler sehr interessieren. Bevorzugt in deutscher Sprache.
      Noch schöner wäre eine Weiterführung des Kurses. Aber das wurde ja schon öfter hier angesprochen.

      Liebe Grüße!
      ThomBraxton

      Nachtrag zum vorherigen Post: Ich war zu dem Zeitpunkt 46 Jahre alt. Wie konnte ich mich soooo verrechnen? Alzheimer lässt grüßen! :böse

      DoReCo #55 am Sa. 16.12.2017 :dafuer:
    • Es gibt die tgi-Library, siehe alles was mit "tgi_" anfängt in der Funktionreferenz: cc65.org/doc/funcref.html#toc3 und tgidemo.c im samples-Verzeichnis der cc65 Installation und zum Compiler generell findet man auch einiges in der Dokumentation. Ansonsten sind die anderen Beispiele auch nicht schlecht. In "nachtm.c" kann man z.B. neben der SID Tonerzeugung auch sehen, wie man im Textmodus Text ausgibt mit den cc65 Funktionen.

      Du brauchst aber wirklich nur C zu können, denn macht viel mehr Spaß den Rest dann selbst zu programmieren, mit Sprites, geändertem Charset, Rasterinterrupt, Scrolltext usw. :)
      So Long, and Thanks for All the Fish!
    • Du brauchst aber wirklich nur C zu können

      mmmh naja. grad bei cc65 stösst man relativ schnell an grenzen wo solide kenntnisse der architektur/assembler gefragt sind. was passiert wenn das nicht so ist kann man ja super an diesem trap them code sehen =P
    • Hi skoe,

      bin gerade auf den c kurs gestossen, ganz tolle sache!!

      sehr schade dass er aufhört gerade da wo es richtig spannend wird. würde mich tierisch freuen wenn es eine fortsetzung gäbe welche die weiteren bibliotheken des cc65 erklärt, insbes sprites, scrolling und musik!! falls es so etwas gibt

      auch wie man leveldaten, sprites und charsets von diksette nachlädt würde mich interessieren

      viele grüsse
    • marvin schrieb:

      Ich hätte auch Interesse :dafuer:
      Speziell am Thema, wie man Musik und Soundeffekte in einem cc65 C-Programm vernünftig einbauen kann. :)


      Kommt drauf an, wie du das meinst. Eigenen Player-Code in C würde ich lassen, deswegen:
      github.com/oliverschmidt/cc65/wiki/Interrupt-handlers-in-C

      Prinzipiell natürlich machbar, aber umständlich und nicht sehr performant. Allerdings kann man ja durchaus aus einer mit
      oliverschmidt.github.io/cc65/doc/funcref.html#set_irq
      installierten ISR direkt einen player anspringen, den man als binary an sein compilat linkt.
    • Meine im C-Code erzeugten Soundeffekte (mit "POKE") funktionieren wirklich nicht gut, sondern bremsen das Spiel.
      Daher würde mich mal interessieren, wie man in einem C-Projekt mit Assembler Soundeffekte vernünftig abspielen kann.

      Hintergrund: Assemblercode für einen player hatte ich mal testweise im C-Programm eingebaut, aber Töne konnte ich ihm nicht entlocken.
      Daher vermute ich, dass einige grundlegenden Tipps zur Handhabung von Musik und Soundeffekten in einem cc65 C-Projekt hilfreich wären ;)
      DON'T PANIC
    • marvin schrieb:

      Meine im C-Code erzeugten Soundeffekte (mit "POKE") funktionieren wirklich nicht gut, sondern bremsen das Spiel.
      Daher würde mich mal interessieren, wie man in einem C-Projekt mit Assembler Soundeffekte vernünftig abspielen kann.

      Das sollte aber nicht sein, denn ein paar "poke"s brauchen ja kaum Rechenzeit. Hast du auch alles per Rasterzeileninterrupt synchronisiert?

      marvin schrieb:


      Hintergrund: Assemblercode für einen player hatte ich mal testweise im C-Programm eingebaut, aber Töne konnte ich ihm nicht entlocken.
      Daher vermute ich, dass einige grundlegenden Tipps zur Handhabung von Musik und Soundeffekten in einem cc65 C-Projekt hilfreich wären ;)

      Müsste im Prinzip genauso wie bei einem typischen Assembler-Spiel funktionieren: Alles per Rasterzeileninterrupt synchronisieren, dann pro Interrupt Noten abspielen, also nächste Note aus einer Tabelle, Anzahl Rasterinterrupts Wartezeit in Zähler, aus Tabellen neue Wert auslesen usw.
      So Long, and Thanks for All the Fish!
    • gartenzwerg schrieb:

      Das sollte aber nicht sein, denn ein paar "poke"s brauchen ja kaum Rechenzeit. Hast du auch alles per Rasterzeileninterrupt synchronisiert?

      Du hast natürlich recht, die POKEs an sich sind schnell.
      Mein Problem kommt daher, dass ich nicht am Rasterzeileninterrupt synchronisiere(n kann) aber ein Soundeffekt einige Zeit laufen soll (z.B. 1 Sekunde).
      Ohne Interrupt oder Synchonisation am selbigen entspricht mein C-Sound also effektiv einer Schleife, auf die der Rest erstmal warten muss. Ein eher bescheidener Ansatz, den ich gerne optimieren würde :)

      gartenzwerg schrieb:

      Müsste im Prinzip genauso wie bei einem typischen Assembler-Spiel funktionieren: Alles per Rasterzeileninterrupt synchronisieren, dann pro Interrupt Noten abspielen, also nächste Note aus einer Tabelle, Anzahl Rasterinterrupts Wartezeit in Zähler, aus Tabellen neue Wert auslesen usw.

      Prinzipiell hat der eingebaute Player das so machen sollen, aber ich habs im C-Projekt nicht hinbekommen.
      Informationen zum Player habe ich von hier.
      Einige Gründe, die ich seinerzeit im Verdacht hatte:
      - mein SID-Wissens beruht auf C64-Anleitung und 1541-Demodisk :D
      - möglicherweise falscher Goattracker, oder falsches Exportformat
      - Einbindung / Speicherplatzzordnung der Musikdaten im cc65 Projekt ist falsch

      Ich spreche mich immer noch gerne für einen Kurs zur multimedialen C-Programmierung aus, wie von Bombjack vorgeschlagen :thumbsup:
      DON'T PANIC
    • Also ohne Rasterzeileninterrupt wirst du keine guten Spiele programmieren können. Für den Soundeffekt brauchst du auch nicht eine Sekunde lang zu warten. Einfach den Soundeffekt starten, Zähler setzen, im Rasterzeileninterrupt Zähler dekrementieren bis er auf 0 ist (pro Interrupt) und dann den Sound wieder stoppen. Ich sehe da kein Problem.

      Die C64-Anleitung ist gar nicht so schlecht, solltest du damit hinbekommen können. Wenn du schon ein wenig damit experimentiert hast und Töne erzeugen kannst, dann ist das hier als Referenz gut: c64-wiki.de/index.php/SID
      So Long, and Thanks for All the Fish!
    • Danke sehr.
      Das getimerte Abschalten werde ich mal versuchen, für einfache "POKE"-Sounds wie diesen:

      Quellcode

      1. SID.amp = 0x0F;
      2. SID.v1.freq = 0x6000;
      3. SID.v1.ad = 0x14;
      4. SID.v1.sr = 0x4a;
      5. SID.flt_freq = 0xA000;
      6. SID.flt_ctrl = 0x44;
      7. SID.v1.ctrl = 0x81;
      8. // Ausschalten in aufrufendem Programmteil
      9. //SID.v1.ctrl = 0x80;


      Aber "kompliziertere" Effekte müssten wohl anders als in meinem C-Code erledigt werden, da hier nicht nur einfach ein- und ausschalten wird:
      (delay() ist eine eigene Verzögerungsschleife)

      Quellcode

      1. SID.amp = 0x0F;
      2. SID.v1.freq = 0x8000;
      3. SID.v1.ad = 0x17;
      4. SID.v1.sr = 0xf2;
      5. SID.v1.ctrl = 0x41;
      6. SID.v1.ctrl = 0x40;
      7. for(i = 0; i < 10; i++) {
      8. if( i%2 == 0 ) {
      9. SID.flt_freq = 0xA000;
      10. SID.flt_ctrl = 0x44;
      11. }
      12. else {
      13. SID.flt_freq = 0x4000;
      14. SID.flt_ctrl = 0xf1;
      15. }
      16. SID.v1.ctrl = 0x41;
      17. delay(1);
      18. SID.v1.ctrl = 0x40;
      19. }
      Alles anzeigen


      @Admins: Entschuldigt bitte, dass ich den C-Kurs kapere. Bitte -wenn sinnvoll- in neues Thema trennen :anonym
      DON'T PANIC
    • spider-j schrieb:

      Also in C wird das so nix. Eher so: C für die Spielelogik, Assembler für das, was Du oben "multimedial" getauft hast ;)
      Zoo Mania ist ein gutes Beispiel (cc65/ca65 Sources sind im ZIP dabei).

      Kommt drauf an, was man programmieren will. Klar, sowas wie die Vektorgrafik von Elite wird man nicht in reinem C machen können, oder anderes sehr zeitkritisches wie Rasterfarbbalken, aber z.B. so ein Spiel wie Ghostbusters, Pac Man usw. könnte man bestimmt komplett in C programmieren.

      @marvin: wie lange verzögert "delay"? Auch schnelle Tremolos o.ä. sind meist nicht schneller, als daß man die nicht in die 50 Hz Rasterzeit einbauen könnte.
      So Long, and Thanks for All the Fish!
    • Das Spiel selbst wird am Ende vermutlich einigermassen ordentlich laufen (Onescreener, Pseudo 3D Pong), da man in C (maschinennah denkend) auch ganz gut optimieren, bzw. lahme Teile direkt in Assembler erstellen kann.
      Komplett in MC wäre natürlich optimal, aber da ich C deutlich besser lesen kann, hoffe ich das Spiel nach ettlichen Jahren endlich mal zum Abschluss zu bringen.

      Die Musik und den Sound will ich aber auf alle Fälle in Assembler machen. Ich kriegs bisher einfach nur nicht hin, einen Assembler Player, Musikdaten und meinen C-Code in cc65 zu kombinieren ;)

      delay() verzögert einen unbekannten Bruchteil einer Sekunde, ich habs nie exakt nachgemessen :whistling:

      Quellcode

      1. void delay (u8 t) {
      2. // delay by certain part of second
      3. u8 i, j;
      4. for( i = 0; i <= t; i++ ) {
      5. for( j = 0; j <= 200; j++ ) {
      6. }}
      7. return;
      8. }


      Vielen Dank für den Tipp mit Zoo Mania, das schaue ich mir mal an :thumbup:

      Ansonsten warte ich auch gerne auf weitere Teile des Sound-Workshops in zukünftigen RETURN Ausgaben ... :)
      DON'T PANIC