Ein paar Fragen zu GLBasic und dem Gp2x


Schnatterplatsch

Well-Known Member
Joined
Feb 8, 2009
Messages
1,086
Hallo erstmal

Ich hab mir am Wochenende die Demoversion von GLBasic runtergeladen, und muss sagen, dass ich hellauf begeistert bin, wie einfach man mit dieser Sprache 2D-Spiele programmieren kann. Nach knapp 2h hat ich mein erstes kleines Ballerspiel fertig :p :p :p . Stolze Leistung(zumindest für mich), wenn man bedenkt, das ich selbiges 2 Jahre lang in Java versucht habe und das ganze immer noch recht instabil läuft. Nunja lange Rede kurzer Sinn. Ich hab erfahren, dass man GLBasic Programme recht einfach auf dem Gp2x zum laufen bekommt. Nun, ich überlege mir einen Gp2x zu kaufen, zumindest bis die Wiz erscheint.

Frage 1: Kann man Programme die mit der Demoversion geschrieben sind auf dem gp2x ohne Probleme ausführen???(Abgesehen von Wasserzeichen+5 min Limit)

Frage 1.1: Gibt es irgendwelche gravierenden Probleme mit dem gp2x/wiz compiler???

Frage 2: Da GlBasic so extrem einfach zu proggen ist, wo liegen die Grenzen dieser Sprache?

Frage 3: Gibt es eine Möglichkeit Nebenläufigkeit(Threads) zu programmieren???




Nun, entschuldigt bitte, dass gleich mein erster Post so viele Fragen enthält...
Hoffentlich beachtet das hier eiiner... wenn man bedenkt das der letzte Post hier vor knapp einem Jahr war...

Grüße
 
1. Ja, Demo geht auch auf anderen Platformen
1.1 nein, läuft ganz rund. Nur der WIZ fehlt noch.
2 in Deinem Kopf. Ehrlich. Mit INLINE ist alles möglich.
3 Threads gibt es. Such im Forum oder frag dort nochmal. Das ist eine Bibliothek zum Einbinden. Aber alles easy.
 
1. Ja, Demo geht auch auf anderen Platformen
1.1 nein, läuft ganz rund. Nur der WIZ fehlt noch.
2 in Deinem Kopf. Ehrlich. Mit INLINE ist alles möglich.
3 Threads gibt es. Such im Forum oder frag dort nochmal. Das ist eine Bibliothek zum Einbinden. Aber alles easy.

Dankeschön für deine Hilfe!!! Das beruhigt mich ja. Was hat es denn genau mit diesem INLINE auf sich? verstehe ich das richtig, dass man dann C++ befehle einbinden kann?? Naja is im prinzip egal, im Moment hab ich genug zum spielen :D :D :D
Schnatterplatsch release den shooter!!! ;)

Gib mir mal noch 2 Wöchelchen. Im Moment ist das alles noch recht einfach... Mal sehen vielleicht lad ich im laufe des Abends mal was hoch... Aber dann bitte nicht lachen, ja?!?


EDIT: So ich hab mein "Spielchen" mal hier hoch geladen, wie gesagt nicht lachen, ich weiß da gibts noch viel zu tuen(Ich progge ja erst seit Sonntag daran.).

Wenn ihr verbesserungsvorschläge habt, immer her damit.

Zur Steuerung(eigentlich ganz simpel):
Leertaste -> schießen
Richtungtasten(up and down)-> Schiff bewegen
A -> schneller
Y -> langsamer
 
Schnatterplatsch, ich finde das auch gut für die kurze Zeit, die Du erst mit GLBasic arbeitest. Wenn Du in solch einer Zeit schon so etwas hinkriegst, ist GLBasic eindeutig die richtige Programmiersprache für Dich. Dann stell ich mir leicht vor, was für Spiele Du in ein paar Monaten zustande bringen könntest.
 
Dann stell ich mir leicht vor, was für Spiele Du in ein paar Monaten zustande bringen könntest.

Hehe, ich habe große Pläne....

Ich hab grade angefangen an ner Art "X"(ne hübsche Weltraumspielserie) in 2d zu programmieren. Dabei stellt sich aber das Problem der Kollisionsabfrage von Bildern. So eine Raumstation füllt ja kein Quadrat aus, sondern sieht ungefähr so aus:





Mir fällt dazu eigetnlich nur eine Vorgehensweise ein die auch realisierbar ist: Irgendwie über ".getColor(posx,posy)"(oder so) was einen Hexadezimalwert zurückliefert über den man rausfinden könnte ob sich an der Position Station befindet oder nicht. Gibts sowas in der Art in GLBasic??? Oder gibt in GLBasic schon eine Collisionsabfrage für sprites die die transparenten flächen auslässt???

Gruß

EDIT: Bevor ich es vergesse: hab
http://forum.gp2x.de/viewtopic.php?f=22&t=4799 said:
gelesen, dass Rotosprite auf dem Gp2x sehr langsam seien soll. Ist das eigentlich immer noch so(ich hab noch keinen gp2x)??? Da ich meine schiffe mit rotosprite drehen möchte wäre das nicht so günstig wenn das auf dem GP2x dan nicht funktioniert.

Würde es denn auf der Wiz korrekt laufen(falls das schon einer weiß)

Nachgruß
 
SPRCOLL für die Kollision.
Rotosprite musst Du testen. Ich mach in WIZsticks hundert mit alphablending und rotation, geht. Sind aber klein (6x6)
 
SPRCOLL für die Kollision
Aber doch nur für ungedrehte bilder, oder? Hab grad den Befehl ANIMCOLL entdeckt, der scheint zu sein was ich suche. Weißt du ob der sehr rescourcen- fressend ist?(Ich würd mir ungern nen gp2x kaufen wenn das nachher unter 25fps fällt)

EDIT: Ah, ich glaub jetzt hab ich das Prinzip von Rotosprite verstanden. Animcoll erlidigt sich somit
Rotosprite musst Du testen. Ich mach in WIZsticks hundert mit alphablending und rotation, geht. Sind aber klein (6x6)
Rechne rechne 6*6*100=3600 Pixel entspricht ungefähr 4 schiffen alla 40*20 pixeln sollte also hinhauen

Dank dir für deine hilfe



EDIT!!!

Irgendwie läuft das jetzt doch nicht so wie ich mir das vorgestellt habe.
Hab in diesem testprogramm 4 Sprungtore und ein Schiff erzeugt(das schiff könnt ihr mit den richtungstasten und a(schneller)und y(langsamer steuern)). Probiert das mal aus, bei mir zeigt der Kollisionen an, wo keine sind(siehe Nordtor) oder er zeigt keine Kollision an obwohl eine da ist(dazu mal ganz langsam von oben an das westtor(das tor gleich beim start) ranfliegen bis zu einer giwissen schnittmenge von schiff und tor zeigt er keine kollision an). Wäre wirklich coll, wenn sich jemand das mal anschauen würde
 
Schau mal hier http://www.glbasic.com/forum/index.php?topic=927.0. Hier wird zumindest ein Teil von
deinem Problem besprochen.
Code:
<i>
</i>DRAWSPRITE Westtor1,WesttorVirtPosx-Playerposx,WesttorVirtPosy-Playerposy
DRAWSPRITE Westtor2,WesttorVirtPosx-Playerposx,WesttorVirtPosy-Playerposy
DRAWSPRITE Sudtor1,SudtorVirtPosx-Playerposx,SudtorVirtPosy-Playerposy
DRAWSPRITE Sudtor1,SudtorVirtPosx-Playerposx,SudtorVirtPosy-Playerposy
Kann es sein, dass du dich irgendwo in der letzten Zeile vertippt hast? :wink:
 
Kann es sein, dass du dich irgendwo in der letzten Zeile vertippt hast? :wink:

hab ich, ändert aber leider nichts daran, dass es mit der KA nicht klappt.



Schau mal hier http://www.glbasic.com/forum/index.php?topic=927.0. Hier wird zumindest ein Teil von deinem Problem besprochen.

für mich sieht das so aus als wärs das ganze problem, nämlich(fast mit h geschrieben, uff :D ), dass es für rotierte sprites wegen potenzieller speicherüberlastung keine kollisionsabfrage gibt. Wennn ich das richtig sehe gibt für mich jetzt folgende möglichkeit: Vor programmstart das schiff um ein grad(zwei grad drei grad mal sehen...) drehen mit grabsprite "fotografieren" wieder um ein grad drehen, etc.

sehe ich das richtig???
 
ich bins malwieder. hab da noch ein kleines problem mit glbasic.
ich mach das jetzt so wie du vorgeschlagen hast, das heißt ich drehe meine objekte vor programmstart in 4 grad schritten und soecihere sie ab. funktioniert ja auch alles. wenn ich jetzt aber kleinere objekte habe(40x40), und diese drehe bilden sich um das objekt ränder.

http://www.pic-upload.de/08.04.09/7xmge9.jpg

sieht net schön aus.
also hatte ich folgende idee: ich mal das bild in ein grad schritten(specihere alle 4 schritte ab). nach jedem schritt wird jeder pixel auf seinen farbwert überprüft. weicht er leicht von (255,0,128)<-transparenz ab wird er wieder auf transparent gesetzt. frage ist bloß: wie mach ich das...

col=getpixel(x,y) liefert ja lediglich den farbwert(rbg(a,b,c)) ich will aber sowas: col=getpixel(x,y,a,b,c) geht das irgendwie... bisher blieben meine recherechen erfolglos....
 
Hallo Schatterplatsch

Ich habe folgendes in der GLBasic-Hilfe gefunden:
SMOOTHSHADING mode%
Dieser Befehl schaltet zwischen weicher (mode#=TRUE: GL_LINEAR) und schneller (mode% = FALSE: GL_NEAREST) Interpolation beim Vergrößern von Sprites um.
Die Grafik wird bei mode%=FALSE beim Vergößern blockig, und gleichen damit der Ausgabe auf PocketPC und GP2X mehr.
Tritt bei GRABSPRITE ein unschöner Rand auf, sollte mode%=FALSE auch das beheben.

Hilft Dir das vielleicht bei kleineren Objekten?
 
werds auf jeden fall mal probieren, danke. komisch, das es an GRABSPRITE liegt hätte ich nicht gedacht. eher rotosprite, aber egal wir werden sehen.

gruß

EDIT:Klappt nicht. scheint also DOCH an Rotosprite zu liegen. Hab ich ne Blockade oder ist es wirklich nict möglich die rot, grün und blau werte einzeln zu bekommen????
 
Ansonsten hier eine Beispielfunktion:
Code:
<i>
</i>FUNCTION ConvertPixel: x%,y%,r%,g%,b%

LOCAL col%,rr%,gg%,bb%

        col=GETPIXEL(x,y)
        rr=bAND(col,0xFF0000)
        gg=bAND(col,0x00FF00)
        bb=bAND(col,0x0000FF)
        
        rr=INTEGER(rr/65536)
        gg=INTEGER(gg/256)
        bb=INTEGER(bb/1)

        rr=bAND(rr,r-1)
        gg=bAND(gg,g-1)
        bb=bAND(bb,b-1)

        SETPIXEL x,y,rr*65536+gg*256+bb

ENDFUNCTION
Dabei ist x,y die position des Pixels und r,g,b der Annäherungswert pro Farbwert. Mögliche Werte sind 2,4,8,16.
Versuch's einfach mal.
 
Poste das mal im GLBasic Forum. Das muss schon gehen. Ich hab das bei WIZSticks auch so gemacht (sogar in Echtzeit auf dem WIZ).
 
Ansonsten hier eine Beispielfunktion:
Erschieß mich bitte nicht aber entweder es funktioniert net, oder ich mach was flasch. Wenn ich jetzt einen Pixel auf seine "Nähe" zu transparenz überprüfen lassen will muss ich folgendes eingeben oder???
ConvertPixel x,y,255,0,128

r,g,b der Annäherungswert pro Farbwert. Mögliche Werte sind 2,4,8,16.

Das versteh ich überhaupt nicht.


Was ich jetzt, glaub ich, aber begriffen habe ist: col (definiert durch "=getpixel(x,y)") ist ja ein zahlenwert. irgendwie muss man doch aus diesem zahlenwert die einzelnen werte auslesen können oder. wäre ja nur logisch. hab folgendes probiert:

eine farbige fläche(aus bmp datei) mit (209,115,101), also in hexadezimal "d1,73,65" und in dezimal "13726565"(die hexadezimalzahl d17365 nach dezimal umgerechnet). frage ich jetzt aber den farbwert eines pixels(x=10,y=10) bekomme ich folgenden dezimalwert: "4227327". das verstehe ich irgendwie nicht.
Poste das mal im GLBasic Forum. Das muss schon gehen. Ich hab das bei WIZSticks auch so gemacht (sogar in Echtzeit auf dem WIZ).

Wenns bis heut abend in meinem gehirn nicht ratsch macht und ich weiß was ich falsch mache dann post ichs ins glbasic forum.
arrrgh irgendwie frustriert das. macht aber auch höllisch spaß.



gruß
 
Erschieß mich bitte nicht
Ich hab vor ca 3 Jahren meinen oblig. Militärdienst beendet, bin kein Hobbyschütze und spiele keine "Killerspiele"; also keine Gefahr! :wink:

Allerdings hat sich bei meinem Code auch ein Fehler eingeschlichen :eek:

Ein (24Bit) Farbwert besteht aus 3 Komponenten. Rot, Grün und Blau. Wie du sicher weisst kann jeder von diesen einen Wert von 0..255 enthalten (in hexadezimaler Form 0x00..0xFF). Diese Werte werden in EINER Zahl nacheinander gespeichert. In hexadezimaler Form sieht das dann etwa so aus: 0x00RRGGBB.
Code:
<i>
</i>        rr=bAND(col,0xFF0000)
        gg=bAND(col,0x00FF00)
        bb=bAND(col,0x0000FF)
isoliert den jeweiligen Farbwert durch Maskierung, d.h. es werden die anderen Komponenten auf 0 gesetzt.
Beim Blauwert ist es nun einfach, da wird jetzt schon der richtige Wert angezeigt.
Da zum Beispiel bei Grün der Wert 2 HEX-Stellen weiter links ist müssen wir um diese 2 Stellen nach rechts verschieben, was einer Division durch 256 entspricht.
Bei Rot sind es 4 Stellen, also Division durch 65536.
Code:
<i>
</i>        rr=INTEGER(rr/65536)
        gg=INTEGER(gg/256)
        bb=INTEGER(bb/1)
Jetzt haben wir also alle einzelnen Komponenten in eigenen Variablen (rr,gg,bb).

In der Funktion
Code:
FUNCTION ConvertPixel: x%,y%,r%,g%,b%
sind nun r,g,b wiederum "Bit-Masken". D.h. in BINÄRER Form kann eine Zahl mit 8 Stellen angezeigt werden wobei jede einzelne Stelle mit 0 oder 1 belegt sein kann. Nehmen wir zum Beispiel die Zahl 2. In binärer Form sieht die so aus: b00000010. Bitte "google" mal nach Bit-Arithmetik für detailiertere Erklärungen.
Jetzt kommt der Clou. Durch die folgende binäre Maskierung wird überall, wo in unserer Maske (r,g oder b) eine Null ist bei rr,gg oder bb das Bit an der entsprechenden Stelle gelöscht, ansonsten belassen.

ACHTUNG HIER CODE GEÄNDERT !!!
Code:
<i>
</i>        rr=bAND(rr,256-r)
        gg=bAND(gg,256-g)
        bb=bAND(bb,256-b)
Als Beispiel:
rr enthält den Wert b11111111 (255)
r enthält den Wert b00000010 (2)
Zuerst: 256-r=256-2=254=b11111110
Dann:
b11111111
bAND
b11111110
----------
b11111110 = 254
========
Damit haben wir nun alle Werte zwischen 254 und 255 angeglichen auf 254.

Nächstes Beispiel:
rr enthält den Wert b11111111 (255)
r enthält den Wert b00000100 (4)
Zuerst: 256-r=256-4=252=b11111100
Dann:
b11111111
bAND
b11111100
----------
b11111100 = 252
========
Damit haben wir nun alle Werte zwischen 252 und 255 angeglichen auf 252.
Wenn wir diese Zahl immer erhöhen (8,16,32..) wird die Annäherung immer mehr ausgeweitet.
 
Back
Top