@lycettebros@jonmulcahy I've now pinned my post in the "Working with GS (Mac)" board. It's still experimental and I'd like to hear from those who try it or those who still see issues, either in viewer or ad hoc. I think the recent fixes in the RC might address many issues we're currently seeing. The more feedback I get, the better I can find solutions.
So I'm a little late to the game here reading about the Graphic changes but in seeing what has been said I want some real solid confirmation that I'm understanding things correctly. Basically, if I'm using Photoshop, I can no longer use Save for Web and more specifically I can no longer use the PNG-8 option. Is this correct? Because if this is, then I don't understand how the new megatexture is really going to help us.
Speed and performance is important but keeping my project size to reasonable numbers is actually more important to me because of the 50mb Google Play restriction. We use hundreds of PNG-8 files in our projects. Unless there is some size compression thing that is happening with the megatexture, having all of our PNGs now be 24 bit would bloat our project file to unusable sizes. I hope I am misunderstanding this.
Sorry to resurrect this thread, but I'm hoping @CodeWizard or @TaoOfSalad - or another GS staff member - will weigh in.
I'm working on something at the moment and I'm finding GS's loading of images to be very disappointing. I have actors that are constantly moving and frequently changing their image. I found that every time the actor changed its image, there was a noticeable stall in the rendering of the scene - actors would appear to "jump" a little as GS performed the load.
I got around this by pre-placing the 4 images being swapped between onto the scene hidden out of sight in actors that do nothing. This stopped the jerky loading of images when they were swapping them. These images are about 300k each so I wasn't entirely surprised that GS took a noticeable amount of time to load them. With them being pre-loaded at the start by these hidden actors, though, all seemed good.
I'm now having to add more actors that, also moving, change between a total of 28 possible images. These images, however, are quite small - around 25k each. However, the first time each is loaded onto the scene there is again that noticeable hitch in the movement of all the actors on the scene. So again, I put each image in the scene in an actor so their images would also all be pre-loaded by GameSalad. However, I'm still getting the jerkiness. Once the image has been swapped into the actor once, it doesn't cause the jerkiness again. Just that first time, even if it's present elsewhere on the scene.
I haven't spent much time fixing it, so it may well be I can work around the issue. But I'd really like some clarification from GS staff on exactly how images are handled, how they're stored in memory, and how we can avoid this jerky loading of images - especially ones already on the screen. Please be as technical in any explanation as you want/is possible. My aim here isn't so much to have my problem solved as to understand the underlying functionality of GS that is causing the problem.
Hopefully it'll also help me understand why a game with 3mb of images is using over 100mb of image memory!
I'm absolutely positive it's the actual swapping of the images that's causing the jerking, not any flaw in my logic or other intensive calculation taking place.
(And please no replies from people saying use specific dimensions etc. I have of course tried the usually recommend things.)
Hopefully it'll also help me understand why a game with 3mb of images is using over 100mb of image memory!
I can hopefully help with this bit of the question. The image storage size has zero zilch nada to do with ram usage.
RAM is based on the actual image dimensions. So that's why people usually say you need to adjust image dimensions.
That's where the whole powers of 2 thing you hear from people occasionally comes from.
The ram container sizes are
2,4,8,16,32,64,128,256,512,1024,2028
So as you can imagine the larger the image is the ram will increase exponentially. Any image with a dimension between 1024 and 2048 will use the ram of an image that is 2048. So if it's not going to hurt your visuals you want to make sure you get your dimensions down under the next lowest container size if it's at all close. I know you didn't want to here about image dimensions so I apologize but I think its important.
Hopefully GS can give you some insight on the lag though if you can get the image size down even one step it will help things.
@Armelline said:
(And please no replies from people saying use specific dimensions etc. I have of course tried the usually recommend things.)
Have you tried making your actors 367.93 x 87.9 and placing them on a non-sub-pixel value that is divisible by 3 (and 2 and Pi) ?
But seriously, although I haven't got any answers for your main issue, rather than placing your 28 images onto 28 actors and then placing them into the scene to force GS to load them I sometimes do the following . . . .
Make 1 actor, highlight all your images (regardless of size, shape etc) and drag them into the code area of the actor, this will create an animate behaviour holding all these actors.
Turn both 'Loop' and 'Restore off' and turn the fps up to 30.
Then stick a rule below the animate behaviour that says: When self.image = Last image's name then Destroy this actor.
This is the lazy man's way to force all these images into RAM, there are faster ways (obviously at 30fps, 30 images will take 1 second), but this is quick and easy and the actor deletes itself as soon as it's done its job.
Thanks for the reply, @tenrdrmer, but unfortunately this doesn't seem to help in this instance. Even relatively small images are causing this lag in the movement of the actors.
Also with the ever-increasing image sizes (3x on a background image is going to be huge...) this seems a worrying state of affairs.
@Socks said:
This is the lazy man's way to force all these images into RAM, there are faster ways (obviously at 30fps, 30 images will take 1 second), but this is quick and easy and the actor deletes itself as soon as it's done its job.
Now this is definitely worth trying! Thanks for the tip!
Edit: Nope, it still stutters each time each image is loaded into one of the main actors for the first time.
@Armelline said:
Edit: Nope, it still stutters each time each image is loaded into one of the main actors for the first time.
The idea was not intended to solve your main issue ("I haven't got any answers for your main issue . . . . "), it was to save you having to create multiple actors for each of your 28 images
Your actual idea of loading the actors into the scene is sound, this is what I often do too, so I'm not quite sure why you are getting this little pause.
@Socks said:
Your actual idea of loading the actors into the scene is sound, this is what I often do too, so I'm not quite sure why you are getting this little pause.
Ah I missed that bit And no, neither am I. This seems like a problem that is only going to get worse though if image sizes keep increasing. Already, putting a background on some screen sizes at 3x resolution brings up the "this image is too large to safely import" message.
@Armelline said:
Also with the ever-increasing image sizes (3x on a background image is going to be huge...)
3x doesn't have to be any bigger than 2x, it's really only metadata, take a Retina iPad project that is built with 2048px artwork - in the new system these 2048px source files will be called 3x and the 2x and 1x images will be derived from this source - in the old system your Retina iPad artwork would still be 2048px, except it would be called 2x (which the 1x is derived from).
With the introduction of the iPhone6/6+ we didn't actually see screen resolutions increase, you could argue that the internal processing of the 6+ is slightly higher resolution that a Retina iPad, but even that ends up on a lower resolution (than the iPad) screen.
Of course everything I wrote above is subject to correction as getting information on this stuff from GameSalad is difficult, so there is some degree of guesswork.
@Socks said:
Of course everything I wrote above is subject to correction as getting information on this stuff from GameSalad is difficult, so there is some degree of guesswork.
I would love to read up on the exact state of things. I eagerly await a support document on the new resolutions and image sizes.
@Armelline said:
I would love to read up on the exact state of things. I eagerly await a support document on the new resolutions and image sizes.
Yep, any kind of detailed information would be cool, there has been a lot of this kind of language surrounding the issue . . . [paraphrasing, slightly ] 'make it sort of double size' or 'make it bigger than smaller stuff' or 'the new 3x size assets will need to be kinda, sorta', big, but not kinda' massive, just bigger than 'large', but still sort of 'small' (or smallish) for when you need to produce medium-ish sized assets'.
In the new release candidate thread, GameSalad's usual technical sure-footedness was replaced with . . . 'you can try turning on RI', 'Try' !? You mean you don't know ? I don't want 'try', I want numbers ! Lol.
I suspect they are, like everyone else, still wresting with the implications of yet another Apple technical sea-change.
I would have gone with 4x.
@Armelline said:
This is the boring part of making games
I live for anti-alising, this stuff is like ice cream to me, lol
Okay I'm open to all suggestions now. GameSalad is just utterly failing to load these images smoothly, even when attempting to pre-load them via individual actors or @Sock's animate suggestion (which does work for the first 4 images, but not the the remaining 28 on different actors). I can preload them by looping an actor's image display though them all, but this takes over a second and the entire game grinds to a halt while doing so. This is really very basic stuff that the phone can handle just fine when programmed natively, so it's clearly an issue with GameSalad. The game is basic, the images aren't huge (10-70k) and there is no complex logic happening anywhere inside the project.
tenrdrmerMember, Sous Chef, Senior Sous-ChefPosts: 9,934
You are pro. Have you submitted for pro support? Granted it would be nice for everyone to know the response but you may get a faster reply by going through support.
@tenrdrmer said:
You are pro. Have you submitted for pro support? Granted it would be nice for everyone to know the response but you may get a faster reply by going through support.
I'll try, but I suspect they'll throw this at me:
"PLEASE BE AWARE that we cannot offer project optimization/debugging, game design consulting or business advice via customer service channels!"
Though I've never once managed to get an issue resolved via the GS support system, so perhaps this will be the first!
I could take a look for you if you want although it sounds like you've tried all the obvious fixes already, but you never know when a fresh pair of eyes might spot something, if you want to strip the project down to just the problem (to avoid getting sucked into my evil global template empire) then I'd be happy to see if I can add any ideas or suggest a solution ?
@Socks said:
I could take a look for you if you want although it sounds like you've tried all the obvious fixes already, but you never know when a fresh pair of eyes might spot something, if you want to strip the project down to just the problem (to avoid getting sucked into my evil global template empire) then I'd be happy to see if I can add any ideas or suggest a solution ?
Although replicating the problem with the proper images isn't difficult, even in a super-basic project, your solution only stops working after more than 4 and less than 14 images are involved (I know it works with 4 and doesn't with 14 but I haven't tried to break it down any futher yet). I can't use the images I'm actually using (for obvious reasons) and right now I can't face making 32 new images that will be roughly the same size as the originals. Perhaps tomorrow, depending on the response I get from GS Thanks for the offer, though.
@Armelline said:
Although replicating the problem with the proper images isn't difficult, even in a super-basic project, your solution only stops working after more than 4 and less than 14 images are involved (I know it works with 4 and doesn't with 14 but I haven't tried to break it down any futher yet).
I haven't suggested a solution ?
If you are referring to the idea of using Animate to pre-load images, then like I say above it's not a suggestion as to how to fix your issue, it's nothing to do with your issue ! It's just that if - in your attempts to find a solution - you needed to thrown a bunch of actors onto the scene then placing them into an animate behaviour is faster than making X number of separate actors, that's all the suggestion is, it's not a solution for your main issue.
@Armelline said:
I can't use the images I'm actually using (for obvious reasons) and right now I can't face making 32 new images that will be roughly the same size as the originals. Perhaps tomorrow, depending on the response I get from GS Thanks for the offer, though.
No problem, although you wouldn't need to make new images, just one would do, a black square if you like I would just duplicate the same image 32 times GameSalad doesn't care (or know) what is in an image.
P.S I'm working with a car animation at the moment, 360 images (a complete rotation, an image for every degree), once the images are loaded (once the car has completed a full spin at the start) the changes are then as smooth and invisibly fast as you'd expect, and this thing is changing images up to 60 times a second, so GameSalad can do this sort of thing.
Putting the images that will need to be loaded in the scene so they're loaded on startup is a partial solution to the problem. You suggested a method of doing this more efficiently. I count that as at least a partial solution :P
I could throw an image into a project 32 times but I'd want to approximate my circumstances as closely as possible. Literally all you need to do is make a scene of about 1400x768, add in 3-5 actors the height of the scene and 1/3 the width, and set them to a linear velocity x to something like 200. Then set them to change image when they move to the far edge of the scene out of sight. The first time each image is loaded into an actor there will be a noticeable stalling of the whole scene's movement.
I know what you mean, one of my projects suffers from it too and like you I can basically solve just about any problem myself but I have not (yet) found any solution to this specific issue that you describe. If I do then I'll let you know, feel free to do the same!
@Armelline said:
Putting the images that will need to be loaded in the scene so they're loaded on startup is a partial solution to the problem. You suggested a method of doing this more efficiently. I count that as at least a partial solution :P
Lol ! No, honestly, my idea was not to address the glitch issue you are having, it was a quicker way of loading a bunch of images into the scene (which was your own idea) and while it will save you having to make 28 actors for 28 images it has nothing to do with (nor attempts to address) whatever it is that is causing the glitches.
Honestly ! I know this was my intention as firstly I don't know what it causing your issue and secondly I actually wrote the post where I made the suggestion !
@Armelline said:
I could throw an image into a project 32 times but I'd want to approximate my circumstances as closely as possible.Literally all you need to do is make a scene of about 1400x768, add in 3-5 actors the height of the scene and 1/3 the width, and set them to a linear velocity x to something like 200. Then set them to change image when they move to the far edge of the scene out of sight. The first time each image is loaded into an actor there will be a noticeable stalling of the whole scene's movement.
I'll give it a go if you want . . . . How big are the images ? Also how are you able to tell whether the images have changed when they are out of sight (or doesn't that matter), and what are you using to change the image (Change Image, Change attribute, Constrain . . . etc ?)
@Socks said:
I'll give it a go if you want . . . . How big are the images ? Also how are you able to tell whether the images have changed when they are out of sight (or doesn't that matter), and what are you using to change the image (Change Image, Change attribute, Constrain . . . etc ?)
I have experienced the problem with images ranging in dimension from 340x200 to 768x328. Not tried smaller. File sizes from 20k to 350k. Some with transparency and some without.
I'm using change attribute to change the image, and have tried both change attribute and constrain attribute to control the linear velocity.
It makes no difference if the images change in sight or out of it (for my purposes the change happens out of sight).
@Armelline said:
It makes no difference if the images change in sight or out of it (for my purposes the change happens out of sight).
Ok, I'll try and give it a go later, it does sound pretty weird, especially as you aren't really using particuallry large images . . . . I guess even when the image changes off screen the actors on screen (or rather their movement) glitches ?
One final question, have you tried this on an actual device or is it just happening on your computer ?
. . . . . . . . .
While typing this post I discovered (after 240 years of using a Mac) that command+delete deletes a whole line, one at a time, which is pretty useful for editing !
EDIT . . . and alt+delete deletes a word at a time ! Two discoveries in one post, I'll get a job as a secretary before this thread is done, you mark my words.
@Socks said:
One final question, have you tried this on an actual device or is it just happening on your computer ?
Yes, even if the image changes off-screen at least some (normally all but not always) of the actors on screen glitch.
This happens on device - tested on both iPhone 4S and iPad 4 by myself and iPhone 5S by someone else. It's not particularly noticeable in creator as it's so inconsistent anyway. (Though interestingly, if you run the creator in the background, it'll play a game much more smoothly when you preview it. Try opening creator and then opening another application like TextEdit (I noticed it with Skype) so it's the foremost window but positioned so you can still see the GS window behind it.)
Attaching a project I made for the support ticket. Doesn't demonstrate the issue I have with the images that aren't helped by preloading, but illustrates the general problem.
@Armelline said:
Attaching a project I made for the support ticket. Doesn't demonstrate the issue I have with the images that aren't helped by preloading, but illustrates the general problem.
I'm not sure the problem has to do with images loading (I could be wrong of course), but if you strip all the rules from your main actor and just have a single image that doesn't change (so no new images are being loaded) the glitch still happens.
I'm not getting the glitch in this project. At least not the same one. Additionally, the glitch stops happening in my example project once each image has been loaded once, and also stops happening when you put the pre-loader actor onto the scene.
Comments
@socks "... a massive elephant".
A white elephant, maybe?
This sounds amazing.
@TaoOfSalad Can we please get your link (http://forums.gamesalad.com/discussion/67365) to the image formatting process placed on the front of the forum as I think it is going to be essential reading?
good idea, it should also be added to the release notes for v 11
Send and Receive Data using your own Server Tutorial! | Vote for A Long Way Home on Steam Greenlight! | Ten Years Left
@lycettebros @jonmulcahy I've now pinned my post in the "Working with GS (Mac)" board. It's still experimental and I'd like to hear from those who try it or those who still see issues, either in viewer or ad hoc. I think the recent fixes in the RC might address many issues we're currently seeing. The more feedback I get, the better I can find solutions.
So I'm a little late to the game here reading about the Graphic changes but in seeing what has been said I want some real solid confirmation that I'm understanding things correctly. Basically, if I'm using Photoshop, I can no longer use Save for Web and more specifically I can no longer use the PNG-8 option. Is this correct? Because if this is, then I don't understand how the new megatexture is really going to help us.
Speed and performance is important but keeping my project size to reasonable numbers is actually more important to me because of the 50mb Google Play restriction. We use hundreds of PNG-8 files in our projects. Unless there is some size compression thing that is happening with the megatexture, having all of our PNGs now be 24 bit would bloat our project file to unusable sizes. I hope I am misunderstanding this.
Sorry to resurrect this thread, but I'm hoping @CodeWizard or @TaoOfSalad - or another GS staff member - will weigh in.
I'm working on something at the moment and I'm finding GS's loading of images to be very disappointing. I have actors that are constantly moving and frequently changing their image. I found that every time the actor changed its image, there was a noticeable stall in the rendering of the scene - actors would appear to "jump" a little as GS performed the load.
I got around this by pre-placing the 4 images being swapped between onto the scene hidden out of sight in actors that do nothing. This stopped the jerky loading of images when they were swapping them. These images are about 300k each so I wasn't entirely surprised that GS took a noticeable amount of time to load them. With them being pre-loaded at the start by these hidden actors, though, all seemed good.
I'm now having to add more actors that, also moving, change between a total of 28 possible images. These images, however, are quite small - around 25k each. However, the first time each is loaded onto the scene there is again that noticeable hitch in the movement of all the actors on the scene. So again, I put each image in the scene in an actor so their images would also all be pre-loaded by GameSalad. However, I'm still getting the jerkiness. Once the image has been swapped into the actor once, it doesn't cause the jerkiness again. Just that first time, even if it's present elsewhere on the scene.
I haven't spent much time fixing it, so it may well be I can work around the issue. But I'd really like some clarification from GS staff on exactly how images are handled, how they're stored in memory, and how we can avoid this jerky loading of images - especially ones already on the screen. Please be as technical in any explanation as you want/is possible. My aim here isn't so much to have my problem solved as to understand the underlying functionality of GS that is causing the problem.
Hopefully it'll also help me understand why a game with 3mb of images is using over 100mb of image memory!
I'm absolutely positive it's the actual swapping of the images that's causing the jerking, not any flaw in my logic or other intensive calculation taking place.
(And please no replies from people saying use specific dimensions etc. I have of course tried the usually recommend things.)
Contact me for custom work - Expert GS developer with 15 years of GS experience - Skype: armelline.support
I can hopefully help with this bit of the question. The image storage size has zero zilch nada to do with ram usage.
RAM is based on the actual image dimensions. So that's why people usually say you need to adjust image dimensions.
That's where the whole powers of 2 thing you hear from people occasionally comes from.
The ram container sizes are
2,4,8,16,32,64,128,256,512,1024,2028
So as you can imagine the larger the image is the ram will increase exponentially. Any image with a dimension between 1024 and 2048 will use the ram of an image that is 2048. So if it's not going to hurt your visuals you want to make sure you get your dimensions down under the next lowest container size if it's at all close. I know you didn't want to here about image dimensions so I apologize but I think its important.
Hopefully GS can give you some insight on the lag though if you can get the image size down even one step it will help things.
Cheers
Have you tried making your actors 367.93 x 87.9 and placing them on a non-sub-pixel value that is divisible by 3 (and 2 and Pi) ?
But seriously, although I haven't got any answers for your main issue, rather than placing your 28 images onto 28 actors and then placing them into the scene to force GS to load them I sometimes do the following . . . .
Make 1 actor, highlight all your images (regardless of size, shape etc) and drag them into the code area of the actor, this will create an animate behaviour holding all these actors.
Turn both 'Loop' and 'Restore off' and turn the fps up to 30.
Then stick a rule below the animate behaviour that says: When self.image = Last image's name then Destroy this actor.
This is the lazy man's way to force all these images into RAM, there are faster ways (obviously at 30fps, 30 images will take 1 second), but this is quick and easy and the actor deletes itself as soon as it's done its job.
Thanks for the reply, @tenrdrmer, but unfortunately this doesn't seem to help in this instance. Even relatively small images are causing this lag in the movement of the actors.
Also with the ever-increasing image sizes (3x on a background image is going to be huge...) this seems a worrying state of affairs.
Contact me for custom work - Expert GS developer with 15 years of GS experience - Skype: armelline.support
Now this is definitely worth trying! Thanks for the tip!
Edit: Nope, it still stutters each time each image is loaded into one of the main actors for the first time.
Contact me for custom work - Expert GS developer with 15 years of GS experience - Skype: armelline.support
The idea was not intended to solve your main issue ("I haven't got any answers for your main issue . . . . "), it was to save you having to create multiple actors for each of your 28 images
Your actual idea of loading the actors into the scene is sound, this is what I often do too, so I'm not quite sure why you are getting this little pause.
Ah I missed that bit
And no, neither am I. This seems like a problem that is only going to get worse though if image sizes keep increasing. Already, putting a background on some screen sizes at 3x resolution brings up the "this image is too large to safely import" message.
Contact me for custom work - Expert GS developer with 15 years of GS experience - Skype: armelline.support
3x doesn't have to be any bigger than 2x, it's really only metadata, take a Retina iPad project that is built with 2048px artwork - in the new system these 2048px source files will be called 3x and the 2x and 1x images will be derived from this source - in the old system your Retina iPad artwork would still be 2048px, except it would be called 2x (which the 1x is derived from).
With the introduction of the iPhone6/6+ we didn't actually see screen resolutions increase, you could argue that the internal processing of the 6+ is slightly higher resolution that a Retina iPad, but even that ends up on a lower resolution (than the iPad) screen.
Of course everything I wrote above is subject to correction as getting information on this stuff from GameSalad is difficult, so there is some degree of guesswork.
I would love to read up on the exact state of things. I eagerly await a support document on the new resolutions and image sizes.
This is the boring part of making games
Contact me for custom work - Expert GS developer with 15 years of GS experience - Skype: armelline.support
Yep, any kind of detailed information would be cool, there has been a lot of this kind of language surrounding the issue . . . [paraphrasing, slightly
] 'make it sort of double size' or 'make it bigger than smaller stuff' or 'the new 3x size assets will need to be kinda, sorta', big, but not kinda' massive, just bigger than 'large', but still sort of 'small' (or smallish) for when you need to produce medium-ish sized assets'.
In the new release candidate thread, GameSalad's usual technical sure-footedness was replaced with . . . 'you can try turning on RI', 'Try' !? You mean you don't know ? I don't want 'try', I want numbers ! Lol.
I suspect they are, like everyone else, still wresting with the implications of yet another Apple technical sea-change.
I would have gone with 4x.
I live for anti-alising, this stuff is like ice cream to me, lol
Okay I'm open to all suggestions now. GameSalad is just utterly failing to load these images smoothly, even when attempting to pre-load them via individual actors or @Sock's animate suggestion (which does work for the first 4 images, but not the the remaining 28 on different actors). I can preload them by looping an actor's image display though them all, but this takes over a second and the entire game grinds to a halt while doing so. This is really very basic stuff that the phone can handle just fine when programmed natively, so it's clearly an issue with GameSalad. The game is basic, the images aren't huge (10-70k) and there is no complex logic happening anywhere inside the project.
This is all very disappointing.
Contact me for custom work - Expert GS developer with 15 years of GS experience - Skype: armelline.support
You are pro. Have you submitted for pro support? Granted it would be nice for everyone to know the response but you may get a faster reply by going through support.
I'll try, but I suspect they'll throw this at me:
"PLEASE BE AWARE that we cannot offer project optimization/debugging, game design consulting or business advice via customer service channels!"
Though I've never once managed to get an issue resolved via the GS support system, so perhaps this will be the first!
Contact me for custom work - Expert GS developer with 15 years of GS experience - Skype: armelline.support
I could take a look for you if you want although it sounds like you've tried all the obvious fixes already, but you never know when a fresh pair of eyes might spot something, if you want to strip the project down to just the problem (to avoid getting sucked into my evil global template empire) then I'd be happy to see if I can add any ideas or suggest a solution ?
Although replicating the problem with the proper images isn't difficult, even in a super-basic project, your solution only stops working after more than 4 and less than 14 images are involved (I know it works with 4 and doesn't with 14 but I haven't tried to break it down any futher yet). I can't use the images I'm actually using (for obvious reasons) and right now I can't face making 32 new images that will be roughly the same size as the originals. Perhaps tomorrow, depending on the response I get from GS
Thanks for the offer, though.
Contact me for custom work - Expert GS developer with 15 years of GS experience - Skype: armelline.support
I haven't suggested a solution ?
If you are referring to the idea of using Animate to pre-load images, then like I say above it's not a suggestion as to how to fix your issue, it's nothing to do with your issue !
It's just that if - in your attempts to find a solution - you needed to thrown a bunch of actors onto the scene then placing them into an animate behaviour is faster than making X number of separate actors, that's all the suggestion is, it's not a solution for your main issue.
No problem, although you wouldn't need to make new images, just one would do, a black square if you like I would just duplicate the same image 32 times GameSalad doesn't care (or know) what is in an image.
P.S I'm working with a car animation at the moment, 360 images (a complete rotation, an image for every degree), once the images are loaded (once the car has completed a full spin at the start) the changes are then as smooth and invisibly fast as you'd expect, and this thing is changing images up to 60 times a second, so GameSalad can do this sort of thing.
Putting the images that will need to be loaded in the scene so they're loaded on startup is a partial solution to the problem. You suggested a method of doing this more efficiently. I count that as at least a partial solution :P
I could throw an image into a project 32 times but I'd want to approximate my circumstances as closely as possible. Literally all you need to do is make a scene of about 1400x768, add in 3-5 actors the height of the scene and 1/3 the width, and set them to a linear velocity x to something like 200. Then set them to change image when they move to the far edge of the scene out of sight. The first time each image is loaded into an actor there will be a noticeable stalling of the whole scene's movement.
Contact me for custom work - Expert GS developer with 15 years of GS experience - Skype: armelline.support
I know what you mean, one of my projects suffers from it too and like you I can basically solve just about any problem myself but I have not (yet) found any solution to this specific issue that you describe. If I do then I'll let you know, feel free to do the same!
Lol !
No, honestly, my idea was not to address the glitch issue you are having, it was a quicker way of loading a bunch of images into the scene (which was your own idea) and while it will save you having to make 28 actors for 28 images it has nothing to do with (nor attempts to address) whatever it is that is causing the glitches.
Honestly ! I know this was my intention as firstly I don't know what it causing your issue and secondly I actually wrote the post where I made the suggestion !
I'll give it a go if you want . . . . How big are the images ? Also how are you able to tell whether the images have changed when they are out of sight (or doesn't that matter), and what are you using to change the image (Change Image, Change attribute, Constrain . . . etc ?)
I have experienced the problem with images ranging in dimension from 340x200 to 768x328. Not tried smaller. File sizes from 20k to 350k. Some with transparency and some without.
I'm using change attribute to change the image, and have tried both change attribute and constrain attribute to control the linear velocity.
It makes no difference if the images change in sight or out of it (for my purposes the change happens out of sight).
Contact me for custom work - Expert GS developer with 15 years of GS experience - Skype: armelline.support
Ok, I'll try and give it a go later, it does sound pretty weird, especially as you aren't really using particuallry large images . . . . I guess even when the image changes off screen the actors on screen (or rather their movement) glitches ?
One final question, have you tried this on an actual device or is it just happening on your computer ?
. . . . . . . . .
While typing this post I discovered (after 240 years of using a Mac) that command+delete deletes a whole line, one at a time, which is pretty useful for editing !
EDIT . . . and alt+delete deletes a word at a time ! Two discoveries in one post, I'll get a job as a secretary before this thread is done, you mark my words.
Yes, even if the image changes off-screen at least some (normally all but not always) of the actors on screen glitch.
This happens on device - tested on both iPhone 4S and iPad 4 by myself and iPhone 5S by someone else. It's not particularly noticeable in creator as it's so inconsistent anyway. (Though interestingly, if you run the creator in the background, it'll play a game much more smoothly when you preview it. Try opening creator and then opening another application like TextEdit (I noticed it with Skype) so it's the foremost window but positioned so you can still see the GS window behind it.)
Attaching a project I made for the support ticket. Doesn't demonstrate the issue I have with the images that aren't helped by preloading, but illustrates the general problem.
Contact me for custom work - Expert GS developer with 15 years of GS experience - Skype: armelline.support
I'm not sure the problem has to do with images loading (I could be wrong of course), but if you strip all the rules from your main actor and just have a single image that doesn't change (so no new images are being loaded) the glitch still happens.
Example project:
https://www.mediafire.com/?87s3v7jg81tlqxa
I'm not getting the glitch in this project. At least not the same one. Additionally, the glitch stops happening in my example project once each image has been loaded once, and also stops happening when you put the pre-loader actor onto the scene.
Contact me for custom work - Expert GS developer with 15 years of GS experience - Skype: armelline.support