Sorry for just blurting out this whole thing but Iāve been thinking about and discussing this privately with friends for a while and would appreciate this. If anything is confusing Iām more than happy to discuss further as well.
Iām proposing to allow developers to draw a subsection of an EditableImage onto another EditableImage rather than requiring full-image transfers. This would enable more efficient memory use and better support for tile-based rendering techniques.
Currently, EditableImage:DrawImage only allows drawing an entire image onto another which presents challenges for tile-based games. In one of my 2D projects where the bulk of rendering is tile-based where rendering is handled using an EditableImage, a common design question arises:
- Should developers upload each tile as a seperate image, consuming fewer resources but quickly becoming impractical with large tilesets?
- Or should they upload a single tileset and extract individual tiles into their own
EditableImages at runtime, which effectively doubles memory usage due to maintaining both the tileset and extracted tiles?
By enabling the ability to draw a subsection of an EditableImage, develoeprs can efficiently use tilesets without excessive memory duplication which improves both flexibility and performance.
Since EditableImage:DrawImage does not support drawing subections, I currently use the second method- extractng indidiaul tiles at runtime into seperate EditableImages. However, as mentioned, this approach is inefficient, consuming unnecessary memory and adding extra processing overhead. This inherently limits support on the platform as less devices will be supported.
There are currently no APIs in Roblox that allow the drawing of a subsection of an EditableImage, making this a gap in functionality that could be improved.
In a traditional workflow, developers typically use ImageLabel or ImageButton instances to display textures, including tilesets. However, EditableImage is a better fit for 2D game rendering.
Unlike standard UI rendering, EditableImage grants direct access to pixel data, enabling procedural modifications, custom effects, and dynamic texture generationākey features for creating unique 2D visual styles.
Using instances for tile-based rendering introduces significant overhead due to the sheer number of unique UI elements required. In contrast, EditableImage allows all rendering to be handled within a single texture, drastically improving performance.
Additionally, EditableImage offers the flexibility to implement custom rendering techniques, such as auto-tiling, making it a powerful tool for efficient and dynamic 2D game development.
A modification to DrawImage or the introduction of a new method would allow for developers to efficiently use tilesets without excessive memory duplication.
Option 1: Modify DrawImage to accept a window region
EditableImage:DrawImage(position, windowPosition, windowSize, image, combineType)
-
windowPosition: A Vector2 specifying the top-left corner of the region in the source image.
-
windowSize: A Vector2 defining the width and height of the subsection to be drawn.
With the other parameters staying the same.
Option 2 (Preferred): Use a configuration table
An alternative and more flexible approach would be to modify the DrawImage method to accept a configuration table:
EditableImage:DrawImage(position, image, config)
Where config is a table:
{
WindowPosition: Vector2,
WindowSize: Vector2,
CombineType: Enum.CombineType
}
Why this is a preferred approach:
- The
EditableImage API is already in production, so adding new required parameters to DrawImage would break existing code
- Using a
config table allows new functionality to be added without forcing developers to update all existing usages of DrawImage
- If
config is omitted, it defaults to {}, ensuring full backwards compatibility
- Aligns with the existing trend of
config-based APIs like AssetService:CreateEditableImage, maintaining consistency in API design.
Option 3: Introduce a new method, DrawSubsection
Rather than modifying DrawImage another approach would be to add a dedicated method:
EditableImage:DrawSubsection(position, image, windowPosition, windowSize, combineType)
This method would function similarly to DrawImage but explicitly target drawing subsections.
The benefit of this approach is:
- It avoids modifying
DrawImage, keeping it simple for cases where full-image drawing is still preferred.
- Developers who need subsection drawing can adopt
DrawSubsection without affecting existing workflows.
- This makes it clear in the API that
DrawSubsection is specifically for partial image transfers to discoverability.
