#pixelpaint
Posts and pages on Ape Apps tagged with <strong>#pixelpaint</strong>
This morning I have released the 2.5.0 update for Voxel Paint, which includes a new bi-directional integration with Ape Chat. This feature is new for both apps and will be expanded and improved in the months ahead, but let's take a look at what it does right now!
Now when you click on the toolbar's top-right settings icon, you will see two new options (only available if you are signed in with an Ape Apps Account), Voxel Paint Chat and Set Chat Channel. If you click on Voxel Paint Chat, it will open the new embedded Ape Chat sidebar that will be familiar to players of My Colony and My Colony 2. The Set Chat Channel option lets you customize which Ape Chat channel is used by the app (the default is #voxelpaint, but you can use anything you want, like #mc2-voxeling for instance).
While the Ape Chat sidebar is open, two brand new features are unlocked that tie directly to chat. First, if you click on the toolbar camera icon which is normally used to save a .png of your model, you will now get a new dropdown menu with a Post to Chat option. This will still take a .png of your model as before, but instead of exporting to your device, it will post it directly into whatever Ape Chat channel you are currently signed in to.
Similar to posting .png images, the folder menu contains a new Post to Chat export option, which does the same thing, except it uploads the full model instead of a render. The render can then be viewed, manipulated and downloaded by users in the Ape Chat client.
These features are early and there are still some issues, particularly on the Ape Chat side. For example, currently the Download button in the in-chat renderer seems to be showing a plain text version of your model instead of actually downloading it. The header above the model is not formatted well for the slide-out chat side. It also messes with mouse wheel scrolling. So if you notice any of the aforementioned issues, you do not need to report them, as I already am aware!
Moving forward, I plan to expand this further. For instance, in the model renderer in the slide-out chat frame, I want to have a button that lets you instantly import the model you are looking at into your Voxel Paint workspace. That way if multiple people are in the chat, you can sort of collaborate on something. Someone could make a part of the model, post it, you could click on the import button and it would paste it in selected, and you can move it to where you need it to be.
Over the next day or two, these features will also be making their way to Pixel Paint. I probably will not make a new post about them since they will work largely in the same way that they do in Voxel Paint, but keep a look out for them in the coming days.
That is it for this update to Voxel Paint. I plan to improve the integration on both the Voxel Paint and Ape Chat side of things, so if you have ideas on how to make it even cooler, let me know!
https://voxelpaint.online/
#voxelpaint #pixelpaint
Now when you click on the toolbar's top-right settings icon, you will see two new options (only available if you are signed in with an Ape Apps Account), Voxel Paint Chat and Set Chat Channel. If you click on Voxel Paint Chat, it will open the new embedded Ape Chat sidebar that will be familiar to players of My Colony and My Colony 2. The Set Chat Channel option lets you customize which Ape Chat channel is used by the app (the default is #voxelpaint, but you can use anything you want, like #mc2-voxeling for instance).
While the Ape Chat sidebar is open, two brand new features are unlocked that tie directly to chat. First, if you click on the toolbar camera icon which is normally used to save a .png of your model, you will now get a new dropdown menu with a Post to Chat option. This will still take a .png of your model as before, but instead of exporting to your device, it will post it directly into whatever Ape Chat channel you are currently signed in to.
Similar to posting .png images, the folder menu contains a new Post to Chat export option, which does the same thing, except it uploads the full model instead of a render. The render can then be viewed, manipulated and downloaded by users in the Ape Chat client.
These features are early and there are still some issues, particularly on the Ape Chat side. For example, currently the Download button in the in-chat renderer seems to be showing a plain text version of your model instead of actually downloading it. The header above the model is not formatted well for the slide-out chat side. It also messes with mouse wheel scrolling. So if you notice any of the aforementioned issues, you do not need to report them, as I already am aware!
Moving forward, I plan to expand this further. For instance, in the model renderer in the slide-out chat frame, I want to have a button that lets you instantly import the model you are looking at into your Voxel Paint workspace. That way if multiple people are in the chat, you can sort of collaborate on something. Someone could make a part of the model, post it, you could click on the import button and it would paste it in selected, and you can move it to where you need it to be.
Over the next day or two, these features will also be making their way to Pixel Paint. I probably will not make a new post about them since they will work largely in the same way that they do in Voxel Paint, but keep a look out for them in the coming days.
That is it for this update to Voxel Paint. I plan to improve the integration on both the Voxel Paint and Ape Chat side of things, so if you have ideas on how to make it even cooler, let me know!
https://voxelpaint.online/
#voxelpaint #pixelpaint
I recently got a request from a Pixel Paint user for a way to embed the Pixel Paint application into their web project with some extra UI customization features, so I have added a few things and thought I would share it with anyone who might want to do something similar.
Starting with Pixel Paint v2.9.0, you can now embed the web app version of Pixel Paint into any html based project using a standard iframe tag and a handful of URL parameters which can be used to customize the user experience.
For the most basic implementation, you should append the emb=1 URL parameter to the base Pixel Paint URL. This will disable the Ape Apps Account related stuff as well as some features that do not work properly in a cross origin iframe. So a basic URL would look like this: https://pixelpaint.online/?emb=1 and you could use it on your website with something like this:
From there, Pixel Paint currently supports the following list of URL parameters. If you are interested in this feature and would like to see other customization parameters added, feel free to reply to this post and I will see what can be done.
https://pixelpaint.online/
#pixelpaint
Starting with Pixel Paint v2.9.0, you can now embed the web app version of Pixel Paint into any html based project using a standard iframe tag and a handful of URL parameters which can be used to customize the user experience.
For the most basic implementation, you should append the emb=1 URL parameter to the base Pixel Paint URL. This will disable the Ape Apps Account related stuff as well as some features that do not work properly in a cross origin iframe. So a basic URL would look like this: https://pixelpaint.online/?emb=1 and you could use it on your website with something like this:
<iframe src="https://pixelpaint.online/?emb=1"></iframe>You would then use css to adjust the width/height of your iframe, and I would suggest a good starting point is an iframe size of 480x520 and then you can go from there based on your needs.
From there, Pixel Paint currently supports the following list of URL parameters. If you are interested in this feature and would like to see other customization parameters added, feel free to reply to this post and I will see what can be done.
size: the size of the paint grid, 16 = 16x16, 24 = 24x24, etc. Embedded mode currently only supports square dimensions.
fr: floating readout. when set to 1, the current x:y coordinate that the user is mouse hovering over will show up in a floating box to the side of the cursor.
inv: invert Y axis. when set to 1, 0:0 is at the bottom-left corner instead of the top.
layers: show layers tool. when set to 0, the layers tool will be hidden and disabled
sx: starting X coordinate offset. for example, if set to 5, the origin X coordinate will be 5 instead of 0.
sy: starting Y coordinate offset. for example, if set to 5, the origin Y coordinate will be 5 instead of 0.
ico: show .ico export option. when set to 0, the option to export as .ico will be hidden.
vpp: show .vpp export option. when set to 0, the option to export as a Voxel Paint file will be hidden.
print: show print option. when set to 0, the option to print will be hidden.
mdm: enable mixed dark mode. when set to 1, the app will appear in dark mode regardless of user theme, except for the grid area which will have a white background.
zoom: specify the default zoom level. default is 1, I think the minimum supported is 0.2 but I am not 100% sure on that.
labels: when set to 1, show x:y axis and origin labels
stats: when set to 1, show stats in the corner for number of pixels in painting and number of colors used
ps: preset sizes. a comma separated list of custom square grid sizes you will let the user select from, ex 8,16,32
csv: when set to 1, shows the export to csv quick tool in the main toolbox
em: When supplied with an absolute URI that is base64 encoded (using js btoa function for example) that points to a valid Pixel Paint file (*.ppp), will download and display the file.
Here is a sample URL of many of the URL parameters in use:fr: floating readout. when set to 1, the current x:y coordinate that the user is mouse hovering over will show up in a floating box to the side of the cursor.
inv: invert Y axis. when set to 1, 0:0 is at the bottom-left corner instead of the top.
layers: show layers tool. when set to 0, the layers tool will be hidden and disabled
sx: starting X coordinate offset. for example, if set to 5, the origin X coordinate will be 5 instead of 0.
sy: starting Y coordinate offset. for example, if set to 5, the origin Y coordinate will be 5 instead of 0.
ico: show .ico export option. when set to 0, the option to export as .ico will be hidden.
vpp: show .vpp export option. when set to 0, the option to export as a Voxel Paint file will be hidden.
print: show print option. when set to 0, the option to print will be hidden.
mdm: enable mixed dark mode. when set to 1, the app will appear in dark mode regardless of user theme, except for the grid area which will have a white background.
zoom: specify the default zoom level. default is 1, I think the minimum supported is 0.2 but I am not 100% sure on that.
labels: when set to 1, show x:y axis and origin labels
stats: when set to 1, show stats in the corner for number of pixels in painting and number of colors used
ps: preset sizes. a comma separated list of custom square grid sizes you will let the user select from, ex 8,16,32
csv: when set to 1, shows the export to csv quick tool in the main toolbox
em: When supplied with an absolute URI that is base64 encoded (using js btoa function for example) that points to a valid Pixel Paint file (*.ppp), will download and display the file.
https://pixelpaint.online/?emb=1&size=24&fr=1&inv=1&sy=1&sx=1&ico=0&vpp=0&print=0&mdm=1&zoom=0.65&labels=1&stats=1&ps=9,16,24So those are all of the options currently available for Pixel Paint embedded mode. If there are other use cases you can think of for the app or other URL customization parameters you would like to see, just let me know and I will keep this thread updated with the latest information!
https://pixelpaint.online/
#pixelpaint
Today I am updating Pixel Paint to v2.0.0, which brings some UI improvements and the addition of layers, but more importantly, this release of Pixel Paint marks the beginning of a long transition period that is going to completely transform the entire Ape Web Apps ecosystem.
Ape Apps was started back in 2010 with the primary focus on Android apps, and in 2012, I launched the website Ape Web Apps as a place to host HTML5 versions of my apps and games. At that time, I also created wrapper host applications for Android, iOS and Windows for porting my HTML5 apps to "native," and exposing them to native platform features. In the years since, almost my entire software library has transitioned away from pure native applications to web applications, powered by the cross-platform Web App Core framework, which I have been updating and maintaining for the past 10 years.
Since that time, the concept of the Progressive Web App (PWA) has emerged, and web apps have been rapidly gaining capabilities to rival many of those found in native applications, making many of the capabilities found in Web App Core unnecessary or redundant. Furthermore, many of the old restrictions on web apps have been lifted. One example as that of storage space. Back when My Colony was first released, some browsers limited the storage space available to an app at 50mb, and for a time, there was an issue with players losing saved games because they were bumping up against that limit. Today the storage quotas are pretty much limited only by the free space available on the device, just like a native application.
Over the years, a lot of functions, features, and abstractions have been built into Web App Core to make cross platform development simple. As such, the library has continued to grow and grow over time. A relatively simple app like Typepad also carries with it all of the features and functions available in Web App Core, even though it only uses a small handful of them. This makes the app a lot smaller and slower loading than it needs to be.
The "industry" has also pretty much settled on the design pattern that each individual PWA needs to be hosted on it's own domain (or subdomain), which is in direct conflict with the design on the Ape Web Apps website. Sure it is workable the way Ape Web Apps is currently set up, but there are some issues that are going to become more apparent as time goes on, especially when it comes to the new File Handling API. Web apps like Voxel Paint can be associated with specific file types (like the .vpp file) so that you can double-click on them on your device and automatically load them up in the Voxel Paint web app.
This is awesome functionality, but since the PWA framework is designed to have one app per domain, things start to get messed up when you have multiple PWA's installed from a single domain (like Ape Web Apps) each trying to be associated with different file types. On some platforms, such as Windows 10/11, it still kind of works. On others, such as Chrome OS, it's totally broken. It's important that I get on top of these coming changes now, before features like File and Protocol handling become more widespread across the various web browsers.
So changes are on the way to Ape Web Apps (and the Ape Apps Launcher) that are going to impact a large percentage of the library. Firstly, a lot of the apps are going to be moving to new web addresses, the first being Pixel Paint.
Old URL: https://www.apewebapps.com/pixel-paint/
New URL: https://pixelpaint.online/
These moves will be made one by one as I convert these apps off of Web App Core. The moves also make the apps load a lot faster, since in stead of loading the entire Web App Core library, they are only using the specific functions that they need. Web App Core is being replaced by a much smaller library that basically only handles Ape Apps Account related functions, such as account login, managing premium licenses, etc.
I hope to have most apps converted off of Web App Core over the coming year, but not everything will be making the move. Some larger apps such as My Colony, My Colony 2, and some of the EZ Office related applications use so many of the Web App Core functions anyway that there would be literally no size or performance benefits to moving them off, and doing so constitute a substantial undertaking. Moving an app to a new domain also means that current saved data (that wasn't synced to Ape Cloud) would be lost, which is not acceptable for My Colony.
Going forward though, no new apps or games will be based on the old Web App Core framework, and Web App Core will only be maintained to address bugs and issues with existing applications, no new features will be added.
On apps that make the move off of Web App Core, I will still be providing a slimmed down "native" wrapper for users who wish to get the apps from an app store, but now more than ever, users will be better off installing the app through their browser as a PWA. The native apps will be little more than a webview that hosts the PWA and will have more overhead due to being packaged than just installing the PWA through the browser would. This is how all of my apps on Windows 10/11 and Steam already are, and once Android and iOS move in that direction, I will be able to make updates to all platforms without even having to submit new builds to the various app stores, saving myself a ton of time and work.
So those are the changes coming down the pike. The Ape Apps Launcher and Ape Web Apps websites will still be maintained and updated, but a lot of the links will just be redirecting you off-site. It will actually probably be better for some of the apps in terms of search engine discover-ability, being surfaced to their own domain or subdomain. I know on Pixel Paint, it's lighthouse score (which Google uses for page rankings) went from the failing to nearly 100% due to the increased loading time by no longer using Web App Core, so that should help as well.
In the meantime, check out the latest update to Pixel Paint at it's new URL, and check out the PWA by installing it to your homescreen!
https://pixelpaint.online/
#pixelpaint
Ape Apps was started back in 2010 with the primary focus on Android apps, and in 2012, I launched the website Ape Web Apps as a place to host HTML5 versions of my apps and games. At that time, I also created wrapper host applications for Android, iOS and Windows for porting my HTML5 apps to "native," and exposing them to native platform features. In the years since, almost my entire software library has transitioned away from pure native applications to web applications, powered by the cross-platform Web App Core framework, which I have been updating and maintaining for the past 10 years.
Since that time, the concept of the Progressive Web App (PWA) has emerged, and web apps have been rapidly gaining capabilities to rival many of those found in native applications, making many of the capabilities found in Web App Core unnecessary or redundant. Furthermore, many of the old restrictions on web apps have been lifted. One example as that of storage space. Back when My Colony was first released, some browsers limited the storage space available to an app at 50mb, and for a time, there was an issue with players losing saved games because they were bumping up against that limit. Today the storage quotas are pretty much limited only by the free space available on the device, just like a native application.
Over the years, a lot of functions, features, and abstractions have been built into Web App Core to make cross platform development simple. As such, the library has continued to grow and grow over time. A relatively simple app like Typepad also carries with it all of the features and functions available in Web App Core, even though it only uses a small handful of them. This makes the app a lot smaller and slower loading than it needs to be.
The "industry" has also pretty much settled on the design pattern that each individual PWA needs to be hosted on it's own domain (or subdomain), which is in direct conflict with the design on the Ape Web Apps website. Sure it is workable the way Ape Web Apps is currently set up, but there are some issues that are going to become more apparent as time goes on, especially when it comes to the new File Handling API. Web apps like Voxel Paint can be associated with specific file types (like the .vpp file) so that you can double-click on them on your device and automatically load them up in the Voxel Paint web app.
This is awesome functionality, but since the PWA framework is designed to have one app per domain, things start to get messed up when you have multiple PWA's installed from a single domain (like Ape Web Apps) each trying to be associated with different file types. On some platforms, such as Windows 10/11, it still kind of works. On others, such as Chrome OS, it's totally broken. It's important that I get on top of these coming changes now, before features like File and Protocol handling become more widespread across the various web browsers.
So changes are on the way to Ape Web Apps (and the Ape Apps Launcher) that are going to impact a large percentage of the library. Firstly, a lot of the apps are going to be moving to new web addresses, the first being Pixel Paint.
Old URL: https://www.apewebapps.com/pixel-paint/
New URL: https://pixelpaint.online/
These moves will be made one by one as I convert these apps off of Web App Core. The moves also make the apps load a lot faster, since in stead of loading the entire Web App Core library, they are only using the specific functions that they need. Web App Core is being replaced by a much smaller library that basically only handles Ape Apps Account related functions, such as account login, managing premium licenses, etc.
I hope to have most apps converted off of Web App Core over the coming year, but not everything will be making the move. Some larger apps such as My Colony, My Colony 2, and some of the EZ Office related applications use so many of the Web App Core functions anyway that there would be literally no size or performance benefits to moving them off, and doing so constitute a substantial undertaking. Moving an app to a new domain also means that current saved data (that wasn't synced to Ape Cloud) would be lost, which is not acceptable for My Colony.
Going forward though, no new apps or games will be based on the old Web App Core framework, and Web App Core will only be maintained to address bugs and issues with existing applications, no new features will be added.
On apps that make the move off of Web App Core, I will still be providing a slimmed down "native" wrapper for users who wish to get the apps from an app store, but now more than ever, users will be better off installing the app through their browser as a PWA. The native apps will be little more than a webview that hosts the PWA and will have more overhead due to being packaged than just installing the PWA through the browser would. This is how all of my apps on Windows 10/11 and Steam already are, and once Android and iOS move in that direction, I will be able to make updates to all platforms without even having to submit new builds to the various app stores, saving myself a ton of time and work.
So those are the changes coming down the pike. The Ape Apps Launcher and Ape Web Apps websites will still be maintained and updated, but a lot of the links will just be redirecting you off-site. It will actually probably be better for some of the apps in terms of search engine discover-ability, being surfaced to their own domain or subdomain. I know on Pixel Paint, it's lighthouse score (which Google uses for page rankings) went from the failing to nearly 100% due to the increased loading time by no longer using Web App Core, so that should help as well.
In the meantime, check out the latest update to Pixel Paint at it's new URL, and check out the PWA by installing it to your homescreen!
https://pixelpaint.online/
#pixelpaint
