We had discussions recently on the Agon & Console8 Community discord's firmware-vdp channel about some observed discrepancies between an image loading program running on the emulator vs real hardware. Long story short, real hardware does it's drawing via a drawing queue processed by a separate task which means the bitmap data could have changed by the time the bitmap is actually drawn to screen, whereas the emulator only ever does immediate drawing operations.
The issue observed was eventually solved by a combination of things - primarily by making use of VDU 23, 0, &CA to flush the drawing queue after a bitmap was drawn, and before it's buffer was re-used.
The nature of the drawing queue needs to be more clearly documented, especially the differences between real hardware and the emulator, as well as the implications of the drawing queue when drawing bitmaps.
The buffered commands system was designed to allow for bitmap data to be changed after the bitmap has first been set up, so we would not want to prevent that from happening. We should however make it clearer in the documentation about the nature of the drawing queue, it's implications when drawing bitmaps, and also the differences between the VDP running on real hardware and the emulator.
There are still things that we can do to help prevent foot-guns. With how things currently are it's possible to have a bitmap queued up to be drawn where the bitmap object, and/or the bitmap data it points to, could have been invalidated before it's drawn - technically the memory could even have been re-used. Making use of smart-pointers could help here.
An accompanying issue in vdp-gl is found here: AgonPlatform/vdp-gl#27
We had discussions recently on the Agon & Console8 Community discord's firmware-vdp channel about some observed discrepancies between an image loading program running on the emulator vs real hardware. Long story short, real hardware does it's drawing via a drawing queue processed by a separate task which means the bitmap data could have changed by the time the bitmap is actually drawn to screen, whereas the emulator only ever does immediate drawing operations.
The issue observed was eventually solved by a combination of things - primarily by making use of
VDU 23, 0, &CAto flush the drawing queue after a bitmap was drawn, and before it's buffer was re-used.The nature of the drawing queue needs to be more clearly documented, especially the differences between real hardware and the emulator, as well as the implications of the drawing queue when drawing bitmaps.
The buffered commands system was designed to allow for bitmap data to be changed after the bitmap has first been set up, so we would not want to prevent that from happening. We should however make it clearer in the documentation about the nature of the drawing queue, it's implications when drawing bitmaps, and also the differences between the VDP running on real hardware and the emulator.
There are still things that we can do to help prevent foot-guns. With how things currently are it's possible to have a bitmap queued up to be drawn where the bitmap object, and/or the bitmap data it points to, could have been invalidated before it's drawn - technically the memory could even have been re-used. Making use of smart-pointers could help here.
An accompanying issue in vdp-gl is found here: AgonPlatform/vdp-gl#27