Danke für den Tipp.
Ist aber wahrscheinlich nicht notwendig.
Ich werde nachladbare Basic-Teile einsetzen, so dass z.b. immer der jeweilige Raum gesondert als Basic-Teil geladen wird. So bleibt das Kernprogramm kleiner. Mal sehen, was MERGE und CHAIN MERGE so hergeben, ist halt schon ewig her, dass ich mich damit befasst habe.
Ich habe übrigens eben den Loader nochmal überarbeitet und eine Abfrage reingestellt, ob Ausgabe über Digiblaster oder CPC-Speaker.
Hm, also nur Platz bis #3000 ist echt sauwenig (12K). Hm, naja, wer weiß. Aber falls ich mal die Zeit finde, stell ich Dir das in Deinem Preview um, daß Du trotzdem mehr Platz hast für den Fall der Fälle.
Ist die CPC-Speaker Ausgabe jetzt auf Kanal B? Vorhin war die nur rechts, also CALL #3003,1 wäre besser.
Zur allgemeinen Info: Der Digiblaster wird übrigens im WinCPC emuliert.
CU,
Prodatron
Stimmt, hab es nun geändert. Lad es nochmal herunter.
Wäre Super wenn du was ändern könntest wegen BASIC, aber schon die Spriteroutinen fangen sehr früh an.... Naja da werd ich nochmal mit dem momentanen Coder Rücksprache halten. Die Sprites sollen ja auch noch komprimiert werden.
So nun habe ich nochmals die Sprite Routine anpassen können.
Ich habe eben den neuen Code dafür bekommen.
Die unterste Adresse liegt dabei bei &4000.
Das Mod werde ich selber noch anpassen.
Neues Preview hier:
Download DSK
Es sind 3 Screens inzwischen drin.
Testweise können die hin und her getauscht werden.
wie hast du jetzt das mittlere bild hineinbekommen, als sprite?
wie sieht die routine aus?
mfg
Zitat von "Octoate"Prodatron: Wie siehts eigentlich mit der CPU Zeit aus, wenn man die Musik ueber den Digiblaster ausgeben laesst? Frisst das genausoviel Zeit oder laesst sich damit was einsparen?
Digiausgabe auf dem CPC Old Generation frisst eigentlich immer 100% CPU-Zeit. Der Grund ist der, daß Du immer gleichmäßig die Samples mit dem Z80 rausblasen mußt. Zwischen jedem Byte bleibt so gut wie nix übrig, da kann man kaum was vernünftiges machen, außer z.B. Raster oder so (siehe ein WEEE! Part im Terrific Demo oder das Ultimate Megademo Intro).
Wenn Du CPU Zeit "klaust" während der Interrupts verschlechterst Du die Soundqualität, weil dadurch ein 50Hz bzw. 300Hz Brummen hineingelangt, gerade bei hohen Tönen fällt das mies auf.
Auch der Digiblaster hilft da grundsätzlich nicht, weil der auch eine regelmäßige Sampleausgabe erwartet. Was beim Digiblaster besser ist, daß die Ausgabe eines Bytes mit nur einem OUT geht, während man beim PSG mehrere machen muß (hab das nicht mehr genau im Kopf). Der Digiblaster erlaubt also höhere Frequenzen, aber sinnvoll nutzbare CPU-Zeit wird dadurch trotzdem nicht wirklich frei.
Anders ist das beim CPC Plus: Da dank DMA ein Buffer vorgefüllt werden kann, der dann vom DMA ausgegeben wird, ohne daß der Z80 das noch machen muß, hat man hier tatsächlich nutzbare CPU-Zeit frei. Daher waren z.B. die Osziloskope bei der WEEE!-DMA Demo möglich.
CU,
Prodatron
Zitat von "super_castle"wie hast du jetzt das mittlere bild hineinbekommen, als sprite?
Diese Routine habe ich Eliot zu verdanken.
Sie besteht (für mich) aus 2 Teilen.
Der eine Teil "schreibt" aus dem kompletten Bild das fenster auf Disk (Den Teil wird der Spieler später nicht benötigen)
Der andere Teil lässt mich per CALL das Sprite setzen.
Dabei ist die Grösse des Sprites und die Position schon von vornherein für dieses Spiel festgelegt.
Erste Schritte nun möglich in meinem neuen Preview!!!
Download DSK
Nun könnt Ihr mit dem Joystick die ersten paar Räume erkunden!!!
Viel Spass beim Anschauen!
Absolut GEIL! Großartig! Wahnsinn! Ich freue mich schon auf das Endprodukt 
Total geil!! Weiter so!
Und ich freu mich schon voll, das dann mit BDOS laufen zu haben, 0-Ladezeiten! 
Ich weiss ja nicht, ob das ne gute Idee ist, aber ich hab damals am Amiga mal ein Adventure geschrieben. Ich wollte auch zuerst jeden Raum als eigenes Programm schreiben - doch schon beim 2. Raum habe ich gemerkt, das das nahezu unmöglich ist. Es kommt auch viel Zeugs doppent und dreifach vor - z. B. kann man ja in jeden Raum sein Inventar betrachten (z. B. "Schaue an Eimer" -> "Ein verbeulter Eimer...").
Daraufhin habe ich mir ein eigenes Script-System geschrieben. Das Adventure selber hat sich zuerst 000.SCR geladen - da stand alles drin, was in jedem Raum erlaubt ist (z. B. eben Inventar anschauen). Der Rest war variabel. Durch einen selbstgestrickten Compiler konnte man dann mit der Maus Objekte in eine Location setzen, und diverse Befehle compilieren.
So bestand ein Room aus einer IFF-Datei (Hintergrund), Objekt-Shapes und einem Script. Die Engine war relativ simpel gehalten - man hatte 255 Bytes als Flags und ein Script sah in etwa so aus:
@define
defineobj nr,x,y,w,h,zielx,ziely,"name" ; Objekte im Raum definieren
.
.
.
setobj <statusnr> <wert> <obj.nr> ; Je nach Status diese Zeichnen
.
.
.
@Code
If "satzbau"
.
.
.
EndIf
@End
wie gesagt, relativ simpel. Der Compiler hat dann alles in Tokens übersetzt. Es gab Befehle für Samples, Textausgabe, Inventar/Verben ein-/ausschalten, Laufen der Figur, Script laden/ausführen usw.
Sicherlich ist das erstmal ein Aufwand, das zu schreiben, aber ich glaub, man spart letzendlich eine menge Platz (und Arbeit).
Ist jetzt keine Kritik - ich bin mir sicher, du packst das auch so - soll vielmehr eine Anregung sein.
hast du schon eine routine für die bildkomprimierung?
wenn du jetzt das bild in der mitte grösser machen würdest in der breite(4-8x) dann könnte doch noch eine routine rein zum bild scrollen nach rechts und nach links, das sähe so aus , als wenn man sich in den raum umschaut. ist doch eigentlich keine komplizierte bewegung für den cpc-screen, oder?
eine shaperoutine müßte es sein.
müsste doch machbar sein
Cool! Das sieht vielversprechend aus. Hoffe Du hältst durch bis zum Release!
Zitat von "Prodatron"Und ich freu mich schon voll, das dann mit BDOS laufen zu haben, 0-Ladezeiten!
Daran werde ich denken.
Die Disk-Operation wird so ausgelegt sein, dass auf jede Disk ein ASCII Zeichen geschrieben wird. (Das mache ich manuell)
Anschliessend lädt das Spiel vor einem CHAIN MERGE (Damit arbeite ich, weil ich das Spiel so in einzelne Abschnitte aufteilen kann) das ASCII Symbol zurück von Disk.
Ist es dann z.B. "A" weiss das Spiel, dass Disk A Seite 1 eingelegt wurde.
Ist es "B" weiss das Spiel, dass Disk A Seite 2 eingelegt ist... usw usw
So ist es natürlich auch möglich, ein ASCII Symbol auf HD zu schreiben und wenn das Spiel z.b. "Z" liest, weiss es halt, dass keine Disks gewechselt werden müssen und kann so weiterladen.
Im aktuellen Preview habe ich schon mit CHAIN MERGE die erste Szene geladen (001.BAS), das funktioniert also tadellos.
Für heut werd ich aber nicht mehr weiterfummeln... Zuviel ist auch net gut und mir raucht langsam der Kopf.
Aber ich finde, das was zu sehen ist, ist als BASIC-Programm eigentlich ansehnlich.
Schwierigkeiten wird es wohl geben, wenn es um SAVE - LOAD Routinen geht. Aber das wird wohl erst ganz zum Schluss eingebaut. (Wenn überhaupt realisierbar)
Zitat von "super_castle"Alles anzeigenhast du schon eine routine für die bildkomprimierung?
wenn du jetzt das bild in der mitte grösser machen würdest in der breite(4-8x) dann könnte doch noch eine routine rein zum bild scrollen nach rechts und nach links, das sähe so aus , als wenn man sich in den raum umschaut. ist doch eigentlich keine komplizierte bewegung für den cpc-screen, oder?
eine shaperoutine müßte es sein.
müsste doch machbar sein
Richtig, das ist möglich. Die Spriteroutine stellt dann das Sprite erst ab einem bestimmten Offset dar, zeigt nicht die volle Breite, und macht auch einen speziellen Line-Skip bei den Spritedaten. So funktioniert das auch beim Clipping in SymbOS, wenn Du einen Fensterinhalt halb verdeckt hast, das ist Speed-technisch nicht so wild.
CU,
Prodatron
Ausgerechnet heute hab ich den USB-Stick nicht dabei 
Sonst hätte ich das Preview mal auf Platte gehauen - die Animation im Verlies müsste dann ja ziemlich schnell ablaufen.
Ich kann die Bilder nicht breiter machen, weil ich sie vom Amiga konvertiere.
Das einzige, was gehen würde, wäre, wenn man 2 Bilder laden könnte, aber wie Eliot nun diese kleine Sprite Routine geschrieben hat weiss ich nicht.
Im Original-Spiel kommen auch keine Scroll-Effekte hinzu, ausser in der Sequenz, wo der Typ im Verlies hockt und dann scrollt das Bild nach rechts und die Silhouette von Elvira erscheint...
Aber ich bin schon ganz zufrieden so. Es soll ja schliesslich auch alles überschaubar bleiben (an die DSK-Anzahl denk)
Ausserdem weiss so auch ein Dummie wie ich, wie man es umsetzen kann...
Einziges Manko, was ich gern noch hätte, wäre, wenn man 4-5 Bilderchen in einen Buffer laden könnte, und dann als Animation abspielen könnte...
Wer sich da rantrauen würde, kann sich morgen gern mal bei mir melden.
Im Moment sieht es so aus, dass ich mit einem Programm einen normalen 16k Bildschirm lade und das Programm mir daraus das kleine Bild speichert.
Im Spiel kann ich es dann per LOAD"SCREEN1.WIN",&4000 laden
und mit CALL &A000 auf den Bildschirm rufen.
Wer also noch eine andere (auch für mich verständliche) Lösung weiss, sofort HIER rufen. Soviele Screens habe ich ja noch nicht gemacht.
Am simpelsten wären dabei RSX-Befehle...
Wichtig ist halt, dass die kleinen Bilder nicht erst grossartig erzeugt werden müssen, wenn der User das Spiel spielt... Sie müssen schon gespeichert auf der Disk liegen.
Mal sehen ob ihr Rat wisst...
Du willst das beibehalten, daß jedes Bild einzeln von Disc nachgeladen wird?
Naja, eigentlich nicht so tragisch, aber als Optimierung, da es für 128K ist, könnte man ja vielleicht eine ganze Menge Zeug preloaden pro Spielabschnitt, wenn die Pics dann auch noch komprimiert sind...
Ich weiss...
Habe Eliot schon per Email diesbezüglich befragt...
Mal schauen was dabei herauskommt.
Zumal so ja auch mal kleinere Animationen möglich wären.
Oder hast Du eine Ahnung, wie man soetwas coden könnte?
So nu aber Heiabettchen bin.... Gute Nacht Forum!!!
gibt es eine routine , um einzelne bilder aus einem gesamten screen herauszupicken und dann darzustellen. beim c64-vice lese ich zb daten in asm ein :
b_color:
!bin "test.bin",1000,9002
ein bildausschnitt hier : 1000 byte ab byte 9002 von dem screen.
wer kennt sich mit diskroutinen aus beim cpc in asm?
mfg
Zitat
....das ist Speed-technisch nicht so wild.
kannst du mal ein kleines beispiel zeigen?
für mich ist die shapedarstellung am cpc-screenaufbau sehr umständlich zu handhaben, eben durch diese sch... 8byte-scanns.
mfg
Ich habe mal herumexperimentiert und schnell ein neues Preview hochgeschoben.
Dieses Zip enthält nun 2 DSK.
Das Spiel erkennt nun, welche Disk eingelegt ist.
Zugekommen ist auch eine kleine Sprachausgabe 
Download ZIP
Dieses dient zur Veranschaulichung der kleinen Diskerkennungsroutine und der Sample-Ausgabe während des Spiels...
Nach Entfernung einiger kleiner BUGS hab ich nun ein neues Preview zusammengestellt.
Download ZIP
Damit ist der erste kleine Abschnitt spielbar.
Weitere Abschnitte folgen
Zitat von "Kangaroo MusiQue"Schick mir mal die Mods zu dem Spielchen
CPC-Mods oder original Amiga Mods?
Das CPC-Mod befindet sich auf Disk A Seite 1 und heist ELVIRA.MDL
Das Amiga MOD habe ich hier:
Download MOD
Rechtsklicken / Ziel Speichern unter...
EDIT:Alle Mods hier im ZIP:
Download ZIP
Nach etlichen Versuchen habe ich nun wieder ein neues Preview fertig.
- Es hat ein anderes Titelbild,
- Nach der Szene mit dem Kerker kann man nun durch die ersten 2 Räume gehen (und sich in alle 4 Richtungen jeweils drehen)
Durch CHAIN MERGE lade ich so nun jeden einzelnen Raum in das Game.
Dabei bleiben spätere Variablen, wie Stärke, Gesundheit, Inventar usw usw, erhalten.
Hier das neue ZIP:
Download ZIP
Viel Spass beim Anschauen!!!
Bauz, da bin ich echt erstaunt. Schaut super aus! Ich finds schon faszinierend, mit wie wenig (im Verhältnis) aufwand man sowas geiles auf die Beine stellen kann, und vor allem mit im Haupteil Basic.
Tolles ding was du da fabrizierst!
Wenn du so weiter machst, wird das Oberklasse
Das beste ist, ich versuche es so zu gestalten, dass der Mainpart immer derselbe ist, so kann man später an jeder X-Beliebigen Stelle das Spiel mit ESC abbrechen und mit RUN wieder starten... Im Preview seht Ihr schon, dass das Spiel die Disks erkennt.
Das habe ich geregelt, indem ich vorher auf jede Disk ein Ascii-Zeichen geschrieben habe
OPENOUT"DISK":PRINT #9,"a":CLOSEOUT
Für Disk A, Seite 1
OPENOUT"DISK":PRINT #9,"b":CLOSEOUT
Für Disk A, Seite 2
..... weitere Disks folgen
Mit OPENIN lese ich also immer bevor die Disk gewechselt werden muss den Wert ein, so dass das Spiel erkennt, welche Disk im Laufwerk liegt.
Unterbricht man z.B. das Spiel, und tippt RUN ein, dann fragt er sofort nach der ersten Diskette, Seite 1.
Hoffentlich kommt bald die Bilder-komprimierung. Daran wird schon gefeilt. Dann können die kleinen Ingame-Screens komprimiert gespeichert werden und auch mehrere in einen Buffer geladen werden. (4 sind eigentlich geplant, pro Raum).
Momentan liegt die Grösse der Ingame-Screens bei 8k pro Bild, was natürlich einen hurrenden Diskaufwand mit sich ziehen würde, aber ich bin mir sicher, dass bald die Komprimierung funktioniert.
Hallo zusammen,
wer kennt ein Programm, womit ich den Bildschirminhalt komprimiert abspeichern kann?
Das Problem was ich habe, ich hab 2 Screens mit 16k Grösse (Das Titelbild und das Hauptbild)
Ich stelle mir das so vor, dass die beiden Bilder auch noch komprimiert werden und dann z.B. mit
LOAD"MAIN.SCR",&4000:CALL &4000aufgerufen werden.
Dann darf aber nicht auf einen Tastendruck gewartet werden sondern nur der Bildschirm angezeigt werden.
Wisst Ihr, wie sowas geht? Und wer kann mir ein DSK schicken mit so einem Prog?
Grüssle, Markus
