Just tried the update, haven't seen everything, but upon going to preview, something that stood out was that the boss monster is drunk on powers it shouldn't have: sub-mach speeds. I haven't touched the game since before the udpate, perhaps this is what they mean about redoing the rules for some actors? Although what he is doing has nothing to do with collisions. o _o
Glitched boss:
Normal boss behavior:
My game doesn't rely much on the physics engine except for speed/acceleration. Collisions are only used to record damage and have an actor platform to stand on, which means the getting stuck in another actor bug due to high speeds is a rare occurrence in the game. Mostly since half the characters pass through the enemies as part of the gameplay since the beginning so as to not get blockaded by them.
A lot of "collisions" in the game are just interpolates on position or velocity, set to a short duration such as 0.2 so as to give the illusion that the character was stopped by something.
Which is why I'm really interested in the option to remove the BOX2D mechanism mentioned a while ago that would cut the frame rate in half, as my game would go unaffected by it, and benefit immensely from the frame rate increase.
EDIT: Tested it on my android device, a graphic intense level took 36 seconds to load, vs 11 seconds to load in 1.23 {I haven't touched this level since before 1.23 for testing purposes.} As for performance, it was very slow, with low frame rate. o _o I have an app version of the game published from 1.23 on the device for comparisons, and it runs smoothly then.
My device runs on android version 4.1.2, software version 1.020SP. I'm sure the devices you tested on run smoothly, but I guess the new changes aren't compatible with all android devices perhaps?
@Franto said:
Just tried the update, haven't seen everything, but upon going to preview, something that stood out was that the boss monster is drunk on powers it shouldn't have: sub-mach speeds. I haven't touched the game since before the udpate, perhaps this is what they mean about redoing the rules for some actors? Although what he is doing has nothing to do with collisions. o _o
Glitched boss:
Normal boss behavior:
My game doesn't rely much on the physics engine except for speed/acceleration. Collisions are only used to record damage and have an actor platform to stand on, which means the getting stuck in another actor bug due to high speeds is a rare occurrence in the game. Mostly since half the characters pass through the enemies as part of the gameplay since the beginning so as to not get blockaded by them.
A lot of "collisions" in the game are just interpolates on position or velocity, set to a short duration such as 0.2 so as to give the illusion that the character was stopped by something.
Which is why I'm really interested in the option to remove the BOX2D mechanism mentioned a while ago that would cut the frame rate in half, as my game would go unaffected by it, and benefit immensely from the frame rate increase.
EDIT: Tested it on my android device, a graphic intense level took 36 seconds to load, vs 11 seconds to load in 1.23 {I haven't touched this level since before 1.23 for testing purposes.} As for performance, it was very slow, with low frame rate. o _o I have an app version of the game published from 1.23 on the device for comparisons, and it runs smoothly then.
My device runs on android version 4.1.2, software version 1.020SP. I'm sure the devices you tested on run smoothly, but I guess the new changes aren't compatible with all android devices perhaps?
There was never an option to remove box2d. I think you missunderstood. When you uncheck movable you remove most of the physics related to that actor and it already acomplishes what you are after.
@Lost_Oasis_Games I apologize for my sloppy writing, which led to a misunderstanding that I was asking for the entire physics engine's removal.
When I was talking about a "mechanism"{I meant to say continous collision in the orignial post} in box2D, I was referring to this post by stevej, in the 1.24.0 thread::
So to improve performance we disabled what is known as "continuous collision", which >is used to help prevent fast moving objects from intersecting or passing through each >other. That appears to be the problem people are seeing. We'll get a fix out soon.
>
Note that enabling this feature can cut the frame rate in half.
Which for some, caused their actors to get stuck inside others or some other bugs, but in my game, it just sped it up without any ill-effects due to non reliance on the continous collision itself, the game just relies on the speed, max speed, and other velocity related attributes and the ability to stand on platform actors{unless that last thing isn't a box2d-related mechanism?}
@Franto said: @Lost_Oasis_Games I apologize for my sloppy writing, which led to a misunderstanding that I was asking for the entire physics engine's removal.
When I was talking about a "mechanism"{I meant to say continous collision in the orignial post} in box2D, I was referring to this post by stevej, in the 1.24.0 thread::
So to improve performance we disabled what is known as "continuous collision", which >is used to help prevent fast moving objects from intersecting or passing through each >other. That appears to be the problem people are seeing. We'll get a fix out soon.
>
Note that enabling this feature can cut the frame rate in half.
Which for some, caused their actors to get stuck inside others or some other bugs, but in my game, it just sped it up without any ill-effects due to non reliance on the continous collision itself, the game just relies on the speed, max speed, and other velocity related attributes and the ability to stand on platform actors{unless that last thing isn't a box2d-related mechanism?}
@CodeWizard said:
The bigger issue, it seems to me, is that we're really starting to address some of the core issues in the codebase. This includes fixing architectural problems that cause performance issues, etc.
I wonder if work wasn't stopped on Graphine if we would of had a beta release for all users to test by now and well on the way to v1.0. Imagine updates that don't break other functions due to structural/architectural flaws. Imagine users writing plugins for long awaited features. Sigh!
I wonder if work wasn't stopped on Graphine if we would of had a beta release for all users to test by now and well on the way to v1.0. Imagine updates that don't break other functions due to structural/architectural flaws. Imagine users writing plugins for long awaited features. Sigh!
I don't think graphene was close to completion. I'm guessing the group doing it are gone and would now take enormous recourses to finish.
We can only guess in its features and preformance.
I was looking forward to seeing it. It was last Xmas when they announced it. I was excited.
I wonder if work wasn't stopped on Graphine if we would of had a beta release for all users to test by now and well on the way to v1.0. Imagine updates that don't break other functions due to structural/architectural flaws. Imagine users writing plugins for long awaited features. Sigh!
I don't think graphene was close to completion. I'm guessing the group doing it are gone and would now take enormous recourses to finish.
We can only guess in its features and preformance.
I was looking forward to seeing it. It was last Xmas when they announced it. I was excited.
Codewizard was basically building it himself, so the team is still here..lol the engine for Graphene was an engine codewizard built while working for another company and gs bought the engine. So graphine is codewizards baby. Nobody knows the ins and outs of it better than him. Having siad that I believe getting creator right first was the right move. What I can say about Graphine is that the learning curve is quite high. As would be expected for a flexable, powerful piece of software.
@Franto said: @Lost_Oasis_Games I apologize for my sloppy writing, which led to a misunderstanding that I was asking for the entire physics engine's removal.
When I was talking about a "mechanism"{I meant to say continous collision in the orignial post} in box2D, I was referring to this post by stevej, in the 1.24.0 thread::
So to improve performance we disabled what is known as "continuous collision", which >is used to help prevent fast moving objects from intersecting or passing through each >other. That appears to be the problem people are seeing. We'll get a fix out soon.
>
Note that enabling this feature can cut the frame rate in half.
Which for some, caused their actors to get stuck inside others or some other bugs, but in my game, it just sped it up without any ill-effects due to non reliance on the continous collision itself, the game just relies on the speed, max speed, and other velocity related attributes and the ability to stand on platform actors{unless that last thing isn't a box2d-related mechanism?}
be curious if the is possible as an option.
shhhh. dont mention the "option" word. It will awaken @Socks
@FINNBOGG said:
I don't think my options argument spawned from the viewer discussion.
When you posted this . . .
@FINNBOGG said:
See how important having an option is when its a feature "YOU" care about.
. . . there is an implicit suggestion that I have argued against an option that you care about, the most obvious candidate would be your wish to see Creator's release held back so as to neatly line up with the App Store's approval of the viewer, because to you this feels more professional.
But if this is not what you were referring to then what did you mean by your comment ?
I mentioned something along time ago that referred to us having a option is better than not. I dont remember what feature it referred to. I just remembered my idea of having a option was just down right politically incorrect. Heaven forbid having options on specific abilities and features.
Codewizard was basically building it himself, so the team is still here..lol the engine for Graphene was an engine codewizard built while working for another company and gs bought the engine. So graphine is codewizards baby. Nobody knows the ins and outs of it better than him. Having siad that I believe getting creator right first was the right move. What I can say about Graphine is that the learning curve is quite high. As would be expected for a flexable, powerful piece of software.
interesting. More complicated than I assumed. I had impression it was GS with a new look and desired features and scripting.
@FINNBOGG said:
I mentioned something along time ago that referred to us having a option is better than not. I dont remember what feature it referred to. I just remembered my idea of having a option was just down right politically incorrect. Heaven forbid having options on specific abilities and features.
Lol, sure, you've forgotten what you were referring to
@FINNBOGG said:
It wasn't the viewer discussion I know that. That's an option that doesn't have to be given to me. It had something to do an earlier thread.
. . . . yep, that's right, it was something to do with something that you can't remember, but you know it involved me, but you can't remember why or what or when . . .
I wasn't pointing at you. I saw the opportunity to show how options is a nice thing. Example : you having the option to decide how your images are managed. It's a lot of lil things like this that can also make GS creator better and it users happier. Doesn't take some big feature. I'd rather have 20 lil things than wait 2 yrs for 1 big thing.
Codewizard was basically building it himself, so the team is still here..lol the engine for Graphene was an engine codewizard built while working for another company and gs bought the engine. So graphine is codewizards baby. Nobody knows the ins and outs of it better than him. Having siad that I believe getting creator right first was the right move. What I can say about Graphine is that the learning curve is quite high. As would be expected for a flexable, powerful piece of software.
interesting. More complicated than I assumed. I had impression it was GS with a new look and desired features and scripting.
Anything with more of a power option is going to be different from current creator. The current creator engine and layout was never meant to be a power users tool. Making things super simple to use always puts limits on things. Don't get me wrong it was drag and drop but how you built your logic and a new interface and layout give things a learning curve. But if one wants a truly powerful tool things will change. You can see how doing even simple things with the current creator is difficult for the team.
You just happen to be the next person in a situation where options came into play. Next time options comes up I'll use their situation as an example as well.
@Two.E I think those are great suggestions. For me when I'm in a scene the images on the scene layout look a bit dull until I resize the inspector UI with precision. Then it looks sharp until like you said either hit preview or open an actor etc. Saving these modifications would really be nice!
So I know everyone has already reported the poor device performance with this build but I would like to add that I tested one of my projects tonight on iOS. I seem to have lost 20 fps on average and am getting memory warnings I was not getting last time I built (testing in Xcode Instruments.)
Loading between scenes is longer and the fps drops happen most consistently when I initially change into a scene. Scenes with lots of animations are also quite slow.
This makes this project unplayable as before it was 30-50 fps and now it's 10-40.
I have some Core Animation and Activity monitor runs saved and the project is published in my portfolio if you guys need more testing data to figure these performance changes out. @CodeWizard@GeorgeGS@BlackCloakGS
Just a quick update. We're testing out the latest Android build now. Looks like we've found the nasty slowdown. If all goes well, we will have a fix published either today or tomorrow morning. This new build also has some other fixes to logic problems that popped up in the latest round of optimizations.
Thanks for your patience. This issue was quite an annoying one to track down. Who needs sleep anyway?
@CodeWizard thanks for the update and for your efforts !! I've published today to the iOS store so its great to hear that Android slow down problem is nearly solved !!!
Comments
Just tried the update, haven't seen everything, but upon going to preview, something that stood out was that the boss monster is drunk on powers it shouldn't have: sub-mach speeds. I haven't touched the game since before the udpate, perhaps this is what they mean about redoing the rules for some actors? Although what he is doing has nothing to do with collisions. o _o
Glitched boss:
Normal boss behavior:
My game doesn't rely much on the physics engine except for speed/acceleration. Collisions are only used to record damage and have an actor platform to stand on, which means the getting stuck in another actor bug due to high speeds is a rare occurrence in the game. Mostly since half the characters pass through the enemies as part of the gameplay since the beginning so as to not get blockaded by them.
A lot of "collisions" in the game are just interpolates on position or velocity, set to a short duration such as 0.2 so as to give the illusion that the character was stopped by something.
Which is why I'm really interested in the option to remove the BOX2D mechanism mentioned a while ago that would cut the frame rate in half, as my game would go unaffected by it, and benefit immensely from the frame rate increase.
EDIT: Tested it on my android device, a graphic intense level took 36 seconds to load, vs 11 seconds to load in 1.23 {I haven't touched this level since before 1.23 for testing purposes.} As for performance, it was very slow, with low frame rate. o _o I have an app version of the game published from 1.23 on the device for comparisons, and it runs smoothly then.
My device runs on android version 4.1.2, software version 1.020SP. I'm sure the devices you tested on run smoothly, but I guess the new changes aren't compatible with all android devices perhaps?
There was never an option to remove box2d. I think you missunderstood. When you uncheck movable you remove most of the physics related to that actor and it already acomplishes what you are after.
Guru Video Channel | Lost Oasis Games | FRYING BACON STUDIOS
@Lost_Oasis_Games I apologize for my sloppy writing, which led to a misunderstanding that I was asking for the entire physics engine's removal.
When I was talking about a "mechanism"{I meant to say continous collision in the orignial post} in box2D, I was referring to this post by stevej, in the 1.24.0 thread::
>
Which for some, caused their actors to get stuck inside others or some other bugs, but in my game, it just sped it up without any ill-effects due to non reliance on the continous collision itself, the game just relies on the speed, max speed, and other velocity related attributes and the ability to stand on platform actors{unless that last thing isn't a box2d-related mechanism?}
be curious if the is possible as an option.
Guru Video Channel | Lost Oasis Games | FRYING BACON STUDIOS
I wonder if work wasn't stopped on Graphine if we would of had a beta release for all users to test by now and well on the way to v1.0. Imagine updates that don't break other functions due to structural/architectural flaws. Imagine users writing plugins for long awaited features. Sigh!
Universal Binary Template - Universal Binary Template Instructions Rev 4 (Short) - Custom Score Display Template
>
>
I don't think graphene was close to completion. I'm guessing the group doing it are gone and would now take enormous recourses to finish.
We can only guess in its features and preformance.
I was looking forward to seeing it. It was last Xmas when they announced it. I was excited.
It scene load times improvement still coming? My scenes still take 10 seconds to load.
Codewizard was basically building it himself, so the team is still here..lol the engine for Graphene was an engine codewizard built while working for another company and gs bought the engine. So graphine is codewizards baby. Nobody knows the ins and outs of it better than him. Having siad that I believe getting creator right first was the right move. What I can say about Graphine is that the learning curve is quite high. As would be expected for a flexable, powerful piece of software.
Guru Video Channel | Lost Oasis Games | FRYING BACON STUDIOS
shhhh. dont mention the "option" word. It will awaken @Socks
I mentioned something along time ago that referred to us having a option is better than not. I dont remember what feature it referred to. I just remembered my idea of having a option was just down right politically incorrect. Heaven forbid having options on specific abilities and features.
Is the lag problem on android fixed?
interesting. More complicated than I assumed. I had impression it was GS with a new look and desired features and scripting.
Lol, sure, you've forgotten what you were referring to
It wasn't the viewer discussion I know that. That's an option that doesn't have to be given to me. It had something to do an earlier thread.
. . . . yep, that's right, it was something to do with something that you can't remember, but you know it involved me, but you can't remember why or what or when . . .
I wasn't pointing at you. I saw the opportunity to show how options is a nice thing. Example : you having the option to decide how your images are managed. It's a lot of lil things like this that can also make GS creator better and it users happier. Doesn't take some big feature. I'd rather have 20 lil things than wait 2 yrs for 1 big thing.
FINNBOGG: "See how important having an option is when its a feature "YOU" care about."
(emphasis yours)
lol
Anything with more of a power option is going to be different from current creator. The current creator engine and layout was never meant to be a power users tool. Making things super simple to use always puts limits on things. Don't get me wrong it was drag and drop but how you built your logic and a new interface and layout give things a learning curve. But if one wants a truly powerful tool things will change. You can see how doing even simple things with the current creator is difficult for the team.
Guru Video Channel | Lost Oasis Games | FRYING BACON STUDIOS
You just happen to be the next person in a situation where options came into play. Next time options comes up I'll use their situation as an example as well.
@Two.E I think those are great suggestions. For me when I'm in a scene the images on the scene layout look a bit dull until I resize the inspector UI with precision. Then it looks sharp until like you said either hit preview or open an actor etc. Saving these modifications would really be nice!
So I know everyone has already reported the poor device performance with this build but I would like to add that I tested one of my projects tonight on iOS. I seem to have lost 20 fps on average and am getting memory warnings I was not getting last time I built (testing in Xcode Instruments.)
Loading between scenes is longer and the fps drops happen most consistently when I initially change into a scene. Scenes with lots of animations are also quite slow.
This makes this project unplayable as before it was 30-50 fps and now it's 10-40.
I have some Core Animation and Activity monitor runs saved and the project is published in my portfolio if you guys need more testing data to figure these performance changes out. @CodeWizard @GeorgeGS @BlackCloakGS
Follow us: Twitter - Website
Just a quick update. We're testing out the latest Android build now. Looks like we've found the nasty slowdown. If all goes well, we will have a fix published either today or tomorrow morning. This new build also has some other fixes to logic problems that popped up in the latest round of optimizations.
Thanks for your patience. This issue was quite an annoying one to track down. Who needs sleep anyway?
@CodeWizard thanks for the update and for your efforts !! I've published today to the iOS store so its great to hear that Android slow down problem is nearly solved
!!!
Awesome news! Looking forward! :-)
You know we love you even though we moan!
Contact me for custom work - Expert GS developer with 15 years of GS experience - Skype: armelline.support