Lowerdash General Questions thread

Hi, I want to know how is the performance of the object and if it's reliable to use them. I remember that in V0.2, calling a method of an object was slow and the ball program run slow(Well, this issue is also related to the performance of graphic function. If you use sprites then that issue could be removed).

There may be a slight bug with inheriting members in 0.5, but its entirely fixed in 0.6. The new release will also feature more debugging features including compiler errors, and call stack tracing - hopefully to catch dumb things like what happened in 0.5... Calling an object will still always have a lookup. I've tried to make this fairly quick, but its only 20% or so faster. The important thing to remember is that every me("") in an update method is also a lookup. So an update method with normal variables will be fast. A long one with lots of self references will slow down quickly (probably should have a recommended number). I've been finding its much easier to get around this data limitation using the more traditional method, where entities are created and have a management id that indexes into one or more arrays. I've written some allocation code and used it for example in my physics module. I still have a "class" that then provides accessor methods to those arrays (instead of Lowerdash's) and can be inherited from. On the roadmap for 0.7, I plan to ship a command to build this kind of module automatically. Using a unified entity ID allows 1:1 speed, while still having direct access to any single object's properties. Since 0.5, Create and Delete are significantly faster, as instances are passed as data now.

Most of my programs consist on a game loop module that call the input_, update_ and delete_ method of the current "Screen" module. Each Screen has 5 method: init_, destroy_, input_, update_ and render_. Each module used in the screen (For example entities, camera, map, etc) could have any of the previous methods and they are called on the corresponding method of the screen.

This is almost exactly what my game library does. As I've said, Physics and a few other Entity Components are all managed by a single module, meaning fewer update methods and way fewer lookups.