Hey,
Nachdem ich anfängliche Probleme mit Sprites und mit dem Compiler hatte, ist mir inzwischen bereits eine perfekte Menüsteuerung für ein zukünftiges Spiel gelungen und auch der Test auf dem GP2X mit Schuhschachtel hat einwandfrei geklappt. Das ist äußerst lobenswert und deshalb wollte ich das hier auch mal loswerden. Nur Fragen und Kritik darf nicht sein ;-)
Natürlich kommen trotzdem beim ausgiebigen Testen einer neuen Programmiersprache auch immer wieder Fragen auf. Und zwar brauchte ich jetzt eine Funktion wie VAL, die einen String in eine Zahl konvertiert. Meiner Meinung nach oft unverzeichbar bzw. sehr praktisch. Leider finde ich soetwas in der Hilfe nicht. Gibt es wirklich keine solche Funktion oder habe ich nur nicht richtig gesucht?
Zweite Sache ist der Befehl USEASBMP. Unglaublich wichtig finde ich, weil man nicht immer ständig den kompletten Bildschirminhalt neuzeichnen will und somit alle statischen Objekte schnell als neuer Hintergrund definiert werden sollten. Bei mir am PC hält dieser Befehl das Programm für ganze 2 Sekunden auf - das kommt mir sehr viel zu viel vor! Ich habe in der Hilfe gelesen, dass der Befehl auf manchen Grafikkarten langsam werden kann aber das ist ja mehr als langsam! Gottseidank ist er aber auf dem GP2X recht schnell, daher ist es nur halb so wild. Für das Testen meiner Programme am PC jedoch wird das damit schon mühsamer.
Daher meine zweite Frage: ist das zu langsam und stimmt hier etwas nicht? Meine Grafikkarte ist wie schon erwähnt eine NVIDIA GeForce 6200 - ein paar Monate inzwischen alt. Könnte ein aktueller Grafiktreiber (wobei ich annehme, einen recht aktuellen zu haben) helfen oder lohnt es nicht, es zu versuchen?
VAL gibt's nicht. Das mach GLBasic von alleine:
a$ = 5
b = a$
b = b +7
a$ = b
PRINT b, 0,0
SHOWSCREEN
MOUSEWAIT2 Sekunden!? Das ist zu krass. Man schafft i.d.R. schon 60 FPS damit. Installiere einen aktuellen Grafikkartentreiber vom Hersteller (NVidia oder ATI). Deine Karte ist ja ein Monster im Vergleich zu meiner. Und ich schaff' locker 60 FPS.
HAllo,
wie hast Du es programiert ?
Hast DU USEASBMP in einer WHILE-Schleife zusammen mit SHOWSCREEN benutzt ?
Das bremst nähmlich unheimlich aus.
Gruß Heiko
Quote from: "GernotFrisch"Man schafft i.d.R. schon 60 FPS damit.
Du meinst also, mit USEASBMP lässt sich der Backbuffer 60x in der Sekunde als Hintergrund speichern?? Das wäre ja super!! So schnell brauch ich's auch wieder nicht :-D
Es sind in der Tat 2 Sekunden, ich hab es mehrfach probiert und gemessen. Nehm' ich den Befehl raus, erscheint das Hauptmenü meines Spieles sofort.
@HeikoJ
Nein, ich habe den Befehl nicht in einer Schleife. Ich lade alle Sprites, baue dann das Menü auf bis auf den Cursor (der ist ja das bewegliche Objekt) und dann speichere mit diesem Befehl dieses Menü als Hintergrund. Dann kommt der Aufruf von SHOWSCREEN - das Menü erscheint erstmalig und anschließend geht's in die Schleife, die dann die Menüsteuerung usw. beinhaltet.
@GernotFrisch
Wenn das also so nicht sein darf - was ich mir ja fast sicher denken konnte - dann will ich es mal mit einem neueren Treiber probieren. Hoffentlich klappt das, wäre schon schön.
Schicker ist wenn du den Code einfach postes, so kann man sich ein Bild davon machen!
Evtl. ist es ja ein Fehler im Code ?!?
Das hätte ich auch gemacht, wenn ich ihn nicht bereits wieder verworfen hätte. Ich probiere ja erstmal nur aus, solange ich die Demo hab.
So, nun habe ich einen neuen kleinen Test gemacht, nachdem ich mir einen aktuelleren Grafiktreiber geholt habe. Im DirectX-Diagnoseprogramm stand beim Datum des Haupttreibers 04.01.2006 und nun ist der Treiber wohl vom 22.10.2006. Immerhin, auch wenn er nicht von diesem Jahr ist. Ist aber von der Herstellerseite direkt geladen, daher wird es schon der aktuellste für mein Grafikkarten-Modell sein.
Naja, leider schlug der Test dennoch fehl. Es dauert immernoch so lange! Folgendes, ganz simpler Code:
SETSCREEN 320,240,0
FILLRECT 0,0,320,240,RGB(255,0,0)
//USEASBMP
SHOWSCREEN
KEYWAITHier ist der USEASBMP-Befehl noch "deaktiviert", klar ersichtlich. Das Fenster erscheint und wird auch augenblicklich rot.
Doch wenn ich jetzt die 2 Striche vor USEASBMP wegnehme, bleibt das Fenster nach dem Erscheinen noch ganze 2 Sekunden schwarz! Der Test zeigt es also ganz deutlich: Das Programm hält sich viel zu lange an USEASBMP auf.
Könnte das einer mal bitte bei sich ausprobieren und sagen, wie schnell das Fenster ohne und wie schnell es mit dem Befehl rot wird?
Hallo
Dauert bei mir auch länger. Den Befehl hab ich, wenn ich ehrlich
bin noch nie benutzt. Braucht man den überhaupt?:D. Den Treiber (vom 22.10.2006)
hab ich übrigens auch drauf.
Wäre aber trotzdem gut wenn du deine Sytemdaten hier mit reintust dann muß man bei
einem Problem nicht immer Fragen was in deinem PC so alles steckt. Thx.:)
Cheers
Danke für's Ausprobieren! Ein bisschen beruhigt mich, dass es auch bei Dir länger dauert. Vielleicht tritt dieses Problem bei allen Grafikkarten von NVIDIA auf und bei ATI geht es fix. Ich hatte vor einiger Zeit noch eine ATI :-D
QuoteDen Befehl hab ich, wenn ich ehrlich
bin noch nie benutzt. Braucht man den überhaupt?
Ich würde sagen, ja! Er ist zumindest sehr nützlich, wenn man nicht ständig den gesamten Bildschirminhalt neu zeichen möchte. Es ist natürlich sehr abhängig von der Art, wie man es programmiert hat. Ich finde es sinnvoll, wenn man alle Dinge, die sich nicht bewegen, als Hintergrund speichert. Dann braucht man sich darum nicht mehr kümmern. Im Spielgeschehen ist das möglicherweise meistens weniger nötig, da sich je nach Spieltyp sowieso das Meiste bewegt aber in einem Menü ist das schon nicht schlecht, wenn ich lediglich den Cursor neuzeichnen muss. Zugegeben, wenn das Programm darauf ausgelegt ist (durch entsprechende Subroutinen) sowieso immer alles neuzuzeichen, braucht man den Befehl natürlich nicht.
QuoteWäre aber trotzdem gut wenn du deine Sytemdaten hier mit reintust dann muß man bei
einem Problem nicht immer Fragen was in deinem PC so alles steckt. Thx.
Du hast recht, deshalb: siehe Signatur ;-)
Solltest mal an deinem RAM arbeiten XD ... bisschen wenig ... :)
Ich benutze auch NIE das USASBMP
wie du bestimmt schon gemerkt hast musst du in GLBasic auch den Bildschirm nicht löschen, das macht das SHOWSCREEN selber, ist Quasi das FLIP(Backbuffer->Frontbuffer) und CLS in einen .
Ich setze einen Background ganz normal mit SPRITE... Wieso auch nicht :D
Und ich glaub im Menu brauchst du nicht 100% der FPS, wobei das menu möchte ich sehen was dir da was runterzeiht, das es spürbar wäre!
GLBasic ist ein absoluter "Rennwagen" in der Programmierung, mal abgesehen von deisem USEASBMP!
Schau dir mal die Types an, ich glaub die sind in keiner anderen Sprache schneller.
Soviel zum Thema Offtopic, aber ich wollts mal los werden !
Gelle Gernot XD
QuoteIch benutze auch NIE das USASBMP
Öhm..., dann machen wir's doch einfach so: nehmen wir den USEASBMP raus und machen dafür aus:
WRITEBYTE channel#, val#
WRITEBYTE channel#, pos# ,val#
*g*
QuoteGLBasic ist ein absoluter "Rennwagen" in der Programmierung
Davon lasse ich mich gerne überzeugen, wenn ich dann bald die Hauptroutine meines Spieles schreibe.
spätestens wenn du an die types musst...
da wirst dann baff sein ! ;)
Mach mal an aller erster Stelle im Programm ein "SHOWSCREEN" dazu. Würde mich interessieren, ob's immernoch so lange dauert.
Was für eine Auflösung?
8000 x 6000 ? :D
SHOWSCREEN an erster Stelle macht die Sache nicht schneller, hab's soeben probiert. Aber dafür habe ich jetzt herausgefunden, dass es nur beim erstmaligen Aufruf von USEASBMP so lange zu dauern scheint. Ein weiterer Aufruf lässt keine Verzögerung mehr spüren. Dies zeigt folgender Versuch:
SETSCREEN 320,240,0
FILLRECT 0,0,320,240,255
USEASBMP
SHOWSCREEN
KEYWAIT
FILLRECT 0,0,320,240,16711680
USEASBMP
SHOWSCREEN
KEYWAIT@GernotFrisch
Spätestens durch diesen Fakt brauchst du dem Problem nicht weiter auf die Spur zu gehen, aber vor allem, weil die Leute den Befehl offensichtlich nicht benötigen. Zu der verwendeten Auflösung brauche ich nichts zu sagen, ist aus dem Code klar ersichtlich ;-)
Ich seh grad das die die RGB-Werte noch per hand schreibst XD
Tip :
FILLRECT 0,0,320,240,
dann rechtsklcik auf die stelle
Werkzeuge/RGB Auswahl :)
das spart nerven und ,denk arbeit....
Och, das war gar keine Arbeit! Bisher hatte ich es ja mit RGB() gemacht aber so sieht es professioneller aus. Erst wollte ich ein Hexadezimalwert wie $FF0000 angeben, aber den hat er prompt nicht genommen *gg*
es geht so:
0xff0000 - blau
0x00ff00 - grün
0x0000ff - rot
Quote from: S.O.P.M.Och, das war gar keine Arbeit! Bisher hatte ich es ja mit RGB() gemacht aber so sieht es professioneller aus.
Schuldigung, aber gehts noch?
DU bist nunmal kein Profi, wirst das wohl auch nie sein.
An was willst jetzt noch alles rummeckern, bitte?
Obs like Profi ist oder like noob, solange der Code das erwünschte ergebniss ausgibt, ist doch alles ok!
Also manche Leute haben nerven, dann lern C++ und mach dein eigenes Ding.
soviel meinerseits....*kopfschüttel*
lol. Also statt RGB kann man auch die HEX zahlen so angeben: 0xbbggrr, wobei bb blau (00 bis ff) usw ist.
Da ist die Bombe explodiert!
Quote from: "GernotFrisch"Also statt RGB kann man auch die HEX zahlen so angeben: 0xbbggrr, wobei bb blau (00 bis ff) usw ist.
Nice!
@GernotFrisch
Heute habe ich Dir nochmal einen besonderen Dank für Dein fantastisches Produkt auszusprechen! Ich habe soeben die Hauptroutine meines Spiels für den GP2X fertiggestellt und tatsächlich schafft es GLBasic, die Geschwindigkeit auch auf dem Handheld zu halten. Mehrere Subroutinen, die sich gegenseitig aufrufen - mindestens 50.000 mal werden mehrere Feldvariablen pro Frame durchlaufen - und dennoch bleibt die Framerate von 40 stabil, auf die mein Spiel festgesetzt ist.
Jetzt steht der baldigen Fertigstellung meines Projekts nichts mehr im Wege :)
Hast mir ja nicht geglaubt!
PS.: Gernot ist im Urlaub!
Haste nen Screenshot? würde mich interessieren was du so machst, ich geh mal stark von einem RPG auf Tilemap aus :)
Na hab ich recht :D
Ich habe einen Clone des Puzzlespieles Brix geschrieben, falls Du das kennst. Da ich das Spiel so genial fand, wollte ich es mir nun unbedingt als Projekt für den GP2X vornehmen. Hier ist ein Screenshot von Level 1:
(http://img460.imageshack.us/img460/1005/scrshoteh1.png)
Nun wird man sich auf den ersten Blick nicht vorstellen können, warum die Hauptroutine aufwendig sein soll. Bei diesem Spiel folgen die einzelnen Blöcke, die es ja zu zerstören gilt, keinem festen Raster - jedenfalls in der vertikalen Richtung. Sie müssen frei nach unten fallen können (pixelgenau animiert). Deshalb wäre es nicht damit getan, nur eine Matrix von sagen wir 15x15 Feldern zu machen. Jedes einzelne Objekt muss seperat gespeichert werden und nun muss die Interaktion zwischen jedem Objekt zu jedem anderen Objekt kontrolliert werden. Inklusive der Kontrolle, ob sich gleiche Blöcke berühren, ergeben sich dann jede Menge ineinander verschachtelte Loops.
Damit ist es aber immernoch nicht genug. In weiteren Levels kommen dann noch Laser, Fahrstühle, Schalter und zerbröckelnde Mauern hinzu. Das alles ist in der Hauptroutine bereits eingebaut, die Level muss ich nur erstellen.
Joa, dies ist also mein Projekt. Ich hoffe, es wird dann bald gut bei den Leuten ankommen, wenn es fertig ist.
QuotePS.: Gernot ist im Urlaub!
Den hat er sich verdient, keine Frage. Wenn er wieder kommt und das liest, wird er sich dann freuen :)
schaut ganz nett aus
PUZZNIC! Hurra! Das ist ein's meiner Lieblingsspiele!