I was trying to draw an ellipse in the draw function and make it move around. My error was that the ellipse() function doesn’t return anything, so I might be able to store the returned ellipse and modify it via its properties. Why was this designed this way? It seems to me that constantly drawing/clearing the screen @60fps is a poor use of resources. Perhaps I don’t know enough about how to draw objects efficiently, but i was trying to do something like this:
setup()
fill( 255, 0, 0 )
circle = ellipse( 20, 20, 20 )
end
draw()
circle.x = circle.x + 1
end
What stuck out to me was that for objects like tables, if you go “print( table )”, it’ll print the hex memory address of the table. So, why not make it so that we can modify object pointers in the draw() function, instead of having to regenerate and reposition them every frame? I don’t know how codea was implemented, so maybe this fundamental design choice would require a re-write from the ground up, which no one wants to tackle.
@matkatmusic - for the things you want, there are plenty of other languages.
Codea is completely different. It is for making animations/dynamic games, which is why the screen redraws so often. Nobody is going to rewrite it, because it is perfect for doing just that. When you understand it properly, you will see that.
If you want to do animations, including all sorts of games, then you’re in the right place. If you want to build a static form-like screen, I suggest you try something else.
but (if you’re going to give it a go) you should really start further back, by learning some Lua. There are tutorials and ebooks on that, too, in the wiki link above.
I’ve seen Codea apps with hundreds of physics objects on the screen. There is some slowdown with collisions, and the developers are working on this, but normally you shouldn’t notice it.
I have modeled all kinds of things on my iPad 3 retina, and it has been fast enough most of the time. Currently, I’m drawing two 3D aeroplane models with thousands of vertices and lighting shaders, and still getting 35-40 frames per second.
But first, you really need to understand how Codea works. It automatically draws 60 times a second because it is effectively an intelligent movie maker. It uses OpenGL for graphics and Box2D for physics, both top class libraries. If you want to learn about 2D and 3D graphics, there is no better tool.
The strongest recommendation I can give you is that there are many people on this forum who use Codea every day (myself included), and I’m guessing that we all came from a conventional programming environment where you put an object on the screen and then changed its properties. But then we discovered the beauty of Lua and the power of Codea, and speaking for myself, I have not had so much fun in 25 years of programming.
I recommend you read up on it a little more, have a look at some of the projects being discussed on the forum, and have a go at your project. We will be happy to help with any problems.
@natkatmusic Redraws at 60FPS is a strange paradigm, but if you are working in graphics, it solves tons of issues! Having draw() and touch() methods to hook into means you can hook in pretty much anything without worrying about coroutines (thread-like critters).
It takes me back to the Atari ST days where you used the VBL (the time slice called the vertical blank where the RGB guns in the monitor moved from the bottom back up to the top of the screen. ) You would swap out your drawn screen buffer here and get zero flicker. The VBL ran every 60th of a second (or 50th, depending upon how many cycles your country’s power runs.)
If you have objects that are not going to move often, if ever, just flatten them all into a screen-sized image and blit that image as a sprite the first thing in the draw() loop. Then, you only need to worry about the moving-around bits. Suddenly, that slider is always on top and moves smoothly about.
@ignatz I tried to bung up a quick utility in Java just to process a text file and spit out some stats on it. I was swearing well into the wee hours of the morning, cursing some of Java’s awful design. Figuring out how to iterate through a hash table was painful… And setting up files for input and output makes for eye-gouging Greek tragedy. Using Lua (aside from the loose syntax that keeps sticking its foot into the aisle and tripping me) is a revelation to use. Whole-heartedly agreed: it puts the FUN back in functions.
I was looking at the sample code for the Invaders game. Is it really the best choice to call “Invader:draw()” 60 times a second to render the triangle? the function invader:draw() itself isn’t exactly short…
I guess i’m more wondering about how many instructions can Codea handle for each frame, and is there a way to display the amount of remaining processing power per frame? I noticed a fair amount of slowdown in the Physics demo, particularly on the test where you tap on the screen and it generates new Physics bodies that collide. When there were around 15+ bodies on the screen, there was a noticable slowdown in framerate. I’m on an ipad3 retina. I’m asking these questions because I want to create a game like “papa pear saga”, which is a collision/physics game at it’s most basic element.
Ellipse is just drawing something, it’s not an actual ellipse but instead a function that draws a bunch of pixels in an ellipse. It has no actual concept of size, position, rotation, velocity etc - just a bunch of pixels it’ll light up according to those rules.
It sounds inefficient to re-draw the scene many times a second, but this is how almost ALL games draw, and movies, and even web browsers! Think about it - how else would things move? Pixels cannot move, you can only light up different ones creating the illusion of movement, and the ellipse function just draws on pixels. Even turn-based games where nothing moves until a turn are usually redrawed at 60 fps because they’ll have UI elements and menus and a moveable camera.
Essentially - drawing something once and moving it requires drawing it again anyways. There is no performance difference whatsoever whether the function returns an object where you can change the position or not, because it needs to be re-drawn anyways!
