Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Next revision
Previous revision
Last revisionBoth sides next revision
tipsandtricks [2019/08/28 20:10] – created admintipsandtricks [2019/10/03 14:08] – [Threading] admin
Line 15: Line 15:
  
 Use as few bones as possible. Use as few bones as possible.
-A bone hierarchy in a typical desktop game uses somewhere between fifteen and sixty bones. The fewer bones you use, the better the performance will be. You can achieve very good quality on desktop platforms and fairly good quality on mobile platforms with about bones. Ideally, keep the number below thirty for mobile devices, and don’t go too far above thirty for desktop games.+A bone hierarchy in a typical desktop game uses somewhere between 15 and 60 bones. The fewer bones you use, the better the performance will be. You can achieve very good quality on desktop platforms and fairly good quality on mobile platforms with about 16 bones. Ideally, keep the number below 30 for mobile devices, and don’t go too far above 30 for desktop games.
  
 ==== Polygon count ==== ==== Polygon count ====
  
 The number of polygons you should use depends on the quality you require and the platform you are targeting. For mobile devices, somewhere between 300 and 1500 polygons per mesh will give good results, whereas for desktop platforms the ideal range is about 1500 to 4000. You may need to reduce the polygon count per mesh if the game has lots of characters on screen at any given time. The number of polygons you should use depends on the quality you require and the platform you are targeting. For mobile devices, somewhere between 300 and 1500 polygons per mesh will give good results, whereas for desktop platforms the ideal range is about 1500 to 4000. You may need to reduce the polygon count per mesh if the game has lots of characters on screen at any given time.
 +
 +===== Changing Position, RotationAngle or Scale =====
 +
 +Changing one of the transformation settings or visual properties of a 3D scene object initializes rendering implicity.
 +So, when you're manipulating more than one object or property this could lead to very bad performance.
 +
 +Therefor we need some way of grouping those operations and to prevent FMX from updating each time.
 +
 +Due to that, GorillaViewport provides the BeginUpdate() and EndUpdate() methods.
 +Encapsulate your transformations to increase performance.
 +
 +<file pascal>
 +procedure TForm1.Timer1Timer(Sender: TObject);
 +begin
 +  GorillaViewport1.BeginUpdate();
 +  try
 +    GorillaCube1.RotationAngle.Y := GorillaCube1.RotationAngle.Y + 5;
 +    GorillaSphere1.Scale.Point := GorillaSphere1.Scale.Point + Point3D(0.1, 0.1, 0.1);
 +  finally
 +    GorillaViewport1.EndUpdate();
 +  end;
 +end;
 +</file>
 +
 +===== Threading =====
 +
 +It is not uncommon to use a thread to compute visual property values. But because FMX (and also Gorilla3D) only runs in main thread, we need to synchronize somehow.
 +
 +Synchronization needs to be threadsafe, so everyone uses TThread.Synchronize(nil, DoSync) inside of its thread.
 +That's okey for many applications, but the better way is to use messaging or TThread.Queue(nil, DoSync) for this job.
 +
 +While "Synchronize" blocks the application to force updating with main thread, "Queue" instead updates the app when there is time for. For further information take a look at: [[http://docwiki.embarcadero.com/Libraries/Rio/en/System.Classes.TThread.Queue]]
 +