Ein Sprite in bestimmter "fester" Zeit bewegen

Enchanted lord of Shadows

Dienstag, 6. April 2010, 13:26

Ein Sprite in bestimmter "fester" Zeit bewegen

Servus..

aaalsooo...

Iwie scheine ich atm ne riesen Blockade zu haben.. Teilweise bin ich schon happy wenn ich es schaffe ein Sprite ohne Anleitung anzuzeigen (ich glaub das lag am osterstress)...

naja.. auf jeden fall:

Ich suche ein stück code.

Dabei habe ich 1 Sprite "@anicard", sowie XY Koordinaten "@goal[x,y]"

Was ich nun brauche:
Der Code soll ermitteln, wieviele pixel pro Frame ich das sprite an X und Y bewegen muss, damit es innerhalb von den von mir angegebenen Frames zu @goal bewegt. Dabei soll es egal sein, wie weit das Sprite vond en zielkoordinaten weg ist. Es soll sich immer innerhalbd er Frames zum Ziel bewegen.

*hope* das iwer ne idee hat...

There was a Cave,
below a Silent's Grave.
Tunnels, extending far, running wide,
going deep into the World on the other Side.
Poor little Child, that was to brave,
died painfully deep down, in the Devil's Cave.

Neo-Bahamut

Himmelsgleicher

Motto: Wer anderen eine Bratwurst brät, der hat ein Bratwurstbratgerät.

2

Dienstag, 6. April 2010, 14:07

Ruby Quellcode

@anicard = Sprite.new
@goal = [10, 10]
frames = 3
 
x, y = @anicard.x, @anicard.y
newx, newy = @goal
deltax, deltay = newx-x, newy-y
movex, movey = deltax/frames, deltay/frames
 
frames.times do
 Graphics.update
 @anicard.x += movex
 @anicard.y += movey
end

Spoiler: Wurstinator

zum Lesen den Text mit der Maus markieren

Spoiler: Lazer-Wurst

zum Lesen den Text mit der Maus markieren

Spoiler: Hallowurst

zum Lesen den Text mit der Maus markieren

Chaosgod Espér

Enchanted lord of Shadows

3

Dienstag, 6. April 2010, 14:33

k.. nur 1 Problem....

Bild

Sieht soweit ok aus. bewegt sich..dreht sich.. läuft...

ABER:
Bild

Die @goal koordinaten stimmen.. nur iwie verfehlt er den eigentlichen zielplatz immer.

There was a Cave,
below a Silent's Grave.
Tunnels, extending far, running wide,
going deep into the World on the other Side.
Poor little Child, that was to brave,
died painfully deep down, in the Devil's Cave.

Neo-Bahamut

Himmelsgleicher

Motto: Wer anderen eine Bratwurst brät, der hat ein Bratwurstbratgerät.

4

Dienstag, 6. April 2010, 14:40

Das liegt dann wahrscinelich daran, dass movex und movey nur Integer sind. Alternative wäre es so zu machen:

Ruby Quellcode

@anicard = Sprite.new
@goal = [10, 10]
realxy = [@anicard.x.to_f, @anicard.y.to_f]
frames = 3
 
x, y = realxy
newx, newy = @goal
deltax, deltay = newx-x, newy-y
movex, movey = deltax/frames, deltay/frames
 
frames.times do
 Graphics.update
 realxy[0] += movex
realxy[1] += movey
@anicard.x = realxy[0].round
@anicard.y = realxy[1].round
end

Dann bräuchtest du eben noch eine Klasse oder nur einen Array, der die Koordinaten als Floats speichert.

Spoiler: Wurstinator

zum Lesen den Text mit der Maus markieren

Spoiler: Lazer-Wurst

zum Lesen den Text mit der Maus markieren

Spoiler: Hallowurst

zum Lesen den Text mit der Maus markieren

Chaosgod Espér

Enchanted lord of Shadows

5

Dienstag, 6. April 2010, 15:44

iwie schafft er es immernoch das Ziel ned zu erreichen, und dann innerhalb von einemf rame zum andern 40-50 pixel weit zum ziel zu springen ( sieht blöd aus )..

Ich geb jetzt einfach ma den code.. ungeachtet dessen wie unfertig er ist:

Spoiler

Ruby Quellcode

  def card_place_animation(start=0, ziel=0, card="", typus="")
    $duelwindow.back_opacity = 190
    @anicard = Sprite.new
    @anicard.bitmap = RPG::Cache.picture("/Cards/"+card)
    @anicard.x = $spritearray_held[start].x
    @anicard.y = $spritearray_held[start].y
    @anicard.ox = @anicard.bitmap.width/2
    @anicard.oy = @anicard.bitmap.height/2
    @anicard.zoom_x = 0.5
    @anicard.zoom_y = @anicard.zoom_x
    @anicard.z = 9999
    $spritearray_held[start].opacity = 0
    @target_id = ziel
    @goal = [$feld_setup["held"][@target_id][0], $feld_setup["held"][@target_id][1]]
    @realxy = [@anicard.x.to_f, @anicard.y.to_f]
 
    @pixelfly = [0,0,""]
    @pixelfly[2] = typus
 
    frames = 60
    x, y = @anicard.x, @anicard.y
    newx, newy = @goal
    deltax, deltay = newx-x, newy-y
    @pixelfly[0], @pixelfly[1] = deltax/frames, deltay/frames
 
    @phase3 = 1
    @phase2 = 1
    frames.times do
      Graphics.update
      $duelwindow.fadeout if(@phase2 == 1)
      @realxy[0] += @pixelfly[0]
      @realxy[1] += @pixelfly[1]
      @anicard.x = @realxy[0].round
      @anicard.y = @realxy[1].round
      @anicard.zoom_x -= 0.05 if(@anicard.zoom_x > 0.2)
      @anicard.zoom_y = @anicard.zoom_x
      if(@pixelfly[2] == "zauber")
        if(@target_id == 5 && @anicard.angle != 270)
          @anicard.angle += 5
        elsif(@target_id == 6 && @anicard.angle != 90)
          @anicard.angle += 5
        end
      end
    end
    @anicard.x = @goal[0]
    @anicard.y = @goal[1]
    @anicard.zoom_x = 0.2
    @anicard.zoom_y = @anicard.zoom_x      
    if(@pixelfly[2] == "zauber")
      if(@target_id == 5)
        @anicard.angle = 270
      elsif(@target_id == 60)
        @anicard.angle = 90
      end
    end
    @anicard.dispose
  end

zum Lesen den Text mit der Maus markieren

There was a Cave,
below a Silent's Grave.
Tunnels, extending far, running wide,
going deep into the World on the other Side.
Poor little Child, that was to brave,
died painfully deep down, in the Devil's Cave.

Neo-Bahamut

Himmelsgleicher

Motto: Wer anderen eine Bratwurst brät, der hat ein Bratwurstbratgerät.

6

Dienstag, 6. April 2010, 15:51

Zitat

x, y = @anicard.x, @anicard.y

Diese Zeile ist bei dir anders.
Weil du direkt auf @anicard.x und nicht auf @realxy zugreifst ist x ein Integer. Somit ist deltax auch ein Integer und Integer/Integer ist gleich Integer :D

Spoiler: Wurstinator

zum Lesen den Text mit der Maus markieren

Spoiler: Lazer-Wurst

zum Lesen den Text mit der Maus markieren

Spoiler: Hallowurst

zum Lesen den Text mit der Maus markieren

Evrey

Oberschurke im Ruhestand

Motto: "Satzzeichen sind keine Rudeltiere." - Chesra

7

Dienstag, 6. April 2010, 15:59

Das Problem dürften Rundungsfehler sein... daher müsste Neo seinen Code so editieren:

	Ruby Quellcode
1	movex, movey = (deltax/(frames.to_f())).ceil(), (deltay/(frames.to_f())).ceil()

Dadurch werden die Rundungsfehler durch stures truncaten abgeschwächt. ceil() ist die genaueste Rundungsmethode. Beispiel:

	Ruby Quellcode
1 2 3 4 5 6	deltax = 32 frames = 5 movex0 = (deltax/(frames.to_f())).ceil() movex1 = deltax/frames Kernel.p(movex0,movex1) #=>

Quellcode

irb(main):001:0> deltax = 32
=> 32
irb(main):002:0> frames = 5
=> 5
irb(main):003:0> movex0 = (deltax/(frames.to_f())).ceil()
=> 7
irb(main):004:0> movex1 = deltax/frames
=> 6
irb(main):005:0>
irb(main):006:0* Kernel.p(movex0,movex1)
7
6
=> [7, 6]

Na wenn das mal kein Unterschied ist! Und jetzt nehm mal 'ne noch größere Zahl! Mal so nebenbei, den Code zeigte ich dir doch gestern Abend oder heute Morgen?
Ich kann mir nur zwei Fehlerquellen denken:

Deine Koordinaten sind inkorrekt.
Durch das Gedrehe deines Sprites (drehst du es?) ändert sich auch der Bezugspunkt dieses Sprites (obere linke Ecke). Den zu bestimmen ist nicht nur kompliziert, es würde zu einem Eiern des Bildes führen.

Gruß und so,
Evrey

P.S.: Ruby ist OOP, du solltest dich unbedingt mal in Klassen und Module einlernen o__O"

compétences

mes compétences	max.
Maps machen
Musik machen
Scripts machen
Story ausdenken
Pixeln und so
Events proggen

(Dieser Tab ist rein satirisch.)

mes projets

Silentium

Name: Silentium
Maker: Eigenbau (C++, x86-SSE/AVX-Assembly, Ruby/Lua)

Story	NPCs	Scripts	Ressis	Maps	Gesamt
(3+4)%	42	69%	0815	-17.438	103.38% ± 6.3mm²

(Die Tabelle erfüllt lediglich satirische Zwecke.)

Onyx
Eine in C++ implementierte, modulare, plattformunabhängige, virtuelle Maschine. Die Test-Version ist bereits halb fertig. Ab dann gibt es vielleicht mehr Infos. Sie soll die auf dem ersten Blick LISP-artige und eigens dafür konstruierte Sprache Obsidian ausführen können. Experimentell wird auch ein Lua-Compiler für Onyx gebaut. Ziel ist eine leistungsfähige, virtuelle Maschine für beliebige Scriptsprachen. Theoretisch gesehen müsste man bloß noch einen kompatiblen Compiler schreiben, der Quellcode jener Sprache in Onyx-Assembly, oder direkt in Onyx-Bytecode übersetzt. Ob die jemand nutzen wird, ist eine andere Frage und nur ein sekundäres... nein, eher tertiäres Ziel dieser VM. Primär dient es mir lediglich dazu, mein Verständnis von Hardware, ISA, und Assembly zu vertiefen, sowie eigene Grenzen auszutesten.

Warnung!
Das Entwickeln einer virtuellen Maschine oder Programmiersprache (im wahnsinnigsten Fall beides) ist eine höchst komplizierte Tätigkeit, aus der viel Frust und Hirnmatsche hervor gehen. Sollte sich dennoch ein ähnlich wahnsinniger finden, der sowas zusammen schustern will, so lege ich ihm/ihr die folgenden Bücher ans Herz:
- Compiler - Das Drachenbuch [978-3-8273-7097-6]
  Dieses Buch schlachtet ausführlich und leicht verständlich die Grundlagen bis hoch zu den Experten-Techniken des Compilerbaus aus. Es fängt mit der Automaten-Theorie und formalen Sprachen an, arbeitet sich durch Analysetechniken vor, und landet schließlich bei Techniken wie Optimierung und Register-Zuweisung. Das Buch wiegt 3Kg oder 4Kg. Hab's mal gewogen. Ist also nicht gerade die Lektüre für unterwegs.
- Computerarchitektur [3-8273-7016-7]
  Hier werden leicht verständlich die wichtigsten Entwicklungen der Rechnerarchitekturen erklärt (Gut, das Buch ist in die Jahre gekommen, aber der Weg zu heute ist ein winziger Schritt, den man sich nach diesem Buch selbst erdenken kann). Hauptbestandteil des Buchs ist eine relativ umfassende Betrachtung der Funktionsweise dreier gänzlich unterschiedlicher, aber dominierender Prozessor-Typen am Beispiel des Pentium II, UltraSPARC II, sowie picoJava. Die meisten Elemente dieses Buchs sind zwar für die Konstruktion einer virtuellen Maschine irrelevant, oder aufgrund der Tatsache, dass die VM Software ist und z.B. Byte-Grenzen hat, sogar zu Leistungseinbußen führen kann, doch ist ein hinreichendes Verständnis dieser Maschinen, mit denen wir arbeiten, äußerst hilfreich für die Überlegungen, wie die VM arbeiten soll.
Es kann sehr hilfreich und inspirierend sein, den Code quelloffener, virtueller Maschinen anderer Sprachen zu überfliegen. Meine Lieblings-Quelle war und ist stets die VM von Lua. Sie ist schlank, verständlich, in C implementiert, und basiert im Gegensatz zu vielen anderen Scriptsprachen-VMs auf einer Register-Maschine statt einer Stapelmaschine. Es wäre natürlich vorteilhaft, die entsprechende Sprache zu verstehen, in der man auch die eigene VM implementieren will. Weiterhin ist es äußerst vorteilhaft, eine leistungsstarke und bequeme Sprache wie C++ zu beherrschen, um die VM zu implementieren. Und bevor irgendwer auf die Idee kommt: Assembly ist NICHT als dominierende Sprache für den Bau einer VM geeignet. Wer die Frage des "Warum?" nicht beantworten kann, sollte zunächst die gewählte Sprache und Assembly hinreichend verstehen lernen, und es dann erneut mit der Frage versuchen. Es lohnt sich dennoch, Assembly zu lernen. Allein schon, um erneut das Verständnis zu vertiefen, zumal ihr mehr oder weniger gezwungen seid, auch für eure VM eine Assembler-Sprache zu entwickeln (Außer natürlich ihr schreibt eure Test-Programme Bit für Bit ;3).

enfin

Je ne peux pas parler français.
C'est tout ce que Goodle et les restes de cours de français.

Signaturstand: 24.07.2013

Chaosgod Espér

Enchanted lord of Shadows

8

Dienstag, 6. April 2010, 16:06

Zitat

Durch das Gedrehe deines Sprites (drehst du es?) ändert sich auch der Bezugspunkt dieses Sprites (obere linke Ecke). Den zu bestimmen ist nicht nur kompliziert, es würde zu einem Eiern des Bildes führen.

weshalbd er bezugspunkt des Sprites auch im zentrum liegt...
dennoch verfehlt er das ziel ( mit evys methode )

There was a Cave,
below a Silent's Grave.
Tunnels, extending far, running wide,
going deep into the World on the other Side.
Poor little Child, that was to brave,
died painfully deep down, in the Devil's Cave.

Evrey

Oberschurke im Ruhestand

Motto: "Satzzeichen sind keine Rudeltiere." - Chesra

9

Dienstag, 6. April 2010, 16:22

Äh, nee?

	Ruby Quellcode
1 2	@anicard.ox = @anicard.bitmap.width/2 @anicard.oy = @anicard.bitmap.height/2

Soweit, so gut, damit setzt du ihn mittig, ABER...

Ruby Quellcode

    frames.times do
      Graphics.update
      $duelwindow.fadeout if(@phase2 == 1)
      @realxy[0] += @pixelfly[0]
      @realxy[1] += @pixelfly[1]
      @anicard.x = @realxy[0].round
      @anicard.y = @realxy[1].round
      @anicard.zoom_x -= 0.05 if(@anicard.zoom_x > 0.2)
      @anicard.zoom_y = @anicard.zoom_x
      if(@pixelfly[2] == "zauber")
        if(@target_id == 5 && @anicard.angle != 270)
          @anicard.angle += 5
        elsif(@target_id == 6 && @anicard.angle != 90)
          @anicard.angle += 5
        end
      end
    end

Wo setzt du dort nochmal dieses Offset? Wenn du ein Bild drehst, ändert sich die Bildgröße, sodass die verschobenen Pixel im Bild bleiben. Du musst das Offset nach jedem Dreher neu setzen. Dadurch bleibt der "Mittelpunkt" an der später falschen stelle. Das Bild eiert, Vermutung 2 stimmt also doch ._.

compétences

mes compétences	max.
Maps machen
Musik machen
Scripts machen
Story ausdenken
Pixeln und so
Events proggen

(Dieser Tab ist rein satirisch.)

mes projets

Silentium

Name: Silentium
Maker: Eigenbau (C++, x86-SSE/AVX-Assembly, Ruby/Lua)

Story	NPCs	Scripts	Ressis	Maps	Gesamt
(3+4)%	42	69%	0815	-17.438	103.38% ± 6.3mm²

(Die Tabelle erfüllt lediglich satirische Zwecke.)

Onyx
Eine in C++ implementierte, modulare, plattformunabhängige, virtuelle Maschine. Die Test-Version ist bereits halb fertig. Ab dann gibt es vielleicht mehr Infos. Sie soll die auf dem ersten Blick LISP-artige und eigens dafür konstruierte Sprache Obsidian ausführen können. Experimentell wird auch ein Lua-Compiler für Onyx gebaut. Ziel ist eine leistungsfähige, virtuelle Maschine für beliebige Scriptsprachen. Theoretisch gesehen müsste man bloß noch einen kompatiblen Compiler schreiben, der Quellcode jener Sprache in Onyx-Assembly, oder direkt in Onyx-Bytecode übersetzt. Ob die jemand nutzen wird, ist eine andere Frage und nur ein sekundäres... nein, eher tertiäres Ziel dieser VM. Primär dient es mir lediglich dazu, mein Verständnis von Hardware, ISA, und Assembly zu vertiefen, sowie eigene Grenzen auszutesten.

Warnung!
Das Entwickeln einer virtuellen Maschine oder Programmiersprache (im wahnsinnigsten Fall beides) ist eine höchst komplizierte Tätigkeit, aus der viel Frust und Hirnmatsche hervor gehen. Sollte sich dennoch ein ähnlich wahnsinniger finden, der sowas zusammen schustern will, so lege ich ihm/ihr die folgenden Bücher ans Herz:
- Compiler - Das Drachenbuch [978-3-8273-7097-6]
  Dieses Buch schlachtet ausführlich und leicht verständlich die Grundlagen bis hoch zu den Experten-Techniken des Compilerbaus aus. Es fängt mit der Automaten-Theorie und formalen Sprachen an, arbeitet sich durch Analysetechniken vor, und landet schließlich bei Techniken wie Optimierung und Register-Zuweisung. Das Buch wiegt 3Kg oder 4Kg. Hab's mal gewogen. Ist also nicht gerade die Lektüre für unterwegs.
- Computerarchitektur [3-8273-7016-7]
  Hier werden leicht verständlich die wichtigsten Entwicklungen der Rechnerarchitekturen erklärt (Gut, das Buch ist in die Jahre gekommen, aber der Weg zu heute ist ein winziger Schritt, den man sich nach diesem Buch selbst erdenken kann). Hauptbestandteil des Buchs ist eine relativ umfassende Betrachtung der Funktionsweise dreier gänzlich unterschiedlicher, aber dominierender Prozessor-Typen am Beispiel des Pentium II, UltraSPARC II, sowie picoJava. Die meisten Elemente dieses Buchs sind zwar für die Konstruktion einer virtuellen Maschine irrelevant, oder aufgrund der Tatsache, dass die VM Software ist und z.B. Byte-Grenzen hat, sogar zu Leistungseinbußen führen kann, doch ist ein hinreichendes Verständnis dieser Maschinen, mit denen wir arbeiten, äußerst hilfreich für die Überlegungen, wie die VM arbeiten soll.
Es kann sehr hilfreich und inspirierend sein, den Code quelloffener, virtueller Maschinen anderer Sprachen zu überfliegen. Meine Lieblings-Quelle war und ist stets die VM von Lua. Sie ist schlank, verständlich, in C implementiert, und basiert im Gegensatz zu vielen anderen Scriptsprachen-VMs auf einer Register-Maschine statt einer Stapelmaschine. Es wäre natürlich vorteilhaft, die entsprechende Sprache zu verstehen, in der man auch die eigene VM implementieren will. Weiterhin ist es äußerst vorteilhaft, eine leistungsstarke und bequeme Sprache wie C++ zu beherrschen, um die VM zu implementieren. Und bevor irgendwer auf die Idee kommt: Assembly ist NICHT als dominierende Sprache für den Bau einer VM geeignet. Wer die Frage des "Warum?" nicht beantworten kann, sollte zunächst die gewählte Sprache und Assembly hinreichend verstehen lernen, und es dann erneut mit der Frage versuchen. Es lohnt sich dennoch, Assembly zu lernen. Allein schon, um erneut das Verständnis zu vertiefen, zumal ihr mehr oder weniger gezwungen seid, auch für eure VM eine Assembler-Sprache zu entwickeln (Außer natürlich ihr schreibt eure Test-Programme Bit für Bit ;3).

enfin

Je ne peux pas parler français.
C'est tout ce que Goodle et les restes de cours de français.

Signaturstand: 24.07.2013

Chaosgod Espér

Enchanted lord of Shadows

10

Dienstag, 6. April 2010, 16:27

selbstw enn ich den offset neu setze.. verfehlt er das ziel....

Ruby Quellcode

  def card_place_animation(start=0, ziel=0, card="", typus="")
    $duelwindow.back_opacity = 190
    @anicard = Sprite.new
    @anicard.bitmap = RPG::Cache.picture("/Cards/"+card)
    @anicard.x = $spritearray_held[start].x
    @anicard.y = $spritearray_held[start].y
    @anicard.ox = @anicard.bitmap.width/2
    @anicard.oy = @anicard.bitmap.height/2
    @anicard.zoom_x = 0.5
    @anicard.zoom_y = @anicard.zoom_x
    @anicard.z = 9999
    $spritearray_held[start].opacity = 0
    @target_id = ziel
    @goal = [$feld_setup["held"][@target_id][0], $feld_setup["held"][@target_id][1]]
    @realxy = [@anicard.x.to_f, @anicard.y.to_f]
 
    @pixelfly = [0,0,""]
    @pixelfly[2] = typus
 
    frames = 60
    x, y = @realxy
    newx, newy = @goal
    deltax, deltay = newx-x, newy-y
    @pixelfly[0], @pixelfly[1] = (deltax/(frames.to_f())).ceil(), (deltay/(frames.to_f())).ceil()
 
    @phase3 = 1
    @phase2 = 1
    frames.times do
      Graphics.update
      $duelwindow.fadeout if(@phase2 == 1)
      @realxy[0] += @pixelfly[0]
      @realxy[1] += @pixelfly[1]
      @anicard.x = @realxy[0].round
      @anicard.y = @realxy[1].round
      @anicard.zoom_x -= 0.05 if(@anicard.zoom_x > 0.2)
      @anicard.zoom_y = @anicard.zoom_x
      if(@pixelfly[2] == "zauber")
        if(@target_id == 5 && @anicard.angle != 270)
          @anicard.ox = @anicard.bitmap.width/2
          @anicard.oy = @anicard.bitmap.height/2
          @anicard.angle += 5
        elsif(@target_id == 6 && @anicard.angle != 90)
          @anicard.ox = @anicard.bitmap.width/2
          @anicard.oy = @anicard.bitmap.height/2
          @anicard.angle += 5
        end
      end
    end
    @anicard.x = @goal[0]
    @anicard.y = @goal[1]
    @anicard.zoom_x = 0.2
    @anicard.zoom_y = @anicard.zoom_x      
    if(@pixelfly[2] == "zauber")
      if(@target_id == 5)
        @anicard.angle = 270
      elsif(@target_id == 60)
        @anicard.angle = 90
      end
    end
    @anicard.dispose
  end

There was a Cave,
below a Silent's Grave.
Tunnels, extending far, running wide,
going deep into the World on the other Side.
Poor little Child, that was to brave,
died painfully deep down, in the Devil's Cave.

Evrey

Oberschurke im Ruhestand

Motto: "Satzzeichen sind keine Rudeltiere." - Chesra

11

Dienstag, 6. April 2010, 16:39

Mal etwas, das ich absolut nicht raffe:

Ruby Quellcode

def card_place_animation(start=0, ziel=0, card="", typus="")
    #...
    @anicard.x = $spritearray_held[start].x
    @anicard.y = $spritearray_held[start].y
    #...
    @realxy = [@anicard.x.to_f, @anicard.y.to_f]
    #...
    x, y = @realxy
    newx, newy = @goal
    deltax, deltay = newx-x, newy-y
    @pixelfly[0], @pixelfly[1] = (deltax/(frames.to_f())).ceil(), (deltay/(frames.to_f())).ceil()
    #...
    frames.times do
      #...
      @realxy[0] += @pixelfly[0]
      @realxy[1] += @pixelfly[1]
      @anicard.x = @realxy[0].round
      @anicard.y = @realxy[1].round
      #...
    end
    #...

HÄ? Du, ich blick' da kaum durch, weil du blödsinnig viele Vars nutzt, die nichtmal wirklich einen Sinn ergeben. Und wozu setzt du die Koordinaten bei @realxy auf Floats??? Und was bringt dieses @realxy überhaupt? Wieso nicht sofort auf die echten Koordinaten rauf addieren? Und überhaupt... wozu ein round() bei dem @realxy??? So kommen doch nur wieder unsinnige Rundungsfehler rein, mal abgesehen davon, dass du prinzipiell das tust:

	Ruby Quellcode
1	@realxy = [x.to_f.to_i(),y.to_f.to_i()]

Schlanke deinen Code bitte mal ab, dann blickt man auch besser durch...

compétences

mes compétences	max.
Maps machen
Musik machen
Scripts machen
Story ausdenken
Pixeln und so
Events proggen

(Dieser Tab ist rein satirisch.)

mes projets

Silentium

Name: Silentium
Maker: Eigenbau (C++, x86-SSE/AVX-Assembly, Ruby/Lua)

Story	NPCs	Scripts	Ressis	Maps	Gesamt
(3+4)%	42	69%	0815	-17.438	103.38% ± 6.3mm²

(Die Tabelle erfüllt lediglich satirische Zwecke.)

Onyx
Eine in C++ implementierte, modulare, plattformunabhängige, virtuelle Maschine. Die Test-Version ist bereits halb fertig. Ab dann gibt es vielleicht mehr Infos. Sie soll die auf dem ersten Blick LISP-artige und eigens dafür konstruierte Sprache Obsidian ausführen können. Experimentell wird auch ein Lua-Compiler für Onyx gebaut. Ziel ist eine leistungsfähige, virtuelle Maschine für beliebige Scriptsprachen. Theoretisch gesehen müsste man bloß noch einen kompatiblen Compiler schreiben, der Quellcode jener Sprache in Onyx-Assembly, oder direkt in Onyx-Bytecode übersetzt. Ob die jemand nutzen wird, ist eine andere Frage und nur ein sekundäres... nein, eher tertiäres Ziel dieser VM. Primär dient es mir lediglich dazu, mein Verständnis von Hardware, ISA, und Assembly zu vertiefen, sowie eigene Grenzen auszutesten.

Warnung!
Das Entwickeln einer virtuellen Maschine oder Programmiersprache (im wahnsinnigsten Fall beides) ist eine höchst komplizierte Tätigkeit, aus der viel Frust und Hirnmatsche hervor gehen. Sollte sich dennoch ein ähnlich wahnsinniger finden, der sowas zusammen schustern will, so lege ich ihm/ihr die folgenden Bücher ans Herz:
- Compiler - Das Drachenbuch [978-3-8273-7097-6]
  Dieses Buch schlachtet ausführlich und leicht verständlich die Grundlagen bis hoch zu den Experten-Techniken des Compilerbaus aus. Es fängt mit der Automaten-Theorie und formalen Sprachen an, arbeitet sich durch Analysetechniken vor, und landet schließlich bei Techniken wie Optimierung und Register-Zuweisung. Das Buch wiegt 3Kg oder 4Kg. Hab's mal gewogen. Ist also nicht gerade die Lektüre für unterwegs.
- Computerarchitektur [3-8273-7016-7]
  Hier werden leicht verständlich die wichtigsten Entwicklungen der Rechnerarchitekturen erklärt (Gut, das Buch ist in die Jahre gekommen, aber der Weg zu heute ist ein winziger Schritt, den man sich nach diesem Buch selbst erdenken kann). Hauptbestandteil des Buchs ist eine relativ umfassende Betrachtung der Funktionsweise dreier gänzlich unterschiedlicher, aber dominierender Prozessor-Typen am Beispiel des Pentium II, UltraSPARC II, sowie picoJava. Die meisten Elemente dieses Buchs sind zwar für die Konstruktion einer virtuellen Maschine irrelevant, oder aufgrund der Tatsache, dass die VM Software ist und z.B. Byte-Grenzen hat, sogar zu Leistungseinbußen führen kann, doch ist ein hinreichendes Verständnis dieser Maschinen, mit denen wir arbeiten, äußerst hilfreich für die Überlegungen, wie die VM arbeiten soll.
Es kann sehr hilfreich und inspirierend sein, den Code quelloffener, virtueller Maschinen anderer Sprachen zu überfliegen. Meine Lieblings-Quelle war und ist stets die VM von Lua. Sie ist schlank, verständlich, in C implementiert, und basiert im Gegensatz zu vielen anderen Scriptsprachen-VMs auf einer Register-Maschine statt einer Stapelmaschine. Es wäre natürlich vorteilhaft, die entsprechende Sprache zu verstehen, in der man auch die eigene VM implementieren will. Weiterhin ist es äußerst vorteilhaft, eine leistungsstarke und bequeme Sprache wie C++ zu beherrschen, um die VM zu implementieren. Und bevor irgendwer auf die Idee kommt: Assembly ist NICHT als dominierende Sprache für den Bau einer VM geeignet. Wer die Frage des "Warum?" nicht beantworten kann, sollte zunächst die gewählte Sprache und Assembly hinreichend verstehen lernen, und es dann erneut mit der Frage versuchen. Es lohnt sich dennoch, Assembly zu lernen. Allein schon, um erneut das Verständnis zu vertiefen, zumal ihr mehr oder weniger gezwungen seid, auch für eure VM eine Assembler-Sprache zu entwickeln (Außer natürlich ihr schreibt eure Test-Programme Bit für Bit ;3).

enfin

Je ne peux pas parler français.
C'est tout ce que Goodle et les restes de cours de français.

Signaturstand: 24.07.2013

Neo-Bahamut

Himmelsgleicher

Motto: Wer anderen eine Bratwurst brät, der hat ein Bratwurstbratgerät.

12

Dienstag, 6. April 2010, 16:48

Esper, schonmal meine Methode getestet? oô

Spoiler: Wurstinator

zum Lesen den Text mit der Maus markieren

Spoiler: Lazer-Wurst

zum Lesen den Text mit der Maus markieren

Spoiler: Hallowurst

zum Lesen den Text mit der Maus markieren

Chaosgod Espér

Enchanted lord of Shadows

13

Dienstag, 6. April 2010, 16:49

@Neo: ja.....

So.. also..
Hier nochma mein eigentlicher code ( ohne jegliche änderrungen):

Ruby Quellcode

  def card_place_animation(start=0, ziel=0, card="", typus="")
    $duelwindow.back_opacity = 190
    @anicard = Sprite.new
    @anicard.bitmap = RPG::Cache.picture("/Cards/"+card)
    @anicard.x = $spritearray_held[start].x
    @anicard.y = $spritearray_held[start].y
    @anicard.zoom_x = 0.5
    @anicard.zoom_y = @anicard.zoom_x
    @anicard.z = 9999
    $spritearray_held[start].opacity = 0
    @goal = [$feld_setup["held"][ziel][0], $feld_setup["held"][ziel][1]]
 
    @pixelfly = [0,0,""]
    @pixelfly[2] = typus # "zauber" oder "monster"? zauberkarten drehen sich und ändern bezugspunkt
    @pixelfly[0] = 0 #Der X-weg den ein sprite pro frame zurücklegen muss
    @pixelfly[1] = 0 #Der Y-weg den ein sprite pro frame zurücklegen muss
 
    frames = 60
 
    frames.times do
      Graphics.update
      @anicard.x += @pixelfly[0]
      @anicard.y += @pixelfly[1]
      $duelwindow.fadeout if(@phase2 == 1)
      @anicard.zoom_x -= 0.05 if(@anicard.zoom_x > 0.2)
      @anicard.zoom_y = @anicard.zoom_x
      if(@pixelfly[2] == "zauber")
        if(ziel == 5 && @anicard.angle != 270)
          @anicard.ox = @anicard.bitmap.width/2
          @anicard.oy = @anicard.bitmap.height/2
          @anicard.angle += 5
        elsif(ziel == 6 && @anicard.angle != 90)
          @anicard.ox = @anicard.bitmap.width/2
          @anicard.oy = @anicard.bitmap.height/2
          @anicard.angle += 5
        end
      end
    end
    @anicard.x = @goal[0]
    @anicard.y = @goal[1]
    @anicard.zoom_x = 0.2
    @anicard.zoom_y = @anicard.zoom_x      
    if(@pixelfly[2] == "zauber")
      if(ziel == 5)
        @anicard.angle = 270
      elsif(ziel == 60)
        @anicard.angle = 90
      end
    end
    @anicard.dispose
  end

was ich rbauche ist: für diese beiden zeilen:

	Ruby Quellcode
1 2	@pixelfly[0] = 0 #Der X-weg den ein sprite pro frame zurücklegen muss @pixelfly[1] = 0 #Der Y-weg den ein sprite pro frame zurücklegen muss

Die berechnung des wegs, den des sprite pro frame zurücklegen muss.

There was a Cave,
below a Silent's Grave.
Tunnels, extending far, running wide,
going deep into the World on the other Side.
Poor little Child, that was to brave,
died painfully deep down, in the Devil's Cave.