API nur mit C++ programmieren?
-
sC++k schrieb:
EDIT:...und ich entnehme deiner Erklärung, es geht auch NUR mit C++, also bedeutet das, es gibt auf jedem Betriebssystem o. teils Gerät verschiedene Anweisungen die ich in einen C++ Code einbette, welche dann z.B einen Pixel auf den Bildschirm zaubern. Wenn das stimmt, wo bekomme ich denn dann die Info welche das auf verschiedenen Geräten o. Betriebssystemen genau sind.
Wie wäre es mit dem Source von SDL? ...
Ach ne, dafür müsste man ja Programmieren lernen.
-
sC++k schrieb:
EDIT:...und ich entnehme deiner Erklärung, es geht auch NUR mit C++, also bedeutet das, es gibt auf jedem Betriebssystem o. teils Gerät verschiedene Anweisungen die ich in einen C++ Code einbette, welche dann z.B einen Pixel auf den Bildschirm zaubern.
Das ist jetzt Definitionssache, also was man mit "nur C++" meint.
Der C++ Standard definiert keine solchen Funktionen, also würde ich sagen es geht mit "nur C++" nicht.
Die Betriebssysteme stellen z.T. entsprechende APIs bereit, die man, wenn man die entsprechenden Import-Libraries einbindet, dann aus seinem C++ Programm heraus verwenden kann, ja. Das ist dann aber "C++ + OS-spezifische API" und nicht "nur C++".sC++k schrieb:
Wenn das stimmt, wo bekomme ich denn dann die Info welche das auf verschiedenen Geräten o. Betriebssystemen genau sind.
Auch wieder etwas was du leicht selbst ergoogeln können solltest. Wenn nicht, dann solltest du ernsthaft an deinem Google-Fu arbeiten. Oder willst du weiterhin wegen jeder Kleinigkeit in einem Forum nachfragen müssen, und dich dann entsprechend schief anreden lassen weil du halt nicht googeln kannst?
Ein kleiner Tip (neben dem was TyRoXx schon geschrieben hat, was natürlich auch super funktioniert): auf Windows nimmt man für Grafik normalerweise Direct3D.
(Oder diverse ältere APIs wie z.B. GDI, aber nachdem du hier im Spiele-/Grafikprogrammierung Forum fragst gehe ich davon aus dass du mit denen nicht sonderlich glücklich werden wirst.)
Und was man auf anderen Systemen verwendet, das ergoogelst du dir jetzt selbst. (OK, noch ein kleiner Tip: es gibt auf anderen Systemen eigentlich nur eine relevante API.)Was Sound angeht: da gibt's SO viele verschiedene APIs, alleine unter Windows schon mindestens 4 die für Spiele geeignet sind.
Heisst: nimm dazu lieber SDL, SFML, Allegro oder eine andere Library die dir nur Sound abstrahiert (PortAudio, OpenAL, ...).
-
Nachtrag (hatte ich im falschen Thread gepostet):
ps:
Hier gibt's ne Übersicht über die gesamte C++ Standard-Library:
http://www.cplusplus.com/reference/Alles was damit abgedeckt ist kannst du also mit "nur C++" machen. Alles was damit nicht möglich ist ... ... nicht.
-
hustbaer schrieb:
Alles was damit abgedeckt ist kannst du also mit "nur C++" machen. Alles was damit nicht möglich ist ... ... nicht.
Das ist eine komische Trennung. Die DirectX und OpenGL-Implementierungen werden größtenteils in C geschrieben sein (und damit auch leicht nach C++ portierbar). Und die OS-Funktionen zur Gerätekommunikation, die von diesen Implementierungen genutzt werden, sind ebenfalls in C geschrieben.
Prinzipiell könnte man also schon alles* in reinem C++ machen, man muss "nur" sein eigenes OS und einen eigenen Treiber+ schreiben. Reichlich unbequem, aber möglich. Selbst wenn man das nicht macht, dann gibt es, zumindest unter Unixoiden, bestimmt irgendeine Pseudodatei für die Gerätekommunikation. Mindestens für Tonausgabe weiß ich davon. Ist vielleicht nicht so bequem, wie das direkte Nutzen der vorgesehenen Schnittstellen, aber man kann die tatsächlich wie eine ganz normale Datei in C++ zum Schreiben öffnen und Steuersignale senden. Man muss bloß wissen, welche Signale (und hier liegt das eigentliche Problem :p ). Bei beiden Methoden hätte man an keiner Stelle eine fremde API benutzt. Es sollte aber wohl auch klar sein, wieso das praktisch niemand so macht
(früher gab's tatsächlich noch Computerspiele, die ihr eigenes OS booteten).*: Ok, man braucht vermutlich ein kleines bisschen Assembler für die allerersten Phasen des Bootvorgangs, da man in Hochsprachen nicht die nötige Feinkontrolle über die Struktur der Executable hat und auch keinen Zugriff auf spezielle Eigenheiten der Hardware, um die man sich eventuell kümmern muss.
+: Dies ist natürlich sehr schwierig, da der Hersteller seine Schnittstellen in der Regel nicht veröffentlicht hat.
-
SeppJ schrieb:
Es sollte aber wohl auch klar sein, wieso das praktisch niemand so macht
Wenn das klar ist, dann ist es wohl eine "praktische" Trennung.
Und wenn sie "praktische" ist, wieso ist sie dann "komisch"?Und davon abgesehen: man bedient sich dann zwar vielleicht keiner fremden API (wenn man Dinge wie die BIOS Interrupts bzw. EFI Funktionen, DPMI usw. nicht als API bezeichnen will), aber dafür eines fremden Standards. Bzw. vieler solcher Standards.
Ob man das jetzt als "reines C" oder "reines C++" bezeichnen kann ist halt die Frage.
Und dann bleiben natürlich noch die Punkte * und +. Und der Punkt dass der OP seine Frage so sicherlich nicht gemeint hat.
-
sC++k schrieb:
... wo bekomme ich denn dann die Info welche das auf verschiedenen Geräten o. Betriebssystemen genau sind.
zufaellig haben wir hier im forum ein OS dev projekt wo das wohl gemacht wird:
http://www.c-plusplus.net/forum/f62
-
Gibt's da auch 3D Treiber für AMD und NVIDIA Grafikkarten aus dem letzten Jahrzehnt?
-
hustbaer schrieb:
Und dann bleiben natürlich noch die Punkte * und +. Und der Punkt dass der OP seine Frage so sicherlich nicht gemeint hat.
Das ist die Schuld des TE, wenn er dumme Fragen stellt. Ich habe ihn 2x darauf aufmerksam gemacht, trotzdem hat er wortwörtlich(!) die Fragen wiederholt.
hustbaer schrieb:
Gibt's da auch 3D Treiber für AMD und NVIDIA Grafikkarten aus dem letzten Jahrzehnt?
Man könnte auch sagen, dass die gesamte Linuxszene dazu gehört. Die wirklich guten Treiber sind zwar Closed-Source von den Herstellern beigesteuert, aber prinzipiell existiert ein reverse-engineered Open Source Treiber für Nvidia und ein offen entwickelter Treiber für AMD. Und das ist alles in C geschrieben.
-
Dann hat sich da wohl einiges getan in den letzten ~5 Jahren.
Damals hatte ein Bekannter von mir nämlich noch das Problem dass er von AMD nicht ums verrecken Infos zu den 3D Funktionen der Chips bekommen hat, trotzdem er als Chefentwickler einer halbwegs dicken Firma angefragt hat.
Und damals gab's auch nix Open-Source reverse-engineertes, zumindest nix brauchbares.
-
hustbaer schrieb:
Und damals gab's auch nix Open-Source reverse-engineertes, zumindest nix brauchbares.
Kommt drauf an, was man brauchbar nennt. Meiner Meinung nach sind sie nicht brauchbar (wobei es bei mir ebenfalls ~5 Jahre her ist, dass ich sie benutzt habe und seither habe ich sie aufgrund dieser Erfahrungen nie wieder angeguckt). Aber sie existieren.
-
hustbaer schrieb:
Dann hättest du das vielleicht auch fragen sollen, und nicht...
sC++k schrieb:
Hi, ist es möglich "nur" mit C++(u. STL) eine umfangreiche API wie "SDL" zu programmieren?
Also selber
EDIT: Oh, er editiert schnell die Behauptung weg dass er eigentlich wissen wollte WIE man es macht, nicht ob es mit "nur" C++ geht... Naja, auch gut.
Sorry hatte erst den Text zu unaufmerksam gelesen dann nochmal und schon musste ich gänzlich verbessern. Auf die frage nach dem "Wie" hab' ich's dann aber im Anschluss ausgeweitet, schau!
sC++k schrieb:
TyRoXx schrieb:
Ist es möglich alle zwei Tage die gleiche Frage zu stellen?
Der alte Thread wurde von einem Moderator geschlossen, ohne dass meine Frage beantwortet wurde, ich hatte noch gefragt "wie", weil ich im i-net keine Infos dazu fand! Ich bekamm nur ein "Ja", nur beabtwortet dies nicht viel.
-
hustbaer schrieb:
sC++k schrieb:
EDIT:...und ich entnehme deiner Erklärung, es geht auch NUR mit C++, also bedeutet das, es gibt auf jedem Betriebssystem o. teils Gerät verschiedene Anweisungen die ich in einen C++ Code einbette, welche dann z.B einen Pixel auf den Bildschirm zaubern.
Das ist jetzt Definitionssache, also was man mit "nur C++" meint.
Der C++ Standard definiert keine solchen Funktionen, also würde ich sagen es geht mit "nur C++" nicht.
Die Betriebssysteme stellen z.T. entsprechende APIs bereit, die man, wenn man die entsprechenden Import-Libraries einbindet, dann aus seinem C++ Programm heraus verwenden kann, ja. Das ist dann aber "C++ + OS-spezifische API" und nicht "nur C++".Ja, aber aber auch die API für das Betriebsystem ist ja nicht vom Himmel gefallen, wie wurde die denn programmiert mit Assembler oder was?
-
hustbaer schrieb:
SeppJ schrieb:
Es sollte aber wohl auch klar sein, wieso das praktisch niemand so macht
Wenn das klar ist, dann ist es wohl eine "praktische" Trennung.
Und wenn sie "praktische" ist, wieso ist sie dann "komisch"?Und davon abgesehen: man bedient sich dann zwar vielleicht keiner fremden API (wenn man Dinge wie die BIOS Interrupts bzw. EFI Funktionen, DPMI usw. nicht als API bezeichnen will), aber dafür eines fremden Standards. Bzw. vieler solcher Standards.
Ob man das jetzt als "reines C" oder "reines C++" bezeichnen kann ist halt die Frage.
Und dann bleiben natürlich noch die Punkte * und +. Und der Punkt dass der OP seine Frage so sicherlich nicht gemeint hat.
Weder noch, von mir aus hab ich sie auch so gemeint. Es ging anfangs NUR darum ob man mit C++ ohne Zusatz-API soetwas machen kann.
-
du kannst mit c++ auf die hardware zugreifen, es ist nicht mehr als daten an die richtige stelle zu schreiben
du kannst mit VGA anfangen: http://www.osdever.net/FreeVGA/vga/vga.htm
es gibt entsprechend SVGA und VESA dokumentationen.wenn du es dann krachen lassen moechtest, eine sammlung von low level GPU documentationen findest du auf:
http://renderingpipeline.com/2012/03/low-level-gpu-documentation/wenn du in unser OS-dev unterforum gehst: http://www.c-plusplus.net/forum/f62
findest du sicherlich nicht nur einen thread in dem auch daran gearbeitet wird z.B. http://www.c-plusplus.net/forum/325470
-
@sC++k
Freund... du musst echt lernen dich klarer auszudrücken.
