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?

New Xojo version 2014 r1 Is Out

Good news for Apple developers using Xojo. Version 2014 r1 has been released. This version apparently addresses the Quicktime and QTKit issues when submitting apps to the App store.I have yet to try this myself, but from what I hear, things are working great.
What does this mean for me and Krazy Pengwin Games? Well, this means that I can produce applications in a much tighter time scale. Whilst working directly with Objective-C and Cocoa was an eye opening experience, and one which I surprisingly enjoyed, using Xojo will speed up development ten-fold. There are certain things in Cocoa that I will miss in Xojo (bindings and speed in particular), but I think the speed of development and the ease of code maintenance will outweigh those for most projects, as will the SQLLite integration. I am sure there are times when I will need the speed of native programming, in which case I will go back to Objective-C, but at least, after this learning experience, I have the choice now.

Don't Leave Bad Reviews If...

... the issue can be corrected.
Just wanted to share a recent experience I had with a game I downloaded from the Amazon App Store onto my Kindle Fire.
One of my favourite Facebook games is Monster Busters (I know, I should be working instead of playing games), so imagine my delight when I saw that it was available on the Amazon App Store. Off I went and downloaded it. Whilst downloading, I read the reviews that had already been posted, most of which were fairly negative, because of an issue with logging into Facebook. Still, I’ve read things like this before and not had problems with other apps, so I carried on with the download.
Unfortunately, the comments made were right. The game would not access Facebook, and it needed to in order to sync with my account.
However, rather than leave a negative comment, on what I was sure was a good game, just with a slight issue preventing me playing it, I contacted the makers of the game, PurpleKiwii, and reported the issue. After all, a negative comment can, and does, affect future sales (I know this is a free game, but it’s still not nice to have negative reviews on any of your projects).
The next day, I got a email back from PurpleKiwii, thanking me for my report and letting me know that the issue has now been fixed and available on the Store.
So, what I have to say is, please do not leave negative feedback straightaway if the issue you have is a bug or failing feature. It may be that something beyond control of the developers has changed (I’m not saying that it is the case in this instance, but it is a possibility). It is equally possible that something may work on the developers machine, but for some reason doesn’t work on others. Things DO slip through testing processes from time to time, it’s a way of (developers) life. It is much better to report an issue to the developer and get them to fix it, rather than do without the product all together and leave a review that could impact on the developers future sales.
Anyway, that’s all I have to say, and thank you PurpleKiwii, 10/10 for customer service, but you have now halved MY productivity as I do ‘just one more level’.

Crash Course In Objective-C

Due to Apple’s policies throwing Xojo, inc a curve, I have decided that in order to get some of the smaller applications out I should rewrite them in Objective-C.
I didn’t realise what a steep learning curve this could present.
I have recently released Image Slicer on the App Store, completely rewritten using Apples tools, rather than Xojo. It didn’t take as long as I thought it might, but it was still a challenge, particularly as I have only dabbled with Objective-C before, not really creating anything useful.
The crash course began on Saturday, 25 January, and I was able to submit the initial binary by Monday evening. Unfortunately, I was a bit overzealous with the sandboxing allowances, so it was rejected a couple of days later. But a quick update (and a few other tweaks), and it was submitted again on Wednesday. Two days later, I got the approval email from Apple.
Although this has proven to me that I CAN used Objective-C for my Mac applications, I will probably go back to Xojo after Xojo, inc have addressed the issue preventing apps created in it being accepted by Apple for the App Store, so that I will be able to offer Windows versions as well as Mac versions.

New versions of Image Slicer and Image Stitcher

Been a few months since I last posted an entry here, so I thought I would update everyone with what's been happening in my world.

First of all, Krazy Pengwin Games is now a live venture, with my first game available on the Mac App Store, Google Play and Amazon App Store. The game is Conquest, a remake of an original strategy game from 1983, written by Duncan nightingale. Mr. Nightingale has been instrumental in helping me get this game ready for release, and I am very pleased with the final product. More information about Conquest, as well as links, can be found at http://krazypengwin.com/conquest.php.

I have also revamped two of my most used utilities, to make them easier to use and a little more professional. As soon as I am able, I hope to have these available on the Mac App Store. Until then, here are some screen shots of them:
First the Image Slicer:

Also, the Image Stitcher:

Both of these apps are written in Xojo (formerly Real Studio).

As soon as these are available on the Mac App Store, I will post an update.

New web site is up

I have completely failed to keep you all up to date with the latest development news from me.
A few days ago, my new games development web site went live. Even if I do say so myself, I think it's pretty cool. The entire site is coded by hand (apart from the Lightbox scripts). I prefer to create my own sites this way, so that I have total control over the content, without relying on, or being limited by, a third party content management system.
Anyway, if you want to have a look (and I know you do), then hop on over to: http://www.krazypengwin.com.
Second bit of news, probably not as impressive, but I think it is equally important, I have made some changes to the Colour Code Generator I mentioned before. It is now possible to drag and drop colours from the custom colours to the main colour button, and vice versa. It is also possible to use drag and drop to reorder the colours in the custom section. A little more important, I have added the possibility to drag and drop a colour from the application directly to the source code, and it will insert the colour, in the format selected, into your code. Not a massive change, but it could be useful and save a few seconds, rather than having to click Copy and then Paste. Some more formats have also been added, so the colours can now be formatted for the following languages: Monkey, BlitzMax, Xojo, Cocoa for OS X, Cocoa for iOS, Lazarus (and Delphi), Python, HTML, CSS and as either a list of decimal or hexadecimal values.
This little tool, along with some of the others I have written, will be available from my web site once I have written the help documentation.

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.

New tools

OK, time for another update (already!?).
I have been in the process of developing some in house tools that will help me write the games. I generally create tools as and when I need, or want, them. I could probably go to the App Store and find other peoples versions myself, but I figure, why pay for them, when I can write them. After all, if you are a plumber, you don't call someone in to fix the sink.

So I thought I would show them to you, just so you don't think I've been idly sitting on my arse.

These are obviously jus the icons that our amazing art department (erm... me) created. I shall go through each of these in order.

First up, the Colour Code Generator:

I don't know about you, but I hate having to work out colours and insert them into the source code, or web page. So this little tool allows me to select a colour, using the standard OS X colour selector and it will then display the colour codes in decimal and hex, as well as a source format of my choosing (at present, it will display code for Monkey/BlitzMax, HTML/CSS and Xojo/RealStudio). I can then click copy which will copy the source to the clipboard for pasting into my source code. If I already know the decimal or hex codes, I can enter them manually and it will adjust the colour accordingly. It's a small app, but quite a time saver.

Next, Database Analyser:

This is quite an old tool I wrote some time ago and it is a major headache remover when developing database applications in Xojo.

The analyser will load an SQLLite database file that has been created in the Xojo IDE and kick out the source code required for Xojo to create a new database file on the fly with the same structure. If you have designed quite a large database, this can save you, literally, hours of coding time, converting it to source code.

Font Builder:

Although the Monkey language is ideal for writing cross platform games, one of the areas where it is lacking is font and text support. In fact, it virtually has no font support. So to remedy this, Font Builder allows me to create a PNG image file of the required font and it also exports a definition file that is then loaded into Monkey (using my own custom class) and the font can then be used within the game. But, it is not limited to the standard TrueType fonts that come with a Mac, nor just to those that are downloadable. Because the Builder uses PNG images, it is also possible to create your own fonts, in colour, for your games. This can allow a much more vibrant screen display, without having to create a bunch of extra image files.

Image Slicer:

Working on my current game, I came upon a few limitations in Android that prevented me from using large images effectively. I also noticed that some of the images I was  using were pretty inefficient, memory wise, as there were large areas of transparencies in them. Image Slicer allows me to slice images in a grid pattern of my choosing. I am also able to select which slices are to be exported and which are to be ignored. This way, I can more effectively manage the memory usage of my games and also obtain a few speed enhancements.

Finally, Max Debugger:

I have shown this one before. As I do most of my coding in BBEdit, rather than the Monkey or BlitzMax IDE's, I needed a way to debug my BlitzMax games without having to fire up the IDE. Max Debugger is just that, simply a debugger for BlitzMax games.

I do plan to enhance this further at some point in the future to also act as a debugger for Monkey and to allow remote debugging for multiple platforms.

All these tools were written with RealStudio (I haven't actually upgraded to Xojo yet) and compiled as Cocoa apps.

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.

Bug Fixes and Progression

Well, the IDE has been progressing nicely. Did a bit of testing recently, which should me a number of bugs that had managed to creep in. They have now been thoroughly squished. Most of the pertained to the source navigator, but a couple reared their heads in the actual source editor itself. Nothing major to fix, but they would have been show stoppers in the finished project.

I have been also getting on with the display list editor. This has proven a bit of a challenge, not with the programming itself, but with the design of it. I want to try and create something that is relatively easy to use, whilst at the same time, allowing all possible permutations for the display list. What I have come up with is:

What you can see here is the actual editor. I will explain each section:
Firstly, the table in the top left of the window displays the line types, with various properties. This means that when you are creating your display list, you do not need to worry about adding values to the code to make a DLI or a LMS entry. Even the smooth scrolling flags are taken care of. As you can see by the pop-up window, the antic codes are selected from a list, again meaning that you do not need to remember which code it is you need. (Looking at this right now, I thing I will add additional information in the list, such as pixels/characters per line, etc).
To the right of this, you enter your address for the display list. This can be either an actual address, or a label.
Directly below the address entry, there is a little box to set the display list to one of the predefined BASIC graphics modes. This can be useful if you are going to base your new display list on an existing mode.
At the bottom of the window, we have the preview section. The large rectangle (partially obscured by the pop-up menu) gives a graphical representation of the screen. Each antic mode on the preview is represented by the colours indicated to the right of it. This will allow you to get a quick feel for how the screen is laid out.

Finally, we have the buttons in the bottom right corner. These do the following:
Copy: Copies the completed display list to the clipboard.
Insert: Directly inserts the display list into the current insertion point in the source editor.
Preview: Displays a textual preview of the complete display list.
Close: Closes the window (obviously).
Save: Saves the display list to disk.

One thing I haven’t mentioned, the table also allows you to enter addresses for LMS functions. When copying or inserting the list and an address is found on a particular line, then the Antic Code is automatically converted to an LMS instruction. The software will also append the Jump At Vertical Blank instruction to save you worrying about it. As it stands right now, there is no Jump To Address instruction, however, I will be adding this in for completeness.

Source Navigator In Place

Just to keep everyone up to date with the project.
I have now put in the source navigator. I have copied the graphics and style from the navigator in WUDSN so that it is familiar to people who have used WUDSN before.
At present, it doesn’t display equates, but if there is a call for that, I will put it in.
Anyway, here’s a new screen shot:

Now to get the find and replace dialogs and functions in. Then the editor itself is done.
After that, I will put in the code to call the assemblers and report back to the user with either success or failure options.
I will then create the links to the emulators (Atari800MacX on OSX, Atari800Win and Altirra for Windows), so that the IDE can be used as is.
The sprite editor will come after that. I plan to create an editor that will allow the user to create and preview animated sprites. They will, by default, be saved as a binary file, however, like I plan to create for the character set editor, I will introduce some code export options as well.
Although the screen shot here is still showing the New Screen button on the toolbar, this will be removed. The Atari allows us to create an almost infinite amount of different screen configurations, and with DLI’s, we can even expand on that. So, creating an effective editor would require a great deal of work, more than I want to do before I can release version 1 of this IDE. Therefore, I will be removing any functionality for that area for now.

Source Editor and Character Editor Complete

Time for a quick update on the development environment.

The Main code editor is almost complete (I think). I have written it from scratch, using a canvas, to allow me total control over it.
It has full syntax highlighting that is changeable, dependent on the assembler being used and code folding. I still have to implement the source navigation and search facilities.
The project manager is also in place and 80% functional. As I work on other parts of the project that impact on it, I will make the changes then.

The basic character set editor is now finished. At present, it only saves to binary format, so the character set can be directly included in the source, but I may also add an export facility to create source code.

The preferences window is being created as I do each area of the main program, therefore, I have done the Code Editor and Character Editor sections only, so far.

ACDS Continued...

I have been cracking on with the development environment (Horace seems to have taken a slight back seat while I do this).
So far, I have a character set editor built, the project manager and half the source editor.
I have decided to concentrate on on assemblers for now (sorry C coders), but version 2 may include C compiler facilities.
I am also not limiting it to any particular assemblers, although it will ship with default settings for ATASM, MADS and XASM. Other assemblers can easily be added to it.
One thing I didn’t mention in the original post about this project is that it will be available for both Windows and OS X. I’ve using Real Studio to develop it, which is a great cross platform development system.
Anyway, here is a pic of the startup screen for you:

Atari Computer Development System (ACDS)

As I am developing Atari software now, I have been on the look out for the best tools to help me. So far, the best I have found is Eclipse with the WUDSN plug-in. This makes coding assembly for either the MADS or ATASM assemblers a dream. For user-defined graphics, I have been using EnvisionPC (which I recompiled for Mac), which has also saved me a lot of time.
However, looking for decent tools, I came across something for Spectrum developers that would be ideal for Atari developers. There is an integrated system for the Spectrum called Tommy Gun. This incorporates graphics tools, code editor, assembler and screen editor all in one. Such a thing would be a dream for any developer, regardless of the system being developed for.
So (you guessed it), I am looking at creating something similar for Atari development. As far as I can tell, it would have to have the following:

• Code editor - This would definitely have to be for assembly (allowing for MASDS, ATASM, CA65 and XASM syntax’s), but possibly also C and maybe Effectus and Atalan. For those last two, I would need to either research the syntax thoroughly, or contact the authors directly.
• Font/UDG editor - This is a must in my opinion. Most games use some form of custom graphics or text, so the ability to design them within the development environment would be fantastic. The resultant fonts would also have to be exportable into a number of formats, including (but not limited to), various assemblers, C, Effectus, Action!, Atalan, Quick, Forth, TurboBasic and good old Atari BASIC. Also, an option to save the fonts directly as binary would be marvellous.
• Sprite editor - The Atari is well known for its sprites, or Player/Missile Graphics (PMGs), and again, these are used in most games that are compiled into machine code. Even some BASIC games use PMGs with machine language routines. Again, these would need to be exported in the formats listed above, as well as binary.
• Screen designer - Nothing as advanced as Graph2Font, but it would be useful to have a screen designer that allowed the creation of screen images in ALL of the Ataris ANTIC modes, maybe even combined ANTIC modes. These could then be used for loading screens or possible game screens for faster transitions. Right now, I am not too sure about graphics formats on the Atari, so I figure the best way would be to save these as binary and if required, a linked custom display list.
• Sound/Music editor - T this would have to be the last stage of the project. As I have no idea about accepted formats of sound or music with the Atari 8-bits yet, I will need to research these. I may leave these out altogether, depending on what I find.

So, anyway, that is my plans for I am currently calling the Atari Computer Development System, but I’m sure I can come up with a better name before the project is finished.

Time sure flies - heading into the past

Wow! March already. I guess I should make a post of what I have been up to.

Since the New Year, I have been kind of bummed out with my main projects. I felt it was time for a break, a metaphorical change of scenery. So, I have gone back to my computing roots and begun on a retro project.

I am attempting to recreate one of the Spectrum's classic games, Hungry Horace, on the Atari 8-bit computer. Originally, I was going to do this with a language known as Quick and program directly onto my Atari 800XL. I had not programmed in it before, and I had heard some really good things about it and I could see how much easier it would make things.

I began the coding, and all was going well, but then I got side-tracked (don't I always?).

On the AtariAge forums, I saw a thread where people were talking about their development environments. someone there mentioned a plug-in for Eclipse, known as WUDSN, that was created for writing in assembly to cross compile to the Atari.

I thought I would give it a look, and I liked what I saw.

To that end, I have decided to restart Hungry Horace, but this time, using the MADS assembler. I have never coded in 6502 assembly before, although I knew the basics, so it would be a good learning exercise.

Upshot is, in two days of part-time programming, I am about a quarter of the way through the project coding. I am very happy coding in assembly, it seems to make a lot more sense than higher languages. I have total control of what I am doing. I still come across a few things that I stumble across (such as only being able to use indirect-indexed addressing with zero-page addresses), but I am getting there. And using Eclipse, the WUDSN plug-in and MADS makes it a dream to code. I can honestly say, I haven't enjoyed coding like this for a long time.

If things go according to plan, and I get a successful game at the end of this project, I will almost definitely create some more Atari games (possibly the two official sequels to Hungry Horace to start with). As one of my other computers back in the 80's was also 6502 based (the Oric Atmos), I may look at writing some games for that too.

So have I given up with RealStudio and BlitzMax? Absolutely not. I will get back to some modern programming again soon, but for now, I am enjoying my time in the past.

What have developers got against Mac users?

Just a quick rant about the software industry. In particular, the Mac software industry.

I switched to  Mac back in 2006 and have never looked back. I like the system, the security, the ease of use and maintenance, the build quality, etc. I could probably go on for hours (but I won't).

However, there is one thing that being a Mac user has caused me concern.

Whenever a new version of the OS is released, it appears that developers are almost chomping at the bit to release their software for the new OS. I can understand this if they were taking advantage of the new features of the operating system, some 'whizz-bang' thing that has only just been introduced, but most of the time, they are not. Most of the time, it just appears that the developers are compiling for OSX 10.whatever just for the sake of it.

I find it somewhat frustrating when I find some piece of software that I would like, only to find that it is only available for the latest version of Apple's operating system. Yet, if you look at the Windows requirements, 9 out of 10 times, it will run on Windows XP, an operating system that is over 10 years old!

When I worked in the Windows software industry, one of the prime directives was to make sure you did not alienate those users with older operating systems, and therefore a sizeable chunk of your market. This philosophy does not seem to cross the OS border into Mac. Why not?

It was really brought home to me recently when I saw that Doom 3 had been reduced to a little over £6. I was amazed and overjoyed. I originally played the Demo of Doom 3 on my G5 Mac, running OS X 10.4, so the assumption that it would run ok on my Intel Mac, with 10.5.8, seemed logical. But then I checked the requirements. For some bizarre reason, Aspyr (I'm not picking on them, just using them as an example) have decided that they would recompile Doom 3 to an Intel only application, and in doing so, have increased the required operating system to OS X 10.6.

Now, I understand that this may be to get the game on the App Store, but is it really necessary to cut out a large slice of users? Maybe I should be looking at why Apple decided to make the App Store require 10.6?

Either way, I think it is definitely a problem with the Mac software industry somewhere. Not everyone wants to upgrade to the latest OS. My Windows machine is still running Windows XP, and I don't see me upgrading it for a few years yet. I'm not going to abandon my Mac, in fact I think I'll probably have to go the way most Mac users do and upgrade my OS, just to allow me to run certain software.

I for one, will not be compiling my software for the latest OS. I aim my software at the lowest possible requirement to allow as many people the benefit of using it as possible. I know of a number of others that also go this route, and I salute them.

So, come on developers, you're in the business of making money, so why alienate your customers?