also wenns frei verfügbar ist (und kostenlos) wirds davon auch nie ne Demoversion geben.
--
www.windowsclone.de.vu
- games & progs for casio cfx-calculators
- some old games coded in QBasic
R: technische fragen
2003-04-28 15:34 #41
www.windowsclone.de.vu
- games & progs for casio cfx-calculators
- some old games coded in QBasic
Linux is for people who want to know why it works.
Mac is for people who don't want to know why it works.
DOS is for people who want to know why it does not work.
Windows is for people who don't want to know why it does not work.
2005-11-29 19:24 #42
R=Restore (Wiederherstellung)
Durch einen präzisen Angriff auf ezBoard sind sämtliche Beiträge der Foren verloren gegangen. Durch Restore-Prozesse seitens ezBoards konnte leider nur ein winziger Teil aller Beiträge gerettet werden. Das Robot-Forum hatte es auch schwer getroffen. Durch Google-Caches und Web.Archive.org konnten viele Beiträge wieder gefunden werden. Diese hier gehören dazu. Die Diskussion kann weitergeführt werden.
herc (Thema begonnen am 28/4/03, 14:54)
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)
autofahrn
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....
herc
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.
RobinSword
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.
autofahrn
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...
herc
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.
herc
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.
autofahrn
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.
herc
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.
Mauzi
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!
dusty
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. 😀
autofahrn
Für die Spielpause mache ich 'mal ein neues Topic auf!
herc
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
autofahrn
... vor allem ziemlich falsches Topic...
herc
naja, wollte keinen neuen thread starten...
autofahrn
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... 😃
Mauzi
nene, andreas, das steckt ne andere logik dahinter 😀
dieser thread muss die "hottest discussion" bleiben 🙃
------------
Don't eat clowns, they taste funny!
herc
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?
autofahrn
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.
herc
@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?!?
autofahrn
Mann, sind wir hier off-Topic... 😉
Habe ohnehin erst eben gemerkt, daß ich die alte colotris-Version "geprüft" hab. Den neuen Link hast Du ja wohl schon wieder entfernt... 😉
Hilfreich beim Feststellen, welche Libraries eine Applikation benötigt, ist noch immer Depends, welches Du z.B. im Platform-SDK findest.
Die LibCxx ist die "normale" Standard-Library, welche Funktionien wie strcpy und printf usw. abdeckt.
Die MSVCxxx sind, wie der Name schon sagt, die zur jeweiligen VC-Version passenden DLLs, die zusätzliche Funktionen wie z.B. Unicode-Handling beinhalten.
Wie Du schon geschrieben hast, kann man nicht gleichzeitig zu beiden Libraries linken und sollte sich auf die statische LIBCxx beschränken.
Die Debug/Release-Versionen sollten prinzipiell mischbar sein. Die Debug-Version enthält nur zusätzlichen Code, der z.B. bei Funktions-Aufrufen den lokalen Stack-Frame initialisiert oder grundsätzlich einen Frame-Pointer mitführt, auch wenn die Funktion gar keine lokalen Variablen hat.
Wenn Dein Programm nur in der Debug-Variante sauber läuft, hast Du wahrscheinlich irgend etwas nicht initialisiert (z.B. Elemente in Deinen Objekten).
In der Multi-Threaded LibCxx werden einige Symbole anders exportiert, als in der Single-Threaded-Variante. Schau' Dir einmal die Deklaration von errno an... Hier muß sich das Projekt und alle DLLs völlig einig sein.
Ansonsten hat das nur den Sinn, daß die DLLs z.B. den Zugriff auf zentrale Strukturen absichern. Folglich ist die MT-Variante grundsätzlich ein wenig langsamer. Ob Du sie brauchst, hängt nur davon ab, ob in Deinem Programm mehr als ein Thread werkelt (z.B. Sound-Ausgabe).
Wenn Du, so wie ich, die Standard-Library gar nicht verwendest (insbesondere nicht die I/O-Funktionen), kannst Du die Einstellung getrost auf Single-Threaded lassen.
So, jetzt reicht's erstmal...
herc
ok, danke erstmal für deine info's !! vielleicht nehm ich nochmal einen anlauf und versuche mein programm im multithreaded modus (/MT) zu übersetzen. multithreading brauch ich wohl für die soundlib.
herc
ach ja, die neue (defekte beta) und ein paar funktionierende alte betas findest du unter www.andre-krause.net/tetris/beta
autofahrn
Wie gesagt: Solange Deine Threads die Standard-Library (I/O und so weiter) nicht aufrufen, brauchst Du Dir um /MT keine Gedanken zu machen!
autofahrn
Was machst Du mit OLE? Bei mir fliegt er mit einem eindeutigen NULL-Pointer-Zugriff in OLE32 raus. (nach dem Laden von "fname:data/wav/voice_well_done.wav idx:2663324"
Du kannst Dir ja 'mal meine AutoDbg-DLL auf meiner Tools-Seite (http://www.tofahrn.de/tools) anschauen. Die listet Dir den ganzen Call-Stack auch bei einer Release-Version (mit den richtigen Compiler-Optionen, versteht sich).
herc
@andreas: ja, ich komme wohl nicht drumherum, mir endlich mal die bedeutung der verschiedenen laufzeitbibliotheken klar zu machen und deine debug-dll werde ich auch probieren. denn so geht es nicht weiter *entnervt*. habe mich bisher sehr erfolgreich um solche probleme drumherumgemogelt, aber ab einer gewissen projektkomplexität geht es nicht mehr ohne vernünftiges debuggen. vielleicht war es auch ein fehler, so schnell auf visual studio .net 2003 beta(!!) upzugraden.. aber ich denke der fehler liegt wohl viel eher bei mir. hoffentlich kann ich vc6 noch parallel wieder dazuinstallieren..
OLE benutze ich überhaupt nicht - wirklich sehr komisch - ich wüsste auch nicht, welche lib davon abhängt. fltk-windowstoolkit jedenfalls bietet kein ole.
übrigens muss ich jetzt bei meinem uni-projekt eine weitere "lustige" erfahrung machen: mein programm stürzt im release-modus gestartet mit strg+f5 ab, aber im debugger läuft es problemlos. wie kann sowas sein? initialisiert mir der debugger etwa variablen / zeiger mit null, die sonst zufällig belegt wären? merkwürdig.
autofahrn
Die Initialisierung wird allerdings nicht mit 0 sondern mit CCh (INT3, Breakpoint-Code) durchgeführt. Damit sind garantiert alle Pointer auch bei Lesezugriffen ungültig (0xCCCCCCCC liegt in der Kernel-Area).
Bei numerischen Werten hängt die Wirkung natürlich stark von deren Bedeutung ab. Integer-Werte sind z.B. negativ, unsigned Variablen ziemlich groß.
Natürlich kostet das Füllen (beim Funktionseintritt) und das Testen (beim Verlassen der Funktion) entsprechend Zeit. Ob Du da ein Problem hast, kannst Du natürlich leicht feststellen, wenn Du in der Debug-Build die entsprechenden Optionen abschaltest. Näheres dazu habe ich Dir per Mail zukommen lassen (Du solltest auf Deiner Web-Site ggf. einen Mail-Link anbringen, und fehlendes Impressum/Kontakt/Urheber kann heutzutage auch teuer werden...).
In der Release-Build wird der Stack-Frame nicht initialisiert, sodaß die Variablen mit ziemlich zufälligen Werten gefüllt sind.
Beides hat natürlich einen unterhaltsamen Einfluß auf Bitfelder. In der Debug-Build haben diese logischerweise immer einen definierten Zustand.
Solange Du nur C verwendest, meckert der Compiler normalerweise ziemlich zuverlässig an, wenn Du auf eine lokale Variable lesend zugreifst, bevor diese initialisiert wurde (Ausnahme sind natürlich lokale Arrays, die über Zeiger verarbeitet werden).
Wenn Du C++-Objekte auf dem Stack liegen hast, wird hingegen keinerlei Warnung ausgespuckt, und die Fehler treten in der Regel erst viel später auf. Diese Dinger liebe ich ganz besonders, da man sie nur ziemlich schwierig findet...
Ford
Wo ich das hier so lese...
Anscheinend gibt es ja noch mehr Programiertechnisch begabte Leute in der Robot-Community (kann man das eigentlich schon so nennen? 😃
autofahrn, wie stehst du der Idee gegenüber aus Robot V ein open Source Projekt zu machen?
Wenn ich das richtig verstanden habe bist du im moment allein was Robot angeht.
Ich hab leider keinen Schimmer vom Programmieren (bekomme ja nichtmal die dämlichen Robot I Gatter in die richtige Reinfolge *g) aber mit anderen interessierten gemeinsam müsste es doch machbar sein, wenn man sich ein wenig abspricht, ein neues Projekt zu starten?
Was ins Officelle Tom Productions Release reinkäme und was nicht, müsstest du natürlich immernoch selbst entscheiden, aber zeichen und programmierarbeit aufteilen und gemeinsam Konzepte erarbeiten, anstelle sich von tausend Anfragen nerven zu lassen, wann es denn soweit ist, und was drin ist und warum du nicht dieses oderjenes Feature eingebaut hast, stelle ich mir besser vor...
Nur 'ne Idee 😃
autofahrn
So gut ich die Idee einer konzertierten Aktion ja auch finde, aber was von meiner Seite absolut dagegen spricht ist der Zeitaufwand.
An einem Spiel wie Robot III haben wir zu dritt ein knappes Jahr vollzeitmäßig beschäftigt. Wenn man da ein abendliches Freizeitvergnügen draus macht, wird das ein ewiges Unterfangen. Vom Aufwand der notwendigen Koordination einmal ganz abgesehen.
Wenn es irgendwann ein Robot V gibt, dann eines basierend auf dem Skript, das schon ewig hier rumliegt und mit Christian zusammen. Sonst wäre es nicht TOM Productions und wahrscheinlich auch kein Robot.
Und mit den ständigen Anfragen zu einem Robot V habe ich in den letzten 10 Jahren gut umgehen gelernt... 😉
herc
@andreas: ich missbrauche mal wieder diesen thread 😉
also ich habe es nach 1 woche ständigem neucompilieren diverser opensource-libs endlich geschafft, mein tetris im multitreaded modus zu compilieren, also brauche ich jetzt tatsächlich nicht mehr die beiden runtime-dll's dazupacken. nur eine einzige exe-datei - kein installieren, kein deinstallieren 🙂
was mich eine woche aufgehalten hat: eine mit der soundlib sdl_mixer wurde eine statische ogg-vorbis lib mitgeliefert, die zur sdl_mixer lib hinzugelinkt wurde. die war aber anscheinend im single-threaded-modus compiliert. diese eine lib war wohl für die ganzen nicht aufzulösenden referenzen und anscheinend auch seltsame bugs verantwortlich.
autofahrn
Ach, das bestätigt mich 'mal wieder, nur die Standard-Schnittstellen vom System zu verwenden und alles andere ggf. selber neu zu schreiben. Kostet zwar auch immer ein wenig Zeit, aber wenigstens behält man den vollen Überblick...
moormaster
Von welcher Programmiersprache sprechen wir hier eigentlich?
Mich nervt das nämlich auch, dass man zumindest bei Visual Basic jede Menge DLL-Dateien benötigt, um das kompilierte Programm dann auszuführen. So müssen auf jedem Rechner entweder die Visual Basic Runtime-Files (oder gar Visual Basic an sich) installiert sein oder ich muss ein Setup erstellen.
autofahrn
Was mich betrifft, so ist alles OK, wo ein C drin vorkommt. Also C, C++, Objective C (Mac). Aber auch A ist OK, so wie in Assembler.
Gilt also offensichtlich nicht für VisualBähsik... 😉 Nix gegen die Sprache an sich, vor allem für GUI-basierte Applikationen hat VB einige Vorteile. Aber bei mir geht's irgendwie immer um Performance oder Kompaktheit. Schonmal einen kompletten Logik-Simulator mit Library-Editor für Win32 in entpackten 460kB gesehen? Liegt auf meiner Web-Site (www.tofahrn.de) bei den Tools.
moormaster
Für einige Sachen nehm ich auch lieber Turbo Pascal. Manche Sachen enden in VB manchmal in zu viel Fummelarbeit, vor allem, wenn man mal nur kurz was bestimmtes probieren wollte und nicht vor hatte, gleich ein komplettes Layout für das Programm mitzuerstellen.
RobinSword
@andreas: Auch C# ? 😀
---
Robert Schwortschik, Webmaster Game-of-Robot.de
autofahrn
Ist in ZehSharp etwa ein C ???
Nunja, zumindest einmal reingeschnuppert habe ich. Solange das aber eine proprietäre Plattform bleibt, ist das noch keine Option für mich.
Da wäre Java für mich sicher noch eher einarbeitungswürdig...
herc
ich benutze visual c++
es wurde übrigens schon ein nachfolger von c++ angedacht, die programmiersprache "D"
(www.digitalmars.com)
autofahrn
Genau, da war doch was. Hab's mir eben nochmal angeschaut, die beschriebene Funktionalität ist schon beeindruckend. Bin mir aber nicht sicher ob sich die genannten Features nicht wieder negativ auf das Laufzeitverhalten auswirken.
Dynamische Arrays und Garbage-Collection. Das klingt schon wieder nach viel Code, den man nicht sieht. Davon gibt's schon bei C++ genug, vor allem wenn man fremde Klassen einsetzt.
Ich erinnere mich da an einen dicken Multiprozessor Sun-Application-Server, auf dem eine dicke Java-Applikation lief. Ging alles super, bis man ihn unter Last gesetzt hat. Alle CPUs haben fleissig Daten produziert, nur war das zu viel für den Garbage-Collection-Thread, welcher an eine CPU gebunden und damit viel zu langsam war. Ist schon schick, wenn ab einigen 100 Connects das Teil zuverlässig Core-Dumpt...
Zumindest vervollständigt das mein Sprach-Alphabet:
Assembler
Basic
Cobol, C, C++, C#
D (bischen langweilig..)
Eiffel
Fortran
g++ (Gnu C++-Compiler)
HcRtf (Microsoft Help-Compiler)
Wie geht's weiter?
moormaster
HcRtf? Gibts den als Demo irgendwo zum Download?
--
www.windowsclone.de.vu
- games & progs for casio cfx-calculators
- some old games coded in QBasic
--
www.windowsclone.de.vu
- games & progs for casio cfx-calculators
- some old games coded in QBasic
autofahrn
Hmm, 'ne Demo habe ich davon noch nicht gesehen, allerdings ist das ohnehin frei verfügbar über den Help Workshop. Einfach 'mal nach "Help Workshop" googeln...
moormaster
also wenns frei verfügbar ist (und kostenlos) wirds davon auch nie ne Demoversion geben.
--
www.windowsclone.de.vu
- games & progs for casio cfx-calculators
- some old games coded in QBasic
Die restlichen Beiträge konnten bisher nicht restauriert werden, es darf aber trotzdem weiterhin diskutiert werden.
Durch einen präzisen Angriff auf ezBoard sind sämtliche Beiträge der Foren verloren gegangen. Durch Restore-Prozesse seitens ezBoards konnte leider nur ein winziger Teil aller Beiträge gerettet werden. Das Robot-Forum hatte es auch schwer getroffen. Durch Google-Caches und Web.Archive.org konnten viele Beiträge wieder gefunden werden. Diese hier gehören dazu. Die Diskussion kann weitergeführt werden.
herc (Thema begonnen am 28/4/03, 14:54)
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)
autofahrn
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....
herc
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.
RobinSword
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.
autofahrn
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...
herc
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.
herc
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.
autofahrn
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.
herc
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.
Mauzi
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!
dusty
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. 😀
autofahrn
Für die Spielpause mache ich 'mal ein neues Topic auf!
herc
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
autofahrn
... vor allem ziemlich falsches Topic...
herc
naja, wollte keinen neuen thread starten...
autofahrn
Sorry, falscher Ansatz!Quote:
naja, wollte keinen neuen thread starten...
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... 😃
Mauzi
nene, andreas, das steckt ne andere logik dahinter 😀
dieser thread muss die "hottest discussion" bleiben 🙃
------------
Don't eat clowns, they taste funny!
herc
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?
autofahrn
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.
herc
@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?!?
autofahrn
Mann, sind wir hier off-Topic... 😉
Habe ohnehin erst eben gemerkt, daß ich die alte colotris-Version "geprüft" hab. Den neuen Link hast Du ja wohl schon wieder entfernt... 😉
Hilfreich beim Feststellen, welche Libraries eine Applikation benötigt, ist noch immer Depends, welches Du z.B. im Platform-SDK findest.
Die LibCxx ist die "normale" Standard-Library, welche Funktionien wie strcpy und printf usw. abdeckt.
Die MSVCxxx sind, wie der Name schon sagt, die zur jeweiligen VC-Version passenden DLLs, die zusätzliche Funktionen wie z.B. Unicode-Handling beinhalten.
Wie Du schon geschrieben hast, kann man nicht gleichzeitig zu beiden Libraries linken und sollte sich auf die statische LIBCxx beschränken.
Die Debug/Release-Versionen sollten prinzipiell mischbar sein. Die Debug-Version enthält nur zusätzlichen Code, der z.B. bei Funktions-Aufrufen den lokalen Stack-Frame initialisiert oder grundsätzlich einen Frame-Pointer mitführt, auch wenn die Funktion gar keine lokalen Variablen hat.
Wenn Dein Programm nur in der Debug-Variante sauber läuft, hast Du wahrscheinlich irgend etwas nicht initialisiert (z.B. Elemente in Deinen Objekten).
In der Multi-Threaded LibCxx werden einige Symbole anders exportiert, als in der Single-Threaded-Variante. Schau' Dir einmal die Deklaration von errno an... Hier muß sich das Projekt und alle DLLs völlig einig sein.
Ansonsten hat das nur den Sinn, daß die DLLs z.B. den Zugriff auf zentrale Strukturen absichern. Folglich ist die MT-Variante grundsätzlich ein wenig langsamer. Ob Du sie brauchst, hängt nur davon ab, ob in Deinem Programm mehr als ein Thread werkelt (z.B. Sound-Ausgabe).
Wenn Du, so wie ich, die Standard-Library gar nicht verwendest (insbesondere nicht die I/O-Funktionen), kannst Du die Einstellung getrost auf Single-Threaded lassen.
So, jetzt reicht's erstmal...
herc
ok, danke erstmal für deine info's !! vielleicht nehm ich nochmal einen anlauf und versuche mein programm im multithreaded modus (/MT) zu übersetzen. multithreading brauch ich wohl für die soundlib.
herc
ach ja, die neue (defekte beta) und ein paar funktionierende alte betas findest du unter www.andre-krause.net/tetris/beta
autofahrn
Wie gesagt: Solange Deine Threads die Standard-Library (I/O und so weiter) nicht aufrufen, brauchst Du Dir um /MT keine Gedanken zu machen!
autofahrn
Was machst Du mit OLE? Bei mir fliegt er mit einem eindeutigen NULL-Pointer-Zugriff in OLE32 raus. (nach dem Laden von "fname:data/wav/voice_well_done.wav idx:2663324"
Du kannst Dir ja 'mal meine AutoDbg-DLL auf meiner Tools-Seite (http://www.tofahrn.de/tools) anschauen. Die listet Dir den ganzen Call-Stack auch bei einer Release-Version (mit den richtigen Compiler-Optionen, versteht sich).
herc
@andreas: ja, ich komme wohl nicht drumherum, mir endlich mal die bedeutung der verschiedenen laufzeitbibliotheken klar zu machen und deine debug-dll werde ich auch probieren. denn so geht es nicht weiter *entnervt*. habe mich bisher sehr erfolgreich um solche probleme drumherumgemogelt, aber ab einer gewissen projektkomplexität geht es nicht mehr ohne vernünftiges debuggen. vielleicht war es auch ein fehler, so schnell auf visual studio .net 2003 beta(!!) upzugraden.. aber ich denke der fehler liegt wohl viel eher bei mir. hoffentlich kann ich vc6 noch parallel wieder dazuinstallieren..
OLE benutze ich überhaupt nicht - wirklich sehr komisch - ich wüsste auch nicht, welche lib davon abhängt. fltk-windowstoolkit jedenfalls bietet kein ole.
übrigens muss ich jetzt bei meinem uni-projekt eine weitere "lustige" erfahrung machen: mein programm stürzt im release-modus gestartet mit strg+f5 ab, aber im debugger läuft es problemlos. wie kann sowas sein? initialisiert mir der debugger etwa variablen / zeiger mit null, die sonst zufällig belegt wären? merkwürdig.
autofahrn
Hatte ich mir schon gedacht. Es lebe .net ...Quote:
OLE benutze ich überhaupt nicht
Die wesentliche Laufzeit-Änderung im Debug-Modus ist, daß jeder Stack-Frame initialisiert und mit einer Guard-Area versehen wird. Die Guard-Area hat den Sinn, übergelaufene Puffer festzustellen, was in der Regel recht zuverlässig funktioniert.Quote:
übrigens muss ich jetzt bei meinem uni-projekt eine weitere "lustige" erfahrung machen: mein programm stürzt im release-modus gestartet mit strg+f5 ab, aber im debugger läuft es problemlos. wie kann sowas sein? initialisiert mir der debugger etwa variablen / zeiger mit null, die sonst zufällig belegt wären? merkwürdig.
Die Initialisierung wird allerdings nicht mit 0 sondern mit CCh (INT3, Breakpoint-Code) durchgeführt. Damit sind garantiert alle Pointer auch bei Lesezugriffen ungültig (0xCCCCCCCC liegt in der Kernel-Area).
Bei numerischen Werten hängt die Wirkung natürlich stark von deren Bedeutung ab. Integer-Werte sind z.B. negativ, unsigned Variablen ziemlich groß.
Natürlich kostet das Füllen (beim Funktionseintritt) und das Testen (beim Verlassen der Funktion) entsprechend Zeit. Ob Du da ein Problem hast, kannst Du natürlich leicht feststellen, wenn Du in der Debug-Build die entsprechenden Optionen abschaltest. Näheres dazu habe ich Dir per Mail zukommen lassen (Du solltest auf Deiner Web-Site ggf. einen Mail-Link anbringen, und fehlendes Impressum/Kontakt/Urheber kann heutzutage auch teuer werden...).
In der Release-Build wird der Stack-Frame nicht initialisiert, sodaß die Variablen mit ziemlich zufälligen Werten gefüllt sind.
Beides hat natürlich einen unterhaltsamen Einfluß auf Bitfelder. In der Debug-Build haben diese logischerweise immer einen definierten Zustand.
Solange Du nur C verwendest, meckert der Compiler normalerweise ziemlich zuverlässig an, wenn Du auf eine lokale Variable lesend zugreifst, bevor diese initialisiert wurde (Ausnahme sind natürlich lokale Arrays, die über Zeiger verarbeitet werden).
Wenn Du C++-Objekte auf dem Stack liegen hast, wird hingegen keinerlei Warnung ausgespuckt, und die Fehler treten in der Regel erst viel später auf. Diese Dinger liebe ich ganz besonders, da man sie nur ziemlich schwierig findet...
Ford
Wo ich das hier so lese...
Anscheinend gibt es ja noch mehr Programiertechnisch begabte Leute in der Robot-Community (kann man das eigentlich schon so nennen? 😃
autofahrn, wie stehst du der Idee gegenüber aus Robot V ein open Source Projekt zu machen?
Wenn ich das richtig verstanden habe bist du im moment allein was Robot angeht.
Ich hab leider keinen Schimmer vom Programmieren (bekomme ja nichtmal die dämlichen Robot I Gatter in die richtige Reinfolge *g) aber mit anderen interessierten gemeinsam müsste es doch machbar sein, wenn man sich ein wenig abspricht, ein neues Projekt zu starten?
Was ins Officelle Tom Productions Release reinkäme und was nicht, müsstest du natürlich immernoch selbst entscheiden, aber zeichen und programmierarbeit aufteilen und gemeinsam Konzepte erarbeiten, anstelle sich von tausend Anfragen nerven zu lassen, wann es denn soweit ist, und was drin ist und warum du nicht dieses oderjenes Feature eingebaut hast, stelle ich mir besser vor...
Nur 'ne Idee 😃
autofahrn
So gut ich die Idee einer konzertierten Aktion ja auch finde, aber was von meiner Seite absolut dagegen spricht ist der Zeitaufwand.
An einem Spiel wie Robot III haben wir zu dritt ein knappes Jahr vollzeitmäßig beschäftigt. Wenn man da ein abendliches Freizeitvergnügen draus macht, wird das ein ewiges Unterfangen. Vom Aufwand der notwendigen Koordination einmal ganz abgesehen.
Wenn es irgendwann ein Robot V gibt, dann eines basierend auf dem Skript, das schon ewig hier rumliegt und mit Christian zusammen. Sonst wäre es nicht TOM Productions und wahrscheinlich auch kein Robot.
Und mit den ständigen Anfragen zu einem Robot V habe ich in den letzten 10 Jahren gut umgehen gelernt... 😉
herc
@andreas: ich missbrauche mal wieder diesen thread 😉
also ich habe es nach 1 woche ständigem neucompilieren diverser opensource-libs endlich geschafft, mein tetris im multitreaded modus zu compilieren, also brauche ich jetzt tatsächlich nicht mehr die beiden runtime-dll's dazupacken. nur eine einzige exe-datei - kein installieren, kein deinstallieren 🙂
was mich eine woche aufgehalten hat: eine mit der soundlib sdl_mixer wurde eine statische ogg-vorbis lib mitgeliefert, die zur sdl_mixer lib hinzugelinkt wurde. die war aber anscheinend im single-threaded-modus compiliert. diese eine lib war wohl für die ganzen nicht aufzulösenden referenzen und anscheinend auch seltsame bugs verantwortlich.
autofahrn
Ach, das bestätigt mich 'mal wieder, nur die Standard-Schnittstellen vom System zu verwenden und alles andere ggf. selber neu zu schreiben. Kostet zwar auch immer ein wenig Zeit, aber wenigstens behält man den vollen Überblick...
moormaster
Von welcher Programmiersprache sprechen wir hier eigentlich?
Mich nervt das nämlich auch, dass man zumindest bei Visual Basic jede Menge DLL-Dateien benötigt, um das kompilierte Programm dann auszuführen. So müssen auf jedem Rechner entweder die Visual Basic Runtime-Files (oder gar Visual Basic an sich) installiert sein oder ich muss ein Setup erstellen.
autofahrn
Was mich betrifft, so ist alles OK, wo ein C drin vorkommt. Also C, C++, Objective C (Mac). Aber auch A ist OK, so wie in Assembler.
Gilt also offensichtlich nicht für VisualBähsik... 😉 Nix gegen die Sprache an sich, vor allem für GUI-basierte Applikationen hat VB einige Vorteile. Aber bei mir geht's irgendwie immer um Performance oder Kompaktheit. Schonmal einen kompletten Logik-Simulator mit Library-Editor für Win32 in entpackten 460kB gesehen? Liegt auf meiner Web-Site (www.tofahrn.de) bei den Tools.
moormaster
Für einige Sachen nehm ich auch lieber Turbo Pascal. Manche Sachen enden in VB manchmal in zu viel Fummelarbeit, vor allem, wenn man mal nur kurz was bestimmtes probieren wollte und nicht vor hatte, gleich ein komplettes Layout für das Programm mitzuerstellen.
RobinSword
@andreas: Auch C# ? 😀
---
Robert Schwortschik, Webmaster Game-of-Robot.de
autofahrn
Ist in ZehSharp etwa ein C ???
Nunja, zumindest einmal reingeschnuppert habe ich. Solange das aber eine proprietäre Plattform bleibt, ist das noch keine Option für mich.
Da wäre Java für mich sicher noch eher einarbeitungswürdig...
herc
ich benutze visual c++
es wurde übrigens schon ein nachfolger von c++ angedacht, die programmiersprache "D"
(www.digitalmars.com)
autofahrn
Genau, da war doch was. Hab's mir eben nochmal angeschaut, die beschriebene Funktionalität ist schon beeindruckend. Bin mir aber nicht sicher ob sich die genannten Features nicht wieder negativ auf das Laufzeitverhalten auswirken.
Dynamische Arrays und Garbage-Collection. Das klingt schon wieder nach viel Code, den man nicht sieht. Davon gibt's schon bei C++ genug, vor allem wenn man fremde Klassen einsetzt.
Ich erinnere mich da an einen dicken Multiprozessor Sun-Application-Server, auf dem eine dicke Java-Applikation lief. Ging alles super, bis man ihn unter Last gesetzt hat. Alle CPUs haben fleissig Daten produziert, nur war das zu viel für den Garbage-Collection-Thread, welcher an eine CPU gebunden und damit viel zu langsam war. Ist schon schick, wenn ab einigen 100 Connects das Teil zuverlässig Core-Dumpt...
Zumindest vervollständigt das mein Sprach-Alphabet:
Assembler
Basic
Cobol, C, C++, C#
D (bischen langweilig..)
Eiffel
Fortran
g++ (Gnu C++-Compiler)
HcRtf (Microsoft Help-Compiler)
Wie geht's weiter?
moormaster
HcRtf? Gibts den als Demo irgendwo zum Download?
--
www.windowsclone.de.vu
- games & progs for casio cfx-calculators
- some old games coded in QBasic
--
www.windowsclone.de.vu
- games & progs for casio cfx-calculators
- some old games coded in QBasic
autofahrn
Hmm, 'ne Demo habe ich davon noch nicht gesehen, allerdings ist das ohnehin frei verfügbar über den Help Workshop. Einfach 'mal nach "Help Workshop" googeln...
moormaster
also wenns frei verfügbar ist (und kostenlos) wirds davon auch nie ne Demoversion geben.
--
www.windowsclone.de.vu
- games & progs for casio cfx-calculators
- some old games coded in QBasic
Die restlichen Beiträge konnten bisher nicht restauriert werden, es darf aber trotzdem weiterhin diskutiert werden.
2005-11-29 19:25 #43
R=Restore (Wiederherstellung)
Durch einen präzisen Angriff auf ezBoard sind sämtliche Beiträge der Foren verloren gegangen. Durch Restore-Prozesse seitens ezBoards konnte leider nur ein winziger Teil aller Beiträge gerettet werden. Das Robot-Forum hatte es auch schwer getroffen. Durch Google-Caches und Web.Archive.org konnten viele Beiträge wieder gefunden werden. Diese hier gehören dazu. Die Diskussion kann weitergeführt werden.
Die restlichen Beiträge konnten bisher nicht restauriert werden, es darf aber trotzdem weiterhin diskutiert werden.
2005-12-13 14:13 #44
Der Tannenbaum jedoch wurde, als Objekt aus der Vorderansicht, in seinem Ur-Zustand belassen. Gibt es da einen bestimmten Grund für?Quote:
Original geschrieben von autofahrn
...Robot IV, wo wir die bewegten Figuren von schräg oben darstellen...
2005-12-13 23:07 #45
Ich denke 'mal, bei den paar Pixeln hätte das Teil nicht mehr nach Tanne ausgesehen. Aber für eine endgültige Klärung kommt die Frage irgendwie 10 Jahre zu spät...😉Quote:
Der Tannenbaum jedoch wurde, als Objekt aus der Vorderansicht, in seinem Ur-Zustand belassen. Gibt es da einen bestimmten Grund für?
...und zu den "bewegten Figuren" zählt die Tanne ohnehin nicht...😉
