Ich habe ein Konzept!

Diskussion zum Thema Programmierung unter DOS (Intel x86)
Benutzeravatar
zatzen
DOS-Guru
Beiträge: 518
Registriert: Di 17. Apr 2012, 05:10
Wohnort: bei Köln
Kontaktdaten:

Ich habe ein Konzept!

Beitrag von zatzen »

Da ist mir doch gestern Abend eine Idee gekommen, die für mich eigentlich gar nicht so neu ist.

Und zwar ein rundenbasiertes Deathmatch Spiel mit humanoiden Robotern.

Von diesen können mehrere gegeneinander antreten oder auch nur je einer.

Die beiden Spieler können vorher ihre Bots konfigurieren und dann entsprechend der
konfigurierten Teile und der Fähigkeiten mit einer Pseudo-KI programmieren.

So, und jetzt kommt's: Ich selber mag die Idee, dass es bei einem Spiel nicht auf Echtzeit-
reaktionsvermögen ankommt, sondern dass der Kern des Geschehens etwas ist, was man
einfach nur beobachtet. Ich bin zwar überhaupt kein Fan von Strategie, aber diese Art
von Strategie dass man sich einen Roboter konfiguriert geht gerade noch.

Bildtechnisch komme ich dabei locker mit 18.2 frames aus.

Wann und ob ich das Spiel machen werde steht noch in den Sternen.
Es ist eine Sache, die ich komplett alleine schaffen könnte.
Für die Grafik mal nebenbei, kennt jemand eine gute 256er Palette?

Gibt es so ein Spiel schon? Wenn nicht, könnte das ja sogar etwas werden
für das der ein oder andere modern ausgestatte Mensch DosBox anwirft.

Das wird dann natürlich kein Spiel einer Spiel-Engine sondern hat seinen indivuduellen Code.
ZVID würde ich verwenden, da würde ich mich schon drauf freuen denn es gäbe einiges an animierter Grafik.

Für dieses Spiel würde ich dann aber auch gerne Tracker Musik in meinem Format verwenden,
das passt für soetwas sehr gut.


Falls jemand mitmachen möchte, gerne.
Allerdings würde ich schon gerne meine Formate ZVID und ZSM (Zatzen simple Tracker Format)
verwenden. Da müsste also jemand eher selbstlos coden. Ich selber bin ein langsamer Coder.
Für die Grafik hab ich schon ne ungefähre Vision die mit der Idee zusammenhängt, daher würde
ich gern auch wenn jemand anders die Grafik macht darüber Regie führen.
Ich selbst bin kein guter Grafiker, nur wenn es nicht anders geht, und dann dauert das wieder
sehr lange.

Ok, mal sehen wann und ob da was draus wird :)
mov ax, 13h
int 10h

while vorne_frei do vor;
Benutzeravatar
Dosenware
DOS-Gott
Beiträge: 3745
Registriert: Mi 24. Mai 2006, 20:29

Re: Ich habe ein Konzept!

Beitrag von Dosenware »

zatzen hat geschrieben:Gibt es so ein Spiel schon?
jepp, ich hatte mal ein Spiel wo mann in Pascal Roboter programmiert hat, die dann gegeneinander angetreten sind.
Benutzeravatar
zatzen
DOS-Guru
Beiträge: 518
Registriert: Di 17. Apr 2012, 05:10
Wohnort: bei Köln
Kontaktdaten:

Re: Ich habe ein Konzept!

Beitrag von zatzen »

Das hier?
http://corewar.co.uk/probots/

Werd ich mir mal ansehen.
mov ax, 13h
int 10h

while vorne_frei do vor;
Benutzeravatar
zatzen
DOS-Guru
Beiträge: 518
Registriert: Di 17. Apr 2012, 05:10
Wohnort: bei Köln
Kontaktdaten:

Re: Ich habe ein Konzept!

Beitrag von zatzen »

Von der Illustration her wird es den verwöhnten Gamer wohl kaum ansprechen, wenngleich dieses Konzept sehr
komplexe und intelligente Strategien erlaubt. Was mir auch gefällt, dass man das Programm seines Roboters
in einer Datei hat, jederzeit ändern und erweitern kann und dann immer wieder damit gegen andere antreten kann.
Allerdings haben ja nur die Leute Zugang dazu, die etwas vom Programmieren in Pascal verstehen...

Ich wollte das schon audivisuell ausstatten wie ein kommerzielles Spiel, und die Programmierung der Roboter sollte
parametrisch geschehen. Das Spiel würde eine Datenbankk anlegen mit den Roboterteams der Spieler.
Bei der Konfiguration der Roboter könnte man nach einem Punkteverteilungssystem vorgehen, z.B. jeder Spieler
hat 100 Punkte und entsprechende Teile kosten soundsoviel Punkte, so könnte man sich auch überlegen ob man
lieber wenige teure Roboter zusammenstellt oder viele weniger teure.
Aber das ist vorerst alles mal Zukunftsmusik.

Bleibt für mich nur nochmal die Frage, ob es soetwas als für jeden spielbares Spiel und mit Grafik schon gibt.
Und ob es das so gibt wie ich es angedacht hatte, Jump&Run Perspektive (mit entsprechendem plattformartigen
Leveldesign), die Roboter nach vorne blickend dargestellt und sich seitlich bewegend, damit vermeide ich sprungartige
Spiegelungen oder andererseits die aufwändige Animationsphase der 180° Drehung.

Ein bisschen denkt man da an Worms. Es soll aber nur Nahkampfwaffen geben die vielmehr direkt ein Teil des
Roboters sind. Und es soll eben alles automatisch laufen, nicht unterbrochen durch die User.
Am meisten haben ich und ein Freund bei irgendwelchen Kettenreaktionen bei Worms gelacht.
Von daher denke ich, wäre so eine lange Show ohne Unterbrechung einmal sehr interessant.
mov ax, 13h
int 10h

while vorne_frei do vor;
Benutzeravatar
Dosenware
DOS-Gott
Beiträge: 3745
Registriert: Mi 24. Mai 2006, 20:29

Re: Ich habe ein Konzept!

Beitrag von Dosenware »

zatzen hat geschrieben:Das hier?
http://corewar.co.uk/probots/

Werd ich mir mal ansehen.
glaube ja - ist jetzt auch 17/18 Jahre her... fand ich damals ganz witzig
Benutzeravatar
zatzen
DOS-Guru
Beiträge: 518
Registriert: Di 17. Apr 2012, 05:10
Wohnort: bei Köln
Kontaktdaten:

Re: Ich habe ein Konzept!

Beitrag von zatzen »

Aber eigentlich... Wenn ich doch mal weiter überlege ist da noch eine andere Idee, die ich faszinierender fände
und die auch weniger schwer zu programmieren sein dürfte:

Ein Jump&Run mit großzügig dimensionierten Figuren und Gegenständen, und, das besondere,
die Landschaften und Orte des Geschehens wären nicht blockweise zusammengesetzt aus einer
sich wiederholenden Palette an Teilen, sondern ohne Wiederholungen individuell durchgezeichnet,
ähnlich wie bei einem Adventure. Nur dass man alles ein wenig stilisierter macht, so dass ZVID
ordentlich komprimieren kann.
mov ax, 13h
int 10h

while vorne_frei do vor;
Benutzeravatar
Dosenware
DOS-Gott
Beiträge: 3745
Registriert: Mi 24. Mai 2006, 20:29

Re: Ich habe ein Konzept!

Beitrag von Dosenware »

Der HG ist also quasi ein Film zum Vor- und zurückspulen?

Gegner, Gegenstände etc. sind nur drübergezeichnet?
Benutzeravatar
zatzen
DOS-Guru
Beiträge: 518
Registriert: Di 17. Apr 2012, 05:10
Wohnort: bei Köln
Kontaktdaten:

Re: Ich habe ein Konzept!

Beitrag von zatzen »

Die Namensgebung "ZVID" mag irritieren, das Format kann auch einfach nur ein einzelnes großes Bild speichern.

Ich stelle mir das bei diesem Jump&Run so vor, dass der Hintergrund ein großes breites (oder hohes) Bild ist,
und dann hätte man noch eine Ebene für Vordergründe, dazwischen wären dann die Sprites angesiedelt.
Eine Vordergrund-Ebene kann optisch ganz reizvoll sein, z.B. Gitter, Fenster, Treppengeländer welche die
Objekte oder die Spielfigur dann teilweise verdecken.

Zudem müsste es natürlich ein "mapping" oder wie auch immer man es nennen möchte geben, heisst,
es muss bekannt sein, welche Bereiche des Hintergrundbildes als was funktionieren, ob man darauf
laufen kann oder nicht bswp. Man könnte so eine "nackte" Map nehmen und darüber ganz frei das konkrete
Hintergrundbild zeichnen.

Im Gegensatz zu dem Roboter Deathmatch Spiel hat dieses Konzept mit dem Jump&Run den Vorteil,
dass ich das über eine generalisierte Spiele-Engine umsetzen kann, und wenn die einmal steht gehen
weitere Spiele ohne Programmieren.
mov ax, 13h
int 10h

while vorne_frei do vor;
Benutzeravatar
Dosenware
DOS-Gott
Beiträge: 3745
Registriert: Mi 24. Mai 2006, 20:29

Re: Ich habe ein Konzept!

Beitrag von Dosenware »

Für feste Objekte einfach ein 1Bit Bild verwenden, vorzugsweise mit einer niedrigeren Auflösung (muss ja nicht Pixelgenau sein).
Kolisionserkennung läuft dann halt über das 1Bit Bild, damit hast du auch gleich die Plattformen - Charaktere und Objekte können der Einfachhalt halber Rechtecke sein.

ggf. nimmst du für die Kolisionserkenntung auch ein 2Bit Bild um verschiedene Effekte (rutschig, Schadenswirkung, etc.) einzubauen - je nach Farbwert.

Die Variante wird zumindest für Adventures genutzt.
DOSferatu
DOS-Übermensch
Beiträge: 1220
Registriert: Di 25. Sep 2007, 12:05
Kontaktdaten:

Re: Ich habe ein Konzept!

Beitrag von DOSferatu »

Ach ja - dazu fällt mir verschiedenes ein:
(Achtung - jetzt rede/schreibe ich schon wieder hauptsächlich nur von mir.)

Meine Arcade01/GameSys2-Kombi hat so Sachen auch.
Allerdings ist das Ganze "blockbasiert". Jedem "Block" kann man dabei zwei 4-bit-Typen zuweisen und eine 16bit-Matrix. Die Matrix wird "gedacht" bitweise "unter" den Block gelegt:
00 01 02 03
04 05 06 07
08 09 10 11
12 13 14 15
(Egal wie groß der Block ist: Jedes Bit bedeutet ein Sechzehntel-Quadrat des Blocks. D.h. bei Block mit z.B. 16x16 Pixeln steht jedes Bit für einen 4x4 Pixel Bereich des Blocks, bei 32x32 Pixeln 8x8 usw)
Ist MatrixBit=0 wird der untere 4-Bit-Typ (also unteres Nybble), wenn MatrixBit=1, der obere 4-Bit-Typ (oberes Nybble) des Blocks zurückgemeldet.
Bei der Kollisionsabfrage (dafür sind "Opcodes" in GameSys2 schon eingebaut) wird dann der 4-Bit-Typ zurückgeliefert, je nachdem, an welchen Koordinaten der Blocktest erfolgt ist.... - naja und so weiter. Klingt vielleicht komplizierter als es ist.

Anmerkung:
Ich habe schon überlegt, eine kleine Erweiterung einzubauen, nämlich eine "MAGIC"-Matrix, die für Kollisionen keinen Sinn macht, wie z.B. $A5A5 :
Bits:
1 0 1 0
0 1 0 1
1 0 1 0
0 1 0 1
Die Abfrage würde beim Erkennen des "Magics" dann die Block-Grafikdaten selbst aus dem Block-Speicher lesen und 0 für "transparenten" oder 1 für "deckenden" Bereich des Blocks zurückliefern (denen man dann wieder die 2 Typen zuordnen könnte).
Alternativ könnte man auch das oberste Bit (oder irgendein Bit) der Matrix für "Sondermodi" nutzen (auf 1 setzen) und dann die unteren 15 Bits beliebig anders definieren.
Die vorherigen Möglichkeiten wären durch beides nicht eingeschränkt, da man einfach nur die Matrix invertieren und die Typ-Nybbles tauschen müßte um die vorige Funktionalität herzustellen, wenn das "Sonder"-Bit zufällig 1 wäre.

Aber diese Dinge sind derzeit nicht eingebaut. Naja, prinzipiell kann man ja jeden Kram extrem erweitern. (KANN man machen - MUß man aber nicht...)

Mein ganzes "Zeug für Spiele" habe ich ja beinahe fertig:
* ISM, die Sound-Engine generiert fleißig Sound (es fehlen nur noch 2 Sub-Modi und 1 Befehl).

* Arcade01, die Grafik-Engine ist seit 2004 fertig (Blockbasierte Levels mit bis zu 4 unabhängig scrollbaren "Parallax"-Ebenen, Sprites mit bis zu 255x255 Pixeln, drehbar, spiegelbar, in 65536 Stufen skalierbar, mit Dithereffekt möglich. Levels+Sprites mit "halbtransparenten" Farben...

* TheGame3 zum Erstellen der Sprites/Levels ist quasi auch fertig - nur die eingebaute Hilfe müßte vervollständigt und einige kleine Schönheitsfehler daran noch bereinigt werden.

* GameSys2, die Steuer-Engine zur Steuerung des Spiels, d.h. vor allem der Objekte (Figuren, "Schüsse", Boni...) ist fertig, inklusive des zugehörigen "Assemblers" (eigentlich Bytecode-Generator). Vielleicht sortiere ich einige der Opcodes noch um an andere Stellen (Nummern).
[Eigentlich wollte ich für das GameSys2 mal ein "Hochsprachen"-Frontend bauen, so eine Art einfaches BASIC oder was auch immer, um die Eingabe zu erleichtern - damit man da nicht wie ein Assembler-Coder rummachen muß - vielleicht auch mit einer IDE dazu... Naja, was ICH schon alles machen wollte... Wenn man nur die Zeit dazu hätte...]

* Alles "systemische", wie gleichzeitige Abfrage von Tasten, Setzen des Tickers auf beliebige Frequenzen, Setzen von "legalen" und "Tweaked" VGA-Modi und ähnliche normale und "komische" Dinge sind seit Jahren (teils über 10) fertig und bräuchten "nur noch eingebaut werden".
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Eigentlich würde und könnte ich vieles schon wieder neu machen - könnte auch an der Grafikengine schon wieder drehen... Aber irgendwann sollte ich dann auch endlich mal etwas sinnvolles damit anstellen.

In Wirklichkeit will ich seit Jahren endlich mal wieder ein Spiel machen - aber das ganze "Drumherum" hält mich dermaßen auf... - Das kommt davon, wenn man mal NICHT "alles auf die blanke Maschine schmeißt" (egal wie Spaghetti der Code ist). Dann will man alles "richtig machen" - und das dauert eben.

Ich müßte mir wirklich mal ein halbes Jahr "von der Welt frei nehmen" - keinen Job, keine blöden Verpflichtungen, nichts von dem, was mich müde, kraftlos und traurig macht - dann würde ich vielleicht mal mit einem wirklich guten Projekt (Spiel) um die Ecke kommen.
Naja... "guten"... - Also mit einem 2D-Spiel für DOS. So Arcade-Zeug eben. Ein Raumschiffshooter und ein etwas aufwendigeres Jump'n'run sind geplant.

Eigentlich bin ich scheinbar gar kein Spieleprogrammierer, sondern wohl eher ein "Engine-Bastler". -Trotzdem wäre es natürlich schön, wenn bei der ganzen Engine+Editor-Bastelei auch mal etwas rumkommt, das andere Leute benutzen (spielen) können.

Ich weiß, sowas ist zwar derzeit beliebt - SOGAR, wenn es pixelig ist. Nur soll es dann eben auf einer 64bit 4 GHz Quadcore Maschine mit 8 GB RAM laufen müssen - ein Spiel, das genauso aussieht, aber nur 100 MHz, 16/32bit und 1-2 MB RAM braucht, will doch keiner haben. Denn das ist ja lame... Da kann ich echt froh sein, daß ich immer noch Lust auf den Kram habe, den ich so mache und daraus meine Zufriedenheit beziehe - denn eine ZIELGRUPPE für meinen Kram gibt es eigentlich nicht mehr...


@zatzen:
(Hast Du Dich also doch dazu durchgerungen, mal wieder ein Spiel machen zu wollen. Schön!)
An sich finde ich das Konzept, schöne Levels (mit richtigen "Landschaft" Hintergründen) zu bauen, schon toll. Ich selbst wüßte nur nicht, wo ich die ganze Grafik "hinstecken" soll. Allein für ein unbewegliches Vollbild in 320x200 braucht man ja schon fast 64kByte - Packen ist zwar gut, aber natürlich weiß man beim Packen vorher nie, was (wieviel) am Ende "rauskommt", da es ja von den zu packenden Daten abhängt und man im Worst Case genau so viel braucht wie ungepackt oder im "Even Worster Case" (ja, so wie im Trickfilm die Doofen Figuren immer sagen: Er ist mein aller-bestester Freund...) braucht man sogar noch mehr, für den Packer-Overhead.

Zuviel Packen hätte dann wieder (zumindest für mich) den kleinen Nachteil, daß die Objekte nicht mehr miteinander interagieren könnten, da ein Objekt (Sprite), das sich auf "den Hintergrund" (das Level) bezieht, im gepackten Stream nach den Daten suchen müßte.

Denn, wenn man das ganze Zeug dann ungepackt im Speicher vorhalten würde, könnte man sich die Packerei auch schenken - denn wie groß die Daten im Datenfile auf der Festplatte sind, stört mich (fast) gar nicht. Mir geht es ja darum, daß während der Laufzeit möglichst sparsam mit dem Speicher umgegangen wird. Grund ist, daß ich - 16bit-Mode-verhaftet - direkt quasi nur auf das untere MB zugreifen kann, alles darüber geht nur mit indirektem Zeug wie XMS etc. - Und ja, ich weiß, daß es diesen "Hack" namens 4G-Flatmode gibt...
Aber das ist ja nur MEINE Meinung dazu. Diese Block/Pattern-basierten Levels sind ja auch nicht direkt MEINE Idee - so kenne ich es eben von 8/16-Bit Konsolen...

Ich weiß: Man könnte z.B. bei einem horizontalen oder vertikalen Scroller die Daten spaltenweise/zeilenweise vorhalten und immer "drankopieren" und bei einem 8-Wege-Scroller dann "quadratweise"... Auf diese Art könnte man riesige Vollgrafiken als Levelhintergrund haben - eine entsprechend intelligente Engine vorausgesetzt, die immer im richtigen Moment reagiert, ohne daß der Spieler etwas merkt.

Ich habe eine ähnliche Idee auch schon ausgebrütet, so eine Art "Hybridlösung":
Die "Blocks" aus denen meine Levels bestehen, werden sowieso aus Grafiken "ausgeschnitten" - so daß größere Grafikelemente aus mehreren Blocks zusammengesetzt werden können. Es KANN, MUß dann aber nicht so aussehen wie AlexKidd oder Mario (mit diesen Klötzen). Es MÜSSEN ja nicht unbedingt "Nahtstellen" an die Blockränder getan werden...

Die Idee ist nun, die gleichen Blocks, während man sich durch das Level bewegt, durch andere Grafik zu überschreiben, je nachdem, wo man sich gerade aufhält. So wäre ein Teil der Grafik dann immer im XMS oder auf Festplatte und würde nur bei Bedarf ausgetauscht werden. Da man nie alle Blocks gleichzeitig ändern würde, sondern nur die, die gerade nicht angezeigt werden, würde das Design dann fließend vom einen ins andere übergehen, ohne daß man es als Spieler bemerkt.

Einige Blocks wären dann so gestaltet, daß sie zu beiden Designs passen, so daß keine "Nahtstellen" entstehen.... usw., d.h. Wenn man von Set A zu Set B wechselt, würden einige Blocks von Set A erhalten bleiben (also gleichzeitig auch zu Set B gehören) - nennen wir sie Set Ax. Gleichzeitig sichtbar wären dann Set A und Set Ax oder Set Ax und Set B... usw.

(Das alles ist ja nur nötig, weil ich max. 256 Blocks supporte und weil nicht unendlich viel Speicher für Grafik vorhanden ist.)

Das Ganze würde die Vorteile von schöner abwechslungsreicher Grafik (für die Vermeidung von Klotzdesign) und blockbasierten Levels (für einfachere Spielmechanik kombinieren) - natürlich müßten zusätzliche Mechanismen geschaffen werden, die den "Grafikaustausch" ermöglichen, ohne daß der dazugehörige Leveleditor für den Levelbauer zum "Pain in the Ass" wird.

Ach, übrigens:
Die Idee mit einer Bitmatrix "hinter" einem Bild hatte ich auch schon - sie wird in meinem PLAYBOX - Tiere klicken - angewendet (die Figuren kommen aus "Löchern" im Bild gekrochen oder "hinter" Objekten hervor).

Die Idee ist auch für die Arcade01 Levels teilweise eingebaut - so daß Sprites die Möglichkeit haben, sich entweder vor allen 4 Ebenen (also "darüber") zu legen, oder alternativ zwischen Ebene 1 und 2 (d.h. von vorn gesehen: Ebene1, Sprite, Ebene2, Ebene3, Ebene4). Ich hatte es nur noch nicht für alle Sprite-Modi umgesetzt.

Irgendwie habe ich inzwischen den Eindruck, als wenn das, was ich da mache, etwas ist, das einen DOS-PC in eine Art "Super Nintendo" verwandelt... - Naja, wahrscheinlich nicht zufällig: Die Spiele, die ich machen will, sollen vom Typ/Genre her so ungefähr wie das werden, was damals so auf SNES lief. Nicht so toll vielleicht (ich messe mich sicher nicht mit diesen Games und ihren Machern), aber vom gleichen Spielprinzip.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Das war wieder zuviel Text.

Achja, @zatzen:
Hast Du in letzter Zeit auch wieder etwas neues gemacht, das man ansehen/benutzen kann? Ich interessiere mich immer auch für die Programmierarbeit von anderen.
Benutzeravatar
zatzen
DOS-Guru
Beiträge: 518
Registriert: Di 17. Apr 2012, 05:10
Wohnort: bei Köln
Kontaktdaten:

Re: Ich habe ein Konzept!

Beitrag von zatzen »

Ich komme nur grad hier rein weil ich ein Spiel gefunden habe das technisch etwa meinem zweiten hier angeführten Konzept entspricht: Another World auf dem Amiga. Auffallend ist, dass die Level-Hintergründe fast immer individuell "gemalt" sind.
Und hier komme ich drauf zu sprechen unter welchen Bedingungen ein Hintergrund wenig Speicher belegen kann mit ZVID:
Bei Another World sind die Hintergründe in wenigen Farben gehalten, und es gibt viel gleichfarbige Flächen. Das wären die Bedingungen, unter denen man mit ZVID mit meinetwegen 100 KB ausreichend genug Hintergrund (vielleicht ein dutzend screens) für ein Level in ein Spiel einbringen könnte.
Generell würde ich aber von der Technik mal abgesehen ein ganz anderes Spiel machen wollen.
Scrolling muss nicht sein, allerdings muss dann alles etwas kleiner sein, sonst ist da ja nicht viel Platz für die Spielfigur.

Ich muss gleich mal weg, schreibe evtl. später noch mehr.
Nur zu meiner bisherigen Art, den Bildschirm mit Hintergrund und Sprites zu füllen:
Ich lege mir einen Bildschirmpuffer an, also bei Vollbild ein Datenfeld mit 64000 Byte.
Zuerst wird da der Hintergrund reinkopiert. Dann die Sprites und zuletzt evtl. verdeckende
Objekte. So ein Vorgehen ist redundant, ich habe aber bisher noch nicht ausprobiert wie
es wäre wenn man intelligenter vorgeht und nur den Hintergrund neu zeichnet der "zerstört" wurde.
Aber da ich so vorgehe wie ich vorgehe ist es völlig gleich ob ich ein Sprite per ZVID einfüge
oder aus einem unkomprimierten Datenfeld. ZVID wird in der Endversion auch ohne Umwege
direkt aus dem Packstream in den Bildschirmpuffer oder sonstwohin entpacken können.

Dass ich überhaupt soetwas wie ZVID "erfunden" habe hängt mit so einer komischen Vorliebe
von mir zusammen dass ich z.B. fasziniert davon bin, was ein intelligentes Verfahren aus
einer gegebenen Grafik in etwas anderes "kompiliert".
Generell habe ich schon immer einmal gern per Hex-Editor auch mal in Dateien reingeguckt
um zu sehen wie dies und das gespeichert wird.

Dem Spieler dürfte es am Ende egal sein welche Technik und welche Dateiformate im Spiel verwendet wurden.

Stellt sich also weiterhin die Sinnfrage nach soetwas wie ZVID.
Immerhin verwendet man heute aber immer noch ausgefeilte Kompressionsalgorhythmen für Videos.

Hmm...
Könnte sich denn hier jemand vorstellen ZVID zu verwenden? Vielleicht bloß für Hintergründe?

Ich habe leider noch nichts weiteres programmiert.
Ich kann auch nicht versprechen wann es weitergeht, lediglich sagen dass es mit hoher Wahrscheintlichkeit
irgendwann nochmal etwas neues von mir gibt. Für's erste würde ich für ein Spiel erstmal auf den Sound
verzichten. Das dürfte das Vorankommen beschleunigen.

Was ich mal machen könnte als erweiterte ZVID-Demo, dass ein Sprite vor einem animierten
Bildschirmfüllenden Hintergrund hin und her läuft.
mov ax, 13h
int 10h

while vorne_frei do vor;
Benutzeravatar
zatzen
DOS-Guru
Beiträge: 518
Registriert: Di 17. Apr 2012, 05:10
Wohnort: bei Köln
Kontaktdaten:

Re: Ich habe ein Konzept!

Beitrag von zatzen »

Über "Another World" bin ich jetzt auch mal zu "Flashback" gelangt.
Und ich sehe mir gerade das Remake von 2012(?) an.

Da kann ich schon verstehen wenn jemand soetwas erwartet, weil es auf heutigen
Rechnern eben machbar ist.
Ich selbst hätte allerdings keine Lust, das zu spielen, und ich bin auch schnell
gelangweilt von diesem Video.
Liegt aber vielleicht auch an der Art des Spiels.
Ich frage mich, was gewesen wäre, wenn die Computer zu meiner Kindheits- und
Jugendzeit so potent gewesen wären. Ich kann wirklich nicht sagen ob es mich
begeistert hätte.
An Grafik von Computerspielen hat mich gerade fasziniert dass die Auflösung so
gering war, dass man wenn man wollte die Pixel hätte zählen können. Alles sah
so schön durchsichtig aus, wie ein Mosaik aus Edelsteinen.
Heutige Grafik sieht fast durch die Bank aus wie abgespeckte CGI für Filme,
nach Plastik, was auch immer, konkretisiert etwas und schiebt einen Riegel
vor, wo man auch an die Vorstellungskraft des Benutzers appelieren könnte.

Irgendwo gibt es aber auch bei mir eine Grenze nach unten hin, und die kann
ich in etwa beim Nintendo NES setzen.
Da gibt es viele Spiele bei denen ich die Grafik enttäuschend finde, wohl
hauptsächlich wegen der geringen Farbtiefe und der systembedingten
Stilisierung auf 4-Farben-Blöcke, was keine feineren Schattierungen und Farbverläufe
erlaubt.

Das ist bei EGA am PC schon anders, zwar auch oft zu wenig Farben, aber keine
8x8 Block Beschränkung, und so kann eine EGA Grafik durchaus den Charme eines
16 Farben Acryl-Gemäldes haben. Überhaupt hat die 320x200 Auflösung einen
gewissen Charme wie aus dem Bereich der Malerei, da man dort mit Pinseln malt
und somit keine besonders feinen Linien und Punkte zeichnet.

Irgendwas "magisches" hat diese mittlere Auflösung (gibt ja noch 160x200, die finde
ich enttäuschend), dass ich sie bei Spielen sogar interessanter finde als bswp. 640x480 ...
Das wäre ein triftiger Grund, um tatsächlich ernsthaft oldskool zu programmieren.
Eben wenn dieses 320x200 mir, und vielleicht auch anderen, etwas gibt, was mit höheren
Auflösungen nicht zu haben ist ... Eine schöne Auflösung ist das, fein genug um Hinter-
gründe fotorealistisch abzubilden, gleichzeitig aber auch grob genug, um Sprites zu pixeln.
mov ax, 13h
int 10h

while vorne_frei do vor;
Benutzeravatar
zatzen
DOS-Guru
Beiträge: 518
Registriert: Di 17. Apr 2012, 05:10
Wohnort: bei Köln
Kontaktdaten:

Re: Ich habe ein Konzept!

Beitrag von zatzen »

Um dem Spass gegenüber der Tüftelei den Vorzug zu geben und mehr Speicher
für die Grafiken zu haben denke ich jetzt doch darüber nach, alle Sounds aus
dem XMS zu holen.
Grafik unkomprimiert aus dem XMS holen ist mir irgendwie zuwider. Das wäre
wirklich Verschwendung, zumal ich mir ja schon die Mühe mit ZVID gemacht habe.

Aber WAVs lassen sich ohnehin ohne dicken Rechenaufwand und ohne Verlust nicht
gut komprimieren, von daher würde ich sie einfach aus dem XMS holen und dafür
dann eine simple, aber fähige Mehrkanal-Soundengine bereitstellen (die ich ja
auch vor 17 Jahren schon gemacht habe, nur noch ein bisschen optimieren).

So komme ich jedenfalls schneller dahin, ein Spieleprojekt zu realisieren.

Ein Trackermusik-Player wäre was feines, aber das kostet Rechenzeit und RAM.

Nur mal eine Frage, wieviel XMS hat "man" denn so?
Davon würde ich die Samplerate abhängig machen.
mov ax, 13h
int 10h

while vorne_frei do vor;
go32
Kommandozeilenfetischist
Beiträge: 174
Registriert: Sa 24. Okt 2015, 22:51

Re: Ich habe ein Konzept!

Beitrag von go32 »

Hallo,

ich stöbere gerade hier und habe diesen Stran gefunden. Wie steht es denn aktuell um das Spielprojekt?

.
Benutzeravatar
zatzen
DOS-Guru
Beiträge: 518
Registriert: Di 17. Apr 2012, 05:10
Wohnort: bei Köln
Kontaktdaten:

Re: Ich habe ein Konzept!

Beitrag von zatzen »

Vor ein paar Wochen wollte ich mal eine kleine Demo machen mit ZVID, dass man eine Figur vor einem
HIntergrund steuern kann.
Aber mir fehlt zur Zeit die Energie bzw. habe ich im "Real Life" zu viel zu tun.

Als Konzept habe ich wieder was anderes.

Generell ist für mich aber eigentlich geklärt, dass ich für DOS programmieren würde, auch wenn fast keiner mehr
original Hardware dafür hat, aber DosBox soll ja wohl schon im Internetbrowser lauffähig sein.
DOS ist technisch bzw. leistungsmäßig zwar sehr beschränkt verglichen mit heutigen Computern, und leider hat
es keinen solchen Kultstatus wie C64 oder NES, aber die Art und Weise wie man für DOS
programmiert, mit der Möglichkeit direkt auf Hardware zuzugreifen, erlaubt einen Programmier-
stil, der mir Spass machen kann, und den man auf Windows-Systemen nicht findet.

Es ist nur die Frage, ob ich einfach Lust habe, so viel Zeit ins Programmieren und Grafik machen
zu stecken - Musik und Sound mache ich dagegen sehr gerne. Es müsste schon was dabei rauskommen
das wirklich Spass macht zu spielen. Ich spiele allerdings seit Jahren praktisch gar nichts mehr.

Wolltest du dich irgendwie kreativ beteiligen?
mov ax, 13h
int 10h

while vorne_frei do vor;
Antworten