If we could provide a (positive integer) x_scale and y_scale optionally to draw sprites (and text), it would bring a few benefits:
sprite storage on Frame could reduce by a significant fraction (and memory is a challenge as soon as we start using sprites) for sprites that don't need to be full-resolution, but we want to draw them larger anyway (e.g. 32-px font could be drawn at 64x64 and save 75% of the space, rather than send bigger sprites just because we want bigger text)
transfer time is reduced by roughly the same fraction (and might be key to getting real-time updates to the display for live translation, action games etc.)
sprites could be reused (e.g. text display at different sizes)
retro-looking pixelated sprites could all just be built at 8x8 or 8x16 etc and be scaled up to pixellated goodness for display
drawing rectangles becomes trivially easy
Positive integer scaling is all that I'd ask for here. In C, repeating each pixel in x or y x_scale or y_scale times would be straightforward to implement, but I'm not sure how easily that translates into the FPGA, so happy to take other suggestions that might be a better fit.
If we could provide a (positive integer) x_scale and y_scale optionally to draw sprites (and text), it would bring a few benefits:
Positive integer scaling is all that I'd ask for here. In C, repeating each pixel in x or y x_scale or y_scale times would be straightforward to implement, but I'm not sure how easily that translates into the FPGA, so happy to take other suggestions that might be a better fit.