@smurfted said:
sound output so we can produce a graphic equaliser . . .
You can pretty much do that now with a little trickery, split your sound up into several bands (using a bandpass filter with very tight crossovers, like 48dB/oct or even more) and control the volume of each one with a slider, I like the idea so much I might just make a demo . . . .
@smurfted said:
or at least know the average volume of the sound output..
@smurfted said:
sound output so we can produce a graphic equaliser . . .
You can pretty much do that now with a little trickery, split your sound up into several bands (with very tight crossovers, like 48dB/oct or even more) and control each one with a slider, I like the idea so much I might just make a demo . . . .
@smurfted said:
or at least know the average volume of the sound output..
What would that give us ?
Here you go (file attached) a quick graphic EQ test . . . drag the bands up and down to equalise, option click a band to reset.
How about the most needed feature in gamesalad? NEAREST NEIGHBOR INTERPOLATION. it would be a godsend for pixel art games, which are a big part of the games being creative with GS.
this single feature would give us pixel game creators so much head room to create better, faster, bigger games. Right now it seems so counter intuitive to resize a 32x32 actor 4x just to have a clear pixel image taking 4x the memory space as the original.
@Retropix said:
How about the most needed feature in gamesalad? NEAREST NEIGHBOR INTERPOLATION. it would be a godsend for pixel art games, which are a big part of the games being creative with GS.
this single feature would give us pixel game creators so much head room to create better, faster, bigger games. Right now it seems so counter intuitive to resize a 32x32 actor 4x just to have a clear pixel image taking 4x the memory space as the original.
owen_dennisJust a guy, you know.Member, PROPosts: 236
@Retropix said:
How about the most needed feature in gamesalad? NEAREST NEIGHBOR INTERPOLATION. it would be a godsend for pixel art games, which are a big part of the games being creative with GS.
this single feature would give us pixel game creators so much head room to create better, faster, bigger games. Right now it seems so counter intuitive to resize a 32x32 actor 4x just to have a clear pixel image taking 4x the memory space as the original.
I've been away from the forum and gamesalad for quite a few months now. About once a month I check back in just to see if there have been any new improvements and, more specifically, to see if this nearest neighbor interpolation is an option yet. I logged back in just to make sure this one is seen! This is so important and it's an option that is highly necessary! It's 2016, indie games that look pixelated is so normal that it's more of a shock now to see a non-pixel looking game. It's actually kind of frustrating seeing comments on a game that say "why is this taking up so much memory? It's such a simple game!" because the users only see simple pixels, but behind the scenes the images have to be much bigger than needed. This one thing could improve the performance of so many people's games by cutting down on RAM and the game's footprint in general. I salivate just thinking about it.
Look at how many "Agrees" @Retropix 's post has! People want this one.
@smurfted said:
Allow jpg images as well as png's. Much smaller files for certain situations..
@smurfted - For now, I run my stuff through Panda's TINYPNG - FREE online image compression site to achieve massive reductions in size for my PNG's - it's getting me by! - between 50% and 18% of the original PNG's size, the absolute minimum saving seems to be 50%, saving huge amounts on my project / resulting APK/APP... - Alpha/transparency looks a little messed up for some images, but ONLY in the editor/creator - my games Catflap and Retro Snippets look fine on every device I've tested them on after TinyPNG has worked it's magic, and I've re-imported them into my project...
PhilipCCEncounter Bay, South AustraliaMemberPosts: 1,390
@smurfted said:
Allow jpg images as well as png's. Much smaller files for certain situations..
@smurfted - For now, I run my stuff through Panda's TINYPNG - FREE online image compression site to achieve massive reductions in size for my PNG's - it's getting me by!
I'm afraid that's an illusion.
When the current graphics engine was implemented Blackcloak explained that it doesn't matter whether you upload JPGs or PNGs or even PSDs, GameSalad doesn't use them in those file formats anyway. The graphics engine slices and dices them into polygons. If you check the online Meetup recordings you can listen to it being explained in detail. The handful of us that regularly attended those Meetups can testify that this was so. I think @Braydon_SFX , @The_Gamesalad_Guru , @Armelline were there. Maybe @ForumNinja can confirm?
Furthermore, we were specifically warned not to use compression software like TinyPNG.
The savings you are seeing are your computer files, but not in the published GS app.
Try this: upload 10 large PNGs, drag them into a scene, publish an Adhoc and note the file size of the app, then convert those PNGs to JPGs and do the same thing and note the file size of the app.
For the best quality output you are supposed to be using 32 bit PNGs, 8 bits per channel plus alpha, while obeying all the other size rules.
I stand open to correction by some of the more seasoned developers if this is not the case.
Agreed, it's mostly an illusion ! (depending on what someone might think they are gaining from the process).
@PhilipCC said:
When the current graphics engine was implemented Blackcloak explained that it doesn't matter whether you upload JPGs or PNGs or even PSDs, GameSalad doesn't use them in those file formats anyway. The graphics engine slices and dices them into polygons. If you check the online Meetup recordings you can listen to it being explained in detail.
That configuration of the graphics engine (64x64 tiles that are LZ4_HC compressed) was never implemented, @Toyman, who was leading the charge on that front, was unfortunately culled in the GreatPurge™.
@PhilipCC said:
Furthermore, we were specifically warned not to use compression software like TinyPNG.
That's always been the official line, files generated by programs like TinyPNG are no longer supported, 24/32bit PNGs are recommended, although there is still some confusion around this issue as GS has on occasion said you can replace PNGs with JPGs, but you still risk having issues further along the line, it might all work well on one device but - for all we know - someone with OS 8.9 on an iPhone 5S or a Amazon Fire running XYZ . . . (or some other unknown configuration) . . . might get a bunch of white squares.
@PhilipCC said:
The savings you are seeing are your computer files, but not in the published GS app.
Yes, agreed, this is the most salient point ! For all the compromises made, the extra work converting images, the risk of some devices screwing up and not displaying the images correctly (or at all), the compromised image quality and "transparency [looking] a little messed up" . . and so on . . . you don't actually improve gameplay, the app will not run any smoother, the loading time will not be any faster, the RAM usage and processor overhead will be identical . . in fact there's an argument to be made that load times might actually be slower with a more compressed image file as it has to be decompressed first.
So, like you say the only advantage is that - for example - a 234MB app will be 168MB instead - when stored on your device - but take up the same amount of RAM when being run, besides using less disk space there are no obvious advantages over using PNGs and a few disadvantages/compromises.
In a world of free Wi-Fi access in every cafe and train station and super fast broadband speeds, do consumers really care whether an app is 37MB or 68MB these days ?
PhilipCCEncounter Bay, South AustraliaMemberPosts: 1,390
@Socks Thanks for the clarification. I spent ages checking the Meetups but couldn't find what I spoke of above. The recordings and threads are not all there anymore.
@PhilipCC said: @Socks Thanks for the clarification. I spent ages checking the Meetups but couldn't find what I spoke of above. The recordings and threads are not all there anymore.
People got whacked, files went missing, they never found Toymam's body.
There's some useful info on page 2 of this thread . . .
I did a project earlier this year and i swapped out my 32 bit for some same resolution 8 bits. some with some with out an alpha. There we're a bunch of images if anyone remembers i had memory issues (100's of images).
While the memory issues (ram) remained exactly the same, i got the project file and the resulting apk file size reduced by nearly 80%. So there is something to it..
@Socks said:
That configuration of the graphics engine (64x64 tiles that are LZ4_HC compressed) was never implemented, @Toyman, who was leading the charge on that front, was unfortunately culled in the GreatPurge™.
That was a sad day, the system he was working on was so close to being ready and showed huge reductions in RAM usage.
But like .exe support, it's been shelved partially completed to never see the light of day =(
@AlchimiaStudios said:
That was a sad day, the system he was working on was so close to being ready and showed huge reductions in RAM usage.
Yeah, I was really disappointed too, from what he said it sounded like a major breakthrough in performance, and like you say it sounds like it was mostly complete.
KickStarter 6 months of Toyman ?
PhilipCCEncounter Bay, South AustraliaMemberPosts: 1,390
@Toyman said:
There is no power-of-two texture limit any more. Make your images any size you like.
If the dimensions are not product-of-64 I will pad your image with black with zero alpha.
As was expressly stated by the GS team that compressing your images is useless and can infact, due to the decompression that needs to happen, can slow down scene loading. The only benefit to image compression is for package size. This is less of an issue now that cell carriers allow for up to 100mb installs over cell networks
@The_Gamesalad_Guru said:
As was expressly stated by the GS team that compressing your images is useless and can infact, due to the decompression that needs to happen, can slow down scene loading. The only benefit to image compression is for package size. This is less of an issue now that cell carriers allow for up to 100mb installs over cell networks
The issue of package size is a major issue, especially on Android where lots of people accross the world have cheaper phones with limited storage. It can have a very real impact on downloads. I had an app with lots of full resolution background art. I reduced the package size by around 75% by compressing with TinyPNG. This had a very real impact on downloads. I tested on many devices and have found absolutely no detrimental effect for doing this in terms of app performance or stability.
It has proven to have much lesser of an effect on iOS as I think larger storage is the norm.
By the way, without compression or the ability to use GIFs or JPEGs it is very easy to go over the Google Play 100MB limit. Especially if you are creating an interactive book type app with full res background art.
Comments
sound output so we can produce a graphic equaliser, or at least know the average volume of the sound output..
make "change" or "constrain" attribute be 1 behaviour, with a choice of which of the two behaviors to do.
in the layer select you should be able to choose on / off and visible or not, also make them lockable so you don't accidentally move them..
add layers on top like a glow or hue / saturation adjustments to the whole scene
add layers that are completly unaffected by camera changes for easier HUDs
when looking at layers of a scene you should be able to see if an actor is a prototype
the ability to group select objects in the editor
You can pretty much do that now with a little trickery, split your sound up into several bands (using a bandpass filter with very tight crossovers, like 48dB/oct or even more) and control the volume of each one with a slider, I like the idea so much I might just make a demo . . . .
What would that give us ?
Here you go (file attached) a quick graphic EQ test . . . drag the bands up and down to equalise, option click a band to reset.
Epic socks, thats very clever.
But if you want to make a character talk or move to a sound like music. It would be a whole new dynamic for game design.
I've worked in motion graphics for years and having stuff move dynamically to sound is great..
Also it would be great to be able to select a row or column in a table and alphabetise it..
How about the most needed feature in gamesalad? NEAREST NEIGHBOR INTERPOLATION. it would be a godsend for pixel art games, which are a big part of the games being creative with GS.
this single feature would give us pixel game creators so much head room to create better, faster, bigger games. Right now it seems so counter intuitive to resize a 32x32 actor 4x just to have a clear pixel image taking 4x the memory space as the original.
+1
+100000000000000
Fix for the splash screen stretching bug iPhone6+
I've been away from the forum and gamesalad for quite a few months now. About once a month I check back in just to see if there have been any new improvements and, more specifically, to see if this nearest neighbor interpolation is an option yet. I logged back in just to make sure this one is seen! This is so important and it's an option that is highly necessary! It's 2016, indie games that look pixelated is so normal that it's more of a shock now to see a non-pixel looking game. It's actually kind of frustrating seeing comments on a game that say "why is this taking up so much memory? It's such a simple game!" because the users only see simple pixels, but behind the scenes the images have to be much bigger than needed. This one thing could improve the performance of so many people's games by cutting down on RAM and the game's footprint in general. I salivate just thinking about it.
Look at how many "Agrees" @Retropix 's post has! People want this one.
Vote for Nearest Neighbor Scaling option in gamesalad! Let's make our games look truly stunning!
@smurfted - For now, I run my stuff through Panda's TINYPNG - FREE online image compression site to achieve massive reductions in size for my PNG's - it's getting me by! - between 50% and 18% of the original PNG's size, the absolute minimum saving seems to be 50%, saving huge amounts on my project / resulting APK/APP... - Alpha/transparency looks a little messed up for some images, but ONLY in the editor/creator - my games Catflap and Retro Snippets look fine on every device I've tested them on after TinyPNG has worked it's magic, and I've re-imported them into my project...
I'm afraid that's an illusion.
When the current graphics engine was implemented Blackcloak explained that it doesn't matter whether you upload JPGs or PNGs or even PSDs, GameSalad doesn't use them in those file formats anyway. The graphics engine slices and dices them into polygons. If you check the online Meetup recordings you can listen to it being explained in detail. The handful of us that regularly attended those Meetups can testify that this was so. I think @Braydon_SFX , @The_Gamesalad_Guru , @Armelline were there. Maybe @ForumNinja can confirm?
Furthermore, we were specifically warned not to use compression software like TinyPNG.
The savings you are seeing are your computer files, but not in the published GS app.
Try this: upload 10 large PNGs, drag them into a scene, publish an Adhoc and note the file size of the app, then convert those PNGs to JPGs and do the same thing and note the file size of the app.
For the best quality output you are supposed to be using 32 bit PNGs, 8 bits per channel plus alpha, while obeying all the other size rules.
I stand open to correction by some of the more seasoned developers if this is not the case.
Agreed, it's mostly an illusion ! (depending on what someone might think they are gaining from the process).
That configuration of the graphics engine (64x64 tiles that are LZ4_HC compressed) was never implemented, @Toyman, who was leading the charge on that front, was unfortunately culled in the GreatPurge™.
That's always been the official line, files generated by programs like TinyPNG are no longer supported, 24/32bit PNGs are recommended, although there is still some confusion around this issue as GS has on occasion said you can replace PNGs with JPGs, but you still risk having issues further along the line, it might all work well on one device but - for all we know - someone with OS 8.9 on an iPhone 5S or a Amazon Fire running XYZ . . . (or some other unknown configuration) . . . might get a bunch of white squares.
Yes, agreed, this is the most salient point ! For all the compromises made, the extra work converting images, the risk of some devices screwing up and not displaying the images correctly (or at all), the compromised image quality and "transparency [looking] a little messed up" . . and so on . . . you don't actually improve gameplay, the app will not run any smoother, the loading time will not be any faster, the RAM usage and processor overhead will be identical . . in fact there's an argument to be made that load times might actually be slower with a more compressed image file as it has to be decompressed first.
So, like you say the only advantage is that - for example - a 234MB app will be 168MB instead - when stored on your device - but take up the same amount of RAM when being run, besides using less disk space there are no obvious advantages over using PNGs and a few disadvantages/compromises.
In a world of free Wi-Fi access in every cafe and train station and super fast broadband speeds, do consumers really care whether an app is 37MB or 68MB these days ?
@Socks Thanks for the clarification. I spent ages checking the Meetups but couldn't find what I spoke of above. The recordings and threads are not all there anymore.
People got whacked, files went missing, they never found Toymam's body.
There's some useful info on page 2 of this thread . . .
http://forums.gamesalad.com/discussion/86687/state-of-gamesalad-on-5-29-2015/p2
I did a project earlier this year and i swapped out my 32 bit for some same resolution 8 bits. some with some with out an alpha. There we're a bunch of images if anyone remembers i had memory issues (100's of images).
While the memory issues (ram) remained exactly the same, i got the project file and the resulting apk file size reduced by nearly 80%. So there is something to it..
That was a sad day, the system he was working on was so close to being ready and showed huge reductions in RAM usage.
But like .exe support, it's been shelved partially completed to never see the light of day =(
Follow us: Twitter - Website
Yeah, I was really disappointed too, from what he said it sounded like a major breakthrough in performance, and like you say it sounds like it was mostly complete.
KickStarter 6 months of Toyman ?
Yeah, I recall that thread now and found it fascinating even though I didn't quite understand it all.
Pity so much good work has been wasted or will never be implemented.
@Toyman said:
There is no power-of-two texture limit any more. Make your images any size you like.
If the dimensions are not product-of-64 I will pad your image with black with zero alpha.
THEY SHOULD HIRE THAT GUY
but seriously
As was expressly stated by the GS team that compressing your images is useless and can infact, due to the decompression that needs to happen, can slow down scene loading. The only benefit to image compression is for package size. This is less of an issue now that cell carriers allow for up to 100mb installs over cell networks
Guru Video Channel | Lost Oasis Games | FRYING BACON STUDIOS
The issue of package size is a major issue, especially on Android where lots of people accross the world have cheaper phones with limited storage. It can have a very real impact on downloads. I had an app with lots of full resolution background art. I reduced the package size by around 75% by compressing with TinyPNG. This had a very real impact on downloads. I tested on many devices and have found absolutely no detrimental effect for doing this in terms of app performance or stability.
It has proven to have much lesser of an effect on iOS as I think larger storage is the norm.
By the way, without compression or the ability to use GIFs or JPEGs it is very easy to go over the Google Play 100MB limit. Especially if you are creating an interactive book type app with full res background art.
//