Aufbau eines Jump'n Run's (like Turrikan)

FinalbrainXP

- GESCHLOSSEN - Bevor hier zu viel Schei**e erzählt wird!!

Sgt. Nukem

+++ SSSCHHHHWOAAAAARZZZEEEEENNNNNNEGGGGGGAAAAAA +++

FinalbrainXP

- GESCHLOSSEN - Bevor hier zu viel Schei**e erzählt wird!!

Sgt. Nukem

Yup.

EDIT: BTW: Manfred hat sich für das Cover von Turrican von ManOwaR's Kings Of Metal-Album inspirieren lassen (kam 2 Jahre vorher raus), womit jawohl eindeutig bewiesen wäre auch ManOwaR herrschen wahrhaftig!

otze

Engine.containerPool->GimmeContainer(0)->PumpSpriteInContainerFromCellFile(0,"Sprite3.bmp",true,265,400,0,0,32,32,COLOR_MAGENTA,true);

also des hät i anders gemacht
müssen das am ende echt 11 parameter sein? und wieso steht da gimme und nicht giveMe? containerpools sieht mir auch ziemlich public aus.

Engine.GiveMeContainer(0).createSprite(0,"Sprite3.bmp",true,265,400,0,0,32,32,COLOR_MAGENTA,true);

oder gleich:

Engine.createSprite(0,0,"Sprite3.bmp",true,265,400,0,0,32,32,COLOR_MAGENTA,true);

aber an den parametern solltest echt was ändern^^.

FinalbrainXP

- GESCHLOSSEN - Bevor hier zu viel Schei**e erzählt wird!!

life

löl. Das nennt man wohl "übermotiviert"

TGGC

FinalbrainXP schrieb:

1.) Gimme ist cooler! Und ist ja meine Engine mein Style!

*ROFL*

Und zu viele Enter sind auch dein Stil?

Bye, TGGC \-/

FinalbrainXP

- GESCHLOSSEN - Bevor hier zu viel Schei**e erzählt wird!!

otze

FinalbrainXP schrieb:

Warum denn "Otze" ???

weil der name ne geschichte hat, und ich seitdem überall so heisse?

//edit jemals vom kapselung oder open-closed-principle gehört?
diese regelungen haben schon einen sinn^^

//edit2

2.) Da sind 3 Objekte Public! ContainerPool, Container, Sprite!
Das sind alles 3 eingenständige Klassen...welche man auch ausserhalb
der Engine benutzen kann!! Wenn ich jetzt nen animerbares Objekt mache,
muss ich dem nur den Pool-Pointer übergeben..

schön für die public objecte, aber wärs wirklich so schwer nen schönen geter/seter zu schreiben? wenn ich das objekt direkt habe, kann ich damit mit leichtigkeit schindluder betreiben(selbst wenns nicht absicht ist).
ne const referenz auf das objekt zurückzugeben ist sicherer, genau dasselbe gilt für const pointer, wenn du weist, dass du das objekt ändern willst, dann benutzt du den seter, sonst den geter,und schon kannst du sicher sein, dass kein schindluder damit betrieben wird.

3.) Das mit den Parametern ist doch toll! Verstehe nicht warum es schlecht ist.
Bei direktX gibt es auch mäßig Parameter! Und dieses ist ja die größte
Funktion! Ob ich jetzt 11 untereinander oder hintereinander mache..ist doch
egal! Jedes Sprite braucht halt diese 11 Unterschiedlichen Parameter!
Es kommen deshalb soviele Parameter zustande, weil diese Funktion
Teilausschnitte aus Bitmaps lesen kann und direkt nen Sprite daraus kloppen
kann!

bitte zähl mir mal direkt ausm kopp alle parameter der dx funktion
D3DXCreateTextureFromFileInMemoryEx
auf, sie hat nur 15 parameter,und dann schau dir deine aussage nochmal an.
viele parameter sind nicht gut, ziel soll sein, funktionen mit maximal 6-7 parametern zu schreiben.
zb bei deiner funktion:

PumpSpriteInContainerFromCellFile(int pos,char * path, bool videoMemory, int 
bmpWidth, int bmpHeight, int startX, int startY, int partWidth, int 
partHeight, unsigned int colorKey, bool transparent)

ich würds so machen

createSprite(vector2 topLeft,vector2 downRight,const bitmap& bitmap,int spriteIdentifier,bool videoMemory=true);

den rest der infos kann man direkt aus dem bitmap nehmen, zb colorkeying oder die größe/breite des bitmaps,oder ob es transparent sein soll.
ich hab hier mit der bitmapklasse einfach eine zusätzliche abstraktionsebene eingebaut, und die positionen in vectoren zusammengefasst.

interpreter

FinalbrainXP schrieb:

Neee das ist ne bombensichere Sache..da würde ICH garnix dran ändern!!

Warum zeigst du es uns dann überhaupt?

1.) Gimme ist cooler! Und ist ja meine Engine mein Style!

lol

Ist ja nicht ne kommerzielle Engine mit Standard Konventionen!

Ah, und drum sollte man keine Konventionen beachten?

2.) Da sind 3 Objekte Public! ContainerPool, Container, Sprite!
Das sind alles 3 eingenständige Klassen...welche man auch ausserhalb
der Engine benutzen kann!! Wenn ich jetzt nen animerbares Objekt mache,
muss ich dem nur den Pool-Pointer übergeben..und es kann sich dann komplett
anhand verschiedener Sequenz-Container selbstanimieren! Da sich die
Container selber den Speicher bereinigen, muss ich beim animierbarem Objekt
nichts mehr beachten..bzw initialisieren! Bei deiner Version
funktioniert dies dann weniger Objekt orientiert, oder ich müsste die
Zuweisung an die Container private mit in den Engine-Code Packen, welches
ich nicht tue, da die Klassen getrennt von einander entwickelt wurden, und
so besser gewartet werden können! Glaube mir das ist echt gut durchdacht!

AnimierbaresObjekt->Pool = Engine.ContainerPool

AnimierbaresObjekt->SetSequences(0,0,0) //Animation links gehenm
AnimierbaresObjekt->SetSequences(1,0,1) //Animation rechts gehen

if Keyboard.links
AnimierbaresObjekt->AnimateMe(0);

if Keyboard.rechts
AnimierbaresObjekt->AnimateMe(1)

AnimierbaresObjekt->DrawMe();

Hm, bis jetzt kein einziger Satz ohne Ausrufezeichen...

3.) Das mit den Parametern ist doch toll! Verstehe nicht warum es schlecht ist.

Kein Kommentar

Bei direktX gibt es auch mäßig Parameter!

massig

Und dieses ist ja die größte
Funktion! Ob ich jetzt 11 untereinander oder hintereinander mache..ist doch
egal! Jedes Sprite braucht halt diese 11 Unterschiedlichen Parameter!

Falsch. Selbst wenn du alle Werte benötigst, könntest du 1. mit Defaultparametern arbeiten und 2. Strukturen benutzen.

Sgt. Nukem

Vielleicht solltest Du dieses "Sprite wird noch aus einem großen Bitmap ausgeschnitten" abkapseln von der Sprite-Lade-Routine.
Sprites die man nicht zerschneiden muß bekommen dann immer 0 als Parameter, das ist doch doof.
Lieber für Sprite-Tables noch eine kleine Sprite-Extractor-Funktion davorhängen.

Zum anderen könntest Du Funktionen überladen. Falls es mir z.B. schnurzegal ist wo im Speicher das Ding lagert reicht ein LoadSprite(char* filename), daß meinetwegen die Position im Container zurückgibt (Größe kann die Funktion selber aus der Datei rausfinden).

FinalbrainXP

- GESCHLOSSEN - Bevor hier zu viel Schei**e erzählt wird!!

ChockoCookie

FinalbrainXP schrieb:

3.) Das mit Separierung von Jum'n Run und Shoot'n Run ist Schwachsinn!
Das kommt, wenn man sich nicht selber Gedanken über die Wort selber macht
und jedes Wort übernimmt, was irgend jemand mal in die Luft geworfen hat.
Jump'n run heißt Laufen und Springen!! Also ist es demnach ein Jump'n Run
und ein Shoot'em Run! Aber warum so kleinlich ? Bei Supermario sagt auch
keiner Shoot'em Run/Jump, obwohl man da durchaus schießen kann!

Oh mann dieser Thread muss in die lolotw. FinalbrainXP 4 President

tasti

ChockoCookie schrieb:

FinalbrainXP schrieb:

3.) Das mit Separierung von Jum'n Run und Shoot'n Run ist Schwachsinn!
Das kommt, wenn man sich nicht selber Gedanken über die Wort selber macht
und jedes Wort übernimmt, was irgend jemand mal in die Luft geworfen hat.
Jump'n run heißt Laufen und Springen!! Also ist es demnach ein Jump'n Run
und ein Shoot'em Run! Aber warum so kleinlich ? Bei Supermario sagt auch
keiner Shoot'em Run/Jump, obwohl man da durchaus schießen kann!

Oh mann dieser Thread muss in die lolotw. FinalbrainXP 4 President

Ganz ehrlich, dass hab ich mir auch gerade gedacht
Immer wieder schön zu sehen, wie gut man sich selbst finden kann.

TGGC

Gut, das ich den Originalthread gerettet habe. Got finally brain?

Bye, TGGC (Reden wie die Großen)

FinalbrainXP

GESCHLOSSEN - Bevor hier zu viel Schei**e erzählt wird!!

interpreter

TGGC schrieb:

Gut, das ich den Originalthread gerettet habe. Got finally brain?

Sgt. Nukem

Arm...

ChockoCookie

Yeah Shoot'em Runs RULEN.