#pixelpaint

Posts and pages on Ape Apps tagged with <strong>#pixelpaint</strong>
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:
<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
Here is a sample URL of many of the URL parameters in use:
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,24
So 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
3mo ago
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
1y ago

Syndication

Welcome
Ape Apps, LLC is an independent software development company founded in 2010 by Brandon Stecklein. Over the years, Ape Apps has published over 400 apps and games across various platforms. You can get in touch with Brandon on Twitter or by leaving a post on his wall @bastecklein
App of the Day