Why Xojo?

Why do I use Xojo?

When talking to my peers in the software industry and they ask what I primarily use for application development, I get a number of reactions when I tell them Xojo. At first I normally get a response that indicates that they have never heard of Xojo. After explaining what it is, the next question is "why not use the standard tools, such as Objective-C for OS X or Visual C++ for Windows?".

In order to answer these questions, let me first give you. Brief history as to how I discovered Xojo. 

When I switched to a Mac, back in 2006, I had come from a Delphi development background. I had just spent the last three years using nothing but Delphi for virtually all of my software. However, making the switch from Windows meant that I needed to find a new development system. At the time, I was not aware that OS X came with developer tools (possibly it didn't, but I'm not sure). So I started to look for a Delphi equivalent for Mac. That led me to Lazarus, the FreePascal IDE that was purportedly cross platform. Unfortunately, at that time, Lazarus required X11 to be installed for OS X, not only for development, but also on the target machine. This was not really acceptable to me, so I moved on. 

My next find was RealBasic. Having also worked with Visual Basic in the past, I was intrigued by this system. RealBasic was supposed to be cross platform, using native controls and allowed for rapid development. I could write on a Mac and compile for Linux, Windows and Mac without the need to use a non-Mac computer. So, I bought a licence.

RealBasic has since been renamed, twice: Firstly to RealStudio, and now Xojo.

Since then, I have also brought my skills for Objective-C and, Apple’s new language, Swift up to date and can comfortably use these. Lazarus has also ditched the requirement for X11, so that is no longer an issue for me.

So why am I still using Xojo?

I think the best way to explain would be to list the pros and cons, that I have discovered, regarding the language:

Cons:

• It is not free. Unlike Xcode (for Swift and Objective-C) and Lazarus, Xojo is not free and requires the purchase of a license for development (rather, I should say, for distribution, Xojo, Inc do allow you to download the IDE for free and program away, but to create stand alone binaries, you do need a license).
• It is slow. Actually, that’s not a really fair statement. What I should say, is that applications written in Xojo do not perform as quickly as application written with the official tools. However, most of the time, that is not an issue, the only time I have encountered a problem with speed was with a very graphic intensive application.
• It’s not as widely supported. As it is not one of the more common languages out there, resources can be a little difficult to find.
• Not all platform features are supported. This needs qualifying. Not all platform features (Windows, OS X or Linux) are supported “out of the box”. However, Xojo does allow access to the platform API’s. Which does bring me on to my next point…
• Xojo, Inc are always playing catchup. This does seem like an odd thing to say, but it is true. As this is a third party development system, the Xojo team can only address new features AFTER they are announced. 
• Fiddly submission to the Mac App Store. With Xcode, I can submit apps to the App Store with very few clicks. However, to do this with Xojo, I either need to go to the command line, or use a third party tool, such as App Wrapper.

That’s a few cons, and for some people it might be enough to turn them away from Xojo. But now we get to the pros:

Pros:

• Cross platform development. Even though I mainly develop for OS X, having the ability to recompile the same source for Windows or Linux is a blessing. I have even been commissioned to write a Windows application in the past, all of which (besides final testing) was done on my Mac.
• Native controls. Whether you are on Mac, Windows or Linux, Xojo will mostly use native controls. There are some that are not (e.g. Listbox), but most of the time, it is very hard to see any difference.
• Fantastic community. I know I mentioned in the cons about the difficulty in finding resources, however, when you do find those resources, they are normally excellent and well supported. Not to mention the very active, and friendly, Xojo forums.
• API access. As I stated above, Xojo allows you access to all the API’s of the operating system. On OS X, this includes the frameworks. Whilst it can be fiddly, it can be done.
• The debugger is easy to use. I know this is an odd “pro” to include, but after having used the Xcode debugger for a couple of projects, I have really come to appreciate the Xojo debugger.
• Rapid development. I can create an application in a couple of days that could potentially take me a week in other languages.
• Easy to understand. Whilst I know that BASIC is not everyone’s cup of tea, and I also know that some still see it as a “toy” language, I find the syntax very easy to read. This is also one of the reasons I used to use Delphi over C++, it’s just easier to read, and therefore debug.
• Xojo promotes good programming. What? How did that get here? But it’s true. Because there are times when an algorithm can be very processor intensive, this can slow the application down. I addressed this in the past by re-writing apps in Objective-C, however, with some careful planning and clever coding, Xojo can perform the required tasks at the required speed. So in this way, it does promote better programming.

That’s just a few of the pros and cons. I could list a lot more, and I am sure I have missed some that other Xojo users would have included. In my opinion, most of the cons can be negated by programming techniques, careful planning, or (in the case of App Store submission) inexpensive third party applications.

I know that Xojo is not for everyone. There are times when I will use Swift or Objective-C for a change, but it is a very useful tool that shouldn’t be overlooked in the industry.  

The upshot is if the end application works and does what it’s supposed to, does it matter what language is used?

Yet another in house tool created

Not been long since my last post, but I thought you all might like to know about my newest in house tool that will save me a lot of time in the future.
First of all, the reasoning behind it: both Monkey and BlitzMax have the facility to import animation strips for using with your sprites. These are images which hold all the frames of a particular animation, so that you can load them at once, rather than having to load multiple images, which is a lot slower.
The concept behind it is dead easy, each frame of the animation has the same height and width, and therefore, the image is easy to break up into the individual frames as the animation progresses. The downside of this is the time it can take to manually create an animation strip, particularly if you have a lot of frames, it is not uncommon to use 15 separate frames just for walking in a single direction. Below is an example of the animation strip I used when I created Mr Wong's Loopy Laundry:

As you can see, there are 59 frames to animate Mr Wong. I created this by hand and it took quite a time.

So, to help ease this process, I have written a small program I call Image Stitcher. I guess you could call it the sister program of Image Slicer. What it allows me to do, is import each of the frames, select the output height and width of the frames (in case I decide to enlarge or shrink them), the drawing style (scaled - maintaining aspect ration, stretched or cropped) and the number of columns in the animation strip. This is then exported as a single image, like the one above.

As you can already see, this is a massive time saver, that will hopefully save me hours of work.
As with my other tools, it was written with Xojo.

Wow! Seems like months since I last posted anything here.

Oh, wait. I HAS been months!

So, what have I been up to in the world of programming?

Well, I have begun work on some new games under the Krazy Pengwin Games label. I'll post some more news about them soon.
I have switched game development language to Monkey. This is also by Blitz Research, in fact, it can be seen as the little brother to BlitzMax, but it has a neat little trick that BlitzMax did not. Whereas BlitzMax was cross platform, allowing me to compile to Mac, Windows and Linux, Monkey goes even further. With a single source project, I can create games for, not only the desktop operating systems, but also for Android and iOS. Monkey also supports XNA, but I'm not too interested in publishing to that platform right now. So the upshot is, the games I am working on will also be available to mobile user, firstly Android, but hopefully iOS by the end of the year.
I'm still using RealStudio (now called Xojo) for in house tools, but not much in the way of commercial applications. Once my new web site is up and running, I will be making some, if not all, of these tools available for free download.
Well, that's it for now, so just watch this space for details of new games and stuff.

Image files in Virtual Volumes

In  a recent Real Studio project, I realised that I needed to save image files with a Virtual Volume. At first, I didn't give this any thought, I proceeded with my normal way of saving and loading the images. Little did I know at that time, but images cannot be saved in this way when using a Virtual Volume, so I needed to come up with a new method.
The best way I discovered to accomplish this is using a MemoryBlock as an intermediary class. Fortunately, the Picture class has a method called GetData and a shared method called FromData that allow us to transfer the image to and from a MemoryBlock.
So armed with this information, I first created a new save routine. I decided to extend the Picture class to help keep things neat:

Sub SaveToVirtualVolume(Extends MyPicture As Picture, file as FolderItem, format As String="public.png", quality As Integer=Picture.QualityDefault)

  'Create a new memory block with the data from the Picture class
  Dim m As MemoryBlock=MyPicture.GetData(format,quality)

  'Open a binary stream to the file, overwriting it if the file already exists
  Dim s As BinaryStream=BinaryStream.Create(file,True)
 
  'If the binary stream has successfully been opened, write out each 
  'byte from the memory block to the binary stream
 if s<>Nil then
    Dim Index As Integer=0
    while Index<m.Size
      s.WriteByte(m.Byte(Index))
      Index=Index+1
    wend
    s.Close
  end if
End Sub

As I normally use the PNG file type for images, I created this method to default to PNG should I not specify a format.
To read the image back from the Virtual Volume, I created a stand alone function, so that if the load failed, it would return a Nil object:

Function LoadImageFromVirtualVolume(file As FolderItem) As Picture
  'Create a new picture object to receive the image file
  Dim MyPicture As Picture

  'If there is a problem with the file passed to the
  'function, we should not attempt to load the image, 
  'and just return a Nil object
  if file<>Nil and file.Exists and not file.Directory then

    'Open the file as a binary stream and load it into a 
    'memory block that we create to hold the contents of the file
    Dim s As BinaryStream=BinaryStream.Open(file)
    if s<>Nil then
      'Create the new memory block with a size that matches the files contents
      Dim m As MemoryBlock=New MemoryBlock(s.Length)
      Dim Index As Integer=0
      while not s.EOF
        m.byte(Index)=s.ReadByte()
        Index=Index+1
      wend
      s.Close

      'Now simply use the FromData shared method to create 
      'the Picture object from the memoryblock contents
      MyPicture=Picture.FromData(m)
    end if
  end if

  'Return the object that is now either nil or the loaded image
  Return MyPicture
End Function

This is a very rough and ready way to accomplish what I am after, but now, when I have an image I need to save in a Virtual Volume, I simply use:

   MyImage.SaveToVirtualVolume(file)

or if I wish to save a JPEG, I could use:
   MyImage.SaveToVirtualVolume(file,Picture.FormatJPEG,Picture.QualityHigh)

To load an image back in from a Virtual Volume, I would use:

  MyImage=LoadImageFromVirtualVolume(file)

If the load was successful, then the variable MyImage would now contain the picture loaded, otherwise it would contain Nil.

Hope this is of some help to anyone who also encounters this minor oddity.

Debugging tips - continued

After my post about the excellent tutorial by Thomas Tempelmann (previous post), I decided to play around with a simple profiling class. I have commented the source, so it should be fairly self explanatory, but I will explain how to use it after the source code:


Class Profiler

    Sub Constructor(name as String)
  
        ' This should only be executed in debug mode
        #if DebugBuild

            ' First create the indent string, this will save time later on

            mIndent=""
  
            Dim Index As Integer=0
            While Index<mDepth
                mIndent=mIndent+"    "
                Index=Index+1
            Wend
  
            ' Store the name of the method
            mName = name
  
            ' Increase the indent depth for the next instance
            mDepth=mDepth+1
  
            ' Display the 'Entered" method
            System.DebugLog mIndent + "<"+name+"> Entered"
  
            ' Store off the time the constructor finished creation.
            ' We do this at the end of the constructor so that the rest of the 
            ' constructor has minimal impact on the time calculations
            mStart=Microseconds

        #EndIf

    End Sub

    Sub Destructor()
        

        ' This should only be executed in debug mode

        #if DebugBuild

            'Calculate the time the methhod took to execute
            'This is done straight away for a more accurate value
            Dim ExecTime As Double=Microseconds-mStart
  
            'Display the "Exited" message and the execution time of the method
            System.DebugLog mIndent + "<"+mName+"> Exited"
            System.DebugLog mIndent + "<"+mName+"> Execution Time = " + Str(ExecTime) + " Micro Seconds"
  
            'Reduce the indent depth for the next instance
            mDepth=mDepth-1
        
        #Endif

    End Sub

    Private mIndent As String
    Private mName As String
    Private mStart As Double

    Private Shared mDepth As Integer

End Class


To use this class to see how well your methods perform, all you need to do is place the following line at the beginning of the method you wish to test:

Dim p As New Profiler(MethodName)

Replace MethodName with the name of your method.

As the instance of the class is destroyed when it goes out of scope, there is not need to call manually call a destructor.

Now, whenever the method is executed, it will send entries to the system log.
On OS X, these can be viewed in the Console and should look something like this:


15/05/2012 17:58:05 [0x0-0x91091].My Application.debug[4452] <BevelButton Action> Entered 
15/05/2012 17:58:05 [0x0-0x91091].My Application.debug[4452]     <Test> Entered 
15/05/2012 17:58:05 [0x0-0x91091].My Application.debug[4452]     <Test> Exited 
15/05/2012 17:58:05 [0x0-0x91091].My Application.debug[4452]     <Test> Execution Time = 12 Micro Seconds 
15/05/2012 17:58:05 [0x0-0x91091].My Application.debug[4452]     <Test> Entered 
15/05/2012 17:58:05 [0x0-0x91091].My Application.debug[4452]     <Test> Exited 
15/05/2012 17:58:05 [0x0-0x91091].My Application.debug[4452]     <Test> Execution Time = 11 Micro Seconds 
15/05/2012 17:58:05 [0x0-0x91091].My Application.debug[4452] <BevelButton Action> Exited 
15/05/2012 17:58:05 [0x0-0x91091].My Application.debug[4452] <BevelButton Action> Execution Time = 141 Micro Seconds 

Note, the method Test was called from within BevelButton Action, therefore, the log is indented automatically for readability.

As a little side note, I have used conditional compilation, so that the log entries are only generated if the application is executed from within the Real Studio IDE, this means that it would be safe to leave the calls in when deploying the application, however, it would be better if they were removed before release.

If you wish to download this class, I have made it available here.

Project Templates

A number of my Real Studio projects have required me to add things such as a Windows menu, for the open windows in a project, and a "Open Recent" menu.
Now while it isn't a bother to create these for each project, I began to think that there must be a better way to spend my time, rather than coding the same thing over and over.
Fortunately, Real Studio allows the use of project templates. In fact, any Real Studio user has already seen the project templates when they start up Real Studio. But what may not be apparent is that you can also add your own templates. It is a very simple process:

1. Create your skeleton project
2. Save it in the Project Templates folder within the Real Studio folder

And that is it.

What I have now done, is created some extra projects templates for some common scenarios I come across. I would also be possible to add things such as About windows, or even a skeleton Settings window. If you find yourself using the same custom controls repeatedly (like I do with my own NumberEdit control), then simply create a default project containing the controls and save it in the Templates folder.
I would, however, recommend not changing the existing projects. There may be a time when you need the bare bones that Real Studio offers you, but that is not a problem. As far as I can tell, the IDE will allow as many project templates as you would like.

Here is a quick shot of the Real Studio New Project window on my Mac to demonstrate this. I have highlighted my custom project templates:

Display List Editor Finished

The Display List Editor is now complete. Users can visually design a display list and then at the click of a button, save it for later use, insert it directly into the source, preview it or copy the generated code to the clipboard.

This should help Atari developers, particularly those who are starting out with coding custom Display Lists.

I still have to add some extra functions in the main program itself regarding this editor, but the will also impact on other areas. One of the functions I want to add is a drag and drop functionality that will allow resources to be dragged from the Project Manager directly into the source. If that item being dragged is a binary file (character set or player missile set), then a binary include function will be inserted into the source. However, because it is not as straightforward to include the display list as a binary source, if you drag the Display List file into the source, then the program will decode the display list and embed the actual source code of the display list into the program source file. Dragging a normal source file into the source will generate a source include function to be inserted.

Hopefully, this will make things that little bit easier for people.

I have also managed to reduce most of the flicker issues I was getting in the Windows version of the IDE. This means that as I am coding this in Real Studio from RealSoftware, I should be able to release the Windows version at the same time as the OSX version.

I have been receiving a lot of positive feedback from the AtariAge community regarding this project, and it is great to see people taking an interest. I am also getting a number of suggestions to help improve the IDE, some of which I have included into the Display List Editor. Some these include an editor to allow the user to edit BASIC files and the facility to export the resources for other languages (such as C, Action!, Quick, etc.). I am excited about putting these functions in, however, I would like to get this to at least beta release by the end of next month, so some of the suggestions may have to wait until version 2, and if the reception the program gets is as good as I think, then there will definitely be a version 2.