eigene Rect Klasse

[Sirius3]

@Madmartigan: interessant wird es, wenn sich etwas ändert, z.B. die darunterliegende Graphik-Bibliothek ändert, und man Rechtecke dann per center und width/height angibt, statt einer Ecke. Dann gibt es plötzlich eine Funktion, die nur ein Attribut wiedergibt und Attribute x und y die irgendwie in der Luft hängen.

@BlackJack: [Klugscheißer]es sind nur zwei Zeilen[/Klugscheißer]

[Don Polettone]

ähhhh... Jungs? Ich geniesse es ja sehr, dass mein Bananen-Thema Euch zu derartigen geistigen Höhenflügen animiert, aber a) verstehe ich nur Banane und b) weiss ich noch immer nicht, warum der print Befehl nicht ausgeführt wird

...neee echt jetzt: Danke für die vielen, interessanten Ansätze! Ich werde vorab jetz mal den Rat von EyDu befolgen:

[/quote]
Erstelle eine Kopie des Moduls und streiche so lange überflüssigen Code, bis nur noch der Fehler übrig bleibt. Oder baue einfach jede Menge print-Aufrufe ein, um die genauen Aufrufe zu verfolgen.[/quote]

Schliesslich will ich meine (zahlreichen) pythonischen Lücken schliessen und jetz mal endlich mit properties umzugehen verstehen; und da bin ich zumindest schon mal auf gutem Wege. Heute kann ich vielleicht schon etwas zügiger mit property stuff coden als gestern; gestern hatte ich noch volllllllll die Mühe damit. Mir habt Ihr also geholfen; ich hab wieder was gelernt und verstehe wieder ein Mü mehr Python Syntax. Wenn das mal nicht fett ist (ist mein's ernst!).

Danke Leute - I'll be back wenn ich den Fehler isoliert und immer noch Fragen habe, dann können wir dann wieder über Sinn und Unsinn meines "Kots" sinnieren... Ist eigentlich schon toll, dass es User wie mich gibt, die eben noch wirklich bananenmässige Fragen haben, oder? Auf jeden Fall scheint's zu reden zu geben! Ich find's amüsant, dass eben gerade die "dummen" Fragen, die Ihr Euch gar nicht mehr erst stellt, so zu reden geben. (Auf positive Weise amüsant; ist nicht abwertend gemeint).

Ich find's toll dass es dieses Forum gibt, und ohne Euch gäb's es nicht.

bis in aller Bälde dann... cheers!

[bwbg]

Auch wenn ich mich nicht gerne selbst zitiere, hier aber doch:

Da Du Python 2.x verwendest, sollte Deine Klasse von object erben.

Setter funktionieren IIRC nicht mit old-style classes.

[Don Polettone]

...dann heisst das, ich kann meine Rect Klasse gar nicht so umsetzen, weil ich in Python 2.x keine properties mit setter machen kann?? Oder was genau heisst das? Es geht schon, wenn ich von object erbe, oder?

[bwbg]

Probiers doch einfach mal aus.

[Don Polettone]

gerade geschehen! Und siehe da; Ihr hattet natütterlich Recht: Wenn My_Rect von object erbt dann geht's - ich hatte richtig gecodet und es funzt soweit

Ich habe ne eigene Rect Klasse gecodet... sooo geil!

Danke

Code: Alles auswählen

class My_Rect(object):

    def __init__(self, left, top, width, height, xyoffsets=(0, 0)):

        self.x_offset = int(xyoffsets[0])
        self.y_offset = int(xyoffsets[1])

        self._x = float(left) + self.x_offset
        self._y = float(top) + self.y_offset
        self._left = int(left)
        self._top = int(top)
        
        self.width = int(width)
        self.height = int(height)

    @property
    def x(self):
        return self._x

    @x.setter
    def x(self, value):
        self._x = float(value)
        self._left = int(self._x) - self.x_offset
        print "self._left set!", self._left

    @property
    def left(self):
        return self._left

def we_are_the_knights_who_say__it_doesnt_print():

    ni = My_Rect(0,0,16,16,(8,8))
    print ni.left
    ni.x += 3
    print ni.x
    print ni.left

we_are_the_knights_who_say__it_doesnt_print()

--->

Code: Alles auswählen

left 0
self._left set! 3
x 11.0
left 3

...heftig

[EyDu]

Du hast noch immer diesen unschönen offset-Parameter.

Auch solltest du die ganzen int- und float-Aufrufe sein lassen. Entweder betreibst du hier Cargo-Cult-Programming oder du implementierst in der Rect-Klasse Dinge, die eigentlich außerhalb der Klasse passieren sollten.

Nach PEP8 sollte deine Klasse MyRect heißen.

[Don Polettone]

Hmmm.... bzgl. den floats und ints: Das ist eigentlich schon so gewollt von mir. Wenn man aus Versehen x oder y einen int zuweist, dann wird er zum float. Dasselbe anders herum: Wenn man rect.left anpasst oder rect.topleft oder so und denen floats zuweist, ist das nicht eine optimale Ausgangslage; ich will gewisse Werte als float (or bust) und gewisse als int. Ganz gezielt und gewollt.

Was Cargo-Cult-Programming ist wusste ich nicht, jetzt schon. Nein, ich code vielleicht nicht "schön" (ich hab's auch nie echt gelernt und mach's noch nicht allzu lange), aber ich code selbst.

Dann findest Du den offsets Parameter nicht so doll... die Sache ist eben, dass üblicherweise, wenn ich einen Char mache, es zwangsweise irgendeine "Boden-Position" gibt, wo der Char, wer hätte es gedacht, am Boden steht. *schmunzel* Nun ist aber je nach Char diese Position nicht immer gleich, aber: Sie ändert sich gewöhnlicherweise nicht. Und wenn ich nun einen 2D Char mache mit elliptischem Schatten unter den Füssen und "Pseudo-Bildtiefe", dann möchte ich diese Position unten zwischen den Füssen haben. Da sollse auch bleiben. Wenn ich aber einen top-down-Char mache, ist's die Mitte des Rects. Wenn ich einen "ordinären" Seitenansicht - Jump'n'Run Char möchte, dann ist's midbottom. Und ich möchte eben die "Ground Pos" immer als float haben (eben mein x, y) und die Rect Koordinaten als ints. Dies war der Grund, warum ich überhaupt eine eigene Rect Klasse haben wollte, sonst könnte ich auch die von Pygame nehmen (was ich bis anhin auch getan hatte).
...und weil ich ja die offsets von x und y nur beim Erstellen eines Chars definieren möchte, habe ich's in __init__ eingebaut. Und weil die offsets aber gebraucht werden, wenn ich rect.x anpasse und dann die Attribute des rects geändert werden sollen, muss ich's doch zuweisen, oder nicht? Evtl. liege ich total falsch, aber siehst Du was ich meine?

[EyDu]

Naja, du solltest halt nicht "aus Versehen" falsche Werte reinstopfen Üblicherweise testet man so etwas mit asserts, dann kann das nicht passieren. An deiner Stelle würde ich einfach alles zulassen, dann hast du eine Rect-Implementierung, welche sowohl mit Integern als auch mit Floats arbeiten kann.

Zum Offset: Jedes Klasse/Methode/Funktion/etc. sollte möglichst genau eine Aufgabe haben. Und ein Rechteck ist nunmal ein Rechteck und besitzt keinen Offset, keine Farbe, keine Textur oder sonstige Eigenschaften. Ein Rechteck ist ein einfaches geometrisches Objekt mit vier Werten. Wie du ja selbser schon geschrieben hast, brauchst du den Offset für Charaktäre, also musst du diesen auch irgendwo dort ansiedeln.

Edit: Bei der Gelegenheit: Hast du schon über den Einsatz von NumPy nachgedacht, das macht einiges doch etwas schöner:

Code: Alles auswählen

import numpy as np

class Rect(object):
    def __init__(self, position, dimensions):
        self._position = position
        self._dimensions = dimensions
    
    @property
    def left(self):
        return self._position[0,0]
    
    @property
    def width(self):
        return self._dimensions[0,0]
    
    @property
    def bottom_right(self):
        return self._position + self._dimensions
    
    def __add__(self, offset):
        return Rect(
            self._position + offset,
            self._dimensions)
        

def main():
    position = np.matrix(
        [[20],
         [10]],
        np.int)
    
    dimensions = np.matrix(
        [[200],
         [100]],
        np.int)
    
    offset = np.matrix(
        [[2],
         [1]],
        np.int)
    
    rect = Rect(position, dimensions)
    print rect.left
    print rect.width
    print rect.bottom_right
    
    rect += offset
    print rect.left
    print rect.width
    print rect.bottom_right


if __name__ == "__main__":
    main()

ergibt

Code: Alles auswählen

20
200
[[220]
 [110]]
22
200
[[222]
 [111]]

[Don Polettone]

sagen wir mal, ich möchte die Rect Attribute wirklich als ints. Für meine Zwecke - also verpixelte 2D Games - sind die ideal. Immer wenn's ans blitten geht müsste ich sonst umrechnen wenn's floats wären.

Jetzt würdest Du x und y (floats) nicht dem rect, sondern dem Char Objekt als Attribute mitgeben, und wenn man diesen einen neuen Wert zuweist würdest Du das char.rect ändern?

also z.Bsp.

char.x = 10.0

-> ändert char.ground_rect

?

Das wäre schon auch sexy aber das Problem ist nun wieder, dass sich ja x und y auch "aktiv" anpassen sollen, wenn ich die Koordinaten des Rects anpasse, und das geht ja dann wieder nicht, weil ich dies ja in die properties der Rect Klasse coden müsste, und diese hat natürlich keinen direkten "Zugriff" auf den Char und dessen Variablen??

Nein echt jetzt, ich glaub ich hab's jetzt wirklich so wie ich es eben wollte... Wenn man nur ein "dummes" Rect haben will ohne die x / y floats, könnte ich ja auch noch implementieren, dass, wenn man kein offsets Parameter mitgibt, es diesen gar nicht definiert ich dann ein dummes Rect habe? Das wäre gerade eine schöne Übung, "assert" ein bisschen anzuwenden glaub ich... ich tu das mal

[Don Polettone]

das mit Numpy ist nett, aber ich möchte glaub ich coden können

ni = MyRect((0, 0), (16, 16))

ich bin's so gewohnt von Pygame und finde das kurz, sauber und lesbar. 2 Fragen aber noch: Wenn ich möchte, dass ich ein Rect mit

ni = Rect(pos, size)

oder

ni = Rect(left, top, width, height)

erstellen kann, wie kann ich das in die Klasse packen, dass beides funktioniert?

Und wie kann ich selbst definieren was passiert, wenn man mein Rect Object printet?

[EyDu]

sagen wir mal, ich möchte die Rect Attribute wirklich als ints. Für meine Zwecke - also verpixelte 2D Games - sind die ideal. Immer wenn's ans blitten geht müsste ich sonst umrechnen wenn's floats wären.

Wenn du nur Integer reinsteckst, dann werden auch nur Integer rauskommen Du musst dir doch nicht unnötigt die Allgemeingültigkeit nehmen.

Jetzt würdest Du x und y (floats) nicht dem rect, sondern dem Char Objekt als Attribute mitgeben, und wenn man diesen einen neuen Wert zuweist würdest Du das char.rect ändern?

Ok, vielleicht gehen wir das Problem mal von der anderen Seite an. Ich habe dich bisher so verstanden, dass du das Rect zum Zeichnen von Objekten benötigst. Bleiben wir einfach mal bei dem von dir ins Spiel gebrachten Character. Dieser Character hat dann eine Position (x,y) und die Größe (width, height), welche du im Rechteck speicherst? Sehe ich das richtig so?

Wenn ja, dann würde ich das Problem anders lösen: der Character bekommt eine Position (cx, cy). Zusätzlich bekommt er ein Rechteck. Dieses erstellst du dann so, dass die Füße (oder was auch immer bei dir der Referenzpunkt ist) sich bei der Position (0, 0) im Rechteck befinden. Und das machst du alles relativ. Mal als Beispiel:

Der Character ist 100 Breit und 200 hoch, dessen Füße befinden sich unten in der Mitte. Dann hat er das Rechteck mit der Position (-50, 0) und die Größe (100, 200). Erst wenn du jetzt den Spieler bei (cx, cy) zeichnen willst, dann erstellst du ein neues Rechteck und addierst darauf (cx, cy).

Du solltest auf keinen Fall die Position und die Ausmaße des Characters irgendwie zusammen in ein Rechteck werfen, das macht später unglaublich viele Dinge kompliziert. Am einfachsten ist es, wenn du alles relativ zur Position der Figur definierst (Ausmaße der Figur, Schatten, Waffen, etc.) und erst ganz am Ende (beim Zeichnen oder bei Kollisionen), das konkrete Rechteck bestimmst. Damit wirst du dir jede Menge unnötige Überlegungen und Berechnungen sparen. Falls meine Überlegungen nicht zutreffen, dann beschreibe doch bitte genauer, was du vor hast.

ni = MyRect((0, 0), (16, 16))

Das könntest du zusätzlich implementieren. NumPy macht viele Dinge halt viele Berechnungen einfacher. Statt zwei Additionen für die Position benötigst du zum Beispiel nur noch eine. Von anderen Transformationen oder Berechnungen von Inversen ganz zu schweigen. Wenn du das alles aber nicht benötigst, dann lasse NumPy einfach weg.

ni = Rect(pos, size)
oder
ni = Rect(left, top, width, height)

Mit ``func(*args)`` kannst du einer Funktion beliebig viele Argumente übergeben (welche dann in args stecken). Wenn es zwei sind, dann könntest du ein Rechteck über die erste Variante erstellen, bei vier über die zweite. Allerdings ist das kein besonder schönes Interface. Üblicherweise bietet sich dafür eine zusätzliche Methode an:

Code: Alles auswählen

class Rect(object):
    def __init__(left, top, width, height):
        ...

    @staticmethod
    def from_tuples(pos, size):
        return Rect(...)

a = Rect(10, 20, 110, 220)
b = Rect.from_tuples((10, 20), (100, 200)

Und wie kann ich selbst definieren was passiert, wenn man mein Rect Object printet?

Implementiere die __str__- und __repr__-Methoden für Rect. Ersteres ist für den Benutzer gedacht, letzteres für den Programmierer. Im Idealfall gibt __repr__ einen String zurück, mit welchem man das Objekt wieder erzeugen könnte.

[Don Polettone]

Ich versuche zu erklären, was genau ich machen möchte und weshalb ich x und y als floats und die rect Attribute als ints haben will:

die update Methode wird ja für den Char einmal pro Frame aufgerufen. Sagen wir ein Frame dauert 10ms (das ist mein übliches delta). Der Char soll sich nun bewegen. Hier sind floats gefragt damit ich den Char genau mit der richtigen Geschwindigkeit bewegen kann. Ich möchte hier nicht mit ints arbeiten, also z.Bsp. einen "Counter" setzen, der den Char alle 3 Frames ein Pixel bewegt oder was auch immer. Deshalb die Floats. Smooth Movement. Ich verändere char.x ein klein wenig, und die rect Attribute werden automatisch angepasst (properties). Das rect des Chars brauche ich für Kollisionsabfragen etc, es wäre im aktuellen Fall so gross wie 1 Tile (16 x 16) Pixel. Das Bild des Chars (char.img) ist aber grösser, hat also ein anderes rect.

Wenn ich den char bewege, soll das hit_rect mitbewegt werden, aber nur in absoluten Pixeln (eben ints). Wenn ich den Char aber auch mal z.Bsp. rechtsbündig anhand des hit_rects ausrichten möchte, möchte ich, dass, wenn ich die hit_rect attribute ändere (char.hit_rect.right = ni), auch x und y geändert werden.

Ich will also, dass (x, y) und das hit_rect sich gegenseitig aktiv beeinflussen, dann muss ich doch das so machen innerhalb meiner MyRect - Klasse, wie ich's gemacht habe, nicht?

[bwbg]

Du denkst zu verpixelt ...

Der Grund, dass Du eine eigene Rect-Klasse entwickelst, ist der, dass du intern für deine Spielfigur eine andere Repräsentation benötigst, als auf dem Bildschirm zu sehen ist. Ein Pixel mehr oder weniger ist später ohnehin nicht relevant, weil es nicht wahrgenommen wird.

Das ist für sich genommen schonmal ein guter Ansatz (Trennung von Logik und Darstellung). Aber so wirklich trennen willst Du die beiden dann doch wieder nicht.

Deine Spielelogik, welche auf die floats setzt, muss und sollte nichts von der späteren Darstellung wissen. Sie sollte vielmehr die nötigen Berechnungen durchführen (Bewegungen, Kollisionsprüfungen, Updates, u. v. m.). Das Ergebnis (der Zustand der Logik) wird dann lesend auf den Bildschirm gebracht.

Die mainloop könnte dann vereinfacht wie folgt aussehen.

Code: Alles auswählen

def mainloop(self):
    while self.running:
        delta_time = self.clock.tick(self.FRAME_LIMIT)
        self.process_events()
        self.update_logic(delta_time)
            # Man sollte jedoch zusehen, dass die Logik in FESTEN
            # Schritten arbeitet.
        self.update_graphics(delta_time)
            # Hier wird u. a. der Zustand der Spiellogik in die Grafik
            # überführt.
        self.draw_graphics()

Als Beispiel meine Rect-Klasse. rects.py
und ihre möglich Anwendung bzw. Überführung in ein pygame.Rect. EDIT: Ich verwende hier Python 3.x.

Nochmal zur Erinnerung: Die Kollisionsprüfungen etc. finden in Deiner Rect-Klasse statt. pygame ist in der Hinsicht nun außen vor.

[EyDu]

Da trifft meine Vermutung ja in etwa zu. bwbg ist in seinem Thread noch einmal gut auf das Problem eingegangen. Vergiss die Pixel, arbeite mit Floats. Erst ganz am Ende, beim Zeichnen, brauchst du das Rechteck in absoluten Koordinaten.

[Don Polettone]

Hey ich glaube ich mache das doch schon so ähnlich?

Darf ich Euch mal mein bisher umfangreichstes Projekt zeigen? Gibt es einen Weg, mittels dem ich das ganze Game hochladen kann, ohne jede einzelne Datei separat auswählen und betiteln zu müssen? Das Teil ist huge; es sind in etwa mind. 30 .py Files und dann noch Sprites, Sounds und weitere Ordner (levels) etc., das alles in einem Ordner - "New Super Mario Bros py".

Gibt es eine Möglichkeit, Euch das als Ganzes zu zeigen, damit Ihr mal reinzocken und natürlich den Code anschauen könnt? Kann ich irgendwo irgendwie DEN GANZEN ORDNER "New Super Mario Bros py" hochladen, damit ihr ihn kopieren und reinschauen könnt?

Ich würde mich freuen, wenn Ihr da mal reinschauen würdet und mir sagt, was ich denn anders mache als ihr...

Ums zu zocken, braucht ZWINGEND ein Gamepad, das mit DirectInput funktionert (XInput geht NICHT). Wenn das aber gegeben ist, könnt Ihr zocken!

[Madmartigan]

Du kannst deinen ganzen Ordner in ein ZIP, RAR oder ähnlich verbreitetes Format packen und bei einem Free-Filehoster hochladen.

z.B. http://www.file-upload.net/ (Nein, ich mache keine Werbung für diverse Hoster, ich griff einfach den Ersten, den Google anbot )

Das geht ohne Registrierung und du bekommst einen Download-Link, den du hier posten kannst.

[EyDu]

Oder du packst das Ding auf Dropbox und machst die Datei öffentlich.

Oder aber, du gehst den sauberen Weg und verwendest eine Versionsverwaltung für dein Projekt. Das bietet sich bei so vielen Dateien so oder so an. Eigentlich schon aber einer... Vielleicht schaust du dir dazu mal GitHub an.

[Don Polettone]

OK, schon passiert: New-Super-Mario-Bros-py.7z

Wichtige Hinweise: Am Anfang startet eine "Pseudo-Lade-Szene", diese ladet nicht wirklich Zeugs einfach mit ESC skippen. Dann kommt das Intro (liesse sich auch skippen mit ESC).

Im Hauptbildschirm dann einfach auf "Level Editor" klicken und dann auf "Load Level" -> was anderes funktioniert noch nicht!

Dann könnt Ihr mein Test Level zocken. Wenn Ihr am Ziel des Levels seid, macht das Game nix mehr; ich habe die Level-Ziel-Szene noch nicht fertig gecodet. Mit ALT-F4 könnt Ihr das Game JEDERZEIT killen.

Wie gesagt, es braucht mind. 1 (max. 2) DirectInput Controller, sonst startet das Spiel NICHT. (Logitech u ä. sollte funzen). Man kann auch zu zweit zocken.

Den Level Editor könnt Ihr mit der Leertaste aufrufen/schliessen, mit der mittleren Maustaste wird das TileMenu des Editors ein- / ausgeblendet. Mit der Maus könnt Ihr das Level in Echtzeit, während des Zockens, ändern mit dem Tile Editor. Mit ESC gelangt man wieder ins Load/Save Level Menu und von da aus ins Hauptmenu. Das ist eigentlich alles, was man wissen muss.

Happy Testing und ich freue mich auf Euer Feedback (in Bezug auf den Code UND in Bezug aufs Spiel selbst).

Danke für Eure Zeit

[bwbg]

Bevor Du auch nur im Ansatz an eine Veröffentlichung denkst, ändere den Namen. Sonst hast Du sehr schnell ein Markenrechtsproblem.

Falls Du Pixelgrafiken aus einem entsprechenden Spiel verwendest und keine Einverständnis zur Nutzung besitzt, tausche diese bitte auch sehr schnell aus. Sonst hast Du ein Urheberrechtsproblem.

Entsprechende Abmahnungen, nebst Forderungen beginnend im mittleren bis oberen vierstelligen Bereich hat man sehr schnell (zzgl. Anwaltskosten).