Image editor gets some love

After my breakthrough with the line and bezier drawing, I've decided it's time to nickel and dime a few things.

This evening I spent about 2 hours getting images to auto-snap in place in the pict editor as well as toggling the images on and off.  This will help with drawing pictures as you can now toggle the background images on and off and "trace" them to get a better picture.  I wanted to actually resize the image rather than just displaying it resized, but alas that's not as easy as I expected.  Still not sure why, that's where the bulk of my time has gone.  NSImage expects you to know a lot more about images than I do apparently.

This still needs some work -- you can add as many pictures as you want (we should limit to 1) and the images need to be re-sampled down smaller than they are.  We also need to make a category, phrase (hint?) and exact word match meta-data in the editor as well so that the pict app can do something useful with the sketch files.

I may as well post a picture as an example of the image background scaling, since this blog would be awfully boring without pictures.  Well okay, and maybe a little bit boring WITH pictures.  Please excuse zeratul's arm, it's currently part of my desktop background.  You can see the auto-scaling at work, the regular size is in preview.

pitfalls of early optimization

So I don't know that I've mentioned this on this blog, at least not recently.  Pict has had a serious issue drawing straight lines when run on the iPad.  As in it locks up the whole iPad for seconds at a time while drawing straight lines if they are longer than about an inch.

Drawing lines and curves over time isn't something that's normally done for computer graphics.  Most applications want to draw a line or a curve from start to finish, they aren't interested in the user watching this happen.  Incidentally the math is totally different.  Fortunately I'm building on the shoulders of giants.  Well, people better at math than I am.

I created my own actions in cocos2d by overriding the CCMoveTo and CCBezierTo classes.  In practice this means that I needed one additional piece of information (the last time we've updated) to be able to draw the points we may have missed along the way in addition to using a CCRenderTexture to draw the "pen" sprite into.

This has been a thorn in my side for months and a point of discouragement on this project.  What's the point of making a drawing app if the drawing takes way too long?  Without that the app is dead.  Very discouraging.

I've been hitting my drawing code off and on for the past four months and have made little headway.  This saturday past I sat down for almost 5 hours and gave it a serious rework.  I know WAY more than I want to about bezier paths and drawing a point on a line.  However I ended up giving up around 1 AM.  The one thing I knew at the end of the night was that most of my approaches had been flawed and I knew why.

However my focus was all for naught.  It seems that due to profiling where my time was being spent with instruments, I was misled. Yes, all of my time was spent drawing and that's where things pointed.  The solution was not how often I was calculating or where I was doing my drawing, but how often I drew to the CCRenderTexture.  Specifically how often I called CCRenderTexture's begin and end functions.  Rather than move my CCSprite and using the method [sprite visit], I saved all of my positions and then drew them in a for loop in my render texture.  In pseudo-code the original was doing something like this:

// figure out the new sprite position that's needed to draw
// draw the sprite into the render texture
  // CCRenderTexture begin drawing
  // set the sprite to the new position
  // [sprite visit]
  // CCRenderTexture end drawing
// repeat as necessary
// return out of our update function

After many many attempts at changing how many and often I drew, I changed the code to do this:

// figure out the new sprite position that's needed to draw

// save the new position

// repeat as necessary

// CCRenderTexture begin drawing

// iterate over my points, moving my sprite

  // [sprite visit]

// CCRenderTexture end drawing

// return out of our update function

This totally fixed the problem.  Ugh, what a pain!  In hindsight it seems somewhat obvious.  Maybe I'm clueless but I'd like to think it wasn't obvious from my previous perspective.

Lesson:  CCRenderTexture (and as an extension, some openGL calls) can be expensive if used too often!

Here is a reference to the (old) cocos2d threads related specifically to my drawing are here, here and here.

About this blog

If you've read any of the past entries here they may be a little confusing.  The previous entries are largely a time log of my iPad development activities related to an app I am writing codenamed "Pict".  The game will be a pictionary variant, and I hope successful on the iPad as a social game.  I had planned on starting this blog much sooner to track my development but it worked out to be about 4 months of writing to a text file on my hard drive.  This evening I've spent a couple of hours and posted that log here.  There are some linked gems with little to no background information on what problems they solve, but I figured worst case they wouldn't be useful to anyone, best case they actually helped some poor googling soul out to find a solution.

I hope to have more interesting and elaborate posts in the future concerning my iPad development rather than a simple time log.  That may or may not happen, we shall see.

Thanks for stopping by.

where did I go?

8:45 PM - it's been almost 2 months and little has happened with Pict.  It's been on hold as I've worked with Folder Lite, Updating Folder, been on vacation, played through the starcraft 2 campaign, and generally haven't done much that's difficult in the way of iOS programming in my spare time.  Though at work I've been working the past month almost exclusively on the iPad, on (the back end of) an iPad front end for our company's software.  I've learned a lot but mostly have worked on the back end, so there's not a lot to show.  That's coming to an end, but the UI heavy portion of the project is coming up in the next month.  I think that's part of why I've been set back some -- I'm doing this full time.  I did get to learn core data on the clock though which was nice.  Core Data may be good for some uses, but I haven't found the best scenario for it yet.  I wish we had used SQLite actually for our app at work as what we are doing is the wrong fit for Core Data.  Anyhow.  This evening I'm going to start a new from scratch but copying a lot of code framework for Geopher Lite and turn it into Geopher Geocaching.  I think that will work better as a name and have it do a number of things better.  I guess we will see.  I may also post this time log on the blog it was originally intended for, we'll see on that as well.

More later.

More love for sketch+Accessibility

5:00-7:00 PM, 8:00-9:30 PM - Today I added the item list tool window to the sketch+accessability project. This window shows all of the objects that are currently stored in the graphics view by name. Right now it's a window with a table in it. It also has a refresh button. Incidentally, the sketch+accessability also uses bindings heavily, and those are kicking my butt. So I'm making refresh calls to the table, which is less than optimal. Someday I'll understand bindings, but for now it's just in my way. :/ Anyhow, the idea is to be able to select multiple items both with your cursor like it did before as well as within this window. This will help to organize the order of the object drawings as well as hopefully make creating and editing a given picture easier, since the selection method is less than ideal. The background is going to have to be done independently of SKTImage I think, otherwise it will get tied up with the rest of the drawing code, which could be bad. I'm not 100% sure how I'm going to handle that yet, but that will have to be finished. Along with other details about the drawing that need to all go together… (category, item name, brief description? etc) Wish me luck, I'll need it. =)

I realize now that at some point I've revisited sketch and ripped out all of the per-pixel specifics and didn't log that.  It's more vanilla and I'll use transforms to get the drawing to draw where I need it.  The window does resize the grey box automatically to the optimal size right now for the iPad, but since I'm not doing other odd pixelly things you can use the already built tools like the grid and zoom features to help draw.  Adding curves to this also helps immensely.  Still no word on if I'll support text, I kind of don't expect to, but we shall see.

Riq is a cool project maintainer

9:30 PM - 10:45 PM - Riq, the creator/maintainer of cocos2d fixed the previous problem. Apparently CCRenderTexture was making bad assumptions on how to get the screen position. I fixed that and added it to my app. I also commented on the cocos2d forums and added (hopefully) proper suspend/resume capability to cocos2d.

cocos2d revisited

10:45 PM - 12:00 AM - Updated to the new cocos2d release candidate (0.99.4rc2 to be exact) and found a bug with it. Did some exploring and posted how to reproduce it on the cocos2d forums. Pict works respectably well on the new iPhone, it looks pretty close to the iPad version actually, which makes sense as far as the resolution goes. Fun to see it on there and work with the new phone some. Here, have a screenshot of the bug.

This is a screenshot from the new iPhone 4 itself, unmodified. That's a lot of pixels to fit on a 3.5 inch screen!