View Poll Results: Callback or Future object?

Voters
22. You may not vote on this poll
  • Callback

    9 40.91%
  • Future Object

    13 59.09%
Page 2 of 3 FirstFirst 123 LastLast
Results 21 to 40 of 45
  1. #21
    Moderator Monster's Avatar
    Join Date
    Jan 2006
    Location
    Germany
    Posts
    13,308
    Making this available via GUI seems to be a good idea. The status could be automatically returned into a property similar to the ActionActuators frameProperty.

    Even without the access to the loader the newly added objects could announce themselves after loading. Simply send a message triggered by an AlwaysSensor . Indeed this does not help if the objects are halfway loaded :P

    @Agoose77: If something is available via Actuator does not mean it is not available via Python.



  2. #22
    I really like the idea of possibly having a loading bar to show progress. I can't see how you could accomplish that with a callback.



  3. #23



  4. #24
    Future object. For the same reasons already stated by Monster.
    |+|-- BDX - A cross-platform game engine for Blender 3D
    |+|-- Game Dev video tutorials - http://www.youtube.com/goranmilovano



  5. #25
    Member JohnnyBlack's Avatar
    Join Date
    Nov 2009
    Location
    Earth>Romania
    Posts
    1,781
    Originally Posted by agoose77 View Post
    I'd prefer not to have an Actuator. In my current game, I have one logic brick, and one controller And i'd like to stay that way!
    Besides, polling it is normal anyway.
    Woah! Cmon, really? 1 logic brick, thats really impossible .



  6. #26
    Originally Posted by BlendingBGE View Post
    Woah! Cmon, really? 1 logic brick, thats really impossible .
    I think he meant 1 sensor and 1 controller. It's possible now, actually - looping through objects, performing their logic for them, animating with Python - most everything that can be done with a logic brick has a Python equivalent.

    Which reminds me that it would be cool if 2D filters could be pushed to Python.



  7. #27
    Member
    Join Date
    Oct 2008
    Location
    Melbourne, Australia
    Posts
    67
    I don't mind too much either way; both can do what we need, and both can be wrapped to behave like the other. But I think I'm leaning towards the future object. The ability to cancel would be nice, which would seem to be more natural with a future. And as for the return type, simply always return a future. The only difference would be that for a synchronous load, future.progress = 100% by the time it is returned.



  8. #28
    Member pqftgs's Avatar
    Join Date
    May 2009
    Location
    UTC -5
    Posts
    490
    A callback sounds good if it can monitor progress. We can always wrap it in our own object.
    Then again... if a future object can support cancelling, I would prefer that.
    /Undecided



  9. #29
    Member klauser's Avatar
    Join Date
    May 2011
    Location
    Scotland
    Posts
    571
    I think I would provide callbacks for LibLoad. Just being able to load an object and have it run a function when its done would be much easier than having to check the future object to see if it has completed, and then run a function. Callbacks just seem more intuitive in this way for me.

    I'm not sure how it would work, but having a callback function that returns the progress of the loading file would be awesome, but this is not essential. Loading a file without that awkward pause will be more than enough for this. I also agree that if your poking around in the source code, to maybe try and unify the variable names so they follow the same naming convention over the entire API.

    ASync loading will be a fantastic addition to the bge. With the project I'm working on at the moment, I was just about to 'get used' to the pause when libloading files, but hopefully this development has come along and solved that problem nicely

    Do you have any updates on this moguri?



  10. #30



  11. #31
    Code:
    For callbacks:
    * Consistent with BGE API (e.g., render callbacks)
    * Doesn't require maintenance (set them up and they get called when needed)
    * Less new code in the codebase (easier to review, implement, etc) #<<<<<<< thats is matter!
    
    For future objects:
    * Easier to debug/read        #<<<<<<<<<(this should be a option usenless)
    * Similar to Python's threading API



    callback again!

    PS: to import ALSO the script togheder to the obj (as the brick do) change something callback or future?
    Last edited by MarcoIT; 02-Jul-12 at 22:43.
    bit of python: http://blenderartists.org/forum/show...19#post1990019velocity max internet 56kb/second



  12. #32
    Moderator Monster's Avatar
    Join Date
    Jan 2006
    Location
    Germany
    Posts
    13,308
    Originally Posted by Moguri View Post
    * Consistent with BGE API (e.g., render callbacks)
    Could anybody show me an working example of callbacks with bge logic?
    There are so many fans of callbacks. Maybe I'm missing something.
    Last edited by Monster; 03-Jul-12 at 00:45.



  13. #33
    With the rather mixed response to future objects versus callbacks, I'm thinking it might be best to actually implement both. My thoughts are a future object that can also be used to register callbacks. To start, the future object will have the following properties and methods:

    Code:
    progress -- estimate of how much of the load is done (will just be 0 and 100 to start)
    libraryName -- the name of the library being loaded (the first arg to LibLoad)
    timeTaken -- the time it took to load the library
    onProgress -- callback to be used when the progress of the load updates
    onFinished -- callback to be used when the loading is done
    By having LibLoad return this object, it would still be simple (although maybe not entirely obvious) to just use the callbacks and not mess with the future object much. So instead of:
    Code:
    bge.logic.LibLoad('mylib.blend', 'Scene', async, async_callback=llcb)
    you could do:
    Code:
    bge.logic.LibLoad('mylib.blend', 'Scene', async=True).onFinished=llcb
    @Monster
    On of the main reasons I like them is I can set them and forget them. In other words, I don't have to waste time constantly checking in on things. This is one of the nice things about event driven programming, which callbacks facilitate.



  14. #34
    Moderator Monster's Avatar
    Join Date
    Jan 2006
    Location
    Germany
    Posts
    13,308
    Hi,

    I know about callbacks and I know they are heavily used in a lot of frameworks. As Java RCP-Developer I'm more used to listeners rather than callbacks. Both systems are quite nice and encapsulate "user logic" from the core processing.

    I wondered about the statement "Consistent with BGE API (e.g., render callbacks)". As far as I see render callbacks belong to Blender not to the BGE respectivly the BGE logic.

    Currently I can't see callbacks somewhere at the current BGE logic. That was the reason why I asked where to find them.

    Because of that I think you need to add a complete new concept on top of or beside the existing event systems (SCA). I'm worried that this is a bit out of scope of the topic "Threaded Loading". I fully understand your question what we would like to get.

    Somehow I have the impression some people see callbacks as the "magical super weapon" against logic bricks (which seems to be not that super ).

    One of the problem I see with callbacks is, they do not have the usual context of the BGE Python code. E.g. current controller, current object, current scene. The context would be essential as the user would try to get the information from the callback into the BGE logic.

    It is also a timing issue.
    When is a callback called? (At sensors evaluation? At controller execution? At actuator running? What is the order? )
    With multiple scenes running the scenes are processed one after the other. When does the callback trigger? (I guess loading belongs to a specific scene).
    This is important as the user usually needs to know when the code is executed (before or after other logic).

    Callbacks completely bypass the SCA (as they do not fit into the SCA event-system). This means they will not be available for non-programmers.

    The progress bar feature is mainly asked by noobs (I guess because advanced BGE users know it is currently not possible). Beginners are usually not really hot to add code (if they even know what a callback is).

    Anyway, if moguri can add both then I'm happy about it.

    In near future a developer should be able to wrap your future object with an LoadingActuator. The benefits are:
    + easy to use GUI (useful for beginners and experts)
    + perfectly fitting into the SCA-scheme
    + user defined activation
    + auto-deactivation after loading -> which means you can use an actuator sensor
    + (optional) similar to the ActionActuator it can write the estimated percentage into a property -> Progressbar!
    + as usually the actuator can still be configured and activated via Python controller.
    + Python purists still do not need to use them as it is a wrapper.
    Disadvantages:
    - someone has to implement is

    I do not think we need this as logic block right now, but we should keep this in mind and in the design.
    I'm not sure if the ActionActuator is even possible with a callback.

    Thanks for reading
    Monster



  15. #35
    Member agoose77's Avatar
    Join Date
    Aug 2010
    Location
    United Kingdom
    Posts
    6,791
    To be honest, the main reason people want asynchronous loading of libraries, is so that their game doens't freeze for such long loading durations. However, by using a callback, which is called on_finish (or something like that) then you cannot check the status of loading. Thus, you would still have to display the loading screen during that time, the only difference is that now your loading screen could have some moving images.
    If you were to use a __future__ object, the ability to read an attribute that returned the percentage or data progress, then you could go one step further and have a moving, realtime progress bar.
    With the aforementioned feature, it would be much harder to find an advantage of any other engine to the BGE.
    I thought, at first, that Monster was asking for an Actuator - only loading feature. However, if he believes that a solution that incorporates both would be good, then I am in agreement with him. The ability to load and set a property to the progress of a loading library would greatly open up new oppertunities to non-programmers.



  16. #36
    Member kilon's Avatar
    Join Date
    Sep 2007
    Location
    Greece , Athens
    Posts
    1,695
    why not use multiprocessing which is the only module that can do true threading and take advantage of multiple cores ....
    http://kilon.blogspot.com/ <--- This my blog, you will find things i make here like music, 3d and 2d graphics and python programming.




  17. #37
    Member
    Join Date
    Oct 2008
    Location
    Melbourne, Australia
    Posts
    67
    Hi Moguri, the future + callback design looks good. Nice work!



  18. #38
    @Agoose77 - You could have a loading bar with a callback. Moguri's example already shows that it would allow you to see how much of a percentage an object or scene is loaded - you could set the loading bar scaling in the middle of that (instead of printing out the percentage of the object loaded like in Moguri's example).

    @Monster - I don't really see the problem with callbacks. You would have to use Python to use callbacks or even have and set up a loading bar, so it seems clear to me that only programmers would have access to them. I don't see how you would make a loading bar with only logic bricks - don't you have to use Python to set the actual scaling variable (can you use a property sensor to set a property to obj.scaling.x, for example)? You're right that it doesn't quite fit into the SCA, but one could assume that it would run as an 'invisible' Python controller.

    And I like the idea of both. I think a future object that allows you to use callbacks allows you to use what you want and gives you the capabilities and advantages of both. Honestly, since either one allows you to do the same thing, it doesn't really matter (neither is worse than the other), so either way, asynchronous loading would be great to have.



  19. #39
    Moderator Monster's Avatar
    Join Date
    Jan 2006
    Location
    Germany
    Posts
    13,308
    Originally Posted by SolarLune View Post
    You could have a loading bar with a callback. Moguri's example already shows that it would allow you to see how much of a percentage an object or scene is loaded - you could set the loading bar scaling in the middle of that (instead of printing out the percentage of the object loaded like in Moguri's example).
    Moguri's example shows the callback function gets called when loading is done = 100%.

    Originally Posted by SolarLune View Post
    @Monster - I don't really see the problem with callbacks. You would have to use Python to use callbacks or even have and set up a loading bar, so it seems clear to me that only programmers would have access to them.
    Exactly that is one of the problems I see . We should clearly avoid solutions that are accessible by Python only. The advantage of the BGE is you do not need to use Python but you can.

    Originally Posted by SolarLune View Post
    I don't see how you would make a loading bar with only logic bricks
    With the suggested LoadingActuator it would be quite simple:
    • Set up the LoadingActuator with an progress property "progress" as float.
    • Set up a ActionActuator with property mode playing property "progress"
    • Activate the ActionActuator on property change of "progress"
    • Activate the LoadingActuator whenever you need

    the ActionActuator simply plays whatever you need for a progress bar (e.g. scale) see the HealthBar-tutorial.

    Both solutions demand a synchronized value transfer (percentage).

    BTW. I suggest to normalize the percentage (0.0 .. 1.0) rather than (0 .. 100)



  20. #40
    Member agoose77's Avatar
    Join Date
    Aug 2010
    Location
    United Kingdom
    Posts
    6,791
    Or you could just use an Action for scale etc. It's been done for health bars etc..
    I'd much prefer an object that i could poll when needed, rather than calling a callback every percentage / tick.
    I also agree, that it shouldn't be a Python only solution, when it would be possible to integrate into an actuator.



Page 2 of 3 FirstFirst 123 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •