Lowlevel
OffZone => Offtopic => Thema gestartet von: TeeJay am 09. June 2005, 20:20
-
Alloa.
Da ich gerade an einem kleinen Spiel arbeite, hatte ich mich entschlossen eine umfangreiche Dokumentation dazu zu schreiben.
Wer interesse hat kann sich das ja mal auf www.jay-code.de unter Projekte -> Bomberman anschauen.
Kritik ist ausdrücklich erwünscht :)
mfg
TJ
PS: Nicht das ich die Leute zur Spieleprogrammierung bekehren möchte, aber kann ja sein das der ein oder andere ohnehin interesse daran hat.
-
Kleine Kritik: C ist für Spiele dieser Art totaler Misst und Schrott, nimm lieber BlitzBasic. ;) (Okay, C is meiner Meinung nach immer Schrott, aber wir wollen ja keine Flames :P)
-
Bei allem Respekt, aber das ist Käse. Zum einen ist C die gebräuchslichste Sprache generell, zum zweiten mag ich Basis dialekte nichm und zum dritten glaubst du wohl kaum das ich jetzt nochmal von vorne Anfangen nur weil ein Herr meint das C dafür nit geeignit sei *G*
Sry, aber das war ein Punkt von Kritik der in gewisser Hinsicht sinnlos war :)
-
BlitzBasic is ehrlich ne mist sache ^^ sorry ich kenns, wenn basic dann RealBasic :P
-
Quatsch ^^ Purebasic rulez :D
aber back2topic:
interessantere idee, ich werds mir morgen mal genauer ansehn, jetz keine zeit mehr :)
-
Ich würde es besser finden, keine Winapi zu benutzen, sondern stattdessen irgenteine Lib (SDL usw.) zu benutzen, aber das ist Geschmackssache und du wirst es warscheinlich nicht mehr ändern wollen.
Der Aufbau sieht schonmal gut aus, ich habe jedoch 3 Kritikpunkte:
1. ProcessFrame() sollte nur aufgerufen werden, wenn keine Nachrichten mehr verarbeitet werden müssen.
2. Die Limitierung auf 30 Frames ist nicht sehr schön meiner Meinug nach, ich würde lieber die Geschwindigkeit des Spiels nicht auf Frames, sondern auf der vergangenen Zeit basieren lassen.
3. timeGetTime() oder queryPerformanceTimer() verwenden, getTickCount hat nur eine Auflösung von etwa 10ms.
-
Kleine Kritik: C ist für Spiele dieser Art totaler Misst und Schrott, nimm lieber BlitzBasic. ;) (Okay, C is meiner Meinung nach immer Schrott, aber wir wollen ja keine Flames :P)
Ausser man hat vor was richtig gutes zu machen! Dann brauch man auch ne ordentliche Engine. Und sollte man meiner Meinung nach z.B. in C++ oder ähnlichem machen! ;)
-
Quatsch ^^ Purebasic rulez :D
Ah, jemand mit Geschmack ^^
Ich würde es besser finden, keine Winapi zu benutzen, sondern stattdessen irgenteine Lib (SDL usw.) zu benutzen, aber das ist Geschmackssache und du wirst es warscheinlich nicht mehr ändern wollen.
Find ich auch aber war ja eh klar dass ich als (größtenteils) penetranter Linux User mich darüber beschwer ^^
Anonsten find ichs lustig auch wenn ichs mir noch nicht so genau angeschaut hab ^^
-
Hi,
hab's auch noch nicht gelesen, würde aber C++ mit GL/glut oder SDL empfehlen, ist viel einfacher finde ich. Und unter Linux/MacOS läuft es auch...
Gruß GhostCoder
-
Auf seiner Homepage steht, dass TJ damit die WINDOWS-Programmierung lernen will. Also wäre es dem Ziel ziemlich abträglich, wenn er auf Linux achten würde.
-
Ist ein reines WinAPI-Interface nicht schneller, als wenn man alles noch zusätzlich ueber eine Lib laufen lassen muesste?
Stelle ich mir mal als Performance-Steigerung vor, wenn direkt die WinAPI angesteuert wird.
Im Kapitel "Was ist Bomberman" fehlen die Screenshots :)
Kapitel I, Seite 5, Absatz 3: "hIcomSm ist ein Handel ähnlich..." Du meintest sicher Handle :-)
Absatz 7: Du wiederholst den Teilsatz "Dies erreichen wir durch den Wert"
Auf Seite 8, Absatz 2 hast du einen Tippfehler mit "Maximieren".
Den Rest lese ich später :) Hoffe, es stört nicht, wenn ich sowas sage.
Svenska
-
@Roshl&Legend: Es geht um einen Bomberman-Clone, nicht um ein 3D-Online-Taktic-Shooter, wie SplinterCell. Und für solche kleinen Spiele eine extra Engine zu bauen und möglichst noch zu abstrahieren oder sonstwas ist total übertrieben! Da sollte man was einfaches wie Basic lohnen, der Mehraufwand lohnt sich erst bei großen Projekten, wo dann auch der Lohn (der erst bei wachsender komplexität auftritt/wächst) merklich ist. In dem Fall hat C KEINEN Vorteil, sondern NUR nachteile.
-
Das ist deine Ansicht, joachim_neu.
Ich zum Beispiel sehe in C eine deutlich strukturierte Sprache als BASIC, bei der ich auch noch Monate lang spaeter was mit dem Code anfangen kann, vorallem kann man mit C irgendwie "modularer" programmieren und daher ist der code besser wartbar und erweiterbar
@TJ Nettes Projekt, gefaellt mir sehr :)[/quote]
-
Das ist nicht nur seine Ansicht ich würde für solche Sachen auch nen Basic Compiler (Purebasic!) Nehmen aber ich bin ja auch ein n00b....
Sind wir nicht alle n00bs? (Bei N00B isses ja eh klar ^^)
-
hi,
also ich glaube, dass solche kleinen Projekte eher zum Lernen dienen, damit man dann auch irgendwann mal ein größeres Projekt starten kann.
Meiner Meinung bringt es dann nichts, wenn man das "Lernprojekt" mit (in diesem Fall) Blitzbasic programmiert, da man Blitzbasic in größere Projekten eh nicht hernimmt und der Lerneffekt dann gleich null ist (biss auf spezielle Techniken, die unabhängig von der Programmiersprache sind).
cu,
stefan2005
-
@stefan2005: stimmt
@asc: eben, weil man nach monaten den code nichtmehr lesen muss und modulare programmierung da nicht notwendig ist. da macht man sich nur nen aufwand für die "lesbarkeit und wartbarkeit", den man aber nicht brauchen wird. bomberman proggste an einem tag in BB...
-
@JN Du hast nicht kapiert warum TJ das proggt:P
-
Hm... Mag sein ;) Ich habs verallgemeinert. :)
-
Also:
- TIppfehler etc schaue ich mir gerade selbst noch an. Hab erstmal die erste Fassung online. Hab mir die Kapitel ausgedruckt und lese nochmal. Evtl ändere ich noch Satzbau und auf jeden Fall Schreibfehler.
- EIne Extra Engine ist für ein so simples 2D spiel überzogen. Mir geht es auch viel mehr darauf einzugehen wie der generelle Ablauf eines Spiels ist. So das man einen EInstieg hat. Wenn das Ding erstmal steht werd ich anstatt der GDI vielleicht auch die Grafikausgabe durch DirectX ersetzen. Ist ja für reines 2D ohne große Effekte auch nicht so das Problem.
- Im Grunde ist der meiste code auch für Linux portierbar. Aufrufe zum erstellen von Fenstern etc. müssen natürlich ausgetauscht werden. Der meiste Code (der zumindest noch folgt) hat relativ wenige API Aufrufe.
- Das ProcessFrame() kann ruhig permanent aufgerufen werden. Die einzigen Messages die verarbeitet werden sollen, sind die WM_CLOSE und später dann noch jene für das inaktiv setzen des Programms. Da muss ich nicht erst alle Messis abarbeiten.
- An der Sprache C wird nix geändert. C ist meiner Meinung nach die am weitest verbreitete (inklusive C++). Und es soll ja auch ein bissl Know-How rüberkommen. Basic-Dialekte gehen meist nicht so ins Detail, weshalb ich den Lerneffekt dort nicht für sonderlich doll erachte. Zum anderen soll das Projekt ja auch nur einen Einstieg/Anregung sein um evtl später ein eigenes, durchaus größeres Projekt zu machen.
- DIe Limitierung auf 30 Frames ist bei dem Spiel eher unrelevant. Es wird auch sicher auf älterer Hardware schnell genug laufen und wie auch im Tut beschrieben ist die Umsetzung einfacher wenn man sich an eine feste Anzahl Frames orientieren kann. Immerhin habe ich die andere Möglichkeit ja erwähnt und beschrieben.
- Die Funktionen timeGetTime() und queryPerformanceCounter() werde ich mir mal anschauen und diese ggf. einsetzen.
@Joachim_Neu
Es geht mir nit darum zu zeigen wie man möglichst "an einem Tag" Bomberman programmiert. Sondern generell ein paar Techniken zum Theme Spieleprogrammierung zu zeigen. Und von Basicdialekten bin ich schon eine ganze Weile geheilt ^^
-
also ich finds ehrlich ganz witzig
@die_basic_progger: jede der sprachen die ihr nanntet hat bestimmte vorteile, die die andern net so ham:
pure basic: einfache zugriife auf WIN-Funktionen
einfache 3d-programmierung
blitzbasic: mein favorit, einfach klasse, leider ohne guten support...
darkbasic: die sprache für 3d-games
realbasic: kennichnich
glbasic: neu und ganz ok
........
-
@joachim_neu und co: Auch spiele sollten in Assembler geschrieben werden. Du kannst die WinAPI ja auch mit Assembler ansprechen. Da denke ich gerade an TASM oder MASM. Nehmt mir es nicht übel, ich programmiere immer in ASM. Das Programm/Spiel wird einfach kleiner und schneller. ;)
bitmaster
PS: Assembler is the best ;)
-
... und der Quelltext wird immer unübersichtlicher und größer ^^ Meiner Meinung nach würde sich C auf jeden Fall immer lohnen, hier in dem Fall würde ich sogar gleich Java nehmen. Und für die verrückten gibts ja immernoch ABAP ;-)
-
Naja, Assembler ist aber das unportabelste was es gibt.
Ausserdem brauchst du sehr viel länger, ein Assemblerprogramm zu schreiben, als ein C Programm zu schreiben. Die Ausführungsgeschwindigkeit wird nicht sehr stark beeinflusst, heutige Compiler können schon sehr guten Code generieren. Oft benutzte Funktionen können ja immernoch in inline Assembler etc. geschrieben werden. Ausserdem ist Assemblercode nicht so gut zu verstehen wie C Code.
-
thema inline-assmbler:
neuere basics gibs mit inline-assembler wie der nachfolger von blitzbasic, blitzmax
-
Nehmt mir es nicht übel, ich programmiere immer in ASM. Das Programm/Spiel wird einfach kleiner und schneller. ;)
Du kennst deinen Rechner also so gut und bist bereit, die Zeit aufzuwenden, daß dein von Hand geschriebener Assemblercode besser ist als eine optimierte Compilerausgabe? Respekt! ;)
-
Nehmt mir es nicht übel, ich programmiere immer in ASM. Das Programm/Spiel wird einfach kleiner und schneller. ;)
Du kennst deinen Rechner also so gut und bist bereit, die Zeit aufzuwenden, daß dein von Hand geschriebener Assemblercode besser ist als eine optimierte Compilerausgabe? Respekt! ;)
Compilerausgabe und optimiert? Also das passt nicht zusammen. Wenn ich eine einfache meldung mit Winapi unter borland oder microsoft visual c++ haben möchte ist das programm zwischen 20-200 KByte groß. Wenn ich das mit Assembler mache bin ich bei 4 KByte. Und die 4 KByte sind pflicht deswegen 4 KByte. Danach wird der unterschied zwischen den Assemblerprogramme sogar noch größer. Und dein PC musst du auch nicht perfekt kennen, es gibt ja auch unter Assmbler die WinAPI.
bitmaster
-
Das liegt dann daran, dass zusätzliche Libraries mitgelinkt werden. Eine MessageBox wird nicht zu 20kB Code kompiliert.
-
jep ich hab das mal unter ms visualc++ 6.0 professional gemacht und unbenötigte einträge bei den libraries und so rausgenommen, siehe da: 6,01kb
-
Das mit kleiner kann ich ja vielleicht noch glauben, wenn auch nicht in wirklich nennenswertem Umfang, aber das mit schneller wage ich doch zu bezweifeln. Da optimieren heutige Compiler doch ganz kräftig.
-
bei mir funktioniert das irgendwie nich, aber man kann sich in visualc++ den assemblercode anschauen dann könntestes ja sehen
-
Ja ja ist ja schon gut. Das solltet ihr ja auch nicht unbedingt so machen. Ich programmiere halt immer in ASM (programmiere aber keine Spiele ;), zumindest nicht nennenswerte). Ich wollte nur sagen das wenn ihr euch schon darum streitet ob Basic, C++, Pascal, Java etc. dann nehmt doch einfach ASM. Wenn ihrs richtig könnt, kann keiner eine bessere Programmiersprache anbieten.
bitmaster
PS: Schneller starten tun sie dann aber doch. Startet mal einen Texteditor der mit C++ geschrieben wurde (allen unnötigen kram beim kompilieren rausgenommen) und einen in ASM geschriebenen von Diskette aus, da werdet ihr den Unterschied merken. Ich frage mich immer warum Windows 3.x sieben disketten brauch, Windows 95 auf einmal eine ganze CD und Windows XP 1 GByte Festplattenspeicher. Mit welcher Programmiersprache schreiben die Windows noch mal? ;)
-
PS: Schneller starten tun sie dann aber doch. Startet mal einen Texteditor der mit C++ geschrieben wurde (allen unnötigen kram beim kompilieren rausgenommen) und einen in ASM geschriebenen von Diskette aus, da werdet ihr den Unterschied merken. Ich frage mich immer warum Windows 3.x sieben disketten brauch, Windows 95 auf einmal eine ganze CD und Windows XP 1 GByte Festplattenspeicher. Mit welcher Programmiersprache schreiben die Windows noch mal? ;)
Dass manche Projekte überdimensional groß werden, hat eher mit schlechtem Desigen zu tuen, als mit einer hohen Programmiersprache.
Man kann auch mit C oder C++ sehr kleine und effiziente Programme schreiben. (z.B. der 3D-Shooter KKriger ~64KB)
Ich glaube aber, dass Assembler von der Ausführungsgeschwindigkeit und besonders von der Dateigröße immer noch ungeschlagen ist. Dafür ist Asm sehr viel schwerer zu schreiben und zu lesen.
-
aso zur info :
msdos is in asm geschrieben von win weiß ichs net....
der dossource steht im netz
-
aso zur info :
msdos is in asm geschrieben von win weiß ichs net....
der dossource steht im netz
Nein, MS-DOS ist nicht in ASM geschrieben. Die ersten Versionen ja, aber die späteren wurden dann auch mit C geschrieben. Windows ist zum größten Teil (auch Linux) in C geschrieben.
bitmaster
EDIT: Der MS-DOS Source steht mit sicherheit nicht im Netz. Eine kopie von MS-DOS vielleicht, aber nicht microsofts MS-DOS.
-
@DOS:
In den späteren DOS-Versionen wird zusätlich C verwendet, der Großteil ist immer noch in Assembler geschrieben.
Der DOS Source wurde irgendwann mal geleakt, ich glaub der ist (fast) komplett im Internet gelandet. Irgendwo hab ich auch mal gelesen, dass auf den letzten Seiten von irgendeinem seltenen & alten DOS-Buch der Source von Version 2.xx abgedruckt ist.
@ASM vs. C:
Ich denke, dass man nicht abstreiten kann, dass Assembler Programme ein klein wenig schneller und kleiner sind als C-Programme - natürlich nur wenn man gut Asm kann. C Programme sind dafür wesentlich übersichtlicher und es lassen sich viele Dinge in C/C++ einfach schöner "ausdrücken".
-
@bitmaster: ich hab mir den source geladen, aber weiß net ob das legal ist deswegen weiß ich nicht ob ich den dir schicken darf sonst würd ichs machen
-
@bitmaster: ich hab mir den source geladen, aber weiß net ob das legal ist deswegen weiß ich nicht ob ich den dir schicken darf sonst würd ichs machen
Den source von was? Den source von MS-DOS hat nur microsoft, glaube es mir. Du hast dann den source einer anderen DOS Version die nicht von Microsoft ist.
bitmaster
-
ganz sicher ms-dos da sind in vielen ordnern copyright-files mit dem inhalt
;/*
; * Microsoft Confidential
; * Copyright (C) Microsoft Corporation 1993
; * All Rights Reserved.
; */
-
ganz sicher ms-dos da sind in vielen ordnern copyright-files mit dem inhalt
;/*
; * Microsoft Confidential
; * Copyright (C) Microsoft Corporation 1993
; * All Rights Reserved.
; */
Hä?
-
wieso häh? in sogut wie jedem ordner ist ne file
"copyright.txt" mit diesem inhalt
-
wieso häh? in sogut wie jedem ordner ist ne file
"copyright.txt" mit diesem inhalt
Na, ob das so stimmt.
-
soll ich dir das archiv rüberschicken
-
Jo, das ist dann wohl der Source von irgendeiner DOS-Version (vermutlich 3.30 oder 6.00). Dürfte übrigens nicht legal sein den zu besitzen oder weiter zu verbreiten ;)
Der Source von Windows wurde ja auch mal geleakt, nur halt nicht komplett...
-
also...ziemlich viele assmebler-files und n paar c-files
der rest
makefiles, .....
lösch ich denn vllt lieber mal,.....
EDIT: is version 6.00 mit den quellcodes zu qbasic und so alles dabei.... aber ich löschs ma
-
Der 6er Source ist glaub ich komplett an die Ãffentlichkeit gekommen, inklusive Treiber, DOS-Shell (die z.B. in C geschrieben ist so weit ich weiß), Tools, Setup, usw. halt.
@Coffee: Behalt den doch, kann man sicher ein wenig draus lernen. Du solltest nur keinen Code kopieren oder es überall rumerzählen ;)
-
ok... die treiber sin dabei, die shell is wirklich in c geschrieben(zumindest um großteil), aber der überblick fehlt bei den vielen files und ordnern.....
achso noch was witziges:
es gibt enige dateien(in englischer sprache) mit kommentaren von und für andere programmierer und so..... wie für die übersetzer :D
-
Wenn der Algorithmus der zugrunde liegt scheiße ist, ist auch ein in ASM geschriebenes Programm/Spiel grottenlangsam, als ein guter Algorithmus in C. Das sollte man mal nicht vergessen. ASM alleine holt nicht immer den maximalen Geschwindigkeitseffekt heraus. ASM ist aufwendig zu schreiben, zu lesen und zu debuggen. Und gerade die Möglichkeit über das beibehalten von werten in Registern zur Geschwindigkeitsoptimierung hat meist den Nachteil das bei einer änderung des Codes (z.B. wegn Bug) oft ein ganzer Codestreifen umgestaltet werden muss, wobei bei C evtl nur das umschreiben einer einzelnen Zeile genügt.
Es gibt einen guten Grund warum man Hochsprachen entwickelt hat. Und zwar wegen der Effizienz des Zeitverbrauches.
SOLLTE ich spezialfunktionen eines Prozessors (z.B. SSE) benutzen wollen, DANN würde ich persöhnlich auch zu ASM greifen. Aber lediglich Inline-ASM.
Jeder hat seine eigene Philosophie was das Programmieren angeht und ich respektiere da jeden Einzelnen. Aber dieser Thread war eigentlich nicht dazu gedacht sich darüber zu streiten in welcher Sprache man das Projekt hätte noch machen können... :)
Ich versuche in den Tutorials so viel als möglich zu dem Code zu schreiben, das man das was da vor sich geht auch versteht. Wer das nochvollziehen kann, der sollte das Spiel auch in ASM oder einer anderen Sprache verfassen können um gleiche Ergebnisse zu erzielen.
-
gute meinung.....
wer sich mal n bissl mit den zfx-projekten(www.zfx.info ) beschäftigt hat, weiß:
für deren 3dengine ham die c++ - genommen, für den gröten mathematischen teil inline-asm
mehr effektivität brauch maan echt nicht
und ob ein textedito in 2,3 oder 2,9 sekunden startet: wem machts was aus?
-
Damit hast du einen weiteren guten Aspekt aufgegriffen.
Es nützt ja auch garnix die Routine für das Laden von Bildern oder Texturen zu optimieren, da dieser Vorgang ja immer nur am Anfang eines Spiels/Levels stattfindet und zum anderen hier auch meist sicher die Geschwindigkeit der Festplatte das begrenzende Medium ist. Man sollte so oder so immer abwägen in wie fern eine Optimierung des Codes (durch welches Mittel auch immer) überhaupt unterm Strich einen Sinn macht.
-
Achja und von wegen warum DOS auf ein paar Disketten passt und WIndows XP 1 GB braucht:
Selbst wenn der Produzierte Code in C umfangreicher ist als in ASM und Windows XP noch so viele Millionen Zeilen Code hat, ist der Code selbst das was am allerwenigsten Platz von dem GB wegnimmt. In neueren Windowsversionen kommt neuer Schnickschnack wie Fonts, Bitmaps usw zum Zuge. Und DAS frisst einen haufen. Man schaue sich als Beispiel mal ein Spiel an (auch wenn der Vergleich natürlich nicht ganz passt). Die EXE-Datei und DLL-Dateien sind nur ein Bruchteil von dem Platz den das Ding auf der Platte belegt. Was viel wegfrisst sind Bilder und sonstige Daten. Also ganz so einfach darf man DOS und WINXP also nicht vergleichen :)
-
Man nehme zB den Linux Kernel, der mit den wichtigsten Modulen kompiliert gerade mal um ein Megabyte groß ist. Und der Kernel besteht auch aus etwa 2 Mio. Zeilen C Code.
-
stimmt.........
-
Man nehme zB den Linux Kernel, der mit den wichtigsten Modulen kompiliert gerade mal um ein Megabyte groß ist. Und der Kernel besteht auch aus etwa 2 Mio. Zeilen C Code.
2 Mio. Zeilen = 1 MByte? Das kaufe ich dir nich ab. Nicht mal in ASM würde man so etwas erreichen.
EDIT: Oder zählen die Komentarzeilen mit?
-
Denk ich mal, dass da auch Kommentare mitzählen...
Übrigens sind es über 6 Mio. Zeilen laut http://www.pro-linux.de/news/2005/8475.html. Allerdings gilt das für sämtliche Module, Treiber usw.
-
und die header nicht vergessen. die erzeugen auch keinen code.
-
außerdem während des compilieren/liken fallen noch mehr sachen weg:
-konstanten
-die funks die nich in den headern sind
-.....
-
Man sollte aber auch sagen, dass Sachen dazu kommen können. Inline-Funktionen sind da so ein Beispiel.
-
ooh ganz vergessen :oops: :oops: