ScriptEngine II (v. 0.6.1)

[sx2008]

Mir fällt auf, dass im gesamten Projekt keine Interfaces verwendet werden.
Ich habe allerdings nur stichprobenartig in den Code geschaut.
Gerade bei so einem komplexen Projekt könnten aber Interfaces und die autom. Referenzzählung bei Interfacepointern eine weitere Verbesserung bringen.

[EugenB]

Zitat:

Zitat von littleDave

Sollte behoben sein, denn .....

:arrow: Version 0.5.0.0

Ja das ist noch besser :)

Jetzt kann ich es sogar kompilieren, danke!

Ich konnte auch noch die console.pas/consoleform.pas unter FPC kompilieren (dachte erst es würde nicht funktionieren :P)

Hab ich mich damals verlesen oder sollten Arrays nicht in Version 0.5.0.0 erscheinen :P

Zitat:

Zitat von sx2008

Mir fällt auf, dass im gesamten Projekt keine Interfaces verwendet werden.
Ich habe allerdings nur stichprobenartig in den Code geschaut.
Gerade bei so einem komplexen Projekt könnten aber Interfaces und die autom. Referenzzählung bei Interfacepointern eine weitere Verbesserung bringen.

Genau das funktioniert leider nicht :(, würde diese auch brauchen um mittels script auf SOAP-Services zuzugreifen, ohne in der Host-Anwendung dieses zu "erstellen" -> oder kennt jemand eine andere Methode um leicht auf SOAP-Services zu zu greifen? :)

Dann bräuchte man "nur" noch Arrays und Interfaces richtig? :)

[littleDave]

Zitat:

Zitat von sx2008

Mir fällt auf, dass im gesamten Projekt keine Interfaces verwendet werden.
Ich habe allerdings nur stichprobenartig in den Code geschaut.
Gerade bei so einem komplexen Projekt könnten aber Interfaces und die autom. Referenzzählung bei Interfacepointern eine weitere Verbesserung bringen.

Also ich habe bisher keine Probleme damit gehabt. Referenz-Probleme habe ich bisher eigentlich nicht. Ich denke, dass man hier eigentlich komplett auf Interfaces verzichten kann - denn ich sehe im Moment keine Verbesserung, die mir Interfaces bieten würden.

Zitat:

Zitat von EugenB

Hab ich mich damals verlesen oder sollten Arrays nicht in Version 0.5.0.0 erscheinen :P

Ist eine kurze Planänderung: ich dachte mir, dass Exception-Handling doch etwas wichtiger ist, als Arrays. Wenn man Listen haben will, kann man sich theoretisch die TList-Klasse aus der Collection-Unit schnappen. Als Datenobjekt erstellt man dann eine Klasse. Dadurch hat man sehr viel mehr Vorteile, als einfach nur ein array of record (z.B. die Vererbung).

Zitat:

Zitat von EugenB

Genau das funktioniert leider nicht :(, würde diese auch brauchen um mittels script auf SOAP-Services zuzugreifen, ohne in der Host-Anwendung dieses zu "erstellen" -> oder kennt jemand eine andere Methode um leicht auf SOAP-Services zu zu greifen? :)

Dann bräuchte man "nur" noch Arrays und Interfaces richtig? :)

Ich glaube sx2008 meint Interfaces im Delphi-Source. Für Interfaces in den Scripts habe ich mal versucht den Assembler-Code, den Delphi erstellt, versucht zu verstehen. Das Problem ist halt die richtige Zuordnung der Methoden - da habe ich noch kein Konzept für gefunden.

[himitsu]

Zitat:

Zitat von littleDave

Für Interfaces in den Scripts habe ich mal versucht den Assembler-Code, den Delphi erstellt, versucht zu verstehen. Das Problem ist halt die richtige Zuordnung der Methoden - da habe ich noch kein Konzept für gefunden.

Delphi-Quellcode:

PInterfaceEntry = ^TInterfaceEntry;
TInterfaceEntry = packed record
  IID: TGUID;
  VTable: Pointer;
  IOffset: Integer;
  ImplGetter: Integer;
end;

PInterfaceTable = ^TInterfaceTable;
TInterfaceTable = packed record
  EntryCount: Integer;
  Entries: array[0..9999] of TInterfaceEntry;
end;

TObject:
  function GetInterface(const IID: TGUID; out Obj): Boolean;
  class function GetInterfaceEntry(const IID: TGUID): PInterfaceEntry;
  class function GetInterfaceTable: PInterfaceTable;

Da findestes du schonmal alle Interfaces eines Objektes.
PInterfaceTable

Direkt an der Adresse, wohin der Interfacezeiger zeigt, liegt eine MethodAdressTabelle.

Und die InterfaceMethoden werden einfach über ihren Index aufgerufen.

Delphi-Quellcode:

IInterface = interface
  function QueryInterface(const IID: TGUID; out Obj): HResult; stdcall;
  function _AddRef: Integer; stdcall;
  function _Release: Integer; stdcall;
end;

Kannst dir ja mal hiervon den ASM-Code anzeigen lassen:

Delphi-Quellcode:

var Intf: IInterface;
begin
  Integer(Intf) := $123;
  Intf._AddRef;

_AddRef ist die 2. Methode des Interfaces.
Es gibt auch keine Vorfahren dieses Interfaces ... deren Methoden würden sonst vorher aufgezählt.
Somit hat die Methode die Adresse, welche bei +4 Byte (Index = 1, da 0-basierendes Array) in dieser Tabelle liegt.

Code:

mov eax, Intf
call TMethod(PPointer(Intf)^ + Index)

Delphi-Quellcode:

ITest = Interface(IInterface)
  Procedure Test;
end;

PS: Wenn nix angegeben ist, dann ist der Standardvorfahr automatisch IInterface.

.Test läge also bei Index 4 aka +12 Byte (0 bis 3 in IInterface und die 4 in ITest)

[littleDave]

@himi: ich habe mir deine Sachen zu den Interfaces noch nicht angeschaut, aber trotzdem sage ich schonmal danke: PInterfaceTable könnte helfen


Zur später Stunde noch ein Update :arrow: Version 0.5.1.0

• Neuerungen
  • Methoden, die über Methoden-Pointer aufgerufen wurden, sind jetzt ebenfalls im Stack-Trace sichtbar
  • Nun können auch beliebig verschachtelte Records mit der Host-Anwendung ausgetauscht werden
  • Es gibt eine neue "Methode" im Script: sizeof(): Gibt die Anzahl der Bytes aus, die ein Objekt belegt (geht nur mit Typennamen - also sizeof(TPoint))
  • Neue Methode: System.TDateTime.UtcNow (Universal Time) [nur Delphi]
  • Neues Record: System.TTimeSpan: zum Setzen, Bearbeiten und komfortablen Auslesen von Zeitdifferenzen (führt auch noch ein paar Helper-Methoden für TDateTime ein, damit das ganze noch einfacher zu Benutzen ist)
  • Neue Klasse: System.TimeZone: zum Auslesen der aktuellen Zeitzone [nur Delphi]
  • Die bisherigen Helper-Klassen für die Basis-Typen erweitert
• Änderungen
  • Die interne Ausrichtung von Records im Speicher geändert (daher auch Punkt 2 unter Neuerungen)
  • Interne Record-Verwaltung sehr beschleunigt
  • Compilerhinweis zu "Variable ist deklariert, wird aber nicht benutzt" verbessert
  • Byte-Code-Optimizier im Linker etwas erweitert
  • Finalization-Teile der benutzen Units werden jetzt in umgekehrter Initialiserungs-Reihenfolge angearbeitet
• Bug-Fixes
  • Kritischer Fehler bei der Script-RunTime-Type-Information behoben
  • Problem beim finden von Identifiern mit zusätzlichen Unit-Namen behoben (nur verschachtelte Unit-Namen waren unter bestimmten Umständen betroffen)
  • Kleiner Fehler in der Methode "System.DateTime.EncodeDateTime" behoben
  • Kritischer Fehler im Unit-Cache behoben: der finalization-Teil einer Unit wurde zum Initialization-Teil hinzugefügt
  • System.EAccessViolation hatte eine falsche Elternklasse im Script

Der Download befindet sich wie immer im ersten Post ( - oder im SVN)

Grüße

[Dolvik]

Hallo littleDave!

Mal ne Frage. Bei welcher Version glaubst du, dass du Arrays implementiert haben wirst und wie lange schätzt du, bis diese Version veröffentlicht werden kann?

Dolvik

[littleDave]

Das Problem mit arrays ist halt: ich brauche sie im Moment nicht. Daher ist es für mich schwer mich dazu zu überwinden, arrays einzubauen. Zumal man mit TList etwas Ähnliches bekommen kann. Ich kann leider nicht sagen, wann ich arrays einbauen werde. Ich baue lieber Sachen ein, die ich gerade brauche. Natürlich will ich auch irgendwann arrays unterstützen, (da ich jedoch kein großer Fan von arrays bin), dauert das leider noch etwas. Ich welchem Zeitraum kann ich leider auch nicht sagen. Ich habs ja schon mal Versucht indem ich Version 0.5 gesagt habe *hust*. Daher will ich jetzt nicht v0.6, v0.7, v4.0, etc sagen und den gleichen Fehler nochmal machen. Hoffe, dass das etwas nachvollziehbar ist.

Weil ich gerade dabei bin, mach ich mal etwas Werbung für die nächste Version ;-)
In der nächsten Version, die bald kommen wird, kann man Multi-Threaded-Scripts erstellen - also eigene Threads im Script erstellen und ausführen. Dafür muss man den Delphi-Quelltext nicht anrühren. Es wird dabei Ähnlich wie in Delphi sein: man muss eine Klasse erstellen, die von einer bestimmten Klasse abgeleitet werden muss. Dort muss dann nur die Execute() - Methode überschrieben werden und fertig. Das ganze schaut dann so aus:

Delphi-Quellcode:

program Test;

uses
  System.Threading;

type
  TMyTest = class(TExecutionContext)
  protected
    procedure Execute; override;
  end;

procedure TMyTest.Execute;
begin
  TThread.Sleep(1000);
end;

var Context   : TMyTest;
    Thread    : TThread;
begin
  Context := TMyTest.Create;
  try
    Thread := TThread.NewThread(Context);
    try
      Thread.Start;
      while not (Thread.State = ThreadState.Finished) do
        { irgendwas } ;
    finally
      Thread.Free;
    end;
  finally
    Context.Free;
  end;
end.

Ist zwar noch nicht final, aber funktioniert schon super. Habe zum Test mal eine Primzahl-Berechnung auf 15 Threads aufgesplittet und hab die Ausführungszeit halbieren können (Dual-Core halt ;-)). Wie gesagt, ist noch nicht fertig, daher dauert das noch ein wenig - jedoch nicht mehr lange ;-)

Gruß

[Dolvik]

Hallo littleDave!

Nein ist überhaupt kein Problem, wenn man keine arrays hat. Hab nur das mit v0.5 mitbekommen und wollte wissen ob das noch in der beta-Phase ist oder ob es hinausgeschoben wurde.

Multithreading klingt interessant :) Freu mich schon aufs Testen.

An was arbeitest du denn gerade für einem Projekt, das die SE2 miteinbezieht?

Dolvik

[littleDave]

Ich arbeite seit längerem an einer 3D-Engine auf OpenGL-Basis. Die Engine an sich ist in Delphi geschrieben, die komplette "Spiellogik" wird dabei von der Script-Engine übernommen. Also vom einfachen Einschalten einer Lampe bis hin zur (späteren) KI- und Spielersteuerung. Die Engine benutzt fast ausschließlich Shader - komplett dynamisches Per-Pixel-Lighting, Realtime-Shadows, Bump/Parallax-Mapping, Depth-of-Field, Deferred Shading, usw. Das ganze ist für relativ starke PCs ausgelegt, daher leiste ich mir auch den "Luxus", die Spiellogik nicht nativ sondern mit der Script-Engine zu realisiern. Da ich SE2 schon ziemlich stark optimiert habe, ist der Performance-Verlust nicht so tragisch.

Hier mal zwei YouTube-Videos: 1. und 2. (falls es dich interessiert)

Gruß

[Dolvik]

Hallo littleDave,

Ist echt gut gemacht! Das die Scriptengine das so schnell hinbekommt hätte ich nicht gedacht. *respekt*
Bin mal gespannt, wie die finale Version des Spiels aussehen wird.

Ich wünsch dir weiterhin viel Glück und gutes Gelingen.

Dolvik

PS: Erstaunlich was du alles schaffst: SE1, SE2, Widgetengine, ImageViewer, Spiel. Übernimm dich nicht ;)