Author Archives: Jon Lennart

Smart Mobile Studio now supports helper objects for various elements, including classes, records and arrays. Helper’s are extremely valuable in leveraging complex data-structures. This is a very powerful addition to Smart’s already impressive list of “must have” features when working with javascript. Features that no existing javascript framework or utility provides.

Here is a small taste of how you can use a helper object to enrich something as simple as an array of TPoints. These are pure “trig” rotations (just one way of doing it).

[sourcecode language=”delphi”]
unit w3polygons;

interface

uses w3system;

type

TPolygonHelper = helper for TPointArray
Procedure Rotate(const angle:Float;const centerX,centerY:Float);
Procedure Scale(factor:float;Const centerX,centerY:Float);
End;

Implementation

procedure TPolygonHelper.Rotate(const angle:Float;
const centerX,centerY:Float);
var
i: integer;
r,p: Float;
begin
if self.Length>0 then
Begin
for i:=self.low to self.high do
begin
r:=sqrt(sqr(self[i].X – centerX) + sqr(self[i].Y – centerY));
p := angle + arcTan2(self[i].Y – centerY, self[i].X – centerX);
self[i].x:=Round(centerX + r * cos(p));
self[i].y:=Round(centerY + r * sin(p));
end;
end;
end;

Procedure TPolygonHelper.Scale(factor:Float;
Const centerX,centerY:Float);
var
i: integer;
r,p: float;
begin
if self.length>0 then
begin
for i := self.low to self.high do
begin
r:= factor * sqrt(sqr(self[i].X – centerX) + sqr(self[i].Y – centerY));
p:= arcTan2(self[i].Y – centerY, self[i].X – centerX);
self[i].X := Round(centerX + r * cos(p));
self[i].Y := Round(centerY + r * sin(p));
end;
end;
end;

end.

[/sourcecode]

Here is a fun graphical effect. Start a new game project and paste in the following code (remember to keep the unit name). The effect is known as Archimedes spiral, although we play with the numbers to create a strobe like effect.

The numbers of life

[sourcecode language=”delphi”]
unit ArchSpiral;

interface

uses w3system, w3components, w3ctrls, w3application,
w3game, w3gameapp, w3graphics, w3components;

type
TApplication = class(TW3CustomGameApplication)
private
{ Private methods }
FaValue: Float;
FbValue: Float;
protected
{ protected methods }
procedure ApplicationStarting; override;
procedure ApplicationClosing; override;
procedure PaintView(Canvas: TW3Canvas); override;
end;

implementation

procedure TApplication.ApplicationStarting;
begin
inherited;

FaValue := 5.0;
FbValue := 1.0;

//Initialize refresh interval, set this to 1 for optimal speed
GameView.Delay:=20;

//Start the redraw-cycle with framecounter active
//Note: the framecounter impacts rendering speed. Disable
//the framerate for maximum speed (false)
GameView.StartSession(true);
end;

procedure TApplication.ApplicationClosing;
begin
GameView.EndSession;
inherited;
end;

// Note: In a real live game you would try to cache as much
// info as you can. Typical tricks are:
// 1: Only get the width/height when resized
// 2: Pre-calculate strings, especially RGB/RGBA values
// 3: Only redraw what has changed, avoid a full repaint
// The code below is just to get you started

procedure TApplication.PaintView(Canvas:TW3Canvas);
var
cx,cy: Float;
i: Integer;
angle: Float;
x,y: Float;
begin
fbValue := fbValue + 0.0009;

// Clear background
Canvas.FillStyle := ‘rgba(0,0,99,0.3)’;
Canvas.FillRectF(0, 0, GameView.Width, GameView.Height);

// Draw our framerate on the screen
Canvas.Font := ’10pt verdana’;
Canvas.FillStyle := ‘rgb(255,255,255)’;
Canvas.FillTextF(‘FPS:’ + IntToStr(GameView.FrameRate),10,20,MAX_INT);

cx := GameView.Width div 2;
cy := GameView.Height div 2;
Canvas.MoveToF(cx,cy);
Canvas.BeginPath;
for i := 0 to 719 do
begin
angle := fbValue * i;
x := cx + (FaValue + FbValue * angle) * cos(angle);
y := cy + (FaValue + FbValue * angle) * sin(angle);
Canvas.LinetoF(x,y);
end;
Canvas.StrokeStyle := ColorToWebStr(clWhite);
Canvas.Stroke;
end;

end.
[/sourcecode]

Demo and code

You can download the project source code here: ArchSpiral.zip

You can find an online demo here: ArchSpiral demo

(Or simply scan the QR code below with your phone)

I have no reason for this picture

I finally took the plunge and decided to really give the RTL a makeover. I was supposed to wait until Smart v1.1 with this, but releasing a product only to alter the RTL radically later would be unfair to our customers. Better to put in place a foundation that wont break the codebase later and that we can build on. So for the past 5 days I have edited every single method and class in the RTL’s foundation. But for what you say? Why fix what already works?

One of the hidden gems that my buddy Eric added to the compiler, is that we have direct access to the real javascript objects. You might have noticed that we used to keep a reference to the actual HTML Tag by use of TObject? In the older (and current) API all visual components have a property called tagRef. The problem was – this reference was both slow and dangerous. If you try to call any of it’s methods the app will crash, because it points to the real javascript handle and not our virtual method table.

Using a TObject reference also meant a greater speed penalty, since you had to typecast and test in a variety of ways before you used it. But now, all that is a thing of the past. The tagRef property has been completely removed from the RTL and has been replaced by a proper THandle. What is the fuzz about? Well, this property IS the actual javascript object. So, Eric in his infinite wizdom added support for magic stuff like:

[sourcecode language=”delphi”]
Self.Handle.style[‘backgroundColor’]:=clRed;
[/sourcecode]

What happens here is that you are accessing the javascript object directly, with nothing in between (!). As you can imagine, this gives us a tremendous advantage in speed over other solutions. It also means that the compiled code will be smaller, more efficient – and most importantly, easy to maintain. So now you can interact directly with the native DOM elements without an ASM section.

Speed injection

An example of just how much extra juice we managed to squeeze out of the browser with this rewrite, can be demonstrated by the “plasma” graphics demo we posted earlier (donated by a tester). Under the older RTL it rendered 120.000 pixels (manually plotted into the HTML5 graphics context via R,G,B,A) at roughly 4 frames per second on an iPhone 4S. That is extremely slow (but considering the amount of calls involved, im surprised we got 4 frames at all). After I ejected the use of tagRef and re-wrote parts of the w3graphics.pas unit, I now get 11 frames per second. Please remember that this extremely fast for a scripting engine, being able to draw 120.000 * 4 bytes eleven times a second. On my iMac it runs at a decent 80 FPS, which is even more impressive.

And this is just for starters. To keep the RTL backwards compatible I have retained the functions in w3system.pas (things like w3_setStyle, w3_setAttrib and so on), which means there are actually thousands of calls being made that are now redundant. It will take a lot of energy to get rid of them by Monday – but when I decide on something I never quit until it’s done.

Structure helpers

Following up on Delphi’s introduction of record functions, I have stripped the older functions for making and working with TRect, TRectF, TPoint and TPointF – and instead placed them directly in the record itself. This is much more uniform and leaves little doubt where a function should be (so new users dont have to wonder what unit function X resides in). Here is the interface for TRect as of writing. More and more functions will be added, but this is the “bare bones” i guess:

[sourcecode language=”delphi”]
TRect = Record
Left:Integer;
Top:Integer;
Right:Integer;
Bottom:Integer;
function Width:Integer;
function Height:Integer;
function toString:String;
function topLeft:TPoint;
function BottomRight:TPoint;
function Clip(Const RectToClip:TRect):TRect;
function Empty:Boolean;
function NullRect:TRect;
function Compare(Const aRect:TRect):Boolean;
function ContainsRow(Const aRow:Integer):Boolean;
function ContainsCol(Const aCol:Integer):Boolean;
function ContainsRect(Const aRect:TRect):Boolean;
function ContainsPos(Const aLeft,aTop:Integer):Boolean;
function ContainsPoint(Const apoint:TPoint):Boolean;
function Intersect(Const aRect:TRect;var intersection:TRect):Boolean;
function Expose(const aChildRect:TRect):TExposure;
function Make(Const aLeft,aTop,aWidth,aHeight:Integer):TRect;overload;
function Make(Const aWidth,aHeight:Integer):TRect;overload;
function MakeAbs(Const aLeft,aTop,aRight,aBottom:Integer):TRect;
End;
[/sourcecode]

FireFox support

The first version of Smart Mobile is designed exclusively for webkit, which means Safari mobile (iPad, iPod, iPhone), Android and equivalent desktop browsers. So little or no effort has gone into making Smart apps run on Opera or FireFox. But with some tweaks I now have a Sprite3d App running under FireFox as well 🙂

The bootstrap code (the section of code that initializes and starts your application) has been altered to include a browser check. So now it checks what system you are running and cache’s known style-prefixes and other information. The magic function that will make all the difference is called “w3_CSSPrefix”. This will help make your CSS calls “universal”. So where you would previously have written:

[sourcecode language=”delphi”]
w3_setStyle(handle,’webkitTranslate’,F3dState);
[/sourcecode]

You can now make it run on all browsers by changing it to:

[sourcecode language=”delphi”]
w3_setStyle(handle,w3_CSSPrefix(‘Translate’),F3dState);
[/sourcecode]

Hardware accelerated animations and events are a bit crappy on FireFox at the moment (in terms of commonalities), for instance their “animation end” event don’t fire as it’s supposed to, and it also deviates from the naming convention used elsewhere. So mozAnimationEnd wont do. I’ll have to come up with a solution for that. But full FireFox support wont happen until later. But you can prepare your app for universal support by using the w3_cssPrefix function.

API drivers

The only way to fully maximize the potential of all platforms is to create a common ground, but one that is rich enough to cater for a browser’s unique features. As such, I have decided to create a driver system to solve the browser compatibility problems once and for all. This is currently being prototyped but should make it into Smart v1.5 probably. In short you  have a basic class with functions for getting the correct style names (and more) for the current browser. The driver will also contain functions to examine device capabilities (is camera supported, is database supported, is orientation supported, touch, sound formats, image formats — the whole multimedia spectrum). When your app starts, the browser will be recognized – and the appropriate driver created. The RTL will then reference the driver to get the correct properties to set.

As a bonus, anyone can write a new driver should a different browser appear on the marked. And should there be changes, you simply update the driver rather than every n’th class or method in the RTL.

The javascript punters are going to go “whaaat? how did they do that?”. Easy, object pascal 🙂

Wow – I would never have thought so many people would download the beta! Or should I say alpha. It really was a disaster to find out that the auto-complete on monkeynews replaced our new 0.5.x build zip-name with the older alpha zip-name. So almost 100 people downloaded the wrong zip. Thankfully we corrected it, so the wast majority of users got the right version.

So please double-check: If the title of the IDE does not say “build 0.5.x” then you must go to your email (we issued a correction message) and download the beta version! I have been cursing since friday because of that mistake.

Make sure your copy have this title

Although this blunder put a shadow over the whole release experience, the weekend ended as a small victory due to all the positive feedback we got (obviously from people who got the right download link). My personal favorite was “It bloody works! Awsome!”. That comment made my day 🙂

Ok let’s wrap it up

I am happy to say that a huge chunk of the proposals and bugs have been fixed. I have also started on smarting up the IDE a bit, so right now I’m adding the final touches to “CTRL + CLICK” functionality like we have in Delphi. It already recognizes unit-names, class-names and method-names from the entire RTL – so it looks good. Not sure how to get synEdit to play ball though, but i’ll find a way.

So all in all we have the following chores left:

• Finish the designer with common editing functions
• Finish the globals editor
• Get rid of the buggy synEdit search/replace dialogs (!)
• Write property editors for font, border etc. so they show up in the inspector

As far as the RTL goes I have a couple of items on my list:

• Global key hook for full screen apps
• Add code donated by friends to the RTL (gestures, sound-api etc.)
• Speed fixes, better error management and more compile options (css as external file etc.)

And that’s basically it for version 1.0 in terms of features. So it’s time to tie up the last lose ends, double, triple and quad check everything – and then it’s done.

The future

• Databases and datalists
• Support all browsers
• webGL

Paying customers will receive updates sequentially (which includes IDE enhancements, new units, updates to the RTL, platform files and compiler updates) of-course. I already have around 200 items on my “must add” list for version 1.1 (including support for remobjects services) so don’t think we will be resting on our laurels 🙂

Datalists is really going to surprise you. It’s actually very close to the old TDataset terminology (I will probably call it TDataset to make it more familiar).

Jai Jai Ganesha!