![Smile :-)](./images/smilies/icon_e_smile.gif)
Eigenes Videoformat
Re: Eigenes Videoformat
Mich interessiert das durchaus - ich schaue mal, ob ich den Player unter BDOS/286 zum Laufen bekomme ![Smile :-)](./images/smilies/icon_e_smile.gif)
![Smile :-)](./images/smilies/icon_e_smile.gif)
Re: Eigenes Videoformat
Hier die "elegantere" Routine mit Tabellenzugriff. Müsste man testen, was tatsächlich schneller ist.
Wie gesagt, Brueggi, ist der bisher hier hochgeladene Player noch sehr langsam. Dass ich gerade die Kern-Assembler-
Routinen neu schreibe ändert das eher geringfügiger, weil das Handling der Daten zu Testzwecken noch umständlich
ist - erst Quelldaten in Puffer kopieren, aus dem Puffer wieder in einen Puffer decodieren, und dann erst diesen
Puffer in den Bildschirmpuffer kopieren. Das optimiere ich aber erst raus, wenn ich die Bit-Decodier-Routinen
1-5 fertig habe, sonst verzettel ich mich noch und habe es schwerer bei der Fehlersuche.
Code: Alles auswählen
procedure decode_bitstream_asm_3_table; assembler;
asm
push ds
les di, outblkbuf_pointer
lds si, bitdata_pointer
lea bx, [si+40] { Anfangsposition der Paletten-Tabelle -> BX }
mov ah, 7 { Maske für 3 Bit }
mov ch, 8
@outerloop:
mov dx, ds:[si+1] { untere 3 Byte (24 Bit) von EDX... }
db 66h; shl dx, 8 { ... }
mov dl, ds:[si] { ... mit Daten für 8 Pixel (= 1 Zeile) beladen }
add si, 3
mov cl, 8
@loop:
mov al, dl { Bitdaten einkopieren }
and al, ah { nur unterste 3 Bits }
xlat { Farbwert aus der Palette holen }
stosb
db 66h; shr dx, 3 { EDX 3 Bits weiter schieben }
dec cl
jnz @loop
dec ch
jnz @outerloop
pop ds
end;
Routinen neu schreibe ändert das eher geringfügiger, weil das Handling der Daten zu Testzwecken noch umständlich
ist - erst Quelldaten in Puffer kopieren, aus dem Puffer wieder in einen Puffer decodieren, und dann erst diesen
Puffer in den Bildschirmpuffer kopieren. Das optimiere ich aber erst raus, wenn ich die Bit-Decodier-Routinen
1-5 fertig habe, sonst verzettel ich mich noch und habe es schwerer bei der Fehlersuche.
mov ax, 13h
int 10h
while vorne_frei do vor;
int 10h
while vorne_frei do vor;
Re: Eigenes Videoformat
Hier aber schonmal eine Version mit den bisherigen drei Kern-ASM-Routinen,
(habe da mal die 8-Farben-in-Registern-halten Version genommen bei 3 Bit)
wenn auch weiterhin mit unnötig viel Speicherschieberei:
http://www.zatzen.net/zvdemo_2.zip
Die dürfte allerdings erst ab 386er funktionieren!
(habe da mal die 8-Farben-in-Registern-halten Version genommen bei 3 Bit)
wenn auch weiterhin mit unnötig viel Speicherschieberei:
http://www.zatzen.net/zvdemo_2.zip
Die dürfte allerdings erst ab 386er funktionieren!
mov ax, 13h
int 10h
while vorne_frei do vor;
int 10h
while vorne_frei do vor;
Re: Eigenes Videoformat
Sorry, das mit dem Soundblaster-Demo-FLI's zu ZVD machen geht leider nicht so ohne Weiteres,
weil die FLI's Palettenrotation oder individuelle Paletten verwenden, wodurch sich insgesamt > 256
Farben ergeben! Aber halt, ich kann die ja einfach alle einzeln konvertieren... Moment...
...nee also es gibt insgesamt unterm Strich eine Verkleinerung, aber weil die FLI's eben viel
mit Paletteneffekten arbeiten werden die ZVD's teilweise ziemlich aufgebläht.
Man könnte zwar die FLI's "nativ" konvertieren und die Palettenänderungen mitspeichern,
aber das ist eigentlich nicht der angedachte Zweck von ZVID.
Palettenrotationen und dergleichen soll der Programmierer in seiner Anwendung lieber
selber bewerkstelligen und aus den ZVD's nur die zugrundeliegenden Grafikdaten beziehen.
Da gibt es ein FLI namens "Flakes", nur kleine Pixelpunkte dünn über den Bildschirm verteilt,
da hat FLI momentan noch die Nase vorn gegenüber ZVD, aber das ändert sich, wenn ich
in ZVD den Blocktyp "einzelne Pixel" einbaue, der bei <= nur 8 Pixeln diese nur einzeln
definiert abspeichert und der ganze Block somit je nachdem mit 3-10 Byte abgehandelt ist.
weil die FLI's Palettenrotation oder individuelle Paletten verwenden, wodurch sich insgesamt > 256
Farben ergeben! Aber halt, ich kann die ja einfach alle einzeln konvertieren... Moment...
...nee also es gibt insgesamt unterm Strich eine Verkleinerung, aber weil die FLI's eben viel
mit Paletteneffekten arbeiten werden die ZVD's teilweise ziemlich aufgebläht.
Man könnte zwar die FLI's "nativ" konvertieren und die Palettenänderungen mitspeichern,
aber das ist eigentlich nicht der angedachte Zweck von ZVID.
Palettenrotationen und dergleichen soll der Programmierer in seiner Anwendung lieber
selber bewerkstelligen und aus den ZVD's nur die zugrundeliegenden Grafikdaten beziehen.
Da gibt es ein FLI namens "Flakes", nur kleine Pixelpunkte dünn über den Bildschirm verteilt,
da hat FLI momentan noch die Nase vorn gegenüber ZVD, aber das ändert sich, wenn ich
in ZVD den Blocktyp "einzelne Pixel" einbaue, der bei <= nur 8 Pixeln diese nur einzeln
definiert abspeichert und der ganze Block somit je nachdem mit 3-10 Byte abgehandelt ist.
mov ax, 13h
int 10h
while vorne_frei do vor;
int 10h
while vorne_frei do vor;
Re: Eigenes Videoformat
Hier noch eine neue Version der 2-Bit-Routine. Die alte war doch etwas umständlich.
Beim Geschwindkeitsvergleich der beiden 3-Bit-Routinen hat übrigens die Variante
mit XLAT, also dem Farbindex-Lesen aus dem Speicher, gewonnen.
Für die 2-Bit-Routine werde ich auch noch eine XLAT-Version machen und die beiden vergleichen.
Oh und mir ist noch etwas aufgefallen bei der 3-Bit-Routine:
anstatt:
einfach:
Ist weniger Geschreibsel und dürfte sogar schneller gehen...
Sorry wenn ich hier so viel Code poste, aber Assembler macht eben einfach Spass!
Beim Geschwindkeitsvergleich der beiden 3-Bit-Routinen hat übrigens die Variante
mit XLAT, also dem Farbindex-Lesen aus dem Speicher, gewonnen.
Für die 2-Bit-Routine werde ich auch noch eine XLAT-Version machen und die beiden vergleichen.
Code: Alles auswählen
procedure decode_bitstream_asm_2; assembler;
asm
push ds
les di, outblkbuf_pointer
lds si, bitdata_pointer
mov bx, ds:[si+40] { Farben 0-1 in BX }
mov dx, ds:[si+42] { Farben 2-3 in DX }
mov cl, 8
@outerloop:
lodsw { eine zeile Bitdaten laden }
mov ch, 8
@loop:
shr ax, 1
jnc @lowbit0
shr ax, 1
jnc @bh
mov es:[di], dh
jmp @done
@bh:
mov es:[di], bh
jmp @done
@lowbit0:
shr ax, 1
jnc @bl
mov es:[di], dl
jmp @done
@bl:
mov es:[di], bl
@done:
inc di
dec ch
jnz @loop
dec cl
jnz @outerloop
pop ds
end;
Oh und mir ist noch etwas aufgefallen bei der 3-Bit-Routine:
anstatt:
Code: Alles auswählen
mov dx, ds:[si+1] { untere 3 Byte (24 Bit) von EDX... }
db 66h; shl dx, 8 { ... }
mov dl, ds:[si] { ... mit Daten für 8 Pixel (= 1 Zeile) beladen }
add si, 3
Code: Alles auswählen
db 66h; mov dx, ds:[si] { EDX mit Daten für 8 Pixel beladen }
add si, 3 { einfach 4 Byte auch wenn nur 3 benötigt werden }
Sorry wenn ich hier so viel Code poste, aber Assembler macht eben einfach Spass!
mov ax, 13h
int 10h
while vorne_frei do vor;
int 10h
while vorne_frei do vor;
Re: Eigenes Videoformat
Ich hab mal die ZVDEMO.EXE mit den mitgelieferten Demos getestet.
Schon sehr beeindruckend das Ganze. Auch die Geschwindigkeit ist in Ordnung.
Wie erhält der Encoder die Daten? Ich nehme an, die Frames als numerierte Bilder?
Schon sehr beeindruckend das Ganze. Auch die Geschwindigkeit ist in Ordnung.
Wie erhält der Encoder die Daten? Ich nehme an, die Frames als numerierte Bilder?
Re: Eigenes Videoformat
Das ist schonmal sehr gut dass sogar die Version mit noch nicht optimalen Bitroutinen und zweifach unnötiger
Speicherkopiererei schnell läuft. Dann könnte es sein, dass man hinterher doch die komplette Grafik für ein Spiel
in dem Format halten kann.
Clipping übrigens erscheint mir ersteinmal zu komplex um es Pixelgenau zu machen, ich denke vorerst mache ich
das auf Blöcke gerastert, dann müsste man einen Bildausschnitt mit Rahmen gestalten anstatt Vollbild.
Für den Encoder wird eine .CFG erstellt, dort drin ist alles definiert, der .ZVD-Name, Anzahl der Frames,
und dann Anzahl Frames mal je vier Zeilen: Grafikdateiname, X-Dimension, Y-Dimension (jeweils Blockeinheiten),
transparente Farbe (0-255, ' - ' für nicht transparent). X-Dimension, Y-Dimension werde ich noch zu
x1-x2, y1-y2 ändern, so dass man aus einem Bild mehrere kleinere Bereiche als Frame definieren kann.
Das ist encoderseitig wirklich so ein Fall, wo sich moderne, leistungsfähige Computersysteme bezahlt machen,
zumindest wenn es um Videos geht und nicht um nur Sprites. Das Problem, den Encoder auf den Realmode
zu portieren besteht u.a. eben darin, dass zum Zweck der Frame-übergreifenden Redundanzkürzung der Blöcke alle
vorkommenden Blöcke der Grafik, also bei Vollbild-Video 1000 (=64000 Byte) * Frameanzahl, im Speicher gehalten
werden müssen.
Speicherkopiererei schnell läuft. Dann könnte es sein, dass man hinterher doch die komplette Grafik für ein Spiel
in dem Format halten kann.
Clipping übrigens erscheint mir ersteinmal zu komplex um es Pixelgenau zu machen, ich denke vorerst mache ich
das auf Blöcke gerastert, dann müsste man einen Bildausschnitt mit Rahmen gestalten anstatt Vollbild.
Für den Encoder wird eine .CFG erstellt, dort drin ist alles definiert, der .ZVD-Name, Anzahl der Frames,
und dann Anzahl Frames mal je vier Zeilen: Grafikdateiname, X-Dimension, Y-Dimension (jeweils Blockeinheiten),
transparente Farbe (0-255, ' - ' für nicht transparent). X-Dimension, Y-Dimension werde ich noch zu
x1-x2, y1-y2 ändern, so dass man aus einem Bild mehrere kleinere Bereiche als Frame definieren kann.
Das ist encoderseitig wirklich so ein Fall, wo sich moderne, leistungsfähige Computersysteme bezahlt machen,
zumindest wenn es um Videos geht und nicht um nur Sprites. Das Problem, den Encoder auf den Realmode
zu portieren besteht u.a. eben darin, dass zum Zweck der Frame-übergreifenden Redundanzkürzung der Blöcke alle
vorkommenden Blöcke der Grafik, also bei Vollbild-Video 1000 (=64000 Byte) * Frameanzahl, im Speicher gehalten
werden müssen.
mov ax, 13h
int 10h
while vorne_frei do vor;
int 10h
while vorne_frei do vor;
Re: Eigenes Videoformat
Ich habe mir mal zvdemo gesagt und alle Animationen angeguckt. Super! Das ist _genau_ das, was ich mir immer gewünscht habe.zatzen hat geschrieben:So, nun habe ich endlich etwas zum Zeigen.
Erste ZVID Version (meinetwegen beta alpha oder sonstwas) ist fertig !
Das sind ein paar Videos, von Spielen, und von ein paar FLI's zum Größenvergleich, ich kündigte ja an,
dass die Komprimierung effektiver sein würde als FLI.
[...]
Hier der Link:
http://www.zatzen.net/zvdemo.zip (1,25 MB)
Hier mal der Größenvergleich FLI - ZVD:
SKELLY -- FLI: 151K ZVD: 61K
[...]
Test PC war ein lahmer 486sx-25 Mhz mit ET4000: Er hat alle Animationen flüssig abgespielt. Dein Player - und das war ja noch nicht die mit den ASM-Routinen optimierte Version, oder? - ist auf meinem Test-PC schon jetzt schneller als mein eigens mit BASM geschriebener FLI-PLayer (der die FLIs auch noch ins RAM laden musste, weil von HD direkt abgespielt viel zu langsam war).
Auf jeden Fall gibt es keinen schlimmen Ruckler. Schaffst Du die ganzen Animationen ins RAM, oder spielst Du sie von HD ab?
Dein Format gefällt mir übrigens auch optisch sehr viel besser als Fli: dadurch, dass Du die Farben etwas reduzieren musst, kommt der Charakter der Bewegungen etwas mehr zum Tragen - ich mag das lieber als die vielen Color-Cycling-Orgien in Fli.
Re: Eigenes Videoformat
Hallo wobo!
Genau, die Version zvdemo.exe hat zwar schon Assembler-Routinen, allerdings für
das Decodieren der Bitweise gespeichteren Blöcke eine allgemeine Routine, die
mehr einliest als es spezialisiert nötig wäre, und mehr Verwaltungsvariablen
unterhält als nötig.
Ebenso verbrät das Speichern der codierten Daten in einen Puffer zum Decodieren Zeit,
dann wird das decodiert, und dann in den Bildschirmpuffer kopiert. Das wird
letztlich auch ohne diese Umwege gehen. Sprungtabelle zum Routinenaufruf
fehlt auch noch, im Moment werden noch ein Haufen IF-Abfragen pro Block durchlaufen.
Möglicherweise ist der ZVD-Player schneller, weil er transparente Bereiche,
wenn sie denn einen kompletten Block einnehmen, einfach komplett überspringt.
Die Demo läuft aber auch nur auf 18.2 fps.
Nein, der Player spielt nicht von HD ab, also alles im RAM. Das liegt ja am Format, es werden
redundante, d.h. mehr als einmal vorkommende, gleiche Blöcke, gesammelt und gesondert
gespeichert, ebenso die Farbinformationen zusammengefasst in einem Datenbereich. Auf diese
Daten muss man dann während des Videos "random access" haben, denkbar wäre da nur,
dass man diese beiden Datenfelder im RAM hält und die Frames vom Datenträger lädt.
Aber ZVID ist nur nebenbei für Videos ausgelegt, eigentlich soll es für allgemeine Grafik
und speziell für Sprites, also Animationen sein, damit man guten Gewissens einfach
Grafiken pixeln kann und sich sicher sein kann dass diese nur so viel Platz im Speicher
verbrauchen wie auch wirklich nötig. Das könnte "psychologisch" als Befreiung wirken,
weil man weder den Drang hat, die 256 Farben in jedem Sprite irgendwie ausnutzen
zu müssen - man kann also auch einfach nur 4 Farben in einem Bereich des Sprites
nutzen weil es dann auch nur mit 2 Bit gespeichert wird - und andererseits hat man
aber jederzeit die Möglichkeit, die vollen 256 Farben auszunutzen, und dennoch
wird es kompakt gespeichtert, da selbst bei einer komplexen farbenfrohen Grafik
in einem 8x8 Block im Schnitt eher nur 16 verschiedene Farben vorkommen.
Ebenso muss man nicht mehr per Hand z.B. bei einem Sprite das nur den Kopf
bewegt soetwas in zwei geteilten Sprites realisieren, weil das System ja redundante
Blöcke erstellt. Auch das Spiegeln soll automatisch werden, da mag es dann
aber Geschmackssache sein ob man lieber "bewusst" im Programm angibt
dass es gespiegelt werden soll, oder aber alle gespiegelten Versionen der
Sprites komplett abspeichert, die dann aber nur ein paar dutzend Bytes
belegen. Wenn man ein bisschen mehr Details in seine Grafiken bringen will,
so dass z.B. eine Sprite-Figur von der einen Seite anders aussehen soll
als von der anderen, meinetwegen links einen Ohrring oder so, dann
würde das Sinn machen.
Die konvertierten Videos in der Demo sind allerdings alle 1:1, d.h. mit genauso viel
Farben wie die Originale. Es ist nur so, dass einige FLIs einfach nicht konvertiert
werden konnten, weil sich mehr als 256 Farben unterm Strich ergeben haben.
Genau, die Version zvdemo.exe hat zwar schon Assembler-Routinen, allerdings für
das Decodieren der Bitweise gespeichteren Blöcke eine allgemeine Routine, die
mehr einliest als es spezialisiert nötig wäre, und mehr Verwaltungsvariablen
unterhält als nötig.
Ebenso verbrät das Speichern der codierten Daten in einen Puffer zum Decodieren Zeit,
dann wird das decodiert, und dann in den Bildschirmpuffer kopiert. Das wird
letztlich auch ohne diese Umwege gehen. Sprungtabelle zum Routinenaufruf
fehlt auch noch, im Moment werden noch ein Haufen IF-Abfragen pro Block durchlaufen.
Möglicherweise ist der ZVD-Player schneller, weil er transparente Bereiche,
wenn sie denn einen kompletten Block einnehmen, einfach komplett überspringt.
Die Demo läuft aber auch nur auf 18.2 fps.
Nein, der Player spielt nicht von HD ab, also alles im RAM. Das liegt ja am Format, es werden
redundante, d.h. mehr als einmal vorkommende, gleiche Blöcke, gesammelt und gesondert
gespeichert, ebenso die Farbinformationen zusammengefasst in einem Datenbereich. Auf diese
Daten muss man dann während des Videos "random access" haben, denkbar wäre da nur,
dass man diese beiden Datenfelder im RAM hält und die Frames vom Datenträger lädt.
Aber ZVID ist nur nebenbei für Videos ausgelegt, eigentlich soll es für allgemeine Grafik
und speziell für Sprites, also Animationen sein, damit man guten Gewissens einfach
Grafiken pixeln kann und sich sicher sein kann dass diese nur so viel Platz im Speicher
verbrauchen wie auch wirklich nötig. Das könnte "psychologisch" als Befreiung wirken,
weil man weder den Drang hat, die 256 Farben in jedem Sprite irgendwie ausnutzen
zu müssen - man kann also auch einfach nur 4 Farben in einem Bereich des Sprites
nutzen weil es dann auch nur mit 2 Bit gespeichert wird - und andererseits hat man
aber jederzeit die Möglichkeit, die vollen 256 Farben auszunutzen, und dennoch
wird es kompakt gespeichtert, da selbst bei einer komplexen farbenfrohen Grafik
in einem 8x8 Block im Schnitt eher nur 16 verschiedene Farben vorkommen.
Ebenso muss man nicht mehr per Hand z.B. bei einem Sprite das nur den Kopf
bewegt soetwas in zwei geteilten Sprites realisieren, weil das System ja redundante
Blöcke erstellt. Auch das Spiegeln soll automatisch werden, da mag es dann
aber Geschmackssache sein ob man lieber "bewusst" im Programm angibt
dass es gespiegelt werden soll, oder aber alle gespiegelten Versionen der
Sprites komplett abspeichert, die dann aber nur ein paar dutzend Bytes
belegen. Wenn man ein bisschen mehr Details in seine Grafiken bringen will,
so dass z.B. eine Sprite-Figur von der einen Seite anders aussehen soll
als von der anderen, meinetwegen links einen Ohrring oder so, dann
würde das Sinn machen.
Die konvertierten Videos in der Demo sind allerdings alle 1:1, d.h. mit genauso viel
Farben wie die Originale. Es ist nur so, dass einige FLIs einfach nicht konvertiert
werden konnten, weil sich mehr als 256 Farben unterm Strich ergeben haben.
mov ax, 13h
int 10h
while vorne_frei do vor;
int 10h
while vorne_frei do vor;
Re: Eigenes Videoformat
Naja, wenn es für Sprites und Spiele gedacht ist - kommt es natürlich darauf an, was man damit machen will.
Bei Adventures könnte ich mir so etwas EVENTUELL vorstellen.
Aber bei interaktiven Spielen (Jump'n'run, Scrollshooter, etc) wohl eher nicht. Grund ist, daß man ja da keine Frames vorberechnen kann, da man ja nicht weiß, was der Spieler alles tut.
Obwohl ich bei Adventures ja dann wohl auch eher so etwas wie meine Spriteroutinen einsetzen würde - Spiegeln und Größenskalieren eingebaut - so daß z.B. abhängig davon, wo die Figur steht ("hinten" oder "vorn" usw...) ihre sichtbare Größe sich ändert (eine unsichtbare Größen-Blockmap "hinter" das Bild gelegt, damit a) klar ist, was ab welcher Entfernung "verdeckt" (so daß die Figur HINTER einem Pfosten entlang gehen kann) und b) damit je nach Standpunkt die Figur größer oder kleiner erscheint...
Egal... Ich weiß auch nicht, welche Art Spiel Du im Sinn hat, zatzen - aber Dein Videoformat performt schonmal ziemlich gut.
Bei Adventures könnte ich mir so etwas EVENTUELL vorstellen.
Aber bei interaktiven Spielen (Jump'n'run, Scrollshooter, etc) wohl eher nicht. Grund ist, daß man ja da keine Frames vorberechnen kann, da man ja nicht weiß, was der Spieler alles tut.
Obwohl ich bei Adventures ja dann wohl auch eher so etwas wie meine Spriteroutinen einsetzen würde - Spiegeln und Größenskalieren eingebaut - so daß z.B. abhängig davon, wo die Figur steht ("hinten" oder "vorn" usw...) ihre sichtbare Größe sich ändert (eine unsichtbare Größen-Blockmap "hinter" das Bild gelegt, damit a) klar ist, was ab welcher Entfernung "verdeckt" (so daß die Figur HINTER einem Pfosten entlang gehen kann) und b) damit je nach Standpunkt die Figur größer oder kleiner erscheint...
Egal... Ich weiß auch nicht, welche Art Spiel Du im Sinn hat, zatzen - aber Dein Videoformat performt schonmal ziemlich gut.
Re: Eigenes Videoformat
Ich glaube, du hast das ein bisschen falsch verstanden. Mit einem Frame ist einfach nur ein Bild,
oder eben ein Sprite-Bild gemeint, die würden in einem ZVD eben nur in einer Datei gruppiert werden,
so wie man für eine Sprite-Animation in unkomprimiertem Format wohl ein Array machen würde.
Dann geht es wirklich nur noch um die Geschwindigkeit.
Man kann mit der derzeitigen ZVID-Unit bis zu 256 ZVD's gleichzeitig in den RAM laden, ich
glaube das genügt vorerst. Wenn denn überhaupt so viel Grafikmaterial reinpasst, kommt immer
drauf an wie komplex und groß die Bilder sind.
Oder ich verstehe auch nicht ganz was du jetzt meinst, denn ein Spiel was nur aus Video-Vollbildern
besteht ist ja fast überhaupt nicht zu realisieren.
Natürlich ist das Skalieren auch eine sehr gute Sache. Ich hatte allerdings Spielideen im Sinn, wo
soetwas nicht gebraucht wird. Auch das Verdecken der Spielfigur, da dachte ich auch nur an eine
Ebene für dahinter.
Mein ganzes Format ist im Grunde sinnlos sobald man bereit ist, mehrere MB XMS oder irgendwas
zu benutzen. Aber irgendwie ist es für mich reizvoll, in echtem Realmode mit nur 640K virtuell
so viel Grafik unterzubringen, als würde man ein paar MB XMS nutzen. Ist eine Sache der Daten-
Ästhetik, keine Bits und Bytes sollen redundant verschwendet werden.
So eine "saubere Architektur" motiviert mich erst vollständig, ein Spiel oder irgendeine
multimediale Anwendung zu basteln. Den Usern/Gamern wird es egal sein was technisch
dahintersteckt, aber mir nicht.
Vielleicht kommt das auch noch aus der Zeit anfang der 90er, als ich mich öfters mit
Spielen rumärgerte, die wegen hohem Speicherbedarf eine Bootdiskette brauchten oder
ähnliche Extrawürste.
oder eben ein Sprite-Bild gemeint, die würden in einem ZVD eben nur in einer Datei gruppiert werden,
so wie man für eine Sprite-Animation in unkomprimiertem Format wohl ein Array machen würde.
Dann geht es wirklich nur noch um die Geschwindigkeit.
Man kann mit der derzeitigen ZVID-Unit bis zu 256 ZVD's gleichzeitig in den RAM laden, ich
glaube das genügt vorerst. Wenn denn überhaupt so viel Grafikmaterial reinpasst, kommt immer
drauf an wie komplex und groß die Bilder sind.
Oder ich verstehe auch nicht ganz was du jetzt meinst, denn ein Spiel was nur aus Video-Vollbildern
besteht ist ja fast überhaupt nicht zu realisieren.
Natürlich ist das Skalieren auch eine sehr gute Sache. Ich hatte allerdings Spielideen im Sinn, wo
soetwas nicht gebraucht wird. Auch das Verdecken der Spielfigur, da dachte ich auch nur an eine
Ebene für dahinter.
Mein ganzes Format ist im Grunde sinnlos sobald man bereit ist, mehrere MB XMS oder irgendwas
zu benutzen. Aber irgendwie ist es für mich reizvoll, in echtem Realmode mit nur 640K virtuell
so viel Grafik unterzubringen, als würde man ein paar MB XMS nutzen. Ist eine Sache der Daten-
Ästhetik, keine Bits und Bytes sollen redundant verschwendet werden.
So eine "saubere Architektur" motiviert mich erst vollständig, ein Spiel oder irgendeine
multimediale Anwendung zu basteln. Den Usern/Gamern wird es egal sein was technisch
dahintersteckt, aber mir nicht.
Vielleicht kommt das auch noch aus der Zeit anfang der 90er, als ich mich öfters mit
Spielen rumärgerte, die wegen hohem Speicherbedarf eine Bootdiskette brauchten oder
ähnliche Extrawürste.
Zuletzt geändert von zatzen am Fr 1. Aug 2014, 23:35, insgesamt 3-mal geändert.
mov ax, 13h
int 10h
while vorne_frei do vor;
int 10h
while vorne_frei do vor;
Re: Eigenes Videoformat
Was vielleicht verwirrend erscheinen mag ist, dass alles in 8x8 Blöcke aufgeteilt ist.
Sprites können, müssen aber nicht in 8x8 aufgehen. Wenn ich also z.b. ein 32x33 Pixel
Sprite habe, hängen bei ZVID unten noch 7 transparente Zeilen "unnötig" dran. Das
dürfte praktisch aber nichts ausmachen.
Video heisst übrigens wörtlich aus dem Lateinischen übersetzt einfach nur "Ich sehe",
und daher muss man bei einem Format, das so heisst, auch gar nicht unbedingt an
bewegte Bilder denken...
Sprites können, müssen aber nicht in 8x8 aufgehen. Wenn ich also z.b. ein 32x33 Pixel
Sprite habe, hängen bei ZVID unten noch 7 transparente Zeilen "unnötig" dran. Das
dürfte praktisch aber nichts ausmachen.
Video heisst übrigens wörtlich aus dem Lateinischen übersetzt einfach nur "Ich sehe",
und daher muss man bei einem Format, das so heisst, auch gar nicht unbedingt an
bewegte Bilder denken...
mov ax, 13h
int 10h
while vorne_frei do vor;
int 10h
while vorne_frei do vor;
Re: Eigenes Videoformat
Achso, alles klar.
Ja, ich habe für Sprites eben bisher schon verschiedene Möglichkeiten ausprobiert. Momentan benutze ich 2 davon.
Aber für so 2D Kram (außer Adventures) favorisiere ich für Levels diese "patternbasierten" Dinge wie man sie von alten Konsolenspielen kennt, d.h. diese 8x8, 16x16, 32x32 "Klötze", aus denen die Levels zusammengesetzt sind.
Ich weiß natürlich, daß das auch mit Deiner Methode möglich ist.
Ich überlege nur gerade, ob damit dann 8-Wege-Scrolling (oder überhaupt Scrolling) funktioniert.
Welche Art Spiel schwebt Dir denn so vor, das Du damit machen wollen würdest?
Ja, ich habe für Sprites eben bisher schon verschiedene Möglichkeiten ausprobiert. Momentan benutze ich 2 davon.
Aber für so 2D Kram (außer Adventures) favorisiere ich für Levels diese "patternbasierten" Dinge wie man sie von alten Konsolenspielen kennt, d.h. diese 8x8, 16x16, 32x32 "Klötze", aus denen die Levels zusammengesetzt sind.
Ich weiß natürlich, daß das auch mit Deiner Methode möglich ist.
Ich überlege nur gerade, ob damit dann 8-Wege-Scrolling (oder überhaupt Scrolling) funktioniert.
Welche Art Spiel schwebt Dir denn so vor, das Du damit machen wollen würdest?
Re: Eigenes Videoformat
Mit Scrolling habe ich mich bisher nicht so sehr beschäftigt.
Jedenfalls nicht irgendwie mit "Rumpfuschen" von Speicherbänken der Grafikkarte oder
so ähnlich, was meines flüchtigen Wissens auch nur bei EGA und nicht bei VGA möglich ist.
Es gibt eine Spieledemo von mir mit Scrolling, ich weiss nicht ob du Youtube ansehen kannst:
http://youtu.be/jqx08ubMIps
Der Hintergrund und die Sounds werden aus dem XMS geholt.
Wenn nicht und bei Interesse kann ich auch mal das ganze als ZIP hochladen.
Ich habe dabei einfach den Hintergrund in Senkrechte Streifen aufgeteilt und
für jedes Bild entsprechend neu gezeichnet.
So würde ich es auch eher wieder machen, möglicherweise wäre das mit ZVID sogar
sehr bequem, wenn man ein sehr großes Bild definiert und dieses dann irgendwo
X-Y Positioniert und automatisch nur die Blöcke dargestellt werden, die innerhalb
des Bildausschnitts liegen.
Als Spiel schwebt mir eher ein 2-D Ding vor, Seitenansicht wie ein Jump n Run.
Es kann aber gerne auch wie ein Adventure sein, und es gibt ja auch Adventures
ohne Scaling (z.B. Simon The Sorcerer).
Ich wollte mir ja eine Game-Engine für einen bestimmten Spieletyp machen, und
das wäre dann eben so eine Art Jump n Run, aber eben ein bisschen Adventure-
mäßiger. Die Vielfältigkeit und Komplexität von Adventures kombiniert mit
der Bewegungsfreiheit und der Dynamik von Jump n Runs, soetwas in der Art.
Jedenfalls nicht irgendwie mit "Rumpfuschen" von Speicherbänken der Grafikkarte oder
so ähnlich, was meines flüchtigen Wissens auch nur bei EGA und nicht bei VGA möglich ist.
Es gibt eine Spieledemo von mir mit Scrolling, ich weiss nicht ob du Youtube ansehen kannst:
http://youtu.be/jqx08ubMIps
Der Hintergrund und die Sounds werden aus dem XMS geholt.
Wenn nicht und bei Interesse kann ich auch mal das ganze als ZIP hochladen.
Ich habe dabei einfach den Hintergrund in Senkrechte Streifen aufgeteilt und
für jedes Bild entsprechend neu gezeichnet.
So würde ich es auch eher wieder machen, möglicherweise wäre das mit ZVID sogar
sehr bequem, wenn man ein sehr großes Bild definiert und dieses dann irgendwo
X-Y Positioniert und automatisch nur die Blöcke dargestellt werden, die innerhalb
des Bildausschnitts liegen.
Als Spiel schwebt mir eher ein 2-D Ding vor, Seitenansicht wie ein Jump n Run.
Es kann aber gerne auch wie ein Adventure sein, und es gibt ja auch Adventures
ohne Scaling (z.B. Simon The Sorcerer).
Ich wollte mir ja eine Game-Engine für einen bestimmten Spieletyp machen, und
das wäre dann eben so eine Art Jump n Run, aber eben ein bisschen Adventure-
mäßiger. Die Vielfältigkeit und Komplexität von Adventures kombiniert mit
der Bewegungsfreiheit und der Dynamik von Jump n Runs, soetwas in der Art.
mov ax, 13h
int 10h
while vorne_frei do vor;
int 10h
while vorne_frei do vor;
Re: Eigenes Videoformat
Ich habe es mir auf Youtube mal angeschaut. Und ja, den Vorläufer dieses Demos von Dir habe ich sogar mal live "gespielt". (Habe ja einiges von Deiner Website heruntergeladen.)
An sich schon nett.
Bei mir liegt es wahrscheinlich daran, daß ich ursprünglich aus der "8-Bit-Ecke" stamme und auch danach eher so Konsolen mit 8 oder 16 Bit mein "Vorbild" waren. Daher ist bei allem außer Adventures wohl auch dieses Pattern-/Block-/Kacheln- basierte Leveldesign immer mein Favorit gewesen - bzw die einzige Art, auf die ich mir ein Gamelevel vorstellen kann. Das bedeutet nicht, daß ich diese dann nicht ebenfalls aus Bildern (egal ob gepixelten oder Fotos) "ausschneiden" und zu Levels zusammensetzen kann - ich will mir aber die Option wiederverwendbarer Objekte vorbehalten. Außerdem versuche ich, XMS Zugriffe, die "live" während des Spiels stattfinden (also bei jedem Frame oder so), zu minimieren oder möglichst ganz zu vermeiden.
Es ist hier wahrscheinlich egal, wie man vorgeht - solange das Endergebnis dem "ursprünglichen Plan" entspricht bzw diesem so nahe wie möglich kommt. Ich lege bei meinen Spielen aber auch keinen Wert auf "Echt Aussehen", "Fotorealismus" oder ähnliches.
Aber ich warte gespannt auf ein Spiel von Dir - ich interessiere mich sehr für die Arbeit meiner "Programmierer-kollegen" - gerade wenn sie ebenfalls unter/für DOS programmieren. Und da speziell Spieleprogrammierung auch der Antrieb ist, dem ich selbst die meisten meiner Entwicklungen zu verdanken habe (auch viele meiner Tools sind darauf ausgerichtet bzw auf dem Weg dahin entstanden), interessiert mich das Ganze speziell bei von anderen Leuten entwickelten SPIELEN auch im Besonderen.
An sich schon nett.
Bei mir liegt es wahrscheinlich daran, daß ich ursprünglich aus der "8-Bit-Ecke" stamme und auch danach eher so Konsolen mit 8 oder 16 Bit mein "Vorbild" waren. Daher ist bei allem außer Adventures wohl auch dieses Pattern-/Block-/Kacheln- basierte Leveldesign immer mein Favorit gewesen - bzw die einzige Art, auf die ich mir ein Gamelevel vorstellen kann. Das bedeutet nicht, daß ich diese dann nicht ebenfalls aus Bildern (egal ob gepixelten oder Fotos) "ausschneiden" und zu Levels zusammensetzen kann - ich will mir aber die Option wiederverwendbarer Objekte vorbehalten. Außerdem versuche ich, XMS Zugriffe, die "live" während des Spiels stattfinden (also bei jedem Frame oder so), zu minimieren oder möglichst ganz zu vermeiden.
Es ist hier wahrscheinlich egal, wie man vorgeht - solange das Endergebnis dem "ursprünglichen Plan" entspricht bzw diesem so nahe wie möglich kommt. Ich lege bei meinen Spielen aber auch keinen Wert auf "Echt Aussehen", "Fotorealismus" oder ähnliches.
Aber ich warte gespannt auf ein Spiel von Dir - ich interessiere mich sehr für die Arbeit meiner "Programmierer-kollegen" - gerade wenn sie ebenfalls unter/für DOS programmieren. Und da speziell Spieleprogrammierung auch der Antrieb ist, dem ich selbst die meisten meiner Entwicklungen zu verdanken habe (auch viele meiner Tools sind darauf ausgerichtet bzw auf dem Weg dahin entstanden), interessiert mich das Ganze speziell bei von anderen Leuten entwickelten SPIELEN auch im Besonderen.