NilObject

Since this is geared more towards a programming-related topic, I figure I’ll post it here rather than at my personal blog. But, for those interested in tips and tricks on REALbasic, this post isn’t for you

I enjoy writing, which is partly why I enjoy having a blog. Sure, it takes motivation to remember to post, but I enjoy writing. Once I start, I generally have a good time writing. For many years, I’ve wanted to write a book. Back in grade school, I wrote a lot of HyperCard lessons for the teachers to have their students do, and by fifth grade, my mother and I actually taught a couple of inservices for teachers and how to use HyperCard in the classroom. After that, my mom and I toyed with the idea of creating a book, but due to family reasons (good ones, not sad ones :P), it slipped by.

I always enjoyed creative writing, and I always seemed to do well on it. I competed and did well at state journalism competitions my Junior and Senior year, and was the co-editor of our high school’s newspaper. That was fun for me — writing stories, editing them, and laying the final product out.

Fast forward to last year. My mom always heard me talk about REALbasic, and how easy it is. So, she wanted to collaborate with me to write a late grade-school to junior high curriculum using REALbasic. I think it’s a great idea, and it’s one that I’ve been thinking of more and more lately. I’m putting my thoughts into writing for two reasons: 1) to hear other’s feedback on the idea, and 2) articulate what will turn into the goal of the curriculum for when I start outlining it. If you have feedback, let me know

If I were to start on this project, I would want to focus on several concepts, not just programming. Programming would be the way things are accomplished, but definitely not the main lesson. The things this curriculum would teach would be common problem solving strategies, visual mathematics, and basic programming principles. This would be accomplished through many different and fun projects. Each project would last less than two weeks, and probably average about one week (five school days). Each day would be roughly 15 minutes of actual learning/guidance, while the next 20 minutes would be used for the problem solving.

You programmers are probably thinking: What could you learn in 15 minutes a day? The idea isn’t to teach them how to build applications from the ground up. The idea is to have a pre-written project where all they have to do is solve a small problem and fill in the implementation in a small area with their solution. The rest of the programs would already be written, but the kids would turn a program that did (or at least appeared to do) absolutely nothing into a nifty game, animation, or image.

My mother, a former teacher and current vice-principal, thinks this is a wonderful idea and when talking to other teachers, they say the same thing. There are a lot of teachers who want a curriculum that they can use and understand, and at the same time will teach and entertain the kids.

Those are the goals if I were to head down this road. So, what does everyone think?

5 Comments »

This is one of the random, off-topic things that has been on my mind. Almost everyone has a hobby outside of their job, an activity they enjoy doing in their off-time. Me, I program at home too, but I enjoy a wide variety of things. My main hobby outside of programming is playing Chopin, Rachmaninoff, and other romantic-era classical piano music (Yes, those recordings are of me).

So, fellow programmers and readers, two part question:

1. What is your main job?
2. What do you do after-hours to entertain yourself?

No Comments yet »

So, one of the biggest things to watch out for in any code that does timing is the failure cases when system functions return very large numbers, such as GetTickCount, or Microseconds (depending on the platform). Timers in the past have had odd bugs that require 28 days of uptime to see, or 14 days, or some other multiple. We’ve squashed all of them, but today we found a new one in our new cooperative thread scheduler. Luckily I was in our timer code on Carbon recently, so I recalled what a very good, safe fix would be.

The problem comes in when you attempt to use really large numbers and convert them to a signed long. Why, back in the day, someone decided to use signed longs is beyond me. However, over the years people have fixed the implementation rather than rewrite it. See, when you query for the milliseconds and store that value, and ask again a few milliseconds later, the comparison you must make depends on whether or not the current and stored values are negative or positive. In the old code (5.5), we inspected the thread scheduler and noticed how a subtle implementation detail actually avoided the problem, but in the rewritten code it showed the problem. But this isn’t the interesting part, or the humorous part. The humorous part is that we were trying to track down an unrelated crash, and I couldn’t reproduce it on my XP box. So, I remote debugged with the latest internal version to the Windows 98 machine. It crashed, which is good — this particular user couldn’t see the crash himself, just on about 5% of his over 15,000 customer install base. We thought we had it, but then I tried again using REALbasic 5.5.5 and the crash wasn’t there. Since that’s what this user was building with, we knew this wasn’t the problem. However, we told Aaron about the new bug, and he began looking into it. Little did we know that we would be using Windows 98 to debug a crash that only happened on machines that had been up between 28 and 56 days long! It has been up for 46 days and counting, strangely enough.

No Comments yet »

Here’s two teaser screenshots. I am re-exposing the OpenGL methods in a nicer way, as well as implementing some of the Direct3D functionality. So, no download yet, but check it out: real time, non-faked reflections, text, and more!

Enjoy!

3 Comments »

I don’t really have any tips today, as most of my day was spent working on the framework. I seem to have a knack for tackling the, “Ooh, that’s scary” things. You know, the things that we’ve had nagging our product because of it’s OS 9 heritage. I can’t make any promises for and particular versions, but these are the things I really want to see done (and some may already be! Watch the release notes!):

• CoreGraphics. Yes, REALbasic supports it, but it doesn’t use it in every case yet. This is a big deal starting in Tiger, as Apple says if QuickDraw touches a window’s backing, it will be stored in RAM, not VRAM. Just imagine if every application written in REALbasic automatically worked in VRAM (of course, unless you explicitly turned on UseOldRenderer). This requires Composite windows, which thanks to a few maintenance releases, are basically working great now. Composite windows are required because it’s the only way to get a CGContextRef during a paint event without having to get a QD port.
• Fixing multiple refreshes under Carbon. Currently, Window activates and deactivates cause three complete window draws before it gets blitted to the screen. This is a *big* undertaking, but really needs to be done.
• Event loop processor utilization. Currently, REALbasic apps use around 1.5-3.0% of the CPU. This is heritage that can be gotten rid of, but it’s quite an interesting undertaking. Due to how Classic worked, and how REALbasic is such a large project, there’s a lot of things to take into account. This is a scary change to go all out on, but it would be a great benefit. Psst.. watch the release notes.
• Optimizing our CoreGraphics implementation. We really can speed this up, but it’s a risky thing that is going to most likely introduce subtle bugs. Psst.. watch the release notes.

So, these are the things that I feel REALbasic needs to do on OS X within the next few versions. Of course, what I feel needs to be done doesn’t make a difference. File requests for what you want at the Feedback system.

1 Comment »

My personal project at home for the last few weekends has been creating an OpenGL “Canvas.” My inspirations were:

• I started playing “Paper Mario: The Thousand Year Door” and loved it so much that it inspired me to make my own platform/RPG game.
• John Balestreiri at TinRocket.com has a wonderful engine called the SuperSpriteSurface. I highly recommend it for OS X development. However, here’s the dilemma for me. I know John, and he told me he hasn’t had time to port all of his declares to Windows yet, and I often find myself doing most of my work on my Windows box during the weekend simply because of speed (Oh how I wish I could get a G5 :P). So, I toyed around with it and really enjoyed it. During a chat conversation, he made a comment along the lines of, “If REALbasic had support for OpenGL it would just work.” I put my game designing on hold, and…
• Wrote my first version of the OpenGL canvas. The majority of the work was creating a utility that parsed gl.h and produced a REALbasic plugin. I wrapped some functionality like loading a texture into a class, and it worked wonderfully on Windows and Mac OS X. I showed it around the office, and it elicited “Ooh”’s, and “Aah”’s. However, Aaron Ballman made an interesting argument for not simply exposing every OpenGL call but rather learning Direct3D and exposing a true cross-platform API. I understand the argument — Direct3D is better supported on Windows. Sure, OpenGL tends to work, but it’s kind of like QuickTime or StuffIt for Windows — people just don’t use it as much.

So I contemplated it pretty deeply yesterday. My day was eerily familiar to this clip. I sat down to work on it several times, but after thinking about it I decided I should come back to it later on in the day.

I finally actually wrote some code today I reworked all of my OpenGL implementation such that it is swappable with a separate implementation on Windows. I commented out my classes that encompassed the OpenGL things such as texture loading, and started rethinking my design from scratch.

I haven’t quite figured it out, however. DirectX uses basically what indexed vertex arrays are in OpenGL. They’re different however, due to how they are stored. This is a problem because how am I supposed to store the information when you simply say “new C3DVertexArray”? The way I look at it, I have several options, each with their own benefits and downsides:

• Make the C3DVertexArray class mutate once it is drawn inside of a Canvas3D.
  Pros
  • Easy to know when the data needs to be transformed.
  • Makes the code under the hood identical between DirectX and OpenGL up to the point of it being drawn

  Cons

  • Slow. Horribly slow. I could cache once it has been drawn once, but then there is the disclaimer that you shouldn’t be creating these things during the Render event.
• Make Canvas3D have a method to create C3DVertexArrays.
  Pros
  • Can be created with the proper data structure under the hood.
  • Fast, since there is no problem with formats

  Cons

  • Can’t be transferred between a Canvas3D in DirectX mode and a Canvas3D in OpenGL mode
• Make C3DVertexArray have both formats internally.
  Pros
  • Can be created with the proper data structure under the hood.
  • Fast for drawing, since there is no problem with formats
  • Can be transferred between both implementations.

  Cons

  • Slower for manipulating elements
  • Higher memory footprint
• Make the Windows implementation either DirectX or OpenGL for the entire app rather than on a per-canvas basis.
  Pros
  • Can be created with the proper data structure under the hood.
  • Fast. No problems with formats
  • No need to worry about mixing and matching formats because a single format is guaranteed

  Cons

  • My interesting idea of a unit testing framework with two windows, one in DirectX and one in OpenGL, can’t be realized.
  • Switching between implementations is a cool feature that could come in handy — let the user decide, OpenGL or DirectX?

At the moment, I’m leaning towards a mixture of the choices. I’m thinking that the likelihood of a person creating a vertex array inside of their Render event is low, so I can always cache the information once it has been rendered. Once someone changes a vertex, I re-compute the information at render time. This potentially increases overhead when doing mesh transformations, but I could probably speed that up in the end as well.

So, why am I writing it here? Well, I just needed some place to write my thoughts. Stay tuned in the next few weeks to see what becomes of my Canvas3D.

No Comments yet »

So, earlier today someone wrote to me asking for help that I offered in a previous post. What my previous post didn’t detail are the types of declares that you cannot achieve in REALbasic.

What types are those? Well, for a quick recap, let’s examine the different techniques:

• If a declare takes a structure byval, you can split the structure into 4 byte chunks and pass that byval. For more information, see this post.
• If a declare takes a structure byref, you simply declare the type as ptr and pass in a memoryblock.
• If a declare returns a pointer to a structure, declare the return type as Ptr and assign the result to a MemoryBlock reference.
• If a declare returns a structure that is 4 bytes, declare the return type as a Long and dissect the result with the various Bitwise operations.

What does that leave out? Functions that return structures larger than 4 bytes. Short answer: you can’t without a plugin. Long answer:

On PPC Mac systems, a long long (64-bit integer) is split up between GPRs 3 and 4 for the return value. If you declare the return type as an Integer, you simply get the high 32 bits of the value, which isn’t ideal. If the type returned is a structure that is larger than 4 bytes, a pointer to the return value is placed in GPR 3. Because of this, there is no way to trick REALbasic into making this work on PPC.

On X86 architectures, the same problem applies. However, if the return value is greater than 8 bytes, then you can declare the return value to be a pointer, and REALbasic won’t know the difference (because that’s what it will be). But this can be potentially fragile.

In the end, REALbasic needs something similar to VB’s User Defined Types (UDTs) for structure passing and returning, and more data types support before any declare is possible. Feel free to search the Feedback system for those reports and sign onto them!

3 Comments »

One of the nice things that languages with immutable (unchangeable) strings offer is a StringBuilder class. Here’s a simple one that is encodings savvy:

Class StringBuilder
  Private Dim buffer As MemoryBlock
  Private Dim usedBytes As Integer
  Private Dim mEncoding As TextEncoding
  Sub Constructor(initialSize As Integer = 1024)
    buffer = New MemoryBlock(1024)
    usedBytes = 0
    Encoding = Encodings.UTF8
  End Sub
  Sub Append(s As String)
    s = ConvertEncoding(s,Encoding)
    
    Dim sLen As Integer
    slen = s.lenb
    
    If buffer.Size < usedBytes + sLen Then
      buffer.size = buffer.size * 2
    End If
    
    buffer.StringValue(usedBytes,slen) = s
    usedBytes = usedBytes + slen
  End Sub
  Sub Encoding(Assigns newEncoding As TextEncoding)
    If newEncoding.Equals(encoding) Then Return
    
    Dim current As String
    current = Self
    
    mEncoding = newEncoding
    usedBytes = 0
    
    Append current
  End Sub
  Function Encoding() As TextEncoding
    Return mEncoding
  End Function
  Function Operator_Convert() As String
    Return DefineEncoding(buffer.StringValue(0,usedBytes), Encoding)
  End Function
  Function ToString() As String
    Return Self
  End Function
End Class

The idea is that a StringBuilder will start out as UTF8, unless you create it by giving it a string. In that case, it will take the encoding from the string. After that point, it will convert any strings you try to append to it to the original encoding. You can change the encoding by using the custom assigns method.

This class is only good if you use the append method. This is the reason that I didn’t expose any more operators. Simply append until you’re done creating your output, and then finally convert back to a string.

No Comments yet »

I had a bug today. Every developer has them. However, this is one that I file under the obvious, but too obvious. I was doing texture loading in OpenGL, and for some reason, only the last texture loaded would be used! I searched high and low, comparing other people’s code to mine, debugging it on both the Mac and Windows, all to find nothing.

I took two breaks — one to eat supper and play some Paper Mario, and the other to chat on the phone a bit. Finally, I decided I wouldn’t sleep until I figured it out. Another hour later, I found my bug.

It was as simple as swapping two lines around. I was calling glBegin, then glBindTexture. That’s a no-no. However, none of the tutorials I was reading said that, except finally I found one that did. “Make sure that you bind to a texture before you do any sort of glBegin/glEnd. You cannot bind to a texture in the middle of a begin/end pair.” It clicked, and I reordered the two calls, and walah, it was working

This is a perfect example of a red herring problem. I was dealing with my own plugin for part of the OpenGL code, and it was loading textures. I assumed it was my texture loading code all along — but it wasn’t. That code was bug free! I rewrote it in my REALbasic portion, and it still persisted. I tried many many many things. But never tried reordering those calls

Well, now that it’s past midnight and I reached my goal, I am going to retire to bed. What’s funny is that I used to be pretty decent at OpenGL. Now I’m having to relearn it — I never had this problem last time I learned it!

1 Comment »

Over at rentzsch.com, he points out a very nice calculator. It’s not as restrictive as common calculator applications, because it lets you type in a full expression and it will calculate it then. However, it’s even cooler because it can be expanded with your own math functions. I quickly added DegToRad, and RadToDeg — less than 1 minute to figure out how to do it.

So, what is this program? It’s Longhand. After a short 2 minute session, I have decided to “Keep in dock”, and positioned it in it’s new home to the left of my development tools.

No Comments yet »