Awesome! You can actually export .codea files from the beta version, @Mark. However copying+pasting now and will post my thoughts.
Oops, didn’t realize. Here’s the project.
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.
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.
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.
Odd. I thought I disabled the run-time instruction limit in the current version of Codea.
@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.
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?).
Are you using setInstructionLimit(0) to disable the instruction limit? Just in case.
Is there anything I can do to help with Spritely?
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.
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.
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.
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.
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.
Take 3 is looking very polished, @Mark. Love the cleaned up look on the buttons and the help screens.
Now I’m slapping myself in the head for not thinking of this obvious use of mesh(). Off to try it.
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
quick bug report: if you set the size to 32 and press undo, it throws an error
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:
- 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
- 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.