PlanetSwitch Planet3DS PlanetVita PSP.de PlanetiPhone Classics Forum Handheld-Wiki

PGN-ID:[?] (Nicht eingeloggt)
Login
Registrieren
PlanetDS PlanetGameboy N-Page.de
portablegaming.de  

Zurück   portablegaming.de > Allgemeines Spielehandheldforum, GBA, N-Gage und Development > Development Abteilung


Development Abteilung Ihr wollt für euren Lieblingshandheld Spiele oder Tools entwickeln?
Bitte die Präfixe benutzen!

Antwort
 
LinkBack Themen-Optionen Thema durchsuchen
Alt 27.02.2007, 16:27   #1
 
Benutzerbild von Dygera
 
Registriert seit: 07.02.2007
Ort: Hamburg
Alter: 33

Dygera wird schon bald berühmt werden

Dygera eine Nachricht über ICQ schicken Dygera eine Nachricht über MSN schicken
Standard Gameoptimierung

Hi,
ich bin jetzt endlich soweit, dass ich etwas habe, was man als erstes Grundgerüst eines Spiels bezeichnen könnte.

Ich habe einen Char, mit dem man rumlaufen kann (war ja in der letzten Verion auch schon) und einen NPC.
Dieser NPC geht einen bestimmten Weg lang, wenn man ein bestimmtes Feld betritt. Wenn man von der Startposition aus ein Feld nach rechts und eins runtergeht, startet der NPC.
Wenn er angekommen ist oder auch schon vorher kann man die A-Taste drücken, was den Weg, den der NPC macht verändert. Es gibt 3 Wege.
Wenn man den Weg geändert hat, muss man wieder über das Startfeld gehen und der NPC läuft los.

Was mich stört ist, dass sich das Spiel auf einmal so schwerfällig "anfühlt".
Wenn man gehten will, dauert es etwas länger bis es losgeht. Und auch die A-Taste zum Wechseln des NPC-Weges muss man ne Sekunde gedrückt halten, bis der GBA-Emu endlich "merkt", dass man gedrückt hat.

Bevor ich das selbststandige Laufen des NPCs eingebaut hatte (siehe if-Abfrage unter der A-Taste-Abfrage im Hauptprogramm) lief das noch um einiges schneller.

Echte GameBoy-Spiele ind auch etwas flotter. Und ich glaube dieses Mal liegt das nicht an VSync.


www.flyff-world.de/GBA_Dev_Headers2.rar
Dygera ist offline   Mit Zitat antworten
Sponsored Links
Alt 27.02.2007, 16:57   #2
 
Registriert seit: 06.02.2005
Alter: 32

zilluss hat die Renommee-Anzeige deaktiviert

Standard AW: Gameoptimierung

Also du musst bedenken das der Prozessor die Abfrage erst machen kann wenn die Funktion "an der Reihe" ist. Guck mal ob du vielleicht extrem viel Funktionen hast oder unnötige Sprünge und Wiederholungen im code
zilluss ist offline   Mit Zitat antworten
Alt 28.02.2007, 15:08   #3
 
Benutzerbild von Dygera
 
Registriert seit: 07.02.2007
Ort: Hamburg
Alter: 33

Dygera wird schon bald berühmt werden

Dygera eine Nachricht über ICQ schicken Dygera eine Nachricht über MSN schicken
Standard AW: Gameoptimierung

Die einzigen Abfragen, die bei mir im Hauptprogramm stehen sind die Tastenabfragen (ob eine Taste gedrückt wurde).
Dygera ist offline   Mit Zitat antworten
Alt 03.03.2007, 17:14   #4
 
Benutzerbild von Dygera
 
Registriert seit: 07.02.2007
Ort: Hamburg
Alter: 33

Dygera wird schon bald berühmt werden

Dygera eine Nachricht über ICQ schicken Dygera eine Nachricht über MSN schicken
Standard AW: Gameoptimierung

Hi,
hat keiner eine Idee?
Ich hatte schon überlegt, um jedesmal weniger abzufragen, eine zusätzliche Abfrage zu machen, die entscheidet, ob der gedrückte Knopf ein Pfeil oder etwas anderes ist. Ich bin mir jedoch nicht sicher, ob das wirklich was bringen würde, da man ja die ganze Zeit läuft und gleichzeitig A drückt.

Ich habe die ganze Zeit das Gefühl falsch vorzugehen.

Bestimmt gibt es dafür einige Profitricks, die aber anscheinend kaum einer kennt.
Dygera ist offline   Mit Zitat antworten
Alt 03.03.2007, 17:47   #5
Jim männlich
 
Benutzerbild von Jim
 
Registriert seit: 14.08.2005

Jim hat die Renommee-Anzeige deaktiviert

Standard AW: Gameoptimierung

Ohne es jetzt ausprobiert zu haben an deinem Projekt, würde ich jetzt mal folgendes machen.

Sämtliche WaitforVsync() und CopyOAM() aufrufe aus der walk- und walknpc-Funktion raus. Es reicht der Aufruf dieser Funktionen "einmal" pro Bild anzeige bzw durchlauf der main-Schleife.

Und dann wäre die Reihenfolge
1. Wait for Vsync
2. Input
3. CopyOAM
wahrscheinlich die bessere Variante. Die Reihenfolge kannst du aber auch beibehalten, wenn es flimmern sollte.

Edit: Hab mir jetzt deinen Code nochmal angeschaut und verstehe jetzt warum du da wartest. Allerdings solltest du die Funktionen da trotzdem rausnehmen.

Du hast da nämlich auch eine for-Schleife die 16mal warte kann. Was 0,26 sek sind. Und in der Schleife hast du keine Tasteneingabe. Deswegen würde ich immer noch raten, das warten und kopieren nur in der Hauptschleife aufzurufen. Und die Funktionen so umzuschreiben das es trotzdem nicht flimmert. Dann sollte die Tastenabfrage eigentlich ohne Verzögern arbeiten.

Geändert von Jim (03.03.2007 um 18:45 Uhr)
Jim ist offline   Mit Zitat antworten
Alt 04.03.2007, 18:04   #6
 
Benutzerbild von Dygera
 
Registriert seit: 07.02.2007
Ort: Hamburg
Alter: 33

Dygera wird schon bald berühmt werden

Dygera eine Nachricht über ICQ schicken Dygera eine Nachricht über MSN schicken
Standard AW: Gameoptimierung

Die Forschleife ist nur, damit der Char beim gehen langsam weiterschwebt und nicht so plötzlich weiter nach vorne "gebeamt" wurde.(das hatte ich vorher/das ging zack-zack-weiter;nicht gut).
Wenn ich das WaitforVSync ganz rausnehme, geht der Char wesentlich schneller, aber das sieht flackerig aus.
Schon sehr komisch; wenn man sich mal Pokemon Smaragd anguckt: der geht schneller, als bei mir aber es flackert überhaupt nicht. Wie haben die das bloß hingekriegt?
Dygera ist offline   Mit Zitat antworten
Alt 05.03.2007, 06:51   #7
 
Registriert seit: 06.02.2005
Alter: 32

zilluss hat die Renommee-Anzeige deaktiviert

Standard AW: Gameoptimierung

Das VSync gehört in den Code aber nicht in deine walk Funktionen. Den Char kriegst du langsamer wenn du mit dem Vsync einen Zähler mitlaufen lässt (der sich selbst resetet) und der Char dann nur geht wenn der Zähler eine bestimmte Zahl hat. Weil Timer für soetwas einfaches zu aufwändig wären.
zilluss ist offline   Mit Zitat antworten
Alt 05.03.2007, 12:39   #8
 
Benutzerbild von Dygera
 
Registriert seit: 07.02.2007
Ort: Hamburg
Alter: 33

Dygera wird schon bald berühmt werden

Dygera eine Nachricht über ICQ schicken Dygera eine Nachricht über MSN schicken
Standard AW: Gameoptimierung

Ich habe das mit dem VSync so verstanden, dass es nach einem Ändern der Werte (Positionen von z.B. Sprites) das Geschehen so lange anhält, bis der Bildschirm fertig geschrieben wurde. Dann wird das neue alles in das OAM-Array kopiert, was bewirkt, dass beim nächsten Bildaufbau angezeigt wird.
Wenn ich es jetzt theoretisch nicht in der Geh-Schleife der Figur hätte, würde das OAM-Array doch verändert werden, während es von der CPU ausgelesen und auf den Bildschirm gebracht wird.
Dadurch kommt dann auch (meiner nicht-Experten-Meinung nach) ein Flackern zu stande.
Daher ist es, meiner Logik nach, nötig mit dem Kopieren in das OAM-Array nach jeder Positionsänderung zu warten, bis der Bilschirm zu ende "dargestellt" wurde.
Darum ist es in der Walk_Funktion. Weil ein Schritt aus 16 Verschiebungen des Sprites um jew. 1 Px besteht.

Habe ich da etwas falsch verstanden? Wie gesagt; bin noch Anfänger:-)
Dygera ist offline   Mit Zitat antworten
Alt 05.03.2007, 18:15   #9
 
Registriert seit: 06.02.2005
Alter: 32

zilluss hat die Renommee-Anzeige deaktiviert

Standard AW: Gameoptimierung

Ja der Vsync wartet automatisch und du bruachst in auch nur einmal. Und nachdem sich die Position des Sprites geändert hat solltest du das ganze auch mithilfe von Copy Oam machen also ich mein das so:

Walknpc (Position des Sprites wird geändert)
CopyOam(Sprite Position wird kopiert)
WaitforVsync(Warten bis der Bildschirm fertig geschrieben ist)
zilluss ist offline   Mit Zitat antworten
Alt 06.03.2007, 15:06   #10
 
Benutzerbild von Dygera
 
Registriert seit: 07.02.2007
Ort: Hamburg
Alter: 33

Dygera wird schon bald berühmt werden

Dygera eine Nachricht über ICQ schicken Dygera eine Nachricht über MSN schicken
Standard AW: Gameoptimierung

Hallo,
innerhalb meiner walk-schleife sieht das so aus:

npcaction(npcperson, action);//verändert die Pos. vom npc
Refresh_Position(person); //lädt die eigene Pos. ins Sprite-Array
person->posy++; //verändert die eigene Pos.
WaitforVsync();
CopyOAM();


(Ich glaube die refresh_position und das person->posy sollte ich mal tauschen. sieht irgentwie sinnlos aus). Jedenfalls ist diese reihenfolge so, wie du meintest.
Die walknpc_funktion ist bei mir nur dazu da, um den char zu bewegen, wenn sich der spieler mal nicht bewegt. Sie geht also nur dann an, wenn man keine pfeiltaste drückt.
Dygera ist offline   Mit Zitat antworten
Alt 06.03.2007, 15:29   #11
Moderator
 
Benutzerbild von O-bake
 
Registriert seit: 30.09.2002
Alter: 42

O-bake genießt hohes Ansehen
O-bake genießt hohes AnsehenO-bake genießt hohes AnsehenO-bake genießt hohes AnsehenO-bake genießt hohes AnsehenO-bake genießt hohes AnsehenO-bake genießt hohes AnsehenO-bake genießt hohes AnsehenO-bake genießt hohes AnsehenO-bake genießt hohes AnsehenO-bake genießt hohes AnsehenO-bake genießt hohes AnsehenO-bake genießt hohes Ansehen

Standard AW: Gameoptimierung

Da ich jetzt speziell in der GBA-Programmierung nicht drinstecke, weiß ich nicht genau, was CopyOAM() macht, aber ich denke, dass es den virtuellen Screen auf den GBA-Screen schreibt, richtig?

Dann brauchst du das nur und wirklich nur in deiner Hauptschleife! Das bremst sonst alles aus (Genau wie WaitForVsync())

Ich baue meine Programme aus übersichtlichkeit immer so auf (sehr verkürzt und verallgemeinert):

- Generelle Funktionen (welche, die man ständig braucht, Sachen laden, Sachen speichern, PutSprite, GetKeys etc...)

- Eigene Funktionen (Spielersteuerung, Gegnerbewegung, AI, Berechnung der Animationen, etc)

- PutAllSprites (da packe ich der Übersichtlichkeit alles rein, was ein Putsprite() oder etwas vergleichbares enthält, um die Reihenfolge überblicken zu können oder auch mal was auszukommentieren)

- Hauptschleife
{
(Eigentlich gibts noch sowas wie ClearVScreen(), oder ähnliches)
Eigene Funktionen
PutAllSprites();
CopyOAM();
VaitForVsync();
}


So. Das CopyOAM() und Vsync() kommt einzig und ausschliesslich da vor. Es sei denn, es gibt noch Unter-Hauptschleifen, wie einem Titelscreen, Pausescreen, usw.

Ich weiss jetzt natürlich nicht, wie genau deine Putsprite()-Funktionen aussehen, aber generell wird es so gemacht, dass es einen "virtuellen Screen" gibt, einen Speicherbereich, in den alle PutSprite()-Funktionen ihre Grafiken schreiben und mit CopyOAM() wird dieser virtuelle Screen dann auf den echten GBA-Screen kopiert und dann auf die vertikale Synchronisation gewartet, bis es weiter gehen kann.

(Falls das CopyOAM() hier was anderes ist, korrigiert mich bitte)
O-bake ist offline   Mit Zitat antworten
Alt 06.03.2007, 17:08   #12
 
Benutzerbild von Dygera
 
Registriert seit: 07.02.2007
Ort: Hamburg
Alter: 33

Dygera wird schon bald berühmt werden

Dygera eine Nachricht über ICQ schicken Dygera eine Nachricht über MSN schicken
Standard AW: Gameoptimierung

Hi,
nein du hast das genau richtig verstanden. CopyOAM bringt den virtuellen auf den echten Screen.
Ich weiß jetzt nicht, wofür deine Programme sind, aber ich erkläre mal, warum ich das so gemacht habe.

Bei meinem Programm gehen die Figuren immer Schrittweise. Für den Spieler heißt das, dass ein Tastendruck eine Schleife startet, die die Figur nicht einen sondern hier 16 Pixel (Schrittlänge) nach vorne bringt. Außerdem wird noch das Bild des Chars gegen eins mit ihm, wo er einen Schritt macht, getauscht.

Wenn man die Schleife durchlaufen lässt (in der Funktion) und das CopyOAM nur einmal danach macht (z.B. im Hauptprogramm), dann ist das, was man als nächstes sieht, wie die Figurn den Schritt gemacht hat. Die Figur springt also nur von der Schritt-Startposition zur Schritt-Endposition.

Eigentlich soll sie aber langsam dahinschweben. Deshalb muss man, nach meiner Logik, die aktuelle Position der Figur nach jeder ein-Pixel-weiter-Bewegung neu anzeigen.

Bei WaitforVSync stelle ich mir das genauso vor.
Dygera ist offline   Mit Zitat antworten
Alt 06.03.2007, 19:07   #13
Moderator
 
Benutzerbild von O-bake
 
Registriert seit: 30.09.2002
Alter: 42

O-bake genießt hohes Ansehen
O-bake genießt hohes AnsehenO-bake genießt hohes AnsehenO-bake genießt hohes AnsehenO-bake genießt hohes AnsehenO-bake genießt hohes AnsehenO-bake genießt hohes AnsehenO-bake genießt hohes AnsehenO-bake genießt hohes AnsehenO-bake genießt hohes AnsehenO-bake genießt hohes AnsehenO-bake genießt hohes AnsehenO-bake genießt hohes Ansehen

Standard AW: Gameoptimierung

Ja, nach deiner Logik ist das dann auch tatsächlich richtig, aber sie enthält einen generellen Denkfehler:
Während deine Schritt-Animation durchläuft, steht der Rest still. Stell dir mal vor, du hast noch weitere Sprites da, die sich bewegen sollen und generell laufen ja immer Berechnungen und Bewegungen. Aber während deines Schrittes passiert ausser dem Schritt nichts.

Deswegen musst du, wenn z.B. nach rechts gedrückt wird folgendes machen (ich schreibe das jetzt mal in Worten, da ich lange nichts mehr in C gemacht hab und nicht durch falsche Syntax verwirren will):

Bsp:
Ein Schritt nach seien also 16 Pixel.
Der Player steht auf einer Rasterkarte aus 16x16 Pixel grossen Feldern.
Player hat die Eigenschaften
PosX, PosY -> Das ist der Standpunkt auf der Rasterkarte
StepX, StepY -> Das ist der Fortschritt eines Schrittes

StepX und StepY sind im Ruhezustand immer = 0

wenn ein Schritt gestartet ist, sind andere Richtungsangaben wirkungslos

Code:
function BewegePlayer()
{
 Tastenabfrage, wie immer die Funktion auch heissen mag

 wenn (Player.StepX==0 und Player.StepY==0) dann
  { 
  wenn RECHTS gedrückt wird, dann Player.StepX++
  (wenn LINKS, dann Player.StepX-- usw.)
  }

 wenn (Player.StepX größer 0) dann Player.StepX++
 wenn (Player.StepY kleiner 0) dann Player.StepX--
 (usw..)

 wenn (Player.StepX == 16)
 {
  Player.StepX=0
  Player.XPos++
 }
 (usw...)
}

function PutPlayer()
{
 PutSprite(PlayerSprite,Player.XPos*16+Player.StepX,Player.YPos*16+Player.StepY)
-> angenommen, du hast sowas wie PutSprite(x,y,Grafik)
}

hauptschleife
{
 vscreen löschen
 BewegePlayer();
 PutPlayer();
 CopyOAM();
 VaitForVsync();
}
so, denn jetzt könnten auch noch Gegnerbewegungen mit in die Hauptschleife gepackz werden, die durch einen Schritt nicht mehr behindert werden.

Ich hoffe, dass das alles nachvollziehbar ist.
Ich glaube, du benutzt bisher noch keine Rasterkarte, aber da wirst du nicht drum herum kommen.
Bei Pokemon ist es doch auch so, dass der Player immer an der gleichen Stelle steht und die Karte sich unter ihm bewegt, oder? Dann musst du die Koordinaten einfach auf die Karte beziehen und nicht auf den Player.

edit: Ich habe absichtlich einen kleinen Fehler eingebaut. Nämlich ist der erste Teilschritt so immer 2 Pixel gross, da ja einmal StepX erhöht wird, um kenntlich zuz machen, dass ein Schritt eingeleitet ist und dann nochmal, um den Schritt weiter zu führen.
Daher muss die Abfrage "wenn Step größer 0, dann" zuerst in die Funktion. Aber das wäre beim ersten Lesen verwirrend gewesen.

Geändert von O-bake (06.03.2007 um 19:11 Uhr)
O-bake ist offline   Mit Zitat antworten
Alt 07.03.2007, 12:49   #14
 
Benutzerbild von Dygera
 
Registriert seit: 07.02.2007
Ort: Hamburg
Alter: 33

Dygera wird schon bald berühmt werden

Dygera eine Nachricht über ICQ schicken Dygera eine Nachricht über MSN schicken
Standard AW: Gameoptimierung

Ja stimmt, das Problem, dass alles andere Stillstand hatte ich vorher. Das hatte ich, zugegeben auf unschöne Art, so gelöst, dass ich die Bewegung des einzigen anderen Sprites, dass ich hatte, mit in die Schritt-Schleife des Player-Chars gepackt hatte. Dann gibt es noch eine Schleife, die durchgeführt wird, wenn keine Taste gedrückt wird. Diese sorgt dann dafür, dass sich der NPC bewegt, wenn man selber nicht geht.
Ehrlich gesagt kam mir diese Möglichkeit von Anfang an falsch vor, alleine schon weil es mir so schwierig schien in diesen Ablauf beliebig viele anderen NPCs, je nach Situation, automatisch zu integrieren.

Deine Lösung gefällt mir wesentlich besser. Aber müsste die Player.PosX oder .Posy nicht auch jedesmal gleichzeitig mit der Player.StepX oder .StepY erhöht werden?
So wie das im Moment aussieht, geht die Figur nur einen Pixel pro Step.
Ich meine die Player.PosX wird nur um einen Pixel erhöht, wenn die Player.StepX schon um 16 erhöht wurde und der Schritt nun vorbei ist (wo die Player.StepX wieder auf 0 gesetzt wird).

Ich denke es müsste eher so heißen:
wenn (Player.StepX größer 0) dann Player.StepX++, Player.PosX++;


wenn (Player.StepX == 16)
{
Player.StepX=0
}
(usw...)Oder hab ich das jetzt falsch verstanden?
Dygera ist offline   Mit Zitat antworten
Alt 07.03.2007, 13:21   #15
Moderator
 
Benutzerbild von O-bake
 
Registriert seit: 30.09.2002
Alter: 42

O-bake genießt hohes Ansehen
O-bake genießt hohes AnsehenO-bake genießt hohes AnsehenO-bake genießt hohes AnsehenO-bake genießt hohes AnsehenO-bake genießt hohes AnsehenO-bake genießt hohes AnsehenO-bake genießt hohes AnsehenO-bake genießt hohes AnsehenO-bake genießt hohes AnsehenO-bake genießt hohes AnsehenO-bake genießt hohes AnsehenO-bake genießt hohes Ansehen

Standard AW: Gameoptimierung

Nein, das StepX macht ja den Schrittvorgang. Wenn man es einfach weglassen würde, würde der Player unflüssig von einer Position auf die nächste "springen".

Beispiel (nur X-Richtung):

Der Player steht auf .XPos=2, .StepX=0
-> Da in PutSprite für player steht: .XPos*16+.StepX, steht er real auf dem Bildschirm auf x-Position 31, klar?

Dann wird ein Schritt eingeleitet. Das .XPos bleibt gleich und nur der .StepX wird erhöht. Also geht es 31+1, 31+2, 31+3,... bis 31+15
Und 31+16 wäre das gleiche, als würde man .XPos um 1 erhöhen, da ein XPos ja immer mit 16 multipliziert wird. StepX wird dann wieder auf null gesetzt, da der Schritt beendet ist.
.XPos=3, .StepX=0
-> in PutSprite stünde dann wieder .XPos*16+.StepX und das ist dann genau 16 Pixel mehr als vor dem Schritt.

Pass daher auf, da wie gesagt ein XPos immer 16 Pixel entspricht. Ich finde das so ganz sinnvoll, da man ja nur ganze Schritte gehen kann und es keine Möglichkeit gibt einen Schritt zu machen, der kleiner als 16 Pixel ist.
Und sobald du auf einer Karte gehst, wirst du den Vorteil nochmehr sehen, denn dann kannst du einfach fragen, wenn du nach rechts gehen willst:

ist die Textur auf der Karte auf Position (XPos+1,YPos) ein Berg? Wenn nein dann .StepX++, ansonsten nichts, weil man durch einen Berg nicht durchgehen kann.
Somit ist (XPos,YPos) immer der Punkt auf der Karte, auf dem du stehst. Und somit kannst du einfach nach rechts (XPos+1,YPos) oder nach unten (XPos,YPos+1), usw. abfragen, was auf der Textur ist, auf die du als nächstes gehen willst.

edit: Und wie du musst aufpassen, dass du alles so allgemein wie möglich verfasst, denn ansonsten kommst du irgendwann an eine Grenze, ab der du alles ändern musst (ist dir ja bei deiner Schritt-Sequenz passiert). Noch ist das zwar alles überschaubar, aber du kannst ja wohl abschätzen, dass in einem fertigen RPG weitaus noch Sachen passieren, als du bis jetzt gemacht hast. Naja, ehrlich gesagt sind es gar nicht so viele. Aber das wirst du durch probieren schon noch rausfinden.

Geändert von O-bake (07.03.2007 um 13:27 Uhr)
O-bake ist offline   Mit Zitat antworten
Alt 07.03.2007, 16:46   #16
 
Benutzerbild von Dygera
 
Registriert seit: 07.02.2007
Ort: Hamburg
Alter: 33

Dygera wird schon bald berühmt werden

Dygera eine Nachricht über ICQ schicken Dygera eine Nachricht über MSN schicken
Standard AW: Gameoptimierung

Die Lösung ist wirklich genial.
Da wär ich bestimmt nie alleine drauf gekommen. Habs mal so eingebaut. Ich musste dafür sogut wie alles umschreiben, aber es funktioniert wirklich besser und vor allem schneller.
Das eigenständige Laufen des NPCs hab ich jetzt noch nicht eingebaut, wird aber auch kein großes Problem. Aber man hat auf jeden Fall das Gefühl, dass die Figur irgentwie schneller reagiert. Ich glaube die von Game Freak haben das bei Pokemon genauso gemacht, da kann die Figur nämlich auch nicht schneller reagieren oder laufen.
Ich werd jetzt den Rest an das neue Grundgerüst anpassen und dann kommen die Tiles. Vielen Dank für die Hilfe.
Dygera ist offline   Mit Zitat antworten
Alt 07.03.2007, 17:08   #17
Moderator
 
Benutzerbild von O-bake
 
Registriert seit: 30.09.2002
Alter: 42

O-bake genießt hohes Ansehen
O-bake genießt hohes AnsehenO-bake genießt hohes AnsehenO-bake genießt hohes AnsehenO-bake genießt hohes AnsehenO-bake genießt hohes AnsehenO-bake genießt hohes AnsehenO-bake genießt hohes AnsehenO-bake genießt hohes AnsehenO-bake genießt hohes AnsehenO-bake genießt hohes AnsehenO-bake genießt hohes AnsehenO-bake genießt hohes Ansehen

Standard AW: Gameoptimierung

Gerne doch.

Ich kriege gerade ein bisschen Lust, meine alten Sachen mal wieder rauszukramen. Vielleicht mach ich das mal, dann kann ich dir noch konkretere Beispiele zeigen.

Wo du aber früher oder später nicht drumherum kommen wirst, ist dir unter Windows (oder welches System auch immer du benutzt), einen Editor zu machen.
Alle Spiele, vom Jump n'Run bis zum RPG, werden gemacht, indem eine Engine erstellt wird (das ist das, was wir hier bisher gemacht haben) und dann wird ein Editor geschrieben, mit dem man das Spiel zusammenbasteln kann.
Du kannst dann in deinem Lieblingsmalprogramm die Texturen, Charktäre und sonstige Sprites malen, in den Editor laden, zu deinen Textur-Paletten hinzufügen und damit Karten ausfüllen.
Eine Karte kann hier natürlich alles sein. Von der Weltkarte bis zum inneren eines Hauses. Alles unterliegt der gleichen Engine.
In so einem Editor kannst du dann Charaktäre markieren und einfach eintippen, was sie sagen sollen, wenn du sie ansprichst, du kannst Items plazieren, und so weiter und so fort.
O-bake ist offline   Mit Zitat antworten
Alt 07.03.2007, 17:54   #18
 
Benutzerbild von Dygera
 
Registriert seit: 07.02.2007
Ort: Hamburg
Alter: 33

Dygera wird schon bald berühmt werden

Dygera eine Nachricht über ICQ schicken Dygera eine Nachricht über MSN schicken
Standard AW: Gameoptimierung

Klingt ja sehr gut.
Ich hätte nicht gedacht, dass man sowas wirklich selber machen kann.

Ich hätte das jetzt alle manuell gemacht. Gerade das mit den Texten muss ja kompliziert sein. Immerhin ist ja jeder Buchstabe ein Bild, das man dann auch an die richtige Stelle schieben muss. Aber damit habe ich mich noch gar nicht richtig beschäftigt.
Ich habe bis jetzt nur versucht ein möglichst ressourcensparendes Grundgerüst zu bauen, in dem man rumlaufen kann und einen NPC zu bestimmten Punkten laufen lassen kann. Das klappt auch schon ziemlich gut.

Als nächstes kommt dann der Background, aber so ein Editor hört sich ja toll an.
Dygera ist offline   Mit Zitat antworten
Alt 09.03.2007, 12:29   #19
 
Benutzerbild von Dygera
 
Registriert seit: 07.02.2007
Ort: Hamburg
Alter: 33

Dygera wird schon bald berühmt werden

Dygera eine Nachricht über ICQ schicken Dygera eine Nachricht über MSN schicken
Standard AW: Gameoptimierung

Hallo,
kennst du ein Tutorial für einen solchen Editor oder weißt du selber wie man sowas programmiert?
Dygera ist offline   Mit Zitat antworten
Alt 09.03.2007, 13:18   #20
Moderator
 
Benutzerbild von O-bake
 
Registriert seit: 30.09.2002
Alter: 42

O-bake genießt hohes Ansehen
O-bake genießt hohes AnsehenO-bake genießt hohes AnsehenO-bake genießt hohes AnsehenO-bake genießt hohes AnsehenO-bake genießt hohes AnsehenO-bake genießt hohes AnsehenO-bake genießt hohes AnsehenO-bake genießt hohes AnsehenO-bake genießt hohes AnsehenO-bake genießt hohes AnsehenO-bake genießt hohes AnsehenO-bake genießt hohes Ansehen

Standard AW: Gameoptimierung

Na klar kann ich das machen. Ich hab die letzten beiden Tage schon meine alten Sachen rausgekramt und arbeite mich da gerade wieder ein.
Um für Windows Programme zu erstellen, habe ich immer Borland Delphi (6 Personal Edition, gabs vor Urzeiten mal kostenlos) genutzt, da kann man Programme im Baukastenprinzip erstellen.

Ich habe sowieso noch viele Funktionen, die ich dir geben kann, darunter auch sowas wie PutTextXY(string), das Text mit einer selbstgezeichneten Schriftart ausgibt und viele andere kleine nützliche Sachen.

Du programmierst nur für den GBA, richtig?
Sag doch einfach mal, welches Devkit genau du benutzt (woher es kommt und wie man es einrichtet), dann kann ich vielleicht auch mal ein paar konkrete Beispiele liefern.
Ich würde ansonsten nämlich auch gerne was für die PSP machen, weil man damit irgendwie doch mehr Leute erreichen kann.
O-bake ist offline   Mit Zitat antworten
Antwort

  portablegaming.de > Allgemeines Spielehandheldforum, GBA, N-Gage und Development > Development Abteilung

Lesezeichen


Aktive Benutzer in diesem Thema: 1 (Registrierte Benutzer: 0, Gäste: 1)
 
Themen-Optionen Thema durchsuchen
Thema durchsuchen:

Erweiterte Suche

Forumregeln
Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are an



Alle Zeitangaben in WEZ +2. Es ist jetzt 07:11 Uhr.


Powered by vBulletin® Version 3.8.9 (Deutsch)
Copyright ©2000 - 2021, Jelsoft Enterprises Ltd.
SEO by vBSEO 3.6.0
Template-Modifikationen durch TMS
PortableGaming.de © bk 2000 - 2010

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231