GLBasic macht sich, 2 neue Fragen

[S.O.P.M.]

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?

[Kitty Hello]

VAL gibt's nicht. Das mach GLBasic von alleine:

Code (glbasic) Select Expand

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.

[HeikoJ]

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

[S.O.P.M.]

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.

[Schranz0r]

Schicker ist wenn du den Code einfach postes, so kann man sich ein Bild davon machen!
Evtl. ist es ja ein Fehler im Code ?!?

[S.O.P.M.]

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.

[S.O.P.M.]

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:

Code (glbasic) Select Expand

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?

[BumbleBee]

Hallo

Dauert bei mir auch länger. Den Befehl hab ich, wenn ich ehrlich
bin noch nie benutzt. Braucht man den überhaupt?.  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

[S.O.P.M.]

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

Den 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.

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.

Du hast recht, deshalb: siehe Signatur ;-)

[Schranz0r]

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

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

[S.O.P.M.]

Ich 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*

GLBasic ist ein absoluter "Rennwagen" in der Programmierung

Davon lasse ich mich gerne überzeugen, wenn ich dann bald die Hauptroutine meines Spieles schreibe.

[Schranz0r]

spätestens wenn du an die types musst...
da wirst dann baff sein !

[Kitty Hello]

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?

[Schranz0r]

8000 x 6000 ?

[S.O.P.M.]

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:

Code (glbasic) Select Expand

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 ;-)