Building during runtime
closed account (4w0o1hU5)
I have used the ensuing structure to avoid lag. How may it be improved, delay still occurs
|
|
Last edited on
its not a telegraph, you can use more words at no extra cost per post.
the syntax looks borky, is the void H stray is H a macro or ?
why do you have a parameter you don't use?
what delay, and where is it? did you compile in release mode / optimized mode?
is this part of a GUI that has slow ramp-up background stuff?
What else can you tell us?
the syntax looks borky, is the void H stray is H a macro or ?
why do you have a parameter you don't use?
what delay, and where is it? did you compile in release mode / optimized mode?
is this part of a GUI that has slow ramp-up background stuff?
What else can you tell us?
closed account (4w0o1hU5)
Sorry @jonnin this is my first post, I surmised the shorted the more commendable.
It's the calling of a function. In a nutshell, the code is a method with a function, rather than a method containing a list of actions. I made it a single function to avoid runtime lag, however lag still occurs, If you could tell me, this is the more efficient way possible, I will have heard all I need.
void H was an error now corrected| why do you have a parameter you don't use? |
It's the calling of a function. In a nutshell, the code is a method with a function, rather than a method containing a list of actions. I made it a single function to avoid runtime lag, however lag still occurs, If you could tell me, this is the more efficient way possible, I will have heard all I need.
calling a function from the method may or may not cause overhead just for calling the inner function. But we are talking 10s of clock cycles, and your clock cycles over 3 billion times per second. Either way, this is unlikely to be your issue esp. for a button press (assuming that is what we are looking at from the names).
So I ask again.. what lag?
if you do this, it should be more or less instant:
void HelloWorld::ButtonX(cocos2d::Ref *pSender)
{
;
}
and if that is the case, then the problem is inside "function()" which we can't see.
and we still don't know if you compiled it with debugging, or much else. Debugging enabled can add 1-2 orders of magnitude to execution time.
how much lag are we talking about? Any true actions take clock cycles. But 1/10 of a second is enough time to process millions of items too. Anything you can point to as a human and say "that was sluggish" is too slow (unless doing heavy lifting that has expected delay). Also, if you punch a button to do slow things, kick that off in a thread, and let the user continue to poke other things if possible, and if not possible, at least draw a 'wait for it' thingy at them.
cocos2d::Ref *pSender still looks like an unused param to me.
So I ask again.. what lag?
if you do this, it should be more or less instant:
void HelloWorld::ButtonX(cocos2d::Ref *pSender)
{
;
}
and if that is the case, then the problem is inside "function()" which we can't see.
and we still don't know if you compiled it with debugging, or much else. Debugging enabled can add 1-2 orders of magnitude to execution time.
how much lag are we talking about? Any true actions take clock cycles. But 1/10 of a second is enough time to process millions of items too. Anything you can point to as a human and say "that was sluggish" is too slow (unless doing heavy lifting that has expected delay). Also, if you punch a button to do slow things, kick that off in a thread, and let the user continue to poke other things if possible, and if not possible, at least draw a 'wait for it' thingy at them.
cocos2d::Ref *pSender still looks like an unused param to me.
Last edited on
cocos2d is a game building framework.
It is likely this is running as an animation loop. The delay would be associated with that animation loop and is typical. It is why game developers insist on a minimum of 30 fps, or 60 fps where possible, so the lag between frames is minimal.
It is part of the large problem of game writing and design. There's just no way around it for the most part, where "delay" or "lag" is the perceived time between input from a control and the visual feedback rendered in the game loop. If the game loop is running at 10 fps, there will be at a minimum a 1/10th of a second before one can see the result of an input.
If the input response functions run in the same thread as the animation loop, it can be until the next frame cycle before the function can be called, because the animation loop is designed to run various stages in that loop, from input to calculation to rendering. If the user hits a button while the loop is in the calculation phase, for example, the input can't be processed until the rendering step completes and, on most occasion, waits until the display refresh signal is received to allow the loop to cycle.
The only way to get the input processing close to the moment input is made available is to process the input in threads. This is highly dependent on the engine design, and I don't know cocos2d well enough to advise if that is even possible in that framework, but the idea would be to run the device input in a thread, and thus the response functions to such input in a thread, but that still doesn't make the animation loop run faster, so while the input may be "sensed" sooner, the feedback to the user still won't appear until the next animation loop cycle.
I should say that is visual feedback. It is possible that other forms of feedback, like sound or input device responses (a shake in the joystick, for example) could be handled outside of the graphics frame loop.
It is likely this is running as an animation loop. The delay would be associated with that animation loop and is typical. It is why game developers insist on a minimum of 30 fps, or 60 fps where possible, so the lag between frames is minimal.
It is part of the large problem of game writing and design. There's just no way around it for the most part, where "delay" or "lag" is the perceived time between input from a control and the visual feedback rendered in the game loop. If the game loop is running at 10 fps, there will be at a minimum a 1/10th of a second before one can see the result of an input.
If the input response functions run in the same thread as the animation loop, it can be until the next frame cycle before the function can be called, because the animation loop is designed to run various stages in that loop, from input to calculation to rendering. If the user hits a button while the loop is in the calculation phase, for example, the input can't be processed until the rendering step completes and, on most occasion, waits until the display refresh signal is received to allow the loop to cycle.
The only way to get the input processing close to the moment input is made available is to process the input in threads. This is highly dependent on the engine design, and I don't know cocos2d well enough to advise if that is even possible in that framework, but the idea would be to run the device input in a thread, and thus the response functions to such input in a thread, but that still doesn't make the animation loop run faster, so while the input may be "sensed" sooner, the feedback to the user still won't appear until the next animation loop cycle.
I should say that is visual feedback. It is possible that other forms of feedback, like sound or input device responses (a shake in the joystick, for example) could be handled outside of the graphics frame loop.
closed account (4w0o1hU5)
| This is highly dependent on the engine design, and I don't know cocos2d well enough to advise if that is even possible in that framework |
TransitionSceneSlide, however the asset created as a result of clicking the button, is oversized, as in 70% image, 100% empty space radius
So I ask again.. what lag? |
1/2 a second delay.
Last edited on
, however the asset created as a result of clicking the button, is oversized, as in 70% image, 100% empty space radius
this sounds like the core of the issue, not how you called it.
I don't know the first thing about your library, but you should pull "function()" apart, see what is taking the time inside it via profile.
I would take a long, hard look at anything that allocates or deallocates memory in there, and all loops (and calls to functions that loop that you did not write). Also might look up or ask in a dedicated forum about what you want to do, how you are doing it, and could it be better. Sometimes the fastest way to do stuff is weird.
this sounds like the core of the issue, not how you called it.
I don't know the first thing about your library, but you should pull "function()" apart, see what is taking the time inside it via profile.
I would take a long, hard look at anything that allocates or deallocates memory in there, and all loops (and calls to functions that loop that you did not write). Also might look up or ask in a dedicated forum about what you want to do, how you are doing it, and could it be better. Sometimes the fastest way to do stuff is weird.
@GolBer,
Yet, you missed the point of the sentence you quoted, where it finished with:
Focusing on the "...response functions to such input...", which is a feature one may access depending on the engine design.
If the engine supports loading assets in threads, then load the asset in the thread.
What you've stated all but proves the point I was making is quite close to correct. The animation loop is being stalled. Pre-staging the asset may be an alternative means of handling the problem. If you're loading the asset inside a response function, time how long that takes.
There may be nothing you can do aside from changing the engine to speed up the loading time of that asset.
You could redesign the asset, or you could see if the engine permits pre-loading of the asset (leaving it invisible), where this button response no longer loads the asset, but enables its visibility (and position, likely).
| It would not suspect engine design, cocos2d-x is widely trusted, and my other buttons work fine, the ones which use the engine's commands, such as: |
Yet, you missed the point of the sentence you quoted, where it finished with:
but the idea would be to run the device input in a thread, and thus the response functions to such input in a thread, |
Focusing on the "...response functions to such input...", which is a feature one may access depending on the engine design.
If the engine supports loading assets in threads, then load the asset in the thread.
What you've stated all but proves the point I was making is quite close to correct. The animation loop is being stalled. Pre-staging the asset may be an alternative means of handling the problem. If you're loading the asset inside a response function, time how long that takes.
There may be nothing you can do aside from changing the engine to speed up the loading time of that asset.
You could redesign the asset, or you could see if the engine permits pre-loading of the asset (leaving it invisible), where this button response no longer loads the asset, but enables its visibility (and position, likely).
Topic archived. No new replies allowed.