Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Spritely Beta

edited January 2012 in Beta Posts: 1,255

Comments

  • SimeonSimeon Admin Mod
    Posts: 5,363

    Awesome! You can actually export .codea files from the beta version, @Mark. However copying+pasting now and will post my thoughts.

  • Posts: 1,255

    Oops, didn't realize. Here's the project.

    http://devilstower.posterous.com/spritely-beta-first-draft

  • SimeonSimeon Admin Mod
    edited January 2012 Posts: 5,363

    Wow. You really went all-out on this version of Spritely. This is amazing!

    It's kind of unbelievable how good it is. I've noticed some minor bugs with touches, you probably already know about them but I'll put them here in case:

    • When you touch-hold a project (which is awesome) and then drag off somewhere else, wherever your touch ends is treated as a tap. If you want to detect taps and not drag-release you might want to check the following situation:
    if touch.state == ENDED and touch.tapCount == 1 then
        if touch-is-inside-my-object
            -- Was tapped
        end
    end
    
    • When you tap the About screen to dismiss it, it paints a pixel.
  • BortelsBortels Mod
    edited January 2012 Posts: 1,557

    I managed to get "exceeded instruction limit" on the Spritely beta.

    And I second it - this is really well done.

    I'm sure it's been suggested, and I'll suggest it again - including Spritely as an example would both be useful as an example of a "real" application, but also fill a need.

  • Posts: 1,255

    Yeah, touch handling has become increasingly sloppy as the program has grown -- lots of touch routines glued together by ugly global status indicators. Time to clean up.

    @Bortels Uh, oh. I haven't seen that one. But I suspect I know why it's happening. In order to support letting the orientation change at any time, I'm redefining things in the draw() loop. Some of those I'm doing the "right" way by changing coordinate paramters of exiting objects. But on some I took the easy route and just copy / pasted the code to recreate the object into draw(), so there are some buttons, icons, etc being recreated thirty times a second. I probably outran any garbage collection.

  • SimeonSimeon Admin Mod
    Posts: 5,363

    Odd. I thought I disabled the run-time instruction limit in the current version of Codea.

  • SimeonSimeon Admin Mod
    Posts: 5,363

    @Mark: I certainly don't want to rush you - Spritely is looking fantastic and will be a great demonstration of what's possible in Codea. But do you have an idea of when you might be happy to allow it in for submission? We'd like to get a build sent to Apple fairly soon (there's some bugs on our end to work out too).

    By the way, will Spritely still have the option to save to global data? Or is it there and I'm just not finding it? Or perhaps it's already doing that.

  • Posts: 1,255

    I've reworked the touch issue, and except for fiddling with the popup menu, I think it's working well. However, I'm now seeing the "instructions exceeded" error after only a few minutes of running. Assuming the problem is from constantly re-doing objects (for example, every draw cycle includes tt = Ttouch(CurrentTouch) to give me my translatable touch object) I've got a moderate stack of code to go through.

    Hmm, I wonder if it would help to nil an object before redefining it?

    Wednesday? (Meaning Thursday for you?).

  • SimeonSimeon Admin Mod
    Posts: 5,363

    Are you using setInstructionLimit(0) to disable the instruction limit? Just in case.

    Is there anything I can do to help with Spritely?

  • Posts: 2,161

    I don't know how you feel about using other's libraries (I'm rubbish at it!), but I have a fairly detailed touch handling routine in my library. Even if you wouldn't use it directly, it might gibe you some ideas.

  • Posts: 1,255

    Andrew, many thanks. The problems I had were mostly of my own doing. Elements where I'm using tap to select, tap and hold for other options, touch and drag, and help screens on top of load screens on top of editing screens. So the problem was routing the right kind of touch to the appropriate elements while not accidentally letting an element receive the wrong kind of touch, or a touch ment for an element "above.". In other words, a mile deep stack of if.

    Andrew, havent yet done the setInstructionLimit(0) bit. I'm rewriting the draw routines so that things only get redefined when there's an orientation change rather than each time. If that doesn't do it, I'll lift the limits.

  • Posts: 1,255

    Take 2. It's after 2 in the morning here, but there's also a massive thunderstorm and a tornado warning, so not exactly a great time to sleep.

    http://devilstower.posterous.com/spritely2-beta-draft-2

  • Posts: 1,255

    Additional clean up, touches no longer seem to be going astray, positioning only being done on reorient. No longer seeing the instruction limit. Even cleaned up the comments. Mostly.

    http://devilstower.posterous.com/spritely-beta-take-3

  • SimeonSimeon Admin Mod
    Posts: 5,363

    Awesome, I was using draft 2 last night.

    I was experimenting last night with re-writing the EditorGrid draw() in draft 2 with mesh(). It speeds it up quite a lot – I'll post the code for it.

  • SimeonSimeon Admin Mod
    Posts: 5,363

    Take 3 is looking very polished, @Mark. Love the cleaned up look on the buttons and the help screens.

  • Posts: 1,255

    Now I'm slapping myself in the head for not thinking of this obvious use of mesh(). Off to try it.

  • Posts: 447

    this is looking really good!

    A suggestion for a next version (after you're done with the current version for 1.3) is to add tools to make lines, rects and ellipses

  • Posts: 447

    quick bug report: if you set the size to 32 and press undo, it throws an error

  • SimeonSimeon Admin Mod
    edited January 2012 Posts: 5,363

    EditGrid really lends itself to using mesh. There's some bug fixes coming in the next build - particularly one that will change the mesh() starting index to be in-line with Lua.

    I wrote some code to use meshes in spritely, but it wasn't as good as it could be. It could be really fast. The way to do that is as follows:

    In init:

    • Allocate a mesh, self.mesh = mesh(); local m = self.mesh
    • Call m:addRect( x, y, w, h ) for each grid cell. You can use the 1:1 size.
    • The full size of the grid is 64, 64. We'll call this self.gridSize

    Whenever you edit a grid cell x, y:

    • Find the index of the rect as follows:
    • index = (y - 1) * self.gridSize + x
    • Update the mesh as follows:
    • m:setRectColor( index, newColor )

    Drawing the mesh:

    • Clip in screen coordinates:
    • clip( frame.x, frame.y, frame.width, frame.height )
    • Scale to the appropriate zoom level
    • m:draw()
    • noClip()
    • Draw the pixel grid lines: you only need to iterate rows + columns number of times, because you can draw a single vertical line or horizontal line across the frame each time.

    This way the drawing of the editor grid has almost no overhead, updating the underlying mesh is as simple as making sure you set the appropriate colors on the mesh the same time you edit the grid data structure.

  • SimeonSimeon Admin Mod
    Posts: 5,363

    @Mark I was thinking about this some more and just wondered: why not just draw a big version of the actual image to draw the image. It seems like that would be efficient. There would be no need to loop through the grid cells, or the hassle of setting up a mesh.

    Just set noSmooth(), a clipping rectangle and draw the image itself. Then you can draw gridlines over it the way described above.

  • edited January 2012 Posts: 1,255

    Yeah, that blinding moment of obvious finally hit me last night -- but only after I tangled myself into knots with the mesh. I'm this close to stripping draw() down to nothing, getting rid of the grid[x][y] element, and making all the string functions run straight from the image.

    Also made yet more cosmetic changes that I think look pretty nice. I have to run into a meeting for the next few hours, but when I get out I hope to tidy up. This actually simplifies quite a few things, not just draw.

  • Posts: 1,255

    Just one problem standing between me and the faster, simpler revision--but it's a weird one.

    Flood fill works in a simple, but recursive manner by identifying candidate pixles above, below, left and right of a target pixel that could be changed, changing the pixels, then looking around changed pixels for other potential candidates. It's not fancy, but it's effective. Only now it's locking up tighter than a drum.

    Here's the weird part: if I put in a displayMode(STANDARD) so I can watch values... it works fine. In fact, I don't even have to throw in a watch, or a print. Putting it in standard mode fixes the problem, while commenting out just the change in displaymode, causes the routine to lock up. It's like it only behaves when it knows I'm watching.

  • SimeonSimeon Admin Mod
    Posts: 5,363

    Hmm the only thing that displayMode(STANDARD) should change in your code is the following:

    • The return value of displayMode() -- called without arguments
    • The values of WIDTH and HEIGHT

    Feel free to email me the project if you need help with this bug (simeon@twolivesleft.com)

  • edited January 2012 Posts: 1,255

    Here's take 4 with the editgrid gutted and everything done directly on the image without an intermediate grid. A heaping pile of code went bye-bye.

    http://devilstower.posterous.com/spritely-beta-take-4

    A couple of things where I'd definitely appreciate a second set of eyeballs:

    In the EditGrid class, the floodFill and textPix functions which together do area fill, can still generate runaway cascades in which it just keeps sitting there re-nominating spots that should have already been changed. I put a hard stop in the routine at 1024 dots (as much as a 32x32 image can generate) so it shouldn't generate overruns, but I'd love to understand what I missed in this. I'm sure it's staring me in the face.

    The other thing is on the Main tab the sliderPaneleTouched() function. There's a simple bit here that resizes the image. This is probably the only place where not having the grid made it harder. When the image is getting smaller, it's easy enough to copy from one image to another, but when sliding the image larger I ran into messy problems. I solved them with a little get / set loop, but the behavior is less than snazzy and the code is ugly. Surely there's a better way.

    Other than that, everyone now suffers the Spacecute background because it's the onlymoderately tilable pattern in the sprite library.

  • SimeonSimeon Admin Mod
    Posts: 5,363

    One thing I notice in EditGrid:draw is that it actually draws the horizontal lines inside the vertical line loop - this is making Codea draw many more lines than it needs to. Here it is with the two loops side by side instead:

    function EditGrid:draw()
        local cw, c, x, y
        cw = (self.frame.x2 - self.frame.x1) / self.img.width
        pushStyle()
        stroke(127, 127, 127, 255)
        strokeWidth(1)
        fill(0, 0, 0, 255)
        self.frame:draw()
        rectMode(CORNER)
        c = color(0, 0, 0, 255)
        sprite(self.img, self.frame:midx(), self.frame:midy(), 
               self.frame:width(), self.frame:height())
        for x = 1, self.img.width do
            line(math.floor(x * cw + self.frame.x1), self.frame.y1, 
            math.floor(x * cw + self.frame.x1), self.frame.y2)
        end
        for y = 1, self.img.height do
            line(self.frame.x1, math.floor(self.frame.y2 - cw * y), 
            self.frame.x2, math.floor(self.frame.y2 - cw * y))
        end
        popStyle()
    end
    

    The Space Cute background works brilliantly by the way :)

    Also it's looking really polished.

  • SimeonSimeon Admin Mod
    Posts: 5,363

    @Mark I'm sure you've noticed spritely is now in the current build of 1.3. I've noticed that it can be slow when drawing pixels. How are you detecting which squares to paint when using the pencil tool?

  • SimeonSimeon Admin Mod
    Posts: 5,363

    Also would you be happy for us to submit with your latest build of Spritely? Are you happy with it?

  • Posts: 1,255

    I've got a slightly updated version with just a little nudge here and there. I'll get it up to poserous shortly. I'm making a last pass through the code to make things a little neater.

    Nice to see it in the build.

  • SimeonSimeon Admin Mod
    Posts: 5,363

    Great! I'm just finalising 1.3 so I'll have a beta build once I include your final version.

  • Posts: 1,255

    Take 5

    http://devilstower.posterous.com/spritely-beta-take-5

    And now I promise to quit niggling things two pixels here, 10% change in alpha there.

  • Posts: 1,255

    Not for 1.3, but for the next version I'm adding a simple form of compression. Since most icons consist of a few colors, it makes sense to scan the image, build a color palette, and then map the actual pix against those colors. In a few test images (in this case, icons that emulate Mario games) this drops the overal size of the info to store the image by >70%. Kind of like a GIF file without the bitmap compression.

    Naturally, on images with a lot of colors, this could actually make things larger, and it will need an image decompress function to use, but it still seems worthwhile.

Sign In or Register to comment.