Eben. Ich verstehe hier die Notwendigkeit gar nicht. Wer ein PC-Spiel machen will, der hat Möglichkeiten ohne Ende. Und das hat wie gesagt auch eigentlich überhaupt nix mit dem Thema hier zu tun. Hier geht es um mögliche Turbo-Erweiterungen für den C64 und Software die man dafür schreiben könnte, aber nicht um irgendwelche C++-Libs für den PC, wovon wie gesagt schon massenhaft existiert, man muss sich da nur umschauen und bedienen.
Hallo Besucher, der Thread wurde 5,1k mal aufgerufen und enthält 38 Antworten
letzter Beitrag von Lutz G am
Neue Herausforderung durch Lib-Begrenzung?
- bernhard
- Erledigt
-
-
siehe SDL.
vielleicht ist es so. wenn man es enorm abspeckt.
würdest du heute abend mal gern schnell die dsl biblithek für amiga schreiben wollen?
ich nicht.würdest du wollen dass dir als programmieranfänger jemand empfiehlt, "ach, schreibs mal schnell in dsl".
Eben. Ich verstehe hier die Notwendigkeit gar nicht. Wer ein PC-Spiel machen will, der hat Möglichkeiten ohne Ende. Und das hat wie gesagt auch eigentlich überhaupt nix mit dem Thema hier zu tun. Hier geht es um mögliche Turbo-Erweiterungen für den C64 und Software die man dafür schreiben könnte, aber nicht um irgendwelche C++-Libs für den PC, wovon wie gesagt schon massenhaft existiert, man muss sich da nur umschauen und bedienen.
alle diese bibliotheken tendieren dazu oft sehr überladen zu sein.
ich möchte gar nicht dran denken, dsl auf scientific linux zum laufen zu bringen. weißt du wies geht?
-
vielleicht ist es so. wenn man es enorm abspeckt.
würdest du heute abend mal gern schnell die dsl biblithek für amiga schreiben wollen?
ich nicht.
Gibt es schon für sogenannte NextGen-Amigas und wurde schon für einige Projekte eingesetzt. Aber für die klassischen Amigas zu schwerfällig.
würdest du wollen dass dir als programmieranfänger jemand empfiehlt, "ach, schreibs mal schnell in dsl".
Bist du ein Anfänger? Sag das doch gleich.
alle diese bibliotheken tendieren dazu oft sehr überladen zu sein.
Mach doch folgendes: Schreib für den Amiga nativ die Funktionen, die du brachst. Dann setze dieselben Funktionsaufrufe in indirekte SDL-Aufrufe um, für alle Platformen, die du unterstützen willst. Schon hast du alles, was du brauchst.
ich möchte gar nicht dran denken, dsl auf scientific linux zum laufen zu bringen. weißt du wies geht?
Stimmt, da war doch nochmal was mit scientific linux. Läuft das inzwischen wie gewünscht? -
geringe hardwarestandards, um sie überall leicht implentieren zu können, und vorallem,
dass es keine einarbeitung braucht.keine geschwindigkeits- oder speicherbeschränkung, um keine unnötigen limiten aufzubauen.
ich sage nur mal 3d-spiele etc.3d-Spiele und geringe Hardwarestandards sowie generell einfache Programmierung sind Dinge, die sich widersprechen.
"rennt das auf deinem selbstgebasteltem computer?".
"nein, dann nimmst du die einfachen 3d-routinen ohne textures",Dann müßtest Du auch vorher sagen, auf welche Art Texture mapping sich das bezieht. Zitat aus Wikipedia: "multi-pass rendering and complex mapping such as height mapping, bump mapping, normal mapping, displacement mapping, reflection mapping, specular mapping, mipmaps, occlusion mapping". Auf welchem Stand sollen sich denn die Graphiken bewegen? Anfang der 1990er? Schon das inflationär gebrauchte Alpha blending ließe sich mit dem Prozessor allein nicht bewerkstelligen, geschweige denn daß beim simplen Weglassen eine brauchbare Spielanzeige zurückbliebe.
Ich hatte mich etwas früher in diesem Thread kritisch gegenüber dem Konzept einer einheitlichen 3d-Schnittstelle für alle Spiele geäußert, und mit einer einheitlichen 3d-Engine für mehrere Rechner verhält es sich meiner Ansicht nach ähnlich. "Auf die schnelle ein 3d-Spiel machen" wird so nicht gelingen. Ich weiß ja nicht, wie weit Deine Programmiererfahrungen reichen, aber ich würde mir das nicht zutrauen.
alle diese bibliotheken tendieren dazu oft sehr überladen zu sein.
Wie gesagt: Niemand zwingt Dich dazu, alle Routinen zu verwenden. Von SDL benutze ich auch nur eine Handvoll, alle anderen Graphikprimitive (Linienziehen, Polygonmalen etc) habe ich selber nach meinem Bedarf in C oder x86-Assembler geschrieben. Aber nochmal: Irgendwie mußt Du z. B. die Tasten von der Tastatur empfangen oder in den Vollbildschirm-Modus schalten oder einen Callback haben für die Audioausgabe. Damit ist man extrem abhängig vom Betriebssystem, denn einen direkten Zugriff auf die Hardware hat man auf dem PC sowieso nicht mehr, und SDL schafft es schon, hier eine Abstraktionsschicht drüberzuziehen. Das macht die Bibliothek aber auch automatisch groß. Nebenbei: Willst Du wirklich das Rad immer wieder neu erfinden und für verschiedene Audioformate (wav, mp3, ogg, flac) jedes Mal eine neue Laderoutine schreiben? Für sowas habe ich echt keine Zeit mehr.
-
SDL ist überhaupt nicht überladen und zudem für eine Vielzahl an Plattformen verfügbar, was unter anderem auch daran liegt, dass es die schon ziemlich lange gibt.
-
Stimmt, da war doch nochmal was mit scientific linux. Läuft das inzwischen wie gewünscht?
ja, das latex geht jetzt.
ich werde heute nur missverstanden.
nochmal: bibliotheken verwenden was man will, natürlich auch die standard c++ laderoutinen.
nur statisch gelinkt einbinden.es geht nur um den hardwarezugriff. den einfach gestalten.
poke x,y, farbe
das ist für jeden anfänger eine freude. "ach, schau ich habe jetzt ein pixel gesetzt."
es muss für anfänger eine freude sein.
das meinte ich, ogd.nur so kann es ein homecomputer sein.
es muss auch leicht auf einer neu konstruierten hardware zu implementieren sein.
wer möchte dann sdl bibliotheken schreiben? -
es geht nur um den hardwarezugriff. den einfach gestalten.
poke x,y, farbe
das ist für jeden anfänger eine freude. "ach, schau ich habe jetzt ein pixel gesetzt."
Wie willst du das syntaktisch in c++ umsetzen? Oder schwebt dir eine andere/neue Sprache vor?Ginge zum Beispiel auch?
poke(x,y, farbe)
bzw. noch aussagekräftiger:
putpixel(x,y, farbe)
-
Alles anzeigen
Wie willst du das syntaktisch in c++ umsetzen? Oder schwebt dir eine andere/neue Sprach vor?
Ginge zum Beispiel auch?
poke(x,y, farbe)
bzw. noch aussagekräftiger:
putpixel(x,y, farbe)
sicher ginge das auch, das ist ja nur zur erläuterung.
-
Aber genau das ist doch auch mit SDL möglich. Um dieses "Erfolgserlebnis" zu bekommen, reichen mit SDL ein paar Zeilen. Im wesentlichen das Initialisieren des Bildschirms (was in der von Dir vorgeschlagenen Lib ja auch vorkäme) und danach das Setzen eines Pixels. Das ist mit Klammern und Include-Zeilen und allem auch nicht länger als die von Dir vorgeschlagene Lösung. Nur dass ich unter SDL stattdessen auch direkt ein PNG laden und auf den Bildschirm setzen kann, statt eines einzelnen Pixels - wenn ich das will. Und das hat am Ende auch nur 2-3 Zeilen mehr.
-
Dann schau dir mal das an: https://www.libsdl.org/release…docs/html/guidevideo.html
Dort gibt es ein Beispiel für so eine Funktion, die wie folgt aufgerufen wird:
putpixel(SDL_Surface *surface, int x, int y, Uint32 pixel)
Wenn dir das zu viele Parameter sind, schreibst du einfach ein Makro. Im Wesentlichen so:
#define PUTPIXEL(x, y, pixel) putpixel(SDL_Surface *surface, int x, int y, Uint32 pixel)
Kannst in deinem Programm dann einen Punkt so setzen:
PUTPIXEL(x, y, farbe);
(Wobei farbe vorher per SDL_MapRGB() aufbereitet werden muss. Aber das lässt sich auch mit einem Makro verstecken.)
Auf einem klassischen Amiga schreibst du dann eine Funktion und kein Makro, vieleicht sogar per Inline Assembler statt in c:
void PUTPIXEL(int x, int y, Uint32 pixel) {
...
}So ganz grob. Aber das Prinzip sollte schon klar sein.
-
Aber genau das ist doch auch mit SDL möglich. Um dieses "Erfolgserlebnis" zu bekommen, reichen mit SDL ein paar Zeilen. Im wesentlichen das Initialisieren des Bildschirms (was in der von Dir vorgeschlagenen Lib ja auch vorkäme) und danach das Setzen eines Pixels. Das ist mit Klammern und Include-Zeilen und allem auch nicht länger als die von Dir vorgeschlagene Lösung. Nur dass ich unter SDL stattdessen auch direkt ein PNG laden und auf den Bildschirm setzen kann, statt eines einzelnen Pixels - wenn ich das will. Und das hat am Ende auch nur 2-3 Zeilen mehr.
das stimmt, sdl kommt dem eh sehr nahe.
nur was ist, wenn du eine neue hardware hast. möchtest du dann die sdl biblithek programmieren?auch gefühlt ist es anderes, wenn es minimialistisch rein, und übrall sofort leicht laufbar wirkt.
aber ich stimme überein, dass man ev. eine 2d-blockkopieroperationen, und eiine
texture 3d-projektion aus geschwindigkeitspraktischen gründen braucht.sicher ist die frage ob man dann immer mehr will, und lightning etc.
hier geht es aber nur um hardwarebeschlleuniger.
wenn es keinen gibt, muss die textureprojektionen eben ausprogrammiert werden.
so soll es ja sein, man soll ja nichts voraussetzen.
wer mehr will, kein problem, aber statisch einlinken. icvh werd bald zur schallplatte. -
Auf sowas wie putpixel() hatte ich schon weiter oben hingewiesen. Der wichtige Punkt aber ist nicht der Bildschirmpunkt, sondern daß Hardware so nicht funktioniert. Die Pokerei existiert bei Systemen nach 1990 nicht mehr. Wenn man sowas wie einen pokebaren Graphikbildschirm auf dem PC emulieren will, muß man einen Hintergrundpuffer im normalen Ram-Speicher anlegen und nach dem Malen den Puffer in die Graphikkarte kopieren, damit die Punkte überhaupt angezeigt werden kann. Zwar könnte man theoretisch sich auch einen Puffer auf der Graphikkarte reservieren und da reinpoken, aber das ist im Vergleich zum Ram im PC schnarchlangsam und wahrlich nicht zu empfehlen.
Ähnlich verhält es sich, wenn man bei 2d-Spielen "Sprites" malen will. An dem Malprozeß selbst ist der Prozessor nicht beteiligt. Vielmehr lädt man zu Beginn des Programms die Shapes in die Graphikkarte und gibt dann nur noch die Befehle an die Graphikkarte aus zum Kopieren. Keine Pokerei. Die Hardware, von der Du sprichst, war die Hardware der 1980er Jahre und ist nicht mehr übertragbar auf moderne Hardware. Daher kann eine einfache Portierung von Programmen, wie Du sie vorschlägst, prinzipiell nicht gelingen.
Nebenbei: Ein Poke(x, y, farbe) dürfte auch schon auf dem Amiga nicht funktionieren, da man dort lediglich den Farbstift angeben kann. Bitmap und Palette sind bekanntlich getrennt. -
nur was ist, wenn du eine neue hardware hast. möchtest du dann die sdl biblithek programmieren?
Warum willst du eigentlich ständig SDL neu schreiben? SDL hat schon jemand geschrieben, wenn das auf einer neuen Systemumgebung laufen soll nimmt man die schon existierende Version und macht ein paar Anpassungen.
-
Warum willst du eigentlich ständig SDL neu schreiben? SDL hat schon jemand geschrieben, wenn das auf einer neuen Systemumgebung laufen soll nimmt man die schon existierende Version und macht ein paar Anpassungen.
ja, vielleicht
-
ich hab schon in den 90zigern direkt in den speicher geschrieben. ich glaub mit assembler OUT.
Ja, toll, unter DOS. Haben wir damals alle so gemacht. Die Zeiten sind aber glücklicherweise vorbei, oder willst Du wirklich das alte DOS zurückhaben?
-
aber das war doch perfekt, traumhafter gings nicht. ein pixel, ein byte
Nee, jetzt nicht ernsthaft, oder? Soll ich wirklich die alten VESA-Treiber aus dem Dokumentenkeller holen und die Mode-X-Routinen? Das ist doch keine realistische Option.
-
Aber die Frage ist dann halt wieder, wer nutzt das. Beim C64 oder anderen existierenden Systemen liegt halt der Reiz auch darin, dass das eine "echte" Plattform ist, die von Millionen Leuten mal genutzt wurde. Wenn man sich nun was phantasie-maessiges ueberlegt, dann muss man das schon auch echt gut vermarkten, um Leute dazu zu bringen, dafuer auch was zu schreibe
So isses.
@bernard
Warum nutzt Du nicht einfach Deine Zeit/Energie/Dein Können um was für den C64 was auf die Beine zu stellen? Hört sich für mich 1000* reizvoller an, als irgendeine vermeintlich restriktive künstliche Umgebung (die sooo restriktiv dann auch wieder nicht ist), die letztendlich auch kein Sau interessiert. Die vielleicht für ne persönliche, akademische - äh - Fingerübung nen Kick bringt - mehr aber auch nicht - und in den Thread hier btw schon gar nicht passt ;->
