Messages

Da ist die Bombe explodiert!

Also statt RGB kann man auch die HEX zahlen so angeben: 0xbbggrr, wobei bb blau (00 bis ff) usw ist.

Nice!

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*

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

Mal ne Sache, die garantiert ganz einfach zu machen wäre: Die Tabulatorweite sollte einstellbar sein bzw. sollte auf 2 statt 4 Zeichen reduziert werden. Praktisch für's bequeme Einrücken in Schleifen u.s.w.

Hmm, das folding finde ich ne Super sache.

Dem schließe ich mich an. Ich bin das von PureBasic noch gewöhnt. Hatte mir immer sehr gefallen, wenn ich dann immer die ganzen Prozeduren und Funktionen, an denen ich nicht mehr gearbeitet habe, einfach zuklappen konnte und alles war wieder wunderbar übersichtlich.

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.

Mit SQR() würde ich sagen.

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

[ohne]

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?

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.

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.

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?

...aber jetzt mal unter uns, willst du kommerzielle Games machen, oder nur so weils dir spass macht?

Nee, kommerzielle nicht. Ich programmiere, weil ich viel Freude daran habe - es soll wieder ein leidenschaftliches Hobby werden, wie es das vor einiger Zeit und vor allem damals war. Ich kann mir da auch nicht helfen aber irgendwie habe ich den Drang, es gerne ein bisschen professionell machen zu wollen, so weit es mir denn möglich ist. Ich weiß selbst nicht, was mich daran stört, aber die Bitmaps einfach so wie sie sind zum Spiel dazutun - das empfinde ich als laienhaft *g*
Naja ich lass' mir da etwas einfallen - vielleicht doch mit Schuhschachtel, wenn das auch auf dem GP2X klappt.

PS.: das Copy - Parse funzt wirklich einfach die Bilddatei kopieren und bei GLBasic mit Einfügen reinmachen !
Versteh net wieso du dir da verarscht vorkommst ?

Oh du, das war dann wohl ein Missverständnis. Ich dachte, du wolltest mir damit ein simples Kopieren->Einfügen im Windowsexplorer, also vom einen zum anderen Ordner, erzählen. Dass ich im GLBasic Editor dann Einfügen soll, darauf bin ich nicht gekommen, da das ja zugegebenermaßen nicht naheliegend ist. Ein nettes Feature! Jetzt verstehe ich, was du meinst :-)

[bestimmte]

Angenommen du hast die Grafiken in den Ordner gfx, der wiederum im Projectordner ist, dann müsstest du nur so laden :

LOADSPRITE "gfx/bild.bmp",1

Ich hatte den kompletten Pfad angegeben, da hätte es auch gehen müssen.

Alternativ hat GLBasic eine GANZ tolle Funktion, und zwar Copy-> Parse

Wir nehmen nochmal den fall von oben an :

Angenommen du hast die Grafiken in den Ordner gfx, der wiederum im Projectordner ist.

1.gehe in den Ordner gfx !
2.bild.bmp auswählen, und rechtsklick, dann kopieren
3.Ins Project gehn, und rechtsklick im Project dann Einfügen!

Ich komme mir jetzt zwar ein bisschen verarscht vor, aber macht ja nix :-D

Es hat zwar nichts mehr mit dem Titel des Threads zu tun aber: ich find das immer doof, wenn Grafiken und Sounds zu einem Spiel in "Klartext" vorliegen - so, dass sie also von Jedermann einsehbar u. manipulierbar sind. Die Schuhschachtel ist zwar eine Lösung dafür, sofern ich Funktion und Sinn derer richtig verstanden habe, aber toll ist die Lösung auch nicht. Daher meine Frage: Gibt es eine Möglichkeit, ein paar weiterreichende Dateioperationen auszuführen? Mir fehlt sowas wie eine Möglichkeit, Bytes in eine Datei an eine bestimmte Position zu schreiben oder sie von einer zu lesen. Mit PureBasic hatte ich so etwas immer gemacht, dass er z.B. den ersten und letzten Byte einer Datei vertauscht oder Ähnliches. Außerdem gab es dort die Möglichkeit, jegliche Dateien ins Executable einzubinden. Hier hatte ich wohl ein Beispiel irgendwo gelesen, dass auf so etwas abzielt!? - war mir aber nicht sicher, ob's das wirklich ist.

Ich glaube meine Systemdaten werden nun nicht mehr notwendig sein - jetzt geht's!

@Schranz0r
Vielen Dank Dir! Jetzt hab ich das mit den Projektdateien kapiert, daran schien es zu hängen. Wenn ich jeweils die Projektdateien zu den Beispielen öffne, dann funktioniert alles wunderbar. Ich hatte zum einen nur die einzelnen .gbas Dateien geöffnet und zum anderen die .gbas Dateien der Beispiele in meinem Projekt geöffnet. Dadurch schien der Compilier verrückt zu spielen.

Der Grund, warum mein eigenes Projekt nicht klappte, war der Ort des Bitmaps. Es befand sich zusammen mit der .gpas Datei in einem Ordner. Die dazugehörige .gpap Datei jedoch befand sich in einem anderen Ordner. Wenn die Bitmap im Projektordner liegt, dann findet er sie. Mit SETCURRENTDIR hätte es meiner Meinung zwar klappen müssen, aber möglicherweise ist GLBasic nicht darauf ausgelegt, Grafik- und Sounddateien von anderen Ordnern zu laden.

Ich war schon bald am Verzweifeln, wo ich doch GLBasic als den Schlüssel für eigene Spiele am GP2X gesehen habe. Bisher hatte ich immer PureBasic und bin damit super zurecht gekommen. Wenn ich hier mit GLBasic nun grundlegende Dinge erfolgreich ausprobiert habe, dann würde ich mir nämlich das SDK premium Paket leisten wollen.