Don’t it hurt to abandon a project? ...unfinished LivePositioner project here.

General
1

For what it’s worth, this project allows you to use any and all of the builtin models to create and save a 3D scene.

It loads with an (unfinished) scene of spaceships attacking a pirate ship crewed by people, monsters, and robots, plus a big spider monster attacking a castle.

I was working for a long time on this but it looks like it’s going to be obsoleted by the new scene maker in Codea 4:

https://codea.io/talk/discussion/11782/when-is-codea-4-coming

That looks like a fantastic tool, and I can’t wait to play with it, and I’m super glad it’s coming, and also, of course, it’s way better than what I was making.

I learned a ton making this, so I can’t say it was wasted effort exactly, but it is a little sad to stop before it’s finished—still, for anyone interested, here’s how far I got.

2

That looks like an amazing project. Codea 4 will not be compatible with Codea 3 projects, and it won’t be ready for some time, so I think there is a lot of value in what you have built

3

@Simeon @UberGoober - this demo (LivePositioner) crashed Codea v287 when I was trying to position the models by using thumb and finger touches to move them. Hadn’t done anything else before that.

4

There is debate over who first said that work is never finished, only abandoned. It is often attributed to DaVinci. Whoever first said it, many have echoed it.

One nice thing about working always from something shippable, playable, usable, is that when we do abandon it, for a while or forever, there’s a bit of good in the world that wasn’t there before. That said, we’re most of us here for fun, and when it comes to fun, I think we do best to wander to whatever catches our eye.

5

@UberGoober - think the crash may have been a result of the touch control. Did you modify that for the demo?

Will have another play with the demo and stick to your parameter controllers - keen to see what you have incorporated into this demo - may give a few ideas for one of my own.

p.s. I don’t like abandoning projects but I have a pad full of half filled projects. As I learn more I go back to see if I can finish them - I don’t like investing time into a project and abandoning it.

6

@Bri_G there aren’t any touch-positioning controls, that’s a thing I was hoping to get to. Touches should only affects the camera.

@Simeon thanks for those kind words.

Maybe I’ve had my head in the sand but this is the first I’ve heard of Codea 4 just flat-out not being compatible with Codea 3. So all current projects will have to be rebuilt from scratch?

7

@Simeon - picking up on @UberGoober 's point; in what way do you mean incompatible? I assumed that the Lua engine would be retained and a few Codea specific commands (graphics, sound, shaders etc) may have to be modified in any transfer between systems. Could you give us a few clues on this?

8

@UberGoober @Simeon I hope not - that would be hugely disappointing.

9

@Bri_G are you still having touch problems? It doesn’t crash at all when I touch it.

10

@UberGoober - it’s not so much touch as the zoom in function using finger and thumb spreading them. It could be to do with memory as the action described may build up a lot of touch entries to the tables involved. On top of the models, textures and code that may have pushed this over the limit. How many models can you add in this demo?

Anyone got any diagnostics for determining allocated memory, graphics memory, audio memory and free memory - could be useful?

Edit: you included OrbitViewer from @John which, I think enables the touch for the camera.

11

@Bri_G

On my iPhone 8 I can pinch, spread, and swipe as much as I want and I don’t get a crash. Do you get an error message? What device are you on?

12

@Bri_G @UberGoober No matter what I did, zoomed in, zoomed out, it didn’t crash for me. iPad Air 3rd gen 64GB.

13

@dave1707 - can’t remember the exact details of what I was doing but - I was using my thumb and finger to zoom in but was also scrolling it around to move into the building at the back left to get a better view of it. It crashed on me twice. @Simeon, on one occasion I posted the error message from Apple that pops up - did you find the cause?

14

@Bri_G to answer your other question, there’s no hard-coded limit on the number of models you can have.

15

@Bri_G @UberGoober @West

Codea 4 will use Lua, and will provide many of the same conventions (setup(), draw(), touched(touch) etc). However in terms of API the underlying engine is a complete re-write, and so some legacy API is no longer necessary or relevant

Stuff like mesh will be gone, although equivalent functionality will be possible. Old-style Codea GLSL shaders (Shader Lab) will no longer be supported, as we are no longer using OpenGL

2D graphics rendering will get an overhaul with better vector drawing, paths, lines, gradients, etc. Better anti-aliasing and and more consistent rendering

3D graphics rendering will be brought out of Craft and be made a first-class process within the API. There will be the concept of “scenes” (3D files that you can edit visually, attach code in-line, refer to them from your regular Codea Lua files, etc). But 3D graphics will also support “immediate” mode drawing just like sprites and other primitives, so you could drop them in your draw() call instead of having to use a scene

The voxel API from Craft may be dropped rather than ported (at least initially), as it is a fairly niche feature. Though we really like it

There’s a couple of paths we are exploring:

  1. Replace Codea 3 with Codea 4 on the App Store. Provide some wrappers that mimic the old 3.x behaviour when you run old projects (e.g., a mesh() wrapper).
  2. Release Codea 4 as a new app and maintain Codea 3.x for a little while
  3. Replace Codea 3 with Codea 4 on the App Store but include both the old (OpenGL) and new (Metal) runtimes. Old projects open in “legacy” mode and can be updated over time, new projects use the new API only. Legacy projects will not be supported on macOS (as there is no OpenGL support)

I like (2) because it’s the cleanest option available, it allows us to trim the code and keep things separate. (3) isn’t too bad as we could keep legacy support for a little while before dropping it, but it’s more effort. (1) is probably going to have issues we don’t foresee when trying to mimic old behaviour with an API wrapper

(Edit: also while (3) is a nice option, the code bloat translates to a larger app, slower load time, and larger surface area for bugs)

16

@Simeon - thanks for the feedback, all sounds pretty exciting. My thoughts on way forward - I would agree with you on 2, but the wrappers to enable retro Codea sound inviting. Is there any way the Codea community could help with those? I’ve used Love-Codea so I can run Codea projects on my PC or Mac with some success.

Thanks again and hope you get a smooth run to the launch.

17

@Simeon I like (3) for having the least impact on current projects.

But I think the user should have to choose which mode the app boots up in.

That way you never see old projects and new projects side-by-side.

And you can’t switch between runtimes without a complete reboot.

And there’s much less confusion over which features are and aren’t available in each mode.

18

@Simeon - does Apple allow you to run more than 1 version in the system ie 3 and 4?

19

@Simeon I would go with option #2. Bite the bullet and keep the code clean and small. Even though I have hundreds of projects, none of them are worth stopping progress. Any project that’s worth anything I’ll covert if it needs it.

20

@dave1707 I got to say speak for yourself there.

Not everybody writes one-tab projects in one sitting while they’re watching TV—in fact almost all of us don’t.

You’re a genius to be able to do that, but please don’t throw the rest of us under the bus because it wouldn’t affect you.