It looks like you're new here. If you want to get involved, click one of these buttons!
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.
Comments
@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.
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.
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.
@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?
@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.
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?
@Bri_G @UberGoober No matter what I did, zoomed in, zoomed out, it didn’t crash for me. iPad Air 3rd gen 64GB.
@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?
@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
meshwill 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 OpenGL2D 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
Craftand 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 yourdraw()call instead of having to use a sceneThe 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:
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)
Thanks again and hope you get a smooth run to the launch.
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.
@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.
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*.
@UberGoober I’m not throwing anyone under the bus and I’m not saying it won’t affect me. @Simeon asked what option we preferred. I preferred 2, you preferred 3. Will Simeon pick 2 because I preferred it, no. He’s going to do what he thinks is best for the continuation of Codea. If I have to convert projects because they don’t work in the newer version, I will or won’t depending if they’re important to me or not.
@Simeon Would there be a way to keep both versions of Codea. Have a latest version 3 that would no longer be updated, but can be loaded on the iPad, iPhone like normal along with version 4 that goes forward with updates. That way all the old projects can be run on version 3 or copied to version 4 and updated if required. There would be a Codea 3 app and a Codea 4 app. Codea 3 would no longer be updated but continue to work until it wouldn’t run anymore on newer iPads.
That would be similar to iLuaBox Pro that I still run on my iPad 1. It’s been dead on the App Store for many, many years, but as long as I don’t delete it from the iPad it’s still as good as it was on it’s last update.
@dave1707 that would be option (2). Keep Codea 3 on the App Store, and release Codea 4 as a new app. Codea 3 could continue to get bug fixes. Eventually, once everyone has migrated their code, Codea 3 can be removed from the store
@UberGoober the API will be largely the same so it certainly isn't all being flushed down the toilet. It's more about the immediate impact of upgrading — i.e., I don't want to release an update to Codea that requires migration to all your existing code (even if they are minor changes) before you can run your projects. I don't think option (2) would be bad for you: you can still load into Codea 3 to access and run your projects, and you can copy them into Codea 4 and migrate them at your own pace
So just to be clear under option (2) Codea 3.x would remain on the store, perhaps with a notice "Do not purchase this, it has been replaced by Codea 4", have its icon changed to a "legacy" icon, but continue to receive bug fix updates for six months or more. And it could be run side-by-side with Codea 4
@Simeon I was thinking that Codea 3 could stay out there until it would no longer work on any iPad/iPhone because of hardware/software requirements. It would be accessible to anyone with Codea that wanted to still run Codea 3. It wouldn’t be updated after a certain point, but just left to die a natural death like other old apps. Hopefully by then everyone would be using Codea 4 and not miss Codea 3.
@Simeon thanks outlining the possible ways forward. Option 2 makes sense in terms of an application but will probably have the biggest impact in terms of this forum as a resource with the wealth of examples which have been built over many years. There will be the current active user base who will likely embrace the transition but the entry point for new users (in terms of support and examples) will need thought. Will Codea 4 still be called Codea? Who is your market for version 4? What will the "typical” Codea user look like and want to get out of Codea?
@dave1707 the only problem I have leaving Codea 3 on the App Store is that I don't want people to accidentally purchase it when Codea 4 is available. Perhaps it can be removed from sale but still made available to those who want to re-download it from their purchases list
@West I am not sure what a typical Codea user looks like, we have just been building it because we like it
It will be similar enough that it will still be called Codea. Good point about the forums, perhaps we will use the update to transition to a new discussion platform — something with much better spam prevention hopefully
@Simeon Thats kind of what I had in mind. Codea 3 wouldn’t be for sale, but still available to Codea 4 users. Like on TestFlight where we can download previous versions of Codea but be able to have both Codea 3 and Codea 4 on an iPad/iPhone.
@skar @Simeon There wouldn’t be multiple apps to maintain. Once Codea 4 is available, that would be the end of updates for Codea 3. It would be there for Codea 4 users to use as is, but without anymore updates.
@skar I guess the biggest problem I have with (3) is that we would be shipping tens (or hundreds?) of thousands of lines of code more than we need to. We would also have to maintain a legacy project format, a different UI for loading legacy projects that locks out new features, and ability to migrate a legacy project to a new project
We kind of get all that "for free" by keeping Codea 3 on the App Store, where you can migrate your project when you're ready by dragging it into Codea 4 in the Files app and working on it from there, while keeping Codea 4 slimmer and more focused
Personally, I like (1) and (2) the most. From what I've seen, the update is by far the biggest Codea has recevied as of yet, so I feel it's a fair choice to release Codea 4 as a new app. I'm quite worried about how much of the compatibility will be broken, though, as my project relies heavily on
meshand shaders. From that standpoint alone, I think it would be good to have two separate spaces.However, providing wrappers e.g. for mesh would really really help and make the transition smoother. Otherwise, migrating larger projects will be needlessly difficult/frustrating. Especially if you are short of time, it's frustrating to rewrite code that already used to work.
@Elias yes I think we would be providing wrappers for legacy Codea functionality. Something like a legacy module where you can redefine
meshby usingmesh = legacy.meshOr something like that. These would be written in Lua and we could make the code editable and part of Codea 4
Hopefully no one minds if I refer back to OT for a moment: would anybody be interested in me finishing this?
It was heartening to see @Simeon write that it seemed useful.
Right now I’m just chopping up the pieces and posting them as individual tools (it’s improving the code a lot actually).