It’s been a while since I did any kind of official update on Codea 4, and I’ve mentioned it on Twitter as well as in various threads when its come up. So I thought I may as well make an official thread to talk about it. I’ve started writing an introduction / migration guide to explain all the differences with the feature set, engine technology and any API changes that break backwards compatibility
Obviously Codea 4 isn’t out yet and won’t be out for a while but I really want to get at least a beta out to testers very soon. This is the biggest and more fundamental change to the engine that we’ve ever done and has taken years of our time. I want it to be as well received by the community as possible, but obviously that requires time and feedback from testers and users. Some of the changes might surprise or even annoy some of you, but I do believe its a big step forward
@binaryblues
The documentation is a work in progress so some stuff hasn’t got a mention yet.
craft.noise can be put back in fairly easily. The entire voxel system is pretty complicated but I want to give it the same treatment as everything else (more streamlined and tightly integrated). It just hasn’t been done yet.
This release is an opportunity to rework systems, so I’d been keen to hear if there’s specific ways voxels can be improved. I think my mistake the first time around was underdocumenting it but also it being such a big complex system in the first place. I almost just want to have voxel volumes that are really flexible without requiring a lot of setup
It’s nice to hear that voxel systems can be maintained, and I think it has a lot of potential and is well worth the time it takes to maintain it (for developers) , it is also well worth the time spent in-depth learning (for users) .
But it was also complex enough that it took me a while to understand its basic use. Regarding the system documentation, I’ve been going through the Codea4 documentation, and it feels like a big deal.
Do you need the assistance of the community? I’m talking about documentation assistance. I’m sure there are plenty of people who would be happy to help, including me, if necessary.
@John - thanks for adding this thread. As I’ve mentioned before 4 looks very interesting from the hints you’ve posted previously and from your initial documentation. Codea support and documentation has always been good so I’m expecting to pick up any changes soon. I agree that a little more information/tutorials would have helped with voxels in 3, maybe some YouTube video tutorials? Or you could leave that to the users.
Waiting in anticipation. Thanks again for the thread
Edit: could be useful up front to let users know if there are any limitations on what kit can support it and any limitations - like introduction of metal etc.
@binaryblues
The documentation is hosted on github and is automatically regenerated from source when new commits are pushed. So any approved pull requests will automatically update it. In case you are interested we’re using https://www.sphinx-doc.org/en/master/ for our new documentation
@Bri_G
I’ll be sure to add a section that will make note of any features that are missing and still in the works. From off the top of my head the following are currently missing:
Voxels
AR
Sensor data - camera, accelerator, gyro, magnetometer, GPS
Noise functions
On the bright side the new internal engine structure is very modular and makes it very quick to add new features / integrations
Some new features that have been added that I haven’t really talked about:
Built-in UI system (still in early stages, similar to Unity 2D Canvas and Shade UI)
Compute shaders (including a falling sand demo I’ve done)
ImGUI support (experimental)
Skeletal animation
Shadow maps
New tween system
Keyboard events (key press/release events)
Gamepad support (i’ve tested this with my PS4 controller on both bluetooth and directly connected)
There’s also the scene editor, which is still a work in progress
Can’t wait to try it out, seems like it will be straight forward for 2D ~but I wonder about shaders, will raw glsl code still work?~ oh never mind you already answered this and the answer is yes can still use glsl
@skar Yes, we have a shader cross-compiler from GLSL to MSL. No doubt we’ll run into bugs here and there since the process isn’t 100% reliable. But at least we get compute shaders!
Sounds promising! If you want a wishlist, it would be nice with a moveandslide() api for physics similar to godot, to more easely make platformer physics. A simple version of a numpy like api for working with image data would be nice for general algorithms. And looking into the possibility to use gps and bluetooth in the background (maybe not possible) would open up for some more use cases. Well the list could be longer
@Simeon@John not to put a damper on things but I didn’t notice any docs regarding breakpoints and debugging. There was previously a mention of the possibility and desire to add better support for debugging so I hope it hasn’t been totally forgotten. I got stuck on a bug that was really difficult to figure out using print statements.
@tnlogy The move_and_slide() function for their KinematicBody class looks interesting. Not exactly sure how to implement it (Some kind of one way collision processing I presume). At the very least we’ll have kinematic bodies that can be moved manually, will have to look into this kind of thing though. As for image processing I’ve found that compute shaders work pretty well and I have made some image filter classes using them
@skar I’m still looking into proper lua debugging. I’ve actually got some stuff working with a socket-based remote debugger, but I need to build a front end to both control and display the results. I wanted to prototype one using Codea itself but you end up with a paradox (lua is frozen while being debugged). I also tried multiple multithreaded instances running in parallel but that comes with a host of issues. So I think either a web-based javascript debugger or a native swift-ui one will probably have to do. Still needs more work. Either way the debugger will exist inside and be possible to remotely access, but might require some hacking before an official debugger interface is built.
@John you can check out their code at https://github.com/godotengine/godot/blob/master/scene/2d/physics_body_2d.cpp#L1103 but it is a bit messy, since they have some special cases for moving platforms etc. I tried to implement something similar with Codeas api, using raycast and Kinetic body, but didn’t succeed. To have a similar API would simplify things a bit. Another perspective on it would be to enable collision checks between kinematic and static bodies in box2d, like in defold https://defold.com/tutorials/platformer/
@moechofe2
There are quite a few reasons. The current runtime is around 10 years old now and many of the technical decisions over the years have made maintaining it much more difficult than it should be and have made it all but impossible to support certain features
Goals for Codea 4
Changing render API from OpenGL ES to Metal (future proofing)
Moving closer to a pure C++ backend (future cross-platform support)
Merging redundant or duplicated craft features (mesh/model, texture/image, shader/material, etc)
Streamlining various API calling conventions
Improving Lua bindings (making new features easier to add in future)
Compute shader support (impossible with OpenGL ES on iOS)
Editor support and scene serialisation
Reduction of technical debt, spaghetti code and making overall engine design more modular
Built in 3D movement commands would be nice (e.g. Entity.move.forward or Entity.move(vec3(x,y,z)) where x,y,z are movement relative to the entity rather than x,y,z coordinates in the 3D scene).
Just a note as well in Codea 4 you can add new functions to existing built-in types.
So if you wanted to you could do this:
LOCAL = 1
GLOBAL = 2
function entity:translate(t, space)
space = space or LOCAL
if space == LOCAL then
self.position = self.position + self:transformDirection(v)
elseif space == GLOBAL then
self.position = self.position + t
end
end
