Programmieren auf der GP2X

[sechsrad]

Und woher hast du die Info, das das Projekt irgendwie auf Eis gelegt ist?...

ich habe hier mehrere fragen reingestellt und keine antwort bekommen.

habe nach einfachen anfängen in pygame gesucht keine gefunden.

habe fragen nach python gestellt für den gp2x, von dir kamen keine antworten von den anderen auch nicht.

nun scheiss äh... schiess mal los.

ich möchte pygame kennenlernen.

ich suche auch eine befehlsauflistung für pygame bzw suche eine liste welche befehle vom pc-python 2.4.2 nicht auf dem pygame laufen.

aber die frage nach der collison bzw spritedarstellung ist jetzt wichtiger.

 

[jawix]

Und woher hast du die Info, das das Projekt irgendwie auf Eis gelegt ist?...

ich habe hier mehrere fragen reingestellt und keine antwort bekommen.

habe nach einfachen anfängen in pygame gesucht keine gefunden.

habe fragen nach python gestellt für den gp2x, von dir kamen keine antworten von den anderen auch nicht.

nun scheiss äh... schiess mal los.

ich möchte pygame kennenlernen.

ich suche auch eine befehlsauflistung für pygame bzw suche eine liste welche befehle vom pc-python 2.4.2 nicht auf dem pygame laufen.

aber die frage nach der collison bzw spritedarstellung ist jetzt wichtiger.

Dieses Forum ist nicht die einzige Informationsquelle für den GP2X. Deinem Post nach zu urteilen hast du aber lediglich dieses für deine Fragen genutzt.

 

[sechsrad]

die anderen sind nicht so informativ über den gp2x , ist nur stückelkram.
die proggen mit pygame noch weniger rum.

 

[D²O]

Wieso hat GLBasic keine 2d Kollisions erkennug ?
Ich versteh Deine Argumente irgendwie nie.
Soweit ich weis, kann ich eine PIxelgenaue kollision nutzen?

Wieso sagst Du GLBasic nutzt OpenGL beim GP2X?
Wird da nicht wieder SDL genutzt?

Du verwirrst mich!

Kann mich mal einer aufklären?

 

[trucidare]

DU hast ernsthaft mein Tutorial gelesen @ Roland13?
Da freu ich mich ja *mehehehehee*

Ich kann nur sagen klar stecken in sdlBasic fehler. Vroby hat zum zeitpunkt der erstellung eigentlich nur wenig vonn c++ gewusst (wie viel und was er nich wusste sagte er mir nich) aber er hat damit ein basic auf die beine bekommen. Fehlerhaft sind z.B. die Inputroutine um nur ein Beispiel zu nennen. Seit dem allerdings ein neuer programmierer aus <setze> dabei ist werden fehler behoben.

GLBasic und sdlBasic lassen sich absolut nicht vergleich bis darauf das sie unter gp2x linux SDL nutzen. GLBasic wird in reinen c++ code umgesetzt und compiliert und sdlbasic wird interpretiert. Dadurch kann keine codesicherheit errreicht werden und alle projekte werden automatisch opensource.

Beide haben vorzüge. Z.B. sdlbasic. Durch den interpreter kann sdlbasic auf alles portiert werden, dass sdl libs nutzen kann (komplett sdlbasic von a bis z). Bei GLBasic sind verschiedene Kombonenten enthalten die nicht einfach auf alles und jedem portiert werden können.

Glbasic hingegen nutzt opengl, ist schneller dank echte kompilate und bietet die möglichkeit für kommerzielle produkte.

Und hier will dir keiner irgendwas unterjubeln, dass sie dir glbasic empfehlen liegt vielleicht daran das sie davon überzeugt sind? das sie es mögen? denk mal drüber nach

 

[sechsrad]

Wieso hat GLBasic keine 2d Kollisions erkennug ?
Ich versteh Deine Argumente irgendwie nie.

col#=X_COLLISION(num#, frame#, rad#, x#, y#, z#) gibt es nur in glbasic für opengl-3dprojekte. die anderen beiden befehle sind auch nur für 3d.

wäre nett wenn du mir den collisonsbefehl zeigen würdest für 2d.

ich versteh dich nicht, wie lange besitzt du schon das glbasic?

Soweit ich weis, kann ich eine PIxelgenaue kollision nutzen?

na dann scheiss äh... schiess ma los mit dem 2d-collisionsbefehl in glbasic.

 

[sechsrad]

glbasic ist schnell mit opengl und das gibt es auf dem gp2x nicht.

wer lesen kann ist klar im vorteil.

Wieso sagst Du GLBasic nutzt OpenGL beim GP2X?

das habe ich nie gesagt!

du solltest mal den text intensiver duchlesen.

du stellst behauptungen hier auf , weisst du überhaupt von was du redest.

 

[D²O]

Wieso hat GLBasic keine 2d Kollisions erkennug ?
Ich versteh Deine Argumente irgendwie nie.

col#=X_COLLISION(num#, frame#, rad#, x#, y#, z#) gibt es nur in glbasic für opengl-3dprojekte. die anderen beiden befehle sind auch nur für 3d.

wäre nett wenn du mir den collisonsbefehl zeigen würdest für 2d.

ich versteh dich nicht, wie lange besitzt du schon das glbasic?

Soweit ich weis, kann ich eine PIxelgenaue kollision nutzen?

na dann scheiss äh... schiess ma los mit dem 2d-collisionsbefehl in glbasic.

Ähmm.

SPRCOLL

col#=SPRCOLL(id1#, x1#, y1#, id2#, x2#, y2#)

Dieser Befehl bietet eine Kollisionsabfrage auf Pixelebene. Der Befehl führt intern ein BOXCOLL aus, so dass man das nicht mehr zu machen braucht, um Geschwindigkeit zu sparen.

Ich dachte immer GLB Befehle die mit "x_" anfangen, sind 3D befehle?

Edit, hab noch was vergessen.

ANIMCOLL()

col# = ANIMCOLL(ani1#,tile1#, x1#,y1#, ani2#,time2#, x2#,y2#)
Führt eine Pixelgenaue Kollision von 2 Animations-Sprites aus. Die Prüfung erfolgt, als ob man das Resultat von
DRAWANIM(ani1,tile1,x1,y1)
und
DRAWANIM(ani2,tile2,x2,y2)
auf überscchneidungen überprüft.

Ist ani1 oder ani2 keine Animation, sonder ein mit LOADSPRITE/GRABSPRITE erzeugtes Bild, sollte tile1 oder tile2 zu 0 gesetzt werden, da es keine Bedeutung hat. Die Kollision kann Animationen und normale Sprites gemischt behandeln.

Wie lange Programmierst den Du schon?

 

[sechsrad]

dass sie dir glbasic empfehlen liegt vielleicht daran das sie davon überzeugt sind?

was nützen empfehlungen, wenn die nur mit der demo arbeiten und hier nichts rüberkommt.

ich kenne nur 3 spiele im forum die auf dem gp2x von glbasic laufen. mehr gibt es zur zeit nicht.

 

[sechsrad]

ANIMCOLL(ani1#,tile1#, x1#,y1#, ani2#,time2#, x2#,y2#)

ich mache keine tileanimationen. ich verwende einfache sprites.

darum habe ich den befehl nicht genommen. man lernt immer dazu.

 

[D²O]

[qoute]
glbasic ist schnell mit opengl und das gibt es auf dem gp2x nicht
[/quote]

Der satz schwer zu deuten.
Ich habe das mal so interpretiert:

Da GLB schnell mit OpenGL ist und man auch für den GP2X Compilieren kann,
der aber kein OpenGL kann, dass das Compilat das auf OpenGL aufbaut
schlecht für den GP2X Gaumen ist!?

Muss schon zugeben, etwas verwirrend

 

[D²O]

ANIMCOLL(ani1#,tile1#, x1#,y1#, ani2#,time2#, x2#,y2#)

ich mache keine tileanimationen. ich verwende einfache sprites.

Ja wenn Du keine Tileanimationen nutzt, dann nimm doch SPRCOLL()
das ist Ideall für Sprites, Pixelgenau, 2D, benutzt intern schon Boxcollision.
Genau das was Du gesucht hast

Oder verstehe ich wieder nicht?
Du möchtest 3D Objekte mit ner Pixelkollision machen?

.


Und, wie lange Programmierst Du schon?

 

[sechsrad]

jup, hast du gut erklärt.

aber wenn ich das sprite drehe (rotosprite 1,100,100,pi) haut die ganze collision nicht mehr hin.
ist nur brauchbar wenn das sprite nicht gedreht wird.

mal sehen wie man das proggen kann damit es im gedrehten zustand erkannt wird.

 

[D²O]

jup, hast du gut erklärt.

aber wenn ich das sprite drehe (rotosprite 1,100,100,pi) haut die ganze collision nicht mehr hin.
ist nur brauchbar wenn das sprite nicht gedreht wird.

mal sehen wie man das proggen kann damit es im gedrehten zustand erkannt wird.

Ah, verstehe.
Rotosprite benutze ich so nicht, muss ich auch mal testen.
Aber erst morgen, muss jetzt zur maloche
Ich habe meine sprites schon fertig oder erstelle sie zur laufzeit,
mach grabsprite und speicher das ganze.
Rotosprite während dem Mainloop ist, denke ich mal, nur für bildefekte gedacht.
Aber ich schaus mir morgen mal an.

 

[sechsrad]

Rotosprite während dem Mainloop ist, denke ich mal, nur für bildefekte gedacht.

wenn du ein raumschiff steuerst in eine andere flugrichtung, muss die nase ja gedreht werden. und wenn dann die collison kommt, sollte eine erkennung stattfinden in diesem gedrehten zustand.

 

[GernotFrisch]

wobei bei kleinen Sprites eine BOXCOLL völlig ausreichend ist. Ausser Du willst KuruKuruKururin nachproggen. Da empfehle ich die gedrehten Grafiken evtl. zu speichern/laden und damit die Kollision durchzuführen.

 

[Sephiroth]

Zur Kollisionsabfrage in Pygame:
http://www.pygame.org/docs/ref/rect.html#Rect.collidepoint
Darin enthalten:
Abfrage ob...
...ein Punkt in einem Rechteck drin ist
...ein Rechteck mit einem anderen überlappt
...ein Rechteck mit irgendeinem Rechteck aus einer Liste von Rechtecken überlappt
...usw...

(Alle diese "Befehle" geben dir dann einen Wahrheitswert zurück)

Das sollte doch wohl als Kollisionsbafrage genügen


Zu Pygame allgemein.
Wenn du Pygame lernen willst(was ich auch grade mache) würde ich dir empfehlen mal auf Seiten wie:
http://www.pygame.org/
oder auch im offiziellen Python Forum nachzuschauen, bzw. Fragen zu stellen.
Dort findest du auch sehr gut erklärte Beispiele.
Du kannst allerdings auch mal in deinem Pygame-Ordner bei Examples nachschauen, dort findest du auch angenehm klare und einfache Beispiel aus denen man viel lernen kann.
Wenn ich später heimkomme, kann ich dir noch ein paar Links zu guten Tutorials etc. posten.
Am besten schreibst du zuerst ein paar Programme in Pygame für deinen PC. Wenn du das drauf hast ist en kein großer Schritt mehr die auch auf dem gp2x laufen zu lassen.

Gruss Sephiroth

 

[sechsrad]

BOXCOLL

geht der befehl auch bei einer gedrehten box?

 

[sechsrad]

wenn man das python 2.2.4 auf dem gp2x benutzt, sollte man dann auf dem windowspython 2.2.4 lernen oder auch schon auf python 2.5 die programme entwerfen?

 

[GernotFrisch]

BOXCOLL

geht der befehl auch bei einer gedrehten box?

Nee - Du machst eine Box so 80% der Größe des echten Sprites und gut. So machen das alle Automatenspiele der 80er und 90er. Die Per-Pixel Kollisionen kosten unglaublich viel Zeit.