? Lowerdash General Questions thread (Page 2) ● SmileBASIC Source Forums

Sign In

Register
*Usernames are case-sensitive
Forgot my password
This website has been moved, please see this post

Lowerdash General Questions thread

1 2
  • #21 ✎ 124 kldck_hul First Month Joined in the very first month of SmileBASIC Source Website Scholar Received for knowing a great deal about programming topics Achievements Zelda Is Awesome! I love The Legend Of Zelda! Express Yourself Can you try to post more code from your main program? Edit: I can reply to miiverse posts. Also, ignore the thing about ACLS, its late, and I don't think ACLS actually clears the memory, just the graphics. Posted Edited by kldck_hul
  • #22 ✎ 131 raimondz First Week Joined in the very first week of SmileBASIC Source Website Expert Programmer Programming no longer gives me any trouble. Come to me for help, if you like! Programming Strength Night Person I like the quiet night and sleep late. Express Yourself 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). Right now I'm using modules with arrays, static method and dictionary for constants. 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. Posted
  • #23 ✎ 124 kldck_hul First Month Joined in the very first month of SmileBASIC Source Website Scholar Received for knowing a great deal about programming topics Achievements Zelda Is Awesome! I love The Legend Of Zelda! Express Yourself
    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.
    Posted Edited by kldck_hul
1 2