Seite 3 von 3 ErsteErste 123
Ergebnis 41 bis 57 von 57

Thema: 5 Stunden zum Variablen löschen

  1. #41
    @Mr.Hunz: Rrrrrrrichtig!

    Zitat Zitat von Ryo Saeba 1000
    Terrain ID abforken, wenn ein neues Feld (Tile) betreten werden soll.
    Die Tiles gibts bei der Move-Technik nicht mehr...
    Aber im Grunde bist du schon auf der richtigen Spur. Denn genau die Technik hab ich angewenden. Dass ich mir Arbeit aufhalse hab ich schon erfahren, denn wenn man sich mal "Battle Versus" hier im Atelier unter "Sonstiges" anguckt, sieht man, dass ich das ganze schon mal hingegriegt hab - nur eben auf einem sehr niedrigen Niveau. Wenn ihr euch das Spiel antut, bitte nicht mit meinem jetzigen Spiel vergleichen - außer dem Kollisionssystem, dass ich beim momentaten Projekt aber auch als Terrain ID laufen lasse.

    Zum Kollissions-Problem: Bei einer "One-Picture-Bahn" hätte man den Vorteil sich nicht auf ein Chipset beschränken zu müssen, sondern könnte frei malen. Soweit ich weiß, kann man ein Picture aber nur bis zu einer gewissen Größe importieren. Zudem entspricht die Bahnposition nicht mehr dem Chipset. Man müsste Die Rennstrecke also drotzdem - wie ein Editor sozusagen - für den Spieler unsichtbar als Chipset erstellen.


    Fragen:
    - Gibt es eine Größenbeschränkung von Pictures?
    - Neue Ideen zum Thema Kollision und Picture?
    - Was ist mit dem Variablen-Runtersetzprogramm?

  2. #42
    Zitat Zitat
    Die Tiles gibts bei der Move-Technik nicht mehr...
    Wieso das? Klar kann man die noch nehmen..
    Du kannst sehr wohl Tiles nutzen^^ ich glaube du begehst den Fehler und nimmst an, nur weil sich das Pic des Spielerchars "eigentlich" nur auf demselben Bildschirmausschnitt bewegt, während die anderen Objekte sich um ihn herum bewegen, dass seine Koordinaten dann nicht mehr für die Tileabfragen zu gebrauchen sind..
    Aber das ist falsch, du kannst ganz einfach zwei Koordinatenpaare "erstellen". Einmal die Koordinaten im Bildschirmausschnitt und einmal die Koordinaten in Relation zur Gesamtmap, so kannst du die Map normal mappen, mit dem Chipset und musst es dann einfach nur "screenshoten" um ein Map-Picture rauszukriegen.

    Gleiches gilt für Events... die kannst du ganz normal auf jeder Position deiner Map platzieren.. und obwohl das Bild des Spielerchars diesen Events "eigentlich" nicht mal nahe kommt, wenn sie nicht auf dem anfänglichen Bildschirmausschnitt des Spielerchars sind, funktioniert die Kollision mit denen problemlos.

    Glaub mir, ich habe mir das auch durchdacht.. ich habe selber schon merehre funktionierende Scripte zum Thema Pixelmovement geschrieben.
    Die Abfrage der Tiles über die Koordinaten des Pictures, mit dessen relativen Koordinaten auf der Map, ist imho die beste Lösung dafür.

    Zitat Zitat
    - Gibt es eine Größenbeschränkung von Pictures?
    Ja, die gibt es. 640*480 Pixel dürften das gewesen sein. Aber bevor du jetzt das Handtuch wirfst, es gibt eine Methode diese Grenze zu übergehen. Damit lassen sich dann locker Pics in der Größe von 800*600 oder 1280*1024 importieren. Wie das genau funktioniert, steht in einer Makersmind Ausgabe, du wirst aber sicher auch schnell im Forum fündig, denn das Thema kam schon oft auf. Im Prinzip musste man nachdem man ein klneineres Pic importierte, dieses dann durch das größere ersetzen, aber schlag das lieber nocheinmal nach, ich weiß es nicht mehr genau. Bin mir auch nicht sicher, wie weit man das treiben kann -> ob 1280*1024 das Maximum ist. Außerdem kann man, wenn einem das noch nicht reicht, zur Not auch mehrere Pics verwenden und den Kurs sousagen in mehrere Pictures einteilen.

    Zitat Zitat
    - Neue Ideen zum Thema Kollision und Picture?
    Wenn du auf die Tilekollision verzichten willst, kannst du sicher noch Kollisionsmasken für den Kurs nehmen. Aber ehrlichgesagt habe ich mir darüber nocht nicht intensiv den Kopf zerbrochen, da man da wieder extrem viele Informationen speichern und während des Spiels abforken müsste. Ich glaube die Tileabfrage ist die praktischere Methode. Immerhin kann man da mit etwas mehr Abfragen auch andere Formen als 16*16 Tiles nutzen, zB. 8*16, 8*8 oder ein Dreieck mit den Seiten 16*16..

  3. #43
    Zitat Zitat von CapSeb
    Man müsste Die Rennstrecke also drotzdem - wie ein Editor sozusagen - für den Spieler unsichtbar als Chipset erstellen.
    Zitat Zitat von Ryo Saeba 1000
    so kannst du die Map normal mappen, mit dem Chipset und musst es dann einfach nur "screenshoten" um ein Map-Picture rauszukriegen.
    Ich denke wir meinen da das Gleiche. Das ganze sieht nach einem vernünftigen Pinzip aus. Denächst werde ichs mal testen.

    Zitat Zitat von Ryo Saeba 1000
    Immerhin kann man da mit etwas mehr Abfragen auch andere Formen als 16*16 Tiles nutzen, zB. 8*16, 8*8 oder ein Dreieck mit den Seiten 16*16...
    Auf welches System beziehst du dich hierbei? Wie sollte man denn die Tiles unterteilen können?

  4. #44
    Ich würde, wenn ich Kollisionsmasken machen würde, diese ebenfalls mit der Terrain-ID koppeln

    Jede Terrain-ID bekäme eine bestimmte Maske, z.B. bekäme Terrain-ID 5 die Maske "Schräge Fläche die Nordwestlich blockt"
    Zuerst wird dann immer abgefragt, welche ID das Tile hat, in dem man sich gerade befindet und dann wird abgefragt, auf welchem Pixel innerhalb des Tiles man sich befindet und wo man hinwill und dann mit der Kollision Mask des Tiles verglichen, ob das möglich ist und ob eine schräge Bewegung möglich wäre
    Die Frage is nur, lohnt sich das oder geht man gleich aufn XP wenn man Pixelmovement will

  5. #45
    Irgendwie haben wir alle die gleichen Ideen...
    Zitat Zitat von Dhan
    bekäme Terrain-ID 5 die Maske "Schräge Fläche die Nordwestlich blockt"
    So hab ichs gemacht nur eben ohne pixelgenaue Bestimmung. Das brauch man aber auch nicht unbedingt und spart viel Arbeit.

  6. #46
    Zitat Zitat
    Zitat Zitat
    Immerhin kann man da mit etwas mehr Abfragen auch andere Formen als 16*16 Tiles nutzen, zB. 8*16, 8*8 oder ein Dreieck mit den Seiten 16*16...
    Auf welches System beziehst du dich hierbei? Wie sollte man denn die Tiles unterteilen können?
    Dhan hat eine wunderbare Möglichkeit genannt, so hätte ich's mir auch ungefähr vorgestellt xD
    Also um noch mal ein bisl in's Detail zu gehen: ich würde dann bei jedem Durchlauf des "Kollisionsfeststellevents" die Koordinaten des Fahrzeugs einlesen und durch 8 teilen, wenn's nen Rest gibt, dann passiert nix, wenn der Rest Null ist (um herauszufinden ob man gerade dabei ist ein neues Tile, bzw. die zweite Hälfte eines Tiles zu betreten), wird weiter abgeforkt um was es sich für eine Terrain ID bei dem Tile handelt und ob der Held bereits in der Mitte draufsteht oder es erst betritt.



    Zitat Zitat von Dhan
    Die Frage is nur, lohnt sich das oder geht man gleich aufn XP wenn man Pixelmovement will
    Ich zweifle ja immer noch stark daran, dass das mit dem XP besser ist. Gut, mit Ruby kann man die Spielfigur pixelgenau gehen lassen, aber der Rest sollte ja ebenfalls in Ruby gescripted werden, und ich denke das kostet selbst damit ordentlich Performance. Die viel höheren Systemanforderungen des XP's tuen ihr übriges.. ich bin mir also mehr als unischer ob's nicht zu einer Ruckelorgie verkommen würde?

    Also wenn wechseln, dann bei diesem Projekt doch definitiv zum Gamemaker anstatt zum XP.
    Der ist wahrscheinlich noch einfacher zu lernen als Ruby, und bietet weit mehr bei solchen arcadelastigen 2D Spielen.
    Wenn man so ein Projekt mit dem RPG Maker 2k/2k3 ernsthaft in Angriff nimmt, geht's mMn eigentlich nur darum sich selbst was zu beweisen, oder anderen zu zeigen, was alles mit diesem Spielzeug möglich ist.

    Geändert von Ryo Saeba 1000 (02.03.2006 um 23:42 Uhr)

  7. #47
    Ruckeln tutet beim Maker ja wegen der schlechten Verarbeitung der Scripte, ich glaub, das liegt nicht generell am Interpretieren.
    Mein Computer schafft ohne weiteres Warcraft III, d.h. er kann größte Mengen an Polygondaten in kürzester Zeit in ein Bild verwandeln aber er scheitert am Maker... das kann einfach nicht an der Leistung liegen sondern muss einfach am Maker liegen
    Von daher könnte ich mir vorstellen, dass Ruby für sowas sogar schneller sein könnte wenn der XP besser geschrieben ist (weiß ich aber nech, net soviel damit geschafft bisher ^^)

  8. #48
    Naabend!

    @CapSeb
    Sorry, war in letzter Zeit ziemlich beschäftigt, habe die letzten Einträge gelesen und jetzt kann es losgehen...

    Also fassen wir zusammen:

    Deine Anforderungen:

    - Du willst 4( +Spieler =5?) Spirites darstellen

    - Die Bewegungen der Spirits soll über Variabelen kontrolliert/gesteuert werden; bzw. eine Analyse der Position x/y abs. (= absolut auf dem Bildschirm und nicht in Realition zur Umgebung) des Spielers alle 0,1 sek.

    (Wenn ich irgendwas vergessen oder falsch verstanden habe, bitte melden! )

    Mein Ansatz:

    - Die Position der KI-Spirits erfolgt durch Skript (=Common Event) und einer Schleife(= ebenfalls Common Event), in der die Position "abgerackert" wird. ([KlugscheißModus]Verabschiede Dich an dieser Stelle von dem Gedanken, dass Variablen nur mit einem Wert belegt werden können..., man kann sie verändern, daher der Name! [/KlugscheißModus] )

    - Die Schleife ist im Grunde eine Art "Zwischenspeicher" und die Variablen in ihr geben den X/Y-Wert, Ausrichtung für die KI-Spirits an und einen Zeitindex! ( <- ganz wichtig, ich gehe später darauf ein...)

    - Die Werte für diesen "Zwischenspeicher" hinterlege ich in einem Common Event, der mit einzelnen Sprungmarken ( =Labels) gespickt ist

    - Der Schleife sage ich, dass sie, nach Erledigung ihrer Arbeit, sich neue Werte für die KI holen soll (= Call Common Event) und einen Schalter betätigt (<- wieder ganz wichtig!)

    - Der Schalter entscheidet in einer vorgeschalteten if-Handeling welcher Datensatz der KI geladen werden soll. Also: if schalter "xy" = 1, goto Label "1", if schalter"xy" = 2 gotoLabel "2", usw...

    - Ein weiterer Common Event:
    Der weiter oben erwähnte "Zeitindex" wird mit dem Zeitindex des Spielers verglichen, weicht er um einen bestimmten Wert ab, so wird das entsprechende Spirit größer (= näher) oder kleiner (= iss janz weit wech) dargestellt, bzw. ab einer gewissen Toleranz wird es auf dem momentanen Bild nicht dargestellt (= außer Sichtweite)

    Lediglich für den Spieler brauche ich auch weiterhin die volle Anzahl der Variablen(= 240k), um im Replay-Modus die "erfahrene" Leistung aufzuzeichnen. Mit Hilfe eines intelligenten Speichersystems können wir es noch evtl. so drehen, dass Du sämtliche Bestzeiten des Spielers auf einen Schlag speichern kannst (also für alle Strecken), ist allerdings ein bißchen komplizierter...
    Zu den genauen Größenordnungen(= Anzahl der Variablen) kann ich an dieser Stelle leider keine genaueren Angaben machen... Sorry, musst Du einfach ausprobieren.

    So, ich hoffe damit alle Klarheiten beseitigt zu haben...

    Viel Spaß beim programmieren!

  9. #49
    Die "One-Picture-Bahn-Methode" scheint funktionieren zu können. Ich bin den Quelltext durchgegangen und es scheint einsetzbar zu sein, habs bisher aber noch nicht umgeschrieben. Nur habt ihr schon mal versucht eine Rennstrecke ohne Chipset frei Hand am Computer zu zeichen, die dann auch mit dem "Kollisions-Chipset" übereinstimmt und ohne Objekte überhalb des Wagens auskommt? Egal...
    Zitat Zitat von White Knight
    Wenn ich irgendwas vergessen oder falsch verstanden habe, bitte melden!
    Dann mal los...
    Zitat Zitat
    - Du willst 4( +Spieler =5?) Spirites darstellen
    Der Geist gilt und erscheint nur in "Time Attack" oder wie man den Einzelspielermodus der Bestzeiten nennen will. Die vier Spieler gleichzeitig haben mit diesem Geist nichts zu tun und werden deswegen nicht gespeichert.
    Zitat Zitat
    eine Analyse der Position x/y abs. (= absolut auf dem Bildschirm und nicht in Realition zur Umgebung) des Spielers alle 0,1 sek.
    Der Geist soll alle 0,05 Sekunden angezeigt werden um sich den 24fps zu nähern. Dafür muss er im Verhältnis zu Map und nicht zum Bildschirm gespeichert bzw. dargestellt werden.
    Zitat Zitat
    Lediglich für den Spieler brauche ich auch weiterhin die volle Anzahl der Variablen(= 240k), um im Replay-Modus die "erfahrene" Leistung aufzuzeichnen.
    Leider ist der Entwickler nichts anderes als ebenfalls ein Spieler - nämlich ich. Und auch ich muss mit der gleichen Methode wie der Spieler die Variablen speichern lassen und kann sie nicht per Hand in ein Common Event schreiben. Dazu verweise ich auf meinen Post auf Seite1 vom 14.02.2006, um 11:40 Uhr

    Es steht jetzt aber immer noch die Frage offen, was mit einem "Variablen-Runtersetz-Programm" oder einer anderen Zeitsparmethode ist.

  10. #50
    Also ich würd sagen, das mit der "Picture-Bahn" sollte man lassen. das bringt nur mehr Probleme als Lösungen...
    Als du noch mit Chips arbeiten wolltest hattes du doch vor, den Gleiter als Pic zu basteln und darunter den hero zu setzen. Da war aber das Prob mit dem Picture und den zusätzlichen Variablen.
    Dann würde ich doch einfach sagen, du machts die Mauern einfach als Event (mit "Same Level As Hero"), oder?


    PS.: Deine neue Sig is klasse... - - - - - -

  11. #51
    Naabend!
    @CapSeb
    Sorry, dass ich beim letztem Mal ein bißchen am Ziel vorbei geschossen bin...

    Zitat Zitat von CapSeb
    Der Geist gilt und erscheint nur in "Time Attack" oder wie man den Einzelspielermodus der Bestzeiten nennen will. Die vier Spieler gleichzeitig haben mit diesem Geist nichts zu tun und werden deswegen nicht gespeichert. Der Geist soll alle 0,05 Sekunden angezeigt werden um sich den 24fps zu nähern. Dafür muss er im Verhältnis zu Map und nicht zum Bildschirm gespeichert bzw. dargestellt werden.
    Leider ist der Entwickler nichts anderes als ebenfalls ein Spieler - nämlich ich. Und auch ich muss mit der gleichen Methode wie der Spieler die Variablen speichern lassen und kann sie nicht per Hand in ein Common Event schreiben.
    Also; dieses Problem lässt sich theoretisch lösen...
    Schraub erstmal Deine Strecke (mit ca. 370k Variablen) zusammen, löse das Kollisionsproblem und dann vollführe ein paar Testfahrten. Wenn Du dann ein Gefühl für die Strecke hast, bau ein automatisches Speichern am Ende der Strecke ein (für alle Fälle) und anschließend lässt Du Dir über eine Textbox (= Message) beim Testspielen noch die Werte der Variablen anzeigen (nimm Dir an dem Abend besser nichts weiter vor, könnte länger dauern...), wie das genau geht steht im E-Book...

    Falls Du es gerade nicht zur Hand hast: \v[0000000] bis \v[370000]

    Die Werte schreibst Du Dir auf einen Zettel und anschließend hast Du dann doch alles was Du brauchst, oder nicht? (Ich habe nicht behauptet, dass es einfach wird...)

    Zitat Zitat von CapSeb
    Es steht jetzt aber immer noch die Frage offen, was mit einem "Variablen-Runtersetz-Programm" oder einer anderen Zeitsparmethode ist.
    Ohne Dir zu nahe treten zu wollen, aber Du weißt schon, dass Du mit einem RPG-Maker arbeitest? Ich betone das deshalb so explizit, weil die Engine sich zwar im gewissen Maße verbiegen lässt, aber irgendwo hat es seine Grenzen...

    Meiner Meinung nach könnte es immer noch klappen, aber muss die Ausrichtung unbedingt auch in einer Variable gespeichert werden?
    Auch dafür würde ich eher eine Lösung mit Switches in Betracht ziehen (je nach Länge des Tastendrucks anderes Bild anzeigen lassen...-> Anzahl im Extremfall 360, aber 16 sollten es auch tun, bei Drehern halt mit Bildern improvisieren).

    Sölltest Du das Projekt also ernsthaft in Erwägung ziehen, kommst Du an einem Skripten der "Geister-KI" sowieso nicht dran vorbei (Wie es gehen könnte steht ja weiter oben), schließlich hast Du ja mehrere Strecken, alle mit eigener KI und mit den eigenen vielen, vielen wunderbaren und ach so einzigartigen Datensätzen...

    Was mir jedoch immer noch Bauchschmerzen bereitet sind die vielen Variablen für den Spieler, irgendwie scheint da kein Weg dran vorbei zu führen, es sei denn:
    Framerate runtersetzen oder den Replaymode/ Streckenaufzeichnung komplett zu canceln...

    Momentaner Zwischenstand wäre also irgendwas bei 250k (370k im Entwicklermodus wegen der Ausrichtung)Variablen und einen Berg an Schaltern, richtig?
    Effektiv hieße das eine Wartezeit von nur noch etwas bei die 2 h
    Ist ja schon mal ein Anfang und Du hättest theoretisch ja auch schon ein Gegnerfeld, statt einem Geist der nur alle paar Sekunden aufblinkt echte Gegner die die Strecke mit Dir abfahren. Die Idee mit 4 Spielern gleichzeitig schiebst Du am Besten erstmal auf die unterste Position der "TO-DO-Liste", wird auf jeden Fall eine "interessante" Herausforderung wenn das euch noch im Replay realisiert werden soll, von dem Gedrämge am Klimperkasten (= Tastatur) ganz zu schweigen...

    Einige Sachen und ein paar coole Gimmicks wie Sektoren-Bestzeit, eine "halbwegs" realisierbare KI und ein autom. Speichern der Bestzeit beim Timetrial sind also in greifbarer Nähe.
    Als Krone könntest Du sogar noch einen Zufallswert einbinden, indem Du unterschiedliche KI-Schwierigkeitsgrade an die gegnerischen Fahrzeuge verteilst, so dass jedes Rennen aufs Neue spannend wird.

    Also das Projekt noch nicht komplett in die Tonne treten (vielleicht wäre es mit dem XP-Maker einfacher (->Ruby-Interface), weiß ich aber auch nicht so genau), früher oder später kommt garantiert die zündende Idee ...

    Hoffe ich konnte Dir heute mehr weiterhelfen

  12. #52
    Zitat Zitat von CapSeb
    Die "One-Picture-Bahn-Methode" scheint funktionieren zu können. Ich bin den Quelltext durchgegangen und es scheint einsetzbar zu sein, habs bisher aber noch nicht umgeschrieben. Nur habt ihr schon mal versucht eine Rennstrecke ohne Chipset frei Hand am Computer zu zeichen, die dann auch mit dem "Kollisions-Chipset" übereinstimmt und ohne Objekte überhalb des Wagens auskommt? Egal...
    Da hab ich doch noch mal ein paar Fragen an dich:
    Was meinst du mit "One-Picture-Bahn-Methode"? Meinst du meinen Vorschlag, die Strecke mit Pictures darzustellen und um den Helden herumzubewegen?
    Dann versteh ich nähmlich nicht, warum du die Rennstrecke ohne Chipset "frei Hand" zeichnen willst o.O
    Kein Chipset zu verwenden ist da doch viel zu aufwendig und unpraktisch, das ergibt keinen Sinn. Du kannst die strecke mit einem stinknormalen Chipset zeichnen, musst nur bei Terrain ID die entsprechenden Einstellungen vornehmen (meinetwegen bei Hindernis-> Kollision nimmst du ID=1).
    Wenn du deine Map im Maker erstellt hast, "screenshotest" du sie einfach und schon hast du dein Picture.
    Und wieso willst du ohne Objekte überhalb des Wagens auskommen? Dafür kannst du wunderbar den Upper Layer im RPG Maker verwenden, dann die Map kopieren, den unteren Layer "löschen" (mit einer ziemlich hervorstechenden Farbe) und wieder "screenshoten" und schon hast du ein zweites Picture.. deinen Upper Layer. Die Picture ID's der Fahrzeuge müssen dann natürlich über dem ersten und unter dem zweiten Map-Picture liegen.

  13. #53
    Halt, halt, haaaaaalt...
    Allmählich gerät das ganze hier aus den Fugen. Ich hab nach meinem letzten Post auf Picture+Chipset Bahn umgestellt und es funktioniert. Aber erstmal zu euch:
    Zitat Zitat von Mr.Hunz
    Dann würde ich doch einfach sagen, du machts die Mauern einfach als Event (mit "Same Level As Hero"), oder?
    Die Events hab ich schon seit längerem abgeschafft, da sie stark auf die Performance wirken. Die Terrain-ID funktioniert da viel besser.
    Zitat Zitat von White Knight
    nimm Dir an dem Abend besser nichts weiter vor, könnte länger dauern...), wie das genau geht steht im E-Book...
    Jetzt Neu! Freie Abende dank E-Book...
    Die ganzen Werte aufzuschreiben wäre natürlich das gleiche. Aber darauf habe ich ehrlich gesagt keine Lust. Zudem ist das Aktualisieren bei späteren Verbesserungen (oder Vereinfachungen) der Entwicklergeister äußerst nervig.
    Zitat Zitat von White Knight
    Meiner Meinung nach könnte es immer noch klappen, aber muss die Ausrichtung unbedingt auch in einer Variable gespeichert werden?
    Eh, nein. Die könnte ich tatsächlich durch das x- und y-Achsen-Verhältnis berechnen, wie es beim Fahren selbst ja auch der Fall ist.
    Zitat Zitat von White Knight
    Sölltest Du das Projekt also ernsthaft in Erwägung ziehen
    Ja.
    Zitat Zitat von White Knight
    Framerate runtersetzen oder den Replaymode/ Streckenaufzeichnung komplett zu canceln...
    Bei der Framerate könnte es "Komprimierungs"-Verfahren geben und die Streckenaufzeichnung funktioniert ja schon.
    Zitat Zitat von White Knight
    eine "halbwegs" realisierbare KI
    Gut, das ist wieder ein ganz anderes Them a, mit dem ich mich bisher aber noch nicht beschäftigt habe. Vielleicht werde ich einen neuen Thread öffnen, wenn ich soweit bin.
    Zitat Zitat von White Knight
    Hoffe ich konnte Dir heute mehr weiterhelfen
    Ich denke schon. Und auf jeden Fall vielen Dank für die Ideen!
    Zitat Zitat von Ryo Saeba 1000
    Dann versteh ich nähmlich nicht, warum du die Rennstrecke ohne Chipset "frei Hand" zeichnen willst o.O
    Die Verständnissprobleme sind meine Schuld. Ich meinte das ganze nicht so ernst und wollte nur betonen, dass es mit dem Screenshoten nicht getan ist. Aber egal, wie gesagt funktioniert es.

  14. #54
    Zitat von White Knight
    nimm Dir an dem Abend besser nichts weiter vor, könnte länger dauern...), wie das genau geht steht im E-Book...
    Jetzt Neu! Freie Abende dank E-Book...
    zitat von cabseb:
    Die ganzen Werte aufzuschreiben wäre natürlich das gleiche. Aber darauf habe ich ehrlich gesagt keine Lust. Zudem ist das Aktualisieren bei späteren Verbesserungen (oder Vereinfachungen) der Entwicklergeister äußerst nervig.

    daran wirst du aber nicht vorbeikommen... du musst entweder deine entwickler geister per hand eingeben... oder die spieler (die das spiel mal später spielen dürfen)müssen ein bereits gespielten spielstand als neuanfang nehmen, denn irgendwie müssen die daten ja im maker rein...oO
    dh. du musst erst fahren, strecken-entwickler-zeit speichern, game speichern
    und der spieler muss dann die save datei laden, damit er in den genuss
    der entwickler zeit kommen kann...

  15. #55
    ...und genau das ist die Methode, die ich am 14.02.2006 um 11:40 auf Seite 1 dieses Threads geposted habe.
    Aber wie schon gesagt, führt kein Weg daran vorbei. Und damit jeder das auch versteht, hier das Prinzip zusammengefasst:

    1. Man steuert einen Koordinatenpunkt
    2. Der Koordinatenpunkt geteilt durch 16 ergibt die Chara-Posi auf dem Chipset für die Kollisionsabfrage
    3. Das "gescreenshotete" Chipset wird als bemaltes Picture (2000x2000 Pixel)unterhalb des Fahrzeugs bewegt ohne Chipsetscrollen
    4. Das "gescreenshotete" Chipset wird als zweites bemaltes Picture (2000x2000 Pixel) oberhalb des Fahrzeugs bewegt ohne Chipsetscrollen
    5. Die Koordinate wird als Picture dargestellt (Fahrzeugposi minus Bildschirmposi)
    6. Die Entwicklerbestzeit (oder wenn besser die Spielerbestzeit) wird alle 0,05 Sekunden dargestellt
    7. Die Koordinatenposition wird alle 0,05 Sekunden als Geist gespeichert bei besserer Bestzeit

  16. #56
    Zitat Zitat von CapSeb
    4. Das "gescreenshotete" Chipset wird als zweites bemaltes Picture (2000x2000 Pixel) oberhalb des Fahrzeugs bewegt ohne Chipsetscrollen
    Ääääm: Wieso sollte die gesamte Map nochmal über dem Fahrzeug erscheinen? Dann sieht man das Fahrzeug doch gar nicht mehr...

    Zitat Zitat von CapSeb
    6. Die Entwicklerbestzeit (oder wenn besser die Spielerbestzeit) wird alle 0,05 Sekunden dargestellt
    Wieso, wie und warum ( ) DAS denn?

  17. #57
    Zitat Zitat von Mr.Hunz
    Ääääm: Wieso sollte die gesamte Map nochmal über dem Fahrzeug erscheinen? Dann sieht man das Fahrzeug doch gar nicht mehr...
    Das hat den gleichen Effekt wie der Upper-Layer: Nur an Stellen wo Bäume oder sonst welche "höheren" Objekte stehen hat das Picture Farbe. An allen anderen Stellen ist es natürlich durchsichtig...

    Zu Punkt 6: Ja, eh nicht die Zeit wird angezeigt sondern natürlich das dazugehörige Picture auf der Picturebahn.

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •