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:

Real Software: Debugging Tips

This is an excellent tip for debugging complex projects and methods. As Thomas states at the end of the blog, it can also be used for a simple form of profiling too, so it would be possible to see how long a particular method takes to execute.

Real Software: Debugging Tips: In this article I am going to share a nifty way to help with debugging your code.  There are times when you need to figure out which methods...

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.