Pixelgenaue Kollision zweier Events

Rekrut

Montag, 11. April 2011, 14:16

Pixelgenaue Kollision zweier Events

Hallo,

da ich nicht fündig wurde, würde ich mich freuen wenn mir jemand einen Tipp geben könnte, wo ich folgendes Script finden kann:

Zwei Funktionen sollte das Script haben:
1. es sollte zurückgeben, welche Events (event_id) an einem bestimmten Punkt sich befinden. Dabei sollte es berücksichtigen, dass dies pixelgenau berechnet. Soll heißen, selbst wenn das Event nocht nicht vollständig auf dem Punkt ist, aber in schon betreten hat, sollte mir die ID des Events zurückgeworfen werden.

2. Vom Prinzip eine bekannte Sache, das Script sollte zurückgegeben, ob sich zwei Events treffen. Dieses sollte jedoch ebenfalls pixelgenau erfolgen.
Genial aber nicht notwendig wäre, wenn das Script die Form des Events berücksichtigt (z.B. Pfeil = ein schmaler Rechteck) und danach die Kollision berechnet.

Wenn eine pixelgenaue Abfrage zu sehr von der Leistung frässe, würde ich mich auch damit begnügen, dass das Script alle 2 oder 4 (oder halt

Pixel abfragt.
Außerdem sollte die Bewegung weiterhin im normalen Raster (32 Pixel) sein.

Bin für Hilfe dankbar.

Gruß
fjurio

SillyMoon

Knappe

Motto: ich bin der brennende schinken

2

Montag, 11. April 2011, 20:20

du willst pixelgenaue collision aber man soll sich nur in 32x32 bewegen können?
Möchteste jz nur schauen ob die 2 Src-Rects der events sich überschneiden?

Spoiler

Ruby Quellcode

class Scene_Map
  attr_reader :spriteset;
end
class Spriteset_Map
  attr_reader :character_sprites;
end
module RPG
  class Sprite < ::Sprite
    def intersectsSprite?(other)
      tw = src_rect.width+x;
      th = src_rect.height+y;
      rw = other.src_rect.width+other.x;
      rh = other.src_rect.height+other.y;
      return ((rw < other.x or rw > x) and
        (rh < other.y || rh > y) and
        (tw < x || tw > other.x) and
        (th < y || th > other.y));
    end
    def includePoint?(xx,yy)
      return (x <= xx and x+src_rect.width >= xx and
              y <= yy and y+src_rect.height >= yy);
    end
  end
end
# event_id:
#    -1 = Player
#    0+ = Others
def getCollisionForEvent(event_id)
  if !$scene.is_a?(Scene_Map) then return nil; end;
  if event_id == -1 then event_id = $scene.spriteset.character_sprites.length-1; end;
  actor = $scene.spriteset.character_sprites[event_id];
  for i in 0...$scene.spriteset.character_sprites.length
    if event_id != i and actor.intersectsSprite?($scene.spriteset.character_sprites[i])
      return i;
    end
  end
  return nil;
end
def getCollisionBetweenEvents(event_id_a,event_id_b)
  if !$scene.is_a?(Scene_Map) then return false; end;
  if event_id_a == -1 then event_id_a = $scene.spriteset.character_sprites.length-1; end;
  if event_id_b == -1 then event_id_b = $scene.spriteset.character_sprites.length-1; end;
  if event_id_a == event_id_b then return true; end;
  return $scene.spriteset.character_sprites[event_id_a].intersectsSprite?($scene.spriteset.character_sprites[event_id_b]);
end
def getCollisionWithPoint(event_id,x,y)
  if !$scene.is_a?(Scene_Map) then return false; end;
  if event_id == -1 then event_id_a = $scene.spriteset.character_sprites.length-1; end;
  return $scene.spriteset.character_sprites[event_id_a].includePoint?(x,y);
end
def getAllEventsAtPoint(x,y)
  ary = [];
  for i in 0...$scene.spriteset.character_sprites.length
    if $scene.spriteset.character_sprites[i].includePoint?(x,y)
      ary << (i == $scene.spriteset.character_sprites.length-1 ? -1 : i);
    end
  end
  return ary;
end

zum Lesen den Text mit der Maus markieren

-1 = Player
0+ = Other Ev.

	Quellcode
1	getCollisionForEvent(event_id)

Gibt die ID des events zurück das mit event_id collidiert.
Nil falls keine collision.

	Quellcode
1	getCollisionBetweenEvents(event_id_a,event_id_b)

Gibt zurück ob die beiden events event_id_a und event_id_b collidiert sind.

	Quellcode
1	getCollisionWithPoint(event_id,x,y)

Gibt zurück ob das event event_id den punkt x/y einschließt.

	Quellcode
1	getAllEventsAtPoint(x,y)

Gibt einen array zurück mit allen events ( deren ID's) die den punkt x/y einschließen

Edit: fixed, sollte es zumindest
PS.: STIRB KATZE!; D:
:hi:

;( :jagen:

Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von »SillyMoon« (12. April 2011, 20:25)

fjurios

Rekrut

3

Dienstag, 12. April 2011, 18:48

Das sieht interessant aus. Da ich es nicht ausgiebig testen konnte werde ich später noch was dazu schreiben.
Im Augenblick habe ich folgende Fehlermeldung wenn ich mir alle Events an einem Punkt anzeigen lassen will:

Playm

RPG Studio Webmaster

4

Dienstag, 12. April 2011, 18:53

In Zeile 52 fehlt eine Indexangabe:

	Ruby Quellcode
1	if $scene.spriteset.character_sprites[i].includePoint?(x,y)

@Genocide:
Ich weiß, du bist davon anscheinend überzeugt, aber wenn du in Ruby die Semikolon weglässt stirbt keine Katze, wirklich :o
Davon abgesehen solltest du die letzten drei Methoden nicht global definieren, sondern in die Interpreterklasse einbetten. Bei der Anwändung ändert sich nichts für fjurio, sollange er die Methoden von Events aufrufen lässt, es ist imo nur sauberer für den Fall.

Das große Scientia Wiki zur Spielentwicklung Bild

Was ist das RGSS ? RGSS-Dokumentation auf Sc
Kyoshiros Makerkurs

Musik von Shabraxxx für euch

Guide zu den Audioformaten :book:

Skripte von mir (Auswahl):
Atmungssystem :rmxp:

| Streichholzsystem :rmxp:

| Animiert durch Bücher blättern :rmxp:

Random : Marktsystem für Kardor :rmxp:

| Staterelated Battlergraphic :rmxp:

| Hinweis auf mögliche Aktionen :rmxp:

SelfSwitchExpirationtimer Skript - Gameplayerweiterung für Pilzesammler und Farmspiele :rmxp:

Meine Skripte werden gerade hier gesammelt.

fjurios

Rekrut

5

Mittwoch, 13. April 2011, 00:54

Oh, nächstes Mal poste ich die Zeile auch. Danke.

Ich bekomme nun keine Fehlermeldung mehr (bei getalleventsatpoint...), jedoch gibt er mir nichts wieder. Zumindest wenn ich die Abfrage in eine Variable abspeichere und diese per Textbox mir anzeigen möchte. Das kann aber auch daran liegen, dass ich mich mit arrays nicht auskenne und da was falsch mache.
Für heute lass ich es aber gut sein. Falls keiner mir helfen kann, werde ich morgen mal das Problem ausführlicher schildern.
In diesem Sinne: Gute Nacht.

Bex

Seher

Motto: Lets have some Fun.

6

Mittwoch, 13. April 2011, 01:48

Da deine Figuren nicht Pixelgenau laufen könnte man die Pixelgenaue abfrage
über Events machen.
Statt Map Koordinaten fragst du Screenkoordinaten ab.

Das Funktioniert und verhindert lästige Bugs bei der Trefferabfrage von AKS und bei anderen Projekten.

Wie man die Screenabfrage zweier Events auch über ein kurzes Call Skript macht müsste jemand anders sagen, da ich absoluter Neuling im Bereich einfaches Call Skript bin.
Solltest du etwas ganz kompliziertes haben muss vieleicht wirkleich ein komplettes Skript geschrieben werden.

Keine richtige Hilfe aber ich hoffe der Beitrag hilft trotzdem irgendwie.

SillyMoon

Knappe

Motto: ich bin der brennende schinken

7

Mittwoch, 13. April 2011, 12:19

getAllEventsAtPoint gibt einen array zurück mit allen event_id's die den punkt einschließen,
du könntest sie dir per textbox ausgeben lassen indem du in Call-Script folgendes machst:

	Ruby Quellcode
1	print getAllEventsAtPoint(x,y);

print ploppt eine box auf mit den array und seinen inhalten.

	Ruby Quellcode
1 2 3	for i in getAllEventsAtPoint(x,y) # hier bekommst du eine event_id nach der anderen bis der array dir alle einträge zurückgegeben hat. end

möchtest du es jz in einer textbox haben könnteste machen:

Ruby Quellcode

$game_variables[1]="" # Leerer string erstellen
for i in getAllEventsAtPoint(x,y)
    $game_variables[1] += ","+i.to_s # wandel integer in string um und häng ihn mit komma and den vorhandennen string an
end

Nun kannst du es einfach in einer textbox auf den geläufigen wege ausgeben lassen.

;( :jagen:

fjurios

Rekrut

8

Mittwoch, 13. April 2011, 18:01

@ Genocide
Jetzt habe ich es verstanden. Ich war zu sehr auf eine fixe Wiedergabe orientiert, dass ich gar nicht darauf kam wie man ein Array abfragt. Danke.

Danke auch dir Bex. Jetzt weiß ich auch wozu die real_x Variabel im RGSS gut ist.

Im übrigen, ich habe eine eigene Abfrage nach Events an einem bestimmten Punkt als Übung geschrieben. Orientiert habe ich mich dabei an dem in dem RGSS schon verhanden §game_map.check_event(x,y). Dazu nahm ich noch das neu gewonnen Wissen durch Genocide.

Ich poste es einfach, ihr könnt es gerne kritisieren, kopieren oder sonst was:

Spoiler

Ruby Quellcode

class Game_Map
  def event_here?(x, y, l=0)
	id = []
	for event in $game_map.events.values
  	if event.x == x and event.y == y
    	id = id + [event.id]
  	end
	end
	if l == "anzahl"
  	return id.length
	end
	return id[l]
  end
end

Hiermit fragt man ab, wieviel Events auf dem Punkt x,y sind:

	Ruby Quellcode
1	$game_map.event_here?(x, y, "anzahl")

Hiermit erhält man die ID des ersten Events (falls vorhanden, ansonsten = 0) an dem Punkt x,y.
Für die meisten Fälle reicht das aus, vor allem wenn nicht mehr als ein Event an der Position zu erwarten ist:

	Ruby Quellcode
1	$game_map.event_here?(x, y)

Hiermit erhält man die ID des zweiten Events (falls vorhanden, ansonsten = 0) an dem Punkt x,y:

	Ruby Quellcode
1	$game_map.event_here?(x, y, 1)

Hiermit das dritte Event...

	Ruby Quellcode
1	$game_map.event_here?(x, y, 2)

usw.

zum Lesen den Text mit der Maus markieren

SillyMoon

Knappe

Motto: ich bin der brennende schinken

9

Mittwoch, 13. April 2011, 21:31

	Ruby Quellcode
1 2 3 4 5 6 7 8 9 10 11	class Game_Map def event_here?(x, y) id = [] for event in $game_map.events.values if event.x == x and event.y == y id = id + [event.id] end end return id end end

das würde schon reichen.

Anzahl:

	Ruby Quellcode
1	$game_map.event_here?(x, y).length

Ein bestimmtes:

	Ruby Quellcode
1	$game_map.event_here?(x, y)[1]

;( :jagen:

fjurios

Rekrut

10

Mittwoch, 13. April 2011, 23:42

Und wieder was gelernt. Danke.
Mensch so langsam kommt man ja beim scripten vorran, das macht Spaß.

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »fjurios« (15. April 2011, 02:02)

fjurios

Rekrut

11

Freitag, 15. April 2011, 02:04

Da mir die Kollisionsabfrage durch die Grafik nicht ganz zusagte, habe ich, mit den Erkenntnisse und Hinweise aus diesem Thread, mir selber ein Script geschrieben.

Dieses wollte ich eurer Kritik nicht vorenthalten.

Verwenden dürft ihr es natürlich auch.

Spoiler

Ruby Quellcode

class Game_Map
 
  def collision(a,b=0,awidth=-30,bwidth=-30,aheight=awidth,bheight=bwidth)
for ax in (events[a].real_x - (127 + awidth))..(events[a].real_x + awidth)
  if b == 0
    for bx in ($game_player.real_x - 
      (127 + bwidth))..($game_player.real_x + bwidth)
      if ax == bx
        x_collision = true
      end
    end
  else
    for bx in (events[b].real_x - 
      (127 + bwidth))..(events[b].real_x + bwidth)
      if ax == bx
        x_collision = true
      end
    end
  end  
end
for ay in (events[a].real_y - (127 + aheight))..(events[a].real_y + aheight)
  if b == 0
    for by in ($game_player.real_y - 
      (127 + bheight))..($game_player.real_y + bheight)
      if ay == by
        y_collision = true
      end
    end
  else
    for by in (events[b].real_y - 
      (127 + bheight))..(events[b].real_y + bheight)
      if ay == by
        y_collision = true
      end
    end
  end
end
if x_collision == true and y_collision == true
  return true
else
  return false
end
  end
end

zum Lesen den Text mit der Maus markieren

Das ist der allgemeine Aufruf der Kollisionsabfrage:

	Ruby Quellcode
1	$game_map.collision(event_id_a, event_id_b, breite_a, breite_b, höhe_a, höhe_b)

Dabei stehen die Variabeln für:
event_id_a = die ID des ersten Events dessen Kollision ermittelt werden soll
event_id_b = die ID des zweiten Events dessen Kollision ermittelt werden soll
breite_a = "Breite" die das erste Event haben soll (ausgehend von der Standardbreite = 128 )
breite_b = "Breite" die das zweite Event haben soll (ausgehend von der Standardbreite = 128 )
höhe_a = "Höhe" die das erste Event haben soll (ausgehend von der Standardhöhe = 128 )
höhe_b = "Höhe" die das zweite Event haben soll (ausgehend von der Standardhöhe = 128 )

ein unvollständige Erklärung (wurde mir zu lang und zu spät / bei Intresse wird sie vorgesetzt):

Spoiler

Die Breite und Höhe bestimmten wie nah sich die beiden Events sein müssen, damit sie als Kollidiert gelten. Man könnte sie auch als die Reichweit eines Events bezeichnen.
Dadurch können Events, wenn sie groß genug sind, kollidieren obwohl sie auf unterschiedlichen Koordinaten stehen oder, wenn sie klein genug sind, sich auf dem selben Koordinatenfeld "streifen" ohne das eine Kollision ausgelöst wird.
Dabei geht man von einer Standardgröße 128 aus. D.h., soll das Event die normale Größe behalten, gibt man für die Breite und Höhe 0 ein. Will man die Reichweite des Events vergrößern verwendet man positive Zahlen (4 = ein Pixel), ansonsten negative.
Würde man also bei der Höhe und Breite jeweils eine 4 schreiben würde die Kollision nicht nur in dem Standardfeld von 32x32 Pixel reagieren, sondern nun in 34x34 Pixel(an jeder Seite kommt durch die 4 ein Pixel dazu).
Hier einige Beispiele:

	Ruby Quellcode
1	$game_map.collision(12, 8, 64, 0, 64, 0)# Schneidet sich das 12te Event, mit vergrößerten Reichweite, mit dem 8ten Event?

Hier könnte Event 12 ein großer Stein sein, der auch benachbarte Events beeinflussen soll.

	Ruby Quellcode
1	$game_map.collision(4, 6, 0, 0, -56, 0)# Schneidet sich das 4te Event, mit der verringerten Höhe, mit dem 6ten Event?

Hier könnte Event 4 ein Pfeil sein, der waagerecht fliegt. Er ist sehr schmal und daher leichter auszuweichen...

An diesem Punkt beende ich die Erläuterung.

zum Lesen den Text mit der Maus markieren

Viel Spaß

Kenai

Landsknecht

Motto: “Niemals aufgeben, bevor man nicht alles versucht hat.”

12

Freitag, 15. April 2011, 12:21

Mal 'ne Frage: Du willst die Kollisionen jetzt an Hand einer Hitbox berrechnen, oder? Wenn dem so ist, brauchst du doch keine for-Schleifen einbauen^^. Ich habe mal deinen Code verbessert... inklusive deiner Überlegungen :3. Habe also die Event-ID-Parameter und Standardbreite / -höhe so belassen - obwohl man es anders lösen könnte (siehe unten^^):

Ruby Quellcode

class Game_Map
  def collision(a, b = 0, a_width = -30, b_width = -30, 
                a_height = a_width, b_height = b_width)
    a_width  += 128
    b_width  += 128
    a_height += 128
    b_height += 128
    a      = a == 0 ? $game_player : @events[a]
    b      = b == 0 ? $game_player : @events[b]
    x      = ((a.real_x + a_width / 2) - (b.real_x + b_width / 2)).abs
    y      = ((a.real_y + a_height / 2) - (b.real_x + b_height / 2)).abs
    width  = a_width / 2 + b_width / 2 - 1
    height = a_height / 2 +  b_height / 2 - 1
    return false if x > width or y > height
    return true
  end
end

(Ich würde auch die Höhe und Breite sowie die Kollisionsmethode in die Game_Character-Klasse einbauen. Ist an sich einfach logischer zumal du dann keine Parameter wie Höhe und Breite extra angeben müsstest. Ist jetzt aber auch nicht wichtig, sondern viel mehr eine Idee wie du das ganze noch verbessern könntest. Solange es aber funktioniert und du keine Probleme haben wirst, kannst du es so lassen :3)

~ Gruß Kenai Bild

Neuigkeiten

Sämtliche Projekte sind erst mal pausiert. Weitere Informationen findet ihr hier. (Stand: 21.12.2012).
Cursal Engine (Jump and Run Engine)

Mit Hilfe der Cursal Engine (RCE) ist es möglich auf ziemlich einfache Weise „Jump and Run“-Projekte im RPG Maker XP zu entwerfen. Das Anlegen basiert auf Installations- und Updatepaketen sowie reinen Archiven für fortgeschrittene Benutzer. Die Version 2 (CE2) befindet sich bereits in Entwicklung. Interessiert? Dann lade dir die neuste Version herunter ;3!
Avatar

Diese kleinen, netten und knuffigen Vögelchen nennen sich Hamachou und dürften einigen aus Skies of Arcadia bekannt sein. Ich habe diese Bilder weder selbst gezeichnet noch modelliert. Dennoch finde ich sie so knuffig, dass man sie einfach lieb haben muss und ich hoffe euch geht's genau so^^". Diese Grafiken sind wirklich rar und ich bin stolz sie im Web gefunden zu haben.

Evrey

Oberschurke im Ruhestand

Motto: "Satzzeichen sind keine Rudeltiere." - Chesra

13

Freitag, 15. April 2011, 14:27

Mal auf µSekunden hin verbessern :3

Ruby Quellcode

class Game_Map
  def collision(a, b=0, a_width = -30, b_width = -30, a_height=a_width, b_height=b_width)
    a_width  += 128
    b_width  += 128
    a_height += 128
    b_height += 128
    a_h2   = a_height/2
    a_w2   = a_width/2
    b_h2   = b_height/2
    b_w2   = b_width/2
    a      = a.zero? ? $game_player : @events[a]
    b      = b.zero? ? $game_player : @events[b]
    x      = ((a.real_x+a_w2)-(b.real_x+b_w2)).abs
    y      = ((a.real_y+a_h2)-(b.real_y+b_h2)).abs
    width  = a_w2+b_w2-1
    height = a_h2+b_h2-1
    return(!(x>width||y>height))
  end # eof collision
end # eof Game_Map

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

Kenai

Landsknecht

Motto: “Niemals aufgeben, bevor man nicht alles versucht hat.”

14

Freitag, 15. April 2011, 16:49

@Evrey: Mmmh... interessant. Da schaut das Ganze doch schon mal deutlich besser aus als meins^^". Ich werde diesen Code für ein gewisses anderes Projekt in meinem "riesigen" Archiv an Grimskrams abspeichern xD. (Irgendwas störte mich auch immer an meinem Code... anscheinend war es das oder so... ist ja auch egal :3.)

@fjurio: Wenn du diese deutlich verbesserte Methode nutzt, könntest du sie vielleicht noch dahingehend anpassen, dass du die Breite und Höhe in Pixeln angibst. Also statt einer Standardbreite bzw. -höhe von 128 nimmt du 32 Pixel. Diese Veränderung wird so schwer nicht sein. Darüber hinaus musst du dann nicht ständig umrechnen ;3.

Neuigkeiten

Sämtliche Projekte sind erst mal pausiert. Weitere Informationen findet ihr hier. (Stand: 21.12.2012).
Cursal Engine (Jump and Run Engine)

Mit Hilfe der Cursal Engine (RCE) ist es möglich auf ziemlich einfache Weise „Jump and Run“-Projekte im RPG Maker XP zu entwerfen. Das Anlegen basiert auf Installations- und Updatepaketen sowie reinen Archiven für fortgeschrittene Benutzer. Die Version 2 (CE2) befindet sich bereits in Entwicklung. Interessiert? Dann lade dir die neuste Version herunter ;3!
Avatar

Diese kleinen, netten und knuffigen Vögelchen nennen sich Hamachou und dürften einigen aus Skies of Arcadia bekannt sein. Ich habe diese Bilder weder selbst gezeichnet noch modelliert. Dennoch finde ich sie so knuffig, dass man sie einfach lieb haben muss und ich hoffe euch geht's genau so^^". Diese Grafiken sind wirklich rar und ich bin stolz sie im Web gefunden zu haben.

Evrey

Oberschurke im Ruhestand

Motto: "Satzzeichen sind keine Rudeltiere." - Chesra

15

Freitag, 15. April 2011, 17:00

Zitat

Also statt einer Standardbreite bzw. -höhe von 128 nimmt du 32 Pixel

Dafür!
Die Optimierung meinerseits bestand übrigens daraus, doppelte Rechnungen zusammen zu fassen und ein sinnloses if zu streichen.

Offtopic

Ich kann deine Codes gern mal optimieren, sobald es Spannendes zu Glübschen gibt.

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

fjurios

Rekrut

16

Freitag, 15. April 2011, 18:48

Cool, danke. Ist echt besser mit Differenzen zu rechnen als einer langen Schleife.
Ist viel effizienter. Besonders staune ich über diese Zeilen:

	Ruby Quellcode
1 2	a = a.zero? ? $game_player : @events[a] b = b.zero? ? $game_player : @events[b]

a wird zu etwas, das durch a definiert wird. Genial.

Diese Zeile verstehe ich nicht:

	Ruby Quellcode
1	(!(x>width\|\|y>height))

Oder gilt false als Null? Jedenfalls mag ich es, wenn sinnlose if´s dabei sind. Ist für mich dann nachvollziehbarer...

Es in Pixel zu machen ist sicherlich nutzerfreundlicher. Und wenn wir schon dabie sind es einfacher zu machen, warum schreibt man die ganzen Rechnungen mit der Höhe und Breite untereinander, wenn man es doch in einer Zeile machen könnte. Ist es untereinander geschrieben effizienter oder hat es einfach mit persönlicher Vorliebe zu tun?

Ruby Quellcode

class Game_Map
  def collision(a, b=0, a_width = -8, b_width = -8, a_height=a_width, b_height=b_width)
	a_h2   = ((a_height * 4) + 128) / 2
	a_w2   = ((a_width * 4) + 128) / 2
	b_h2   = ((b_height * 4) + 128) / 2
	b_w2   = ((b_width * 4) + 128) / 2
	a  	= a.zero? ? $game_player : @events[a]
	b  	= b.zero? ? $game_player : @events[b]
	x  	= ((a.real_x+a_w2)-(b.real_x+b_w2)).abs
	y  	= ((a.real_y+a_h2)-(b.real_y+b_h2)).abs
	width  = a_w2+b_w2-1
	height = a_h2+b_h2-1
	return(!(x>width||y>height))
  end # eof collision
end # eof Game_Map

Den Vorschlag es in game_character zu verschieben kann ich nur ahnend nachvollziehen, da ich keine Ahnung habe wie ich die Events und deren Breite/Höhe in der Klasse abfragen könnte. Die meisten Scripte von denen ich "gelernt" habe bezogen sich auf game_player oder game_map, daher gehen meine Kenntnisse nicht weit darüber hinaus. Aber ich lerne es noch.

Evrey

Oberschurke im Ruhestand

Motto: "Satzzeichen sind keine Rudeltiere." - Chesra

17

Samstag, 16. April 2011, 23:26

(A*B+C)/D = A*B/D+C/D
=>

Ruby Quellcode

class Game_Map
  def collision(a, b=0, a_width = -8, b_width = -8, a_height=a_width, b_height=b_width)
	a_h2   = a_height*2+64
	a_w2   = a_width*2+64
	b_h2   = b_height*2+64
	b_w2   = b_width*2+64
	a  	= a.zero? ? $game_player : @events[a]
	b  	= b.zero? ? $game_player : @events[b]
	x  	= ((a.real_x+a_w2)-(b.real_x+b_w2)).abs
	y  	= ((a.real_y+a_h2)-(b.real_y+b_h2)).abs
	width  = a_w2+b_w2-1
	height = a_h2+b_h2-1
	return(!(x>width||y>height))
  end # eof collision
end # eof Game_Map

Zitat

Diese Zeile verstehe ich nicht: [...]

	Ruby Quellcode
1	!(x>width\|\|y>height)

Liest sich:
"Wenn die Bedingung, dass x größer als die Breite und y größer als die Höhe sind, nicht erfüllt ist,..."

!(A||B) = !A && !B
!(C>D) = C<=D
=>
!((A>B)||(C>D)) = (A<=B)&&(C<=D)
=>

Ruby Quellcode

class Game_Map
  def collision(a, b=0, a_width = -8, b_width = -8, a_height=a_width, b_height=b_width)
	a_h2   = a_height*2+64
	a_w2   = a_width*2+64
	b_h2   = b_height*2+64
	b_w2   = b_width*2+64
	a  	= a.zero? ? $game_player : @events[a]
	b  	= b.zero? ? $game_player : @events[b]
	x  	= ((a.real_x+a_w2)-(b.real_x+b_w2)).abs
	y  	= ((a.real_y+a_h2)-(b.real_y+b_h2)).abs
	width  = a_w2+b_w2-1
	height = a_h2+b_h2-1
	return(x<=width&&y<=height)
  end # eof collision
end # eof Game_Map

Zitat

Und wenn wir schon dabie sind es einfacher zu machen [...]

Ein Bisschen Bool'sche Algebra und Rechengesetze brachten dem Code erneut eine starke Vereinfachung.

Zitat

a wird zu etwas, das durch a definiert wird. Genial.

	Ruby Quellcode
1 2 3 4 5 6 7	Class.new(Object) \ {\|\| define_method(:initialize) \ {\|\| self.class.send(:define_method,:foo) {\|\| Kernel.print("hi")} } }.new.foo() #=> "hi"

Hier wird beim Aufruf eine Klasse generiert, die beim Erstellen eine Methode definiert, die "hi" ausgibt, die daraufhin aufgerufen wird. Ruby kann viiieeel.

Edit Und noch eine letzte Optimierung. Diesmal ist es gar daraufhin optimiert, 4 temporäre Variablen und damit Cache in der VM zu sparen, die es jedoch erst in der nächsten Ruby-Version gibt. Mehr an Optimierung ist - Glaub' ich - nicht d'rin (außer, man packt die Definitionen von width und height direkt in's return, was dann jedoch kontraproduktiv zur Leserlichkeit ist).

Ruby Quellcode

class Game_Map
  def collision(a, b=0, a_w2 = -8, b_w2 = -8, a_h2=a_w2, b_h2=b_w2)
    a_h2   = a_h2*2+64
    a_w2   = a_w2*2+64
    b_h2   = b_h2*2+64
    b_w2   = b_w2*2+64
    a      = a.zero? ? $game_player : @events[a]
    b      = b.zero? ? $game_player : @events[b]
    x      = ((a.real_x+a_w2)-(b.real_x+b_w2)).abs
    y      = ((a.real_y+a_h2)-(b.real_y+b_h2)).abs
    width  = a_w2+b_w2-1
    height = a_h2+b_h2-1
    return(x<=width&&y<=height)
  end # eof collision
end # eof Game_Map

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

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »Evrey« (16. April 2011, 22:59)

fjurios

Rekrut

18

Dienstag, 26. April 2011, 16:49

So, kann wieder ins Internet...

Danke für die Optimierung und Hilfe.

Zitat
Ruby Quellcode
1
2
   !(x>width||y>height)
 
Liest sich:
"Wenn die Bedingung, dass x größer als die Breite und y größer als die Höhe sind, nicht erfüllt ist,..."

Die Zeile verstehe ich leider immer noch nicht. Was es macht habe ich verstanden, nur nicht warum. Laut dieser Seite: Ruby Operators
bedeutet || das true zurück geworfen wird, wenn einer der "operands" nicht 0 ist. Durch ! (not) wird es verdreht, also sobald einer der "operands" 0 ist wird true "returnt". Soweit ist mir alles klar, wann aber wird x > width, bzw. y > height zu 0? So weit ich weiß wirft die "größer-als"-Abfrage nur true oder false zurück?

Evrey

Oberschurke im Ruhestand

Motto: "Satzzeichen sind keine Rudeltiere." - Chesra

19

Dienstag, 26. April 2011, 17:44

Zitat

Laut dieser Seite: Ruby Operators
bedeutet || das true zurück geworfen wird, wenn einer der "operands" nicht 0 ist.

Ruby Quellcode

false ? true : false #=> false
true ? true : false #=> true
nil ? true : false #=> false
0 ? true : false #=> true
"" ? true : false #=> true (warning)
[] ? true : false #=> true
Object.new() ? true : false #=> true

nil wird in Ruby wie ein false gehandhabt. Jedes andere Objekt gilt in Bedingungen als true.

Zitat

Durch ! (not) wird es verdreht, also sobald einer der "operands" 0 ist wird true "returnt"

	Quellcode
1 2	irb(main):025:0> !0 => false

Zitat

!(A||B) = !A && !B
!(C>D) = C<=D
=>
!((A>B)||(C>D)) = (A<=B)&&(C<=D)

Zitat

Soweit ist mir alles klar, wann aber wird x > width, bzw. y > height zu 0?

Nie, weil:

Zitat

So weit ich weiß wirft die "größer-als"-Abfrage nur true oder false zurück?

Und verbrenn' bitte diese obscure Seite dort, sie erzählt dir Müll ôO

Zitat

There are following logical operators supported by Ruby language
Assume variable a holds 10 and variable b holds 20 then: [...]

Quellcode

irb(main):017:0> a,b=10,20
=> [10, 20]
irb(main):018:0> a&&b
=> 20 # angeblich true
irb(main):019:0> a||b
=> 10 # angeblich true
irb(main):020:0> !(a&&b)
=> false # hier stimmt's
irb(main):021:0> (a||b)
=> 10 # auch die Klammern machen keinen Unterschied

Edit

	Quellcode
1 2	irb(main):026:0> RUBY_DESCRIPTION => "ruby 1.9.2p136 (2010-12-25) [i386-mingw32]"

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).