|
Posted By
|
Message
|
![]()
eyeangle
Registered
12/06/2003
Points
1683
|
22nd September, 2012 at 22/09/2012 15:33:18 -
I've made a scrolling level but when my character dies I have him re-position back to the start of the level.
I'm using another active object that is always on the sprite that is the centre of the scrolling. So when my character dies, he is re-positioned back to the start of the level the invisible active camera object travels back at high speed to the sprite at the start of the level.
But when the screen gets back to the sprite it's always fallen through the floor and is not there. The custom movement works fine, so I know it's not that. But it seems that the custom movement isn't working when it's far away from the centre of the screen.
Any ideas how to fix this?
theonecardgame.com
|
Sketchy
Cornwall UK
Registered
06/11/2004
Points
1970
 
|
22nd September, 2012 at 22/09/2012 15:53:37 -
Make sure "Inactivate if too far from window" is set to "No", and that "Handle background collisions outside of window" is ticked.
n/a
|
hapsi
Registered
13/11/2003
Points
775
|
24th September, 2012 at 24/09/2012 08:50:28 -
This is kind of an offtopic but does the "Inactivate if too far from window" option slow down the game much. I have this option in every object in my current project. ..no slowdowns but my crappy computer isn't that crappy. Runs gta IV in medium gfx setting.
 Edited by hapsi
[Signature][/Signature]
|
The Chris Street
Administrator
Unspeakably Lazy Admin
Registered
14/05/2002
Points
48488
      
 
|
24th September, 2012 at 24/09/2012 16:45:56 -
I bring your attention to this topic. It's very long but worth looking at. Lots of hints for optimisation, including using quick backdrops rather than standard backdrop objects:
http://community.clickteam.com/showthread.php?t=72914
But in summary (and this is a quote from Simon at Clickteam in response to a users problem), these are examples which could slow a game down:
* fine detection being enabled for all objects and backdrops (where relevant) rather than much faster box collisions
* save background set for objects which never need to redraw the background
* inactivate if too far from window switched off for everything
* no optimisation to disable objects which are invisible off screen, everything was running everywhere all at once regardless. This doesn't necessarily need to include enemies - things like coins, powerups etc. (which are static and don't move around) can all be frozen when out of sight for example to improve efficiency (as I said above, MMF has an option to do this automatically but you had it disabled on all objects).
* costly conditions such as overlapping/collision tests repeated multiple times rather than testing once and using such as determining whether an active has move since the last check etc. to reduce the need for further collision detections (just one possible technique).
* object selection in loops not sufficiently narrowed/focussed, resulting in unnecessary processing of objects which for which no processing is required.
* costly loops running more times than necessary, increasing the burden on the runtime
n/a
|
AndyUK
Mascot Maniac
Registered
01/08/2002
Points
14586
|
27th September, 2012 at 27/09/2012 04:56:20 -
Considering the original Klik and play engine was designed to run on something like 66mhz computers I don't think those old options have much impact on the processing power of modern computers.
.
|
|
|
|
Advertisement
Post Reply