R: technische fragen

nur mal ne frage: warum musst du das alles neu fixen? ich dachte, du musst "einfach" nur eine sound - und graphik-emulation reimplementieren bzw. die schnittstelle z.b. der graphikausgabe entsprechend anpassen. warum hast du probleme mit der gamelogic ? kommt das durch die umstellung auf 32 bit ?
ach ja , noch ein geheimtipp man kann momentan über emule das neue visual c++ 2003 ziehen und evaluieren.. 😉 ist super, hat z.b. codefolding - man kann funktionen oder ganze klassen zusammenklappen.
hmm - entwickelst du überhaupt mit visual c++? wenn ja, noch ein super geniales tool: www.visualassist.com eimalig genial.
(eigentlich wollte ich dies als reply auf die neue beta-version posten, aber da dürfen nur admins posten)

Tja, hätten wir vor 15 Jahren soviel Erfahrung und Weitsicht gehabt wie heute, dann wäre die Umstellung sicher deutlich einfacher.
Es fängt schon damit an, daß das ganze Spiel ultimativ performanceorientiert implementiert war, um überhaupt auf den damals verfügbaren Systemen (286 und darunter) vernünftig zu laufen. Die vielen Assembler-Routinen sind natürlich nicht 'mal eben nach Windows portierbar, selbst wenn sie einmal nicht direkt die Grafikkarte ansteuern...
Dann war es unter DOS überhaupt kein Problem zu warten, bis der User eine Taste drückt, z.B. um die zweite Seite einer Hilfe anzuschauen, oder um den Dialog zum Abbruch des Spieles zu bestätigen.
Das geht unter Windows schonmal prinzipbedingt nicht, und man muß alles auf Ereignis-Steuerung umstellen. Damit ist die gesamte ursprüngliche Engine schonmal Geschichte.
Das nächste Problem ist, daß jedes Spiel unterschiedliche Objekte beinhaltet, die sich teilweise sogar noch bei den verschiedenen Episoden völlig unterschiedlich verhalten.
Verwaltet wurde das in etwa über eine Byte-Matrix, wobei jedes Objekt allerdings über 16 Bit verfügen konnte. In den oberen acht Bit waren Zusatz-Attribute untergebracht, wie z.B. die verschiedene Mauer-Kanten. Die unteren 7 Bit kodierten die Objekt-Art, was genau 128 Objekte unterscheidbar macht. Das übrige Bit 7 hatte eine ziemlich spezielle Bewandnis, war aber in der Regel ungenutzt.
Natürlich verwendet jede Episode eine völlig unterschiedliche Zuordnung der so kodierten Nummer zum eigentlichen Objekt.
Da ich die alte Kodierung mit über 1000 konditionalen Compiler-Anweisungen nur ungern anfassen wollte, habe ich eben den Entschluß gefaßt, alles neu zu implementieren und gleich einen objektorientierten Ansatz zu wählen.
Die Folge? Von der übrigen Programmierung ist, abgesehen von ein paar Schleifen, kaum noch etwas übrig und fast alle der 240 verschiedenen Objekte mit ihren über 1500 verschiedenen Methoden sind komplett neu implementiert worden.
Das gilt natürlich auch für die ganzen animierten Objekte, die damals mangels Erfahrung völlig bescheuert implementiert wurden und ebenfalls komplett überarbeitet wurden.
Ähnliches kann man natürlich auch zur Grafik-Programmierung und zur Sound-Synthese schildern. Alle Shapes sind hardwarenah an der EGA-Technik implementiert. Sie bestehen aus bis zu drei verschiedenen Ebenen, welche jeweils eine Farbe ansteuern. Durch Kombination kann ein Objekt maximal 8 verschiedene Farben haben. Das muß natürlich auch korrekt umgesetzt werden, was eine bitweise Umschaufelei zur Folge hat. Viele der alten Optimierungen funktionieren dementsprechend unter Windows nicht.
Und die Sound-Ausgabe? Nun, alle Musiken wurden über die Synthesizer-Fähigkeiten der Soundblaster-(kompatiblen) Karte realisiert. Unser Sequenzer steuert also direkt Dinge wie Hüllkurven, Wellenform, Modulation etc. an. Eine vergleichbare
Schnittstelle gibt es schlichtweg unter Windows nicht.
Die (registerkonforme) Emulation der alten OPL-Technik ist ein Thema für sich und bei weitem noch nicht perfekt, was sich bei manchen Sounds schmerzhaft zu erkennen gibt...
Bei den ganzen Umbauten finde ich es nach wie vor erstaunlich, daß die Windows-Engine mit den Original-Szenen-Definitionen arbeitet, wie die DOS-Version und sogar die Spielsicherungen in beiden Richtungen austauschbar sind.
Und wo soviel umgestellt wird, passieren natürlich auch Fehler. Und die versuchen wir eben in einem größeren Beta-Test mit Eurer Hilfe auszumerzen....

ok, das macht einiges klar. erstmal respekt vor der gewaltigen aufgabe, alles neu zu implementieren. aber das eröffnet ja die chance auf ganz ungeahnte möglichkeiten: z.b. das rendern mit opengl, so könnte rein theoretisch ein wenig 3d ins spiel gebracht werden.

Bei aller Liebe und Aufgeschlossenheit zu Neuem: Robot bleibt Robot. Das Ziel war und ist es die Robot-Spiele so wie sie sind und wir sie alle lieben gelernt haben zu erhalten und kein 3D-Spiel oder sonst etwas daraus zu machen. 3D-Shooter, -Adventures und ähnliches gibt es wie Sand am Meer. Robot ist und bleibt einzigartig.

3D in Robot? Sicher nicht!
Das würde zwar in der Tat völlig neue Möglichkeiten eröffnen, das Ergebnis hätte allerdings nichts mehr mit Robot zu tun.
Es ist ja gerade diese naive Draufsicht, welche dem Spiel seinen völlig eigenen Charakter verleiht.
Es gab ja schon bei Robot IV, wo wir die bewegten Figuren von schräg oben darstellen, teilweise massive Proteste von eingefleischten Robot-Spielern...

nein, falsch verstanden!! ich rede von einer draufsicht, nur eben 3d gerendert - vogelperspektive. sonst macht doch robot keinen sinn!! dann könnte man z.b. folgendes machen: einen radius um die spielerfigur legen und innerhalb dieses radius die szene darstellen. bewegt sich die figur, werden neue bereiche sichtbar und alte verschwinden - z.b. im radialen nebel. man könnte z.b. dann auch dichter hineinzoomen oder sich einen grösseren überblick verschaffen, natürlich nur soweit, dass die gamelogik nicht gestört wird - z.b. zu viel verraten wird. oder man stellt nur bereits erkundete räume dar. im einfachsten fall bräuchte man ja nicht mehr machen, als zb. mauern und palmen als einfache 3d-objekte zu zeigen. mit opengl könnten nette atmosphärische effekte wie beleuchtung zu untersch. tageszeiten usw. realisiert werden.

kennt ihr schon www.drod.net ? auch ein geniales spiel!!
geht doch da mal auf screenshots - da sind bilder von einer 3d-version dieses klassikers. so ähnlich würde ich es mir für robot vorstellen. ausserdem könnte man ja bei entspr. programmierung eine 3d-ansicht optional machen.

Klar könnte man. Werden wir aber nicht. Das Hauptproblem dabei ist, daß alle Objekte neu gezeichnet werden müßten. Wollte man eine "echte" 3D-Grafik präsentieren, würde das locker ein halbes Jahr bedeuten, die ganzen Elemente sauber in 3D zu definieren. Das passiert mit 100% Sicherheit nicht.

eigentlich müsste ja gar nichts neu gezeichnet werden, wenn man einfach die vorhandenen kacheln auf ein rechteck als textur legt. dann ist zwar alles so flach wie vorher, aber von da aus könnte man schrittweise einzelne objekte in 3d umwandeln. naja, aber es ist mir natürlich auch klar, dass der aufwand dafür sehr gross ist.

ich finde dein denken ziemlich gut, herc, ich stimme aber den anderen zu, Robot bleibt Robot, jedenfalls die alten Games... diese Ideen koennten in einem Robot V zum Einsatz kommen, das waere nicht schlecht...
------------
Don't eat clowns, they taste funny!

Jo - zu denen gehöre ich auch. Robot IV ist nicht nur reizloser 😬 , sondern meiner Meinung nach auch unübersichtlicher, wenn man Held und Robots von oben sieht 🤓 (Das "reizlose" gilt natürlich nicht für Abenteuer und die enthaltenen Ideen - die waren, wie die vorherigen auch, einfach genial). 😀
Aber 'mal was anderes :Kann man nicht eine Möglichkeit einbauen, womit man ein Spiel auch für länger unterbrechen kann ? Wenn die Zeit es erlaubt, spiele ich ab und zu im Büro. Wenn ich dann aber weg muß, muß ich entweder eine der wertvollen Uhren aufbrauchen oder den Rechner über Nacht anlassen.
Ansonsten danke für Deine Mühe Robot, weiterleben zu lassen und auch danke an Robert, der dafür gesorgt hat, daß Robot nicht gestorben ist. 😀

Für die Spielpause mache ich 'mal ein neues Topic auf!

ok, falsches forum vielleicht, aber evntl. habt ihr ja etwas zeit am sonntag nachmittag und werft einen blick auf meine neue beta-version von gravytris?
www.coreloop.com/games/gravytris
mich würde z.b. interessieren, ob noch dll's fehlen und ob es probleme mit opengl gibt. aber achtung - noch ziemlich beta...
Link aktualisiert von: Grandy02

... vor allem ziemlich falsches Topic...

naja, wollte keinen neuen thread starten...

Quote:

---

naja, wollte keinen neuen thread starten...

---

Sorry, falscher Ansatz!
1) Neue Threads kosten absolut nichts
2) Jemand, der an der Diskussion zu "technischen Fragen" kein Interesse hat, wir den Link niemals lesen.
3) Mehr als ein Topic pro Thread geht irgendwann in Chaos über
Nix für ungut... 😃

nene, andreas, das steckt ne andere logik dahinter 😀
dieser thread muss die "hottest discussion" bleiben 🙃
------------
Don't eat clowns, they taste funny!

genau, das war auch ein teil meiner strategie 🙂

nur - besser hätte ich gar nicht damit angefangen, von meiner beta zu reden, denn die scheint nur auf meinem homerechner zu laufen😖 😡 wie peinlich 😞 vermutlich gibts ein problem mit der statisch gelinkten libjpeg.
@andreas: benutzt du noch zusätzliche bibliotheken?

Ich benutze prinzipiell keine anderen Bibliotheken, gibt nur Ärger. Abgesehen natürlich von System-Bibliotheken und DirectX. Da aber auch immer nur die Standard-Versionen und nicht irgend etwas, was z.B. mit nur bei einer speziellen IE-Release existiert.
Statisch gebundene Libraries können prinzipiell nicht fehlen, da sie ja eben statisch in die Exe eingebunden sind. Eine MSVCP60.DLL, die nur nach Installation vom Visual Studio existiert, hingegen schon.
Wenn Du auf die iostreams verzichtest, solltest Du auch ohne die MSVCP60 auskommen können.

@andreas:
genau desswegen linke ich ja auch alle von mir benutzten libs statisch, ich benutze fltk (www.fltk.org), sdl, sdl_mixer, sdl_image (welches dann libjpeg und libpng benötigt). eigentlich wollte ich mein ganzes projekt mit der libcmt[d] linken, um die zusätzlichen zwei dll's msvcr71.dll und msvcp71.dll zu vermeiden, aber es ist mir nicht gelungen.
ich hatte zwar alle bibliotheken in diesem modus neu übersetzt, aber bekam immer noch konflikte zwischen msvcrt und libcmt und einige nicht aufgelöste referenzen. der einzige weg war, alles im "multithreaded debug dll" modus zu compilieren. aber jetzt spinnt anscheinend die libjpeg, da die ursprünglich wohl für single threaded gedacht war (jedenfalls war das die default einstellung im makefile) ... argh - da könnte man ...
hmm, in völliger unkenntnis über die funktionsweise von dll's - könnte es evntl. einen weg geben, die msvcr71.dll in eine statische lib umzuwandeln bzw. die obj-files in der dll zu extrahieren und diese statisch zum projekt zu linken?!?