Limitations of Processing - daniel-tran/snake-boxer-collection GitHub Wiki

Processing is great and all, except for these things:

Images are expensive to use

If you play any of the Snake Boxer games on a PC with the default full screen resolution, you'll probably notice that the game speed is rather slow - though I could make up the excuse that this to create a more authentic 8-bit gaming experience. This is usually due to the sketch having to draw lots of images at the same time, or a couple of images that have been scaled up.

At worst, this can cause the JVM to run out of memory and crash the sketch. While you can manually increase the allocated memory in the JVM under "File > Preferences", there are usually optimisations you can make within the sketch to stay below the default memory allocation, such as:

• Avoid having large arrays of PImage objects stored in memory.
• For large, static images, consider using the standard drawing functions in Processing to manually draw the image on the screen.
• Use the P2D renderer, although this can cause other side effects (e.g. noticeably longer initial load time on Android).

Incompatible functions between Java and Android mode

While both of these modes are mostly the same, they do support specific functions or global variables which aren't available in the other mode.

For example, Android mode has access to the touches array, which is used to support multiple screen presses. This is not recognised in Java mode, and would register as an undefined variable.

To keep the same code base compatible in both modes, the sketch cannot utilise platform specific functions or variables.

Deliberate resource duplication

If you look at the main folder of the Snake Boxer games, you will notice that some source files and images are the same across all the games. This is intentional, as the sketch will not have access to resources outside of the immediate folder where the main sketch is located.

In Android mode, images MUST be in the data folder. Java mode technically allows images to be loaded from anywhere if you use a relative path from the data folder, but still isn't a good idea since that requires the sketch to load images with a specific directory structure.

As a result, this creates a kind of maintenance burden, where changes in one common image or source file need to be manually propagated across each game AND tested to ensure it didn't break anything.

No unit testing framework

I'm not aware of any unit testing frameworks for Processing, and as such, a lot of testing is done manually. Fortunately, the Snake Boxer games are fairly simple, but the problem still stands: Any change made requires manual testing.