spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Da muss ich mich David anschließen. Es wäre bei weitem einfacher, eine bereits existeirende Sprache und deren Interpreter (/Compiler) für Skripte zu verwenden. Der einzige Aufwand dabei dürfte nur das Portieren auf das eigene System sein (sollte es an der Stelle überhaupt Probleme geben) und ggf. das Integrieren in andere Anwendungen bspw. damit von der Konsole (bzw. der Shell) aus direkt entsprechende Befehle abgesetzt werden können, sollte das gewünscht sein. Man erspart sich also die Entwicklung einer eigenen Sprache _und_ die Entwicklung eines entsprechenden interpreters. (Gerade letzteres dürfte einen enormen Aufwand bedeuten.)
Ich für meinen Teil hege eine gewisse Zuneigung gegenüber Python, Lua ist allerdings auch ziemlich verbreitet. Letztendlich wäre es das beste, mehrere Möglichkeiten anzubieten, für den Anfang solltet ihr aber eine Sprache nehmen, die euch eher gefällt.

Oh, sowas hab ich früher auch mal gemacht... Paging => 32 bit? Oder plant ihr auch 64 bit Unterstützung? SMP? Oder bloß "schnelles Task-Wechseln" auf einem Core?
Ich hatte damals die "Newlib" für mein 'System' (naja, allzu weit ist es nicht gekommen, aber mehrere Tasks und Speicherverwaltung (mit Paging) liefen) portiert, da kann man relativ zügig komplette eigene C-Programme ans Laufen kriegen, wenn man bloß einige wenige System-Calls implementiert. Das macht schon Spaß. Dann sollte ein Lua-Interpreter z. B., der ja recht klein und Standard-C ist, eigentlich kein Problem sein...

Naja, das mit dem Scripting solltest du erstmal etwas nach hinten schieben. Vor dir stehen ja noch Paging, ein vernünftiger speichermanager, Multithreading, verwaltung von prozessen, und das wichtigste, das dateihandling muss gut funktionieren und dateisystem- und fdd/hdd treiber wollen ja auch geschrieben werden außerdem brauchst du noch tastatur und ausgabe, aber das sollte ja nicht unbedingt das problem sein. Dann musst du das ganze noch ordentlich testen.

NTFS solltest du erstmal weg lassen. Ich glaube, bei Microsoft gibts ne Doku, aber guck mal selbst Linux hat noch ein paar kleine Probleme damit. Wenn du vorhast, auf deine Nutzerfestplatte zuzugreifen, vergiss es Lesen vielleicht, aber schreiben auf keinen fall! Mach erstmal was mit FAT und Diskette.

Wenn du schon keine Gratis-Scriptsprache mitnehmen willst, ist NTFS definitiv overkill. Ich glaube, USB-Treiber sind auch eher nicht so einfach. Mach erst mal FAT (und ärger dich über VFAT)

Wenn du nen Grafikmodus willst, kannst du den für den Anfang ziemlich einfach mit VESA im Loader setzen, dann bekommst du framebuffer Zugriff. Musst du nur mit den Pages richtig einblenden. Eine einfache Bitmap-Font sollte irgendwo herzukriegen sein...

Warum nimmst du nicht Linux zur Entwicklung? Da müsste es doch mit 32 und 64 bit gehen. Ich glaube, ich hatte damals die binutils mit allen Binärformaten selbst kompiliert. Vielleicht geht das auch für Windows?

Wie bereits geschrieben dürfte es wesentlich einfacher sein, den vorhandenen Python-Interpreter zu verwenden, als eine eigene Implementierung zu schreiben. (Und das um Längen.)
Die verschiedenen Linux Distributionen liefern i. d. R. auch nur den vorhandenen Interpreter mit (oder man kann diese nachinstallieren), statt eine eigene Implementierung zu schreiben.