Hello,

Thank you for the update, I'm glad to hear you can resolve the astcenc.exe issue.

Would you be able to provide the Conversion settings utilised in your testing? Along with the image dimensions for the needle image?

Best Regards,
BRT Community

Hello,

EVE renders the screen from the contents in RAM_DL, however RAM_DL is actually double buffered meaning there is an active RAM_DL which EVE parses and uses to render the screen for every screen refresh. There is also a passive version of RAM_DL, this is the one you write to when you are issuing a display list or command list to EVE, this is swapped into the active buffer when the SWAP() command is issued.

The intention being that you only write a new display/command list to EVE when require the screen to be updated (say when a button is touched and you wish to enact a 3D effect to make this apparent), otherwise you can let the active display list continue to render the screen in the background and reduce the number of SPI transactions you send to EVE.

I note you mention you are scanning and re-issuing your Display() function every 100ms, but can I ask if this is irrespective of a touch detection?
It would not be necessary to re-issue the Display() call if you do not need to update any of the items on the screen.

Generally there are two approach's to dealing with touch on EVE, in either case we would recommend to initially issue your display list (call Display()):

• Polling - Call Display(), then utilise another routine to periodically poll the appropriate touch registers to detect a touch (for example REG_TOUCH_TAG) 
• If a touch is detected then you can re-issue a new display list with the appropriate updates (call Display() to update the screen) if required
• Interrupts - Configure the touch interrupt, Call Display(), then wait for the interrupt pin to trigger and process this interrupt on your MCU (read the appropriate touch registers)
• If an item has been touched which requires the screen to be updated then issue Display() accordingly with the required updates

Both approaches should reduce the number of times you call Display() the idea being that you would only need to update RAM_DL when something has to be changed on the screen. i.e. you shouldn't need to worry about an interrupt being triggered half way through your Display() routine because you are not continuously writing this data to EVE. If you structure your code in am manner that calls Display() and then only calls it again once a touch has been detected you should avoid any interrupted Display() calls. However it is possible that for example two interrupts would be trigged very close to each other, in this case you can utilise the recovery routine detailed in section 5.7 of the Programmers Guide and then re-issue the Display() command. As EVE will be rendering from the active versions of RAM_DL is a write to EVE is interrupted half way through a Display() command then the screen contents wont be affected.

Best Regards,
BRT Community

Hello,

Unfortunately it is not possible to achieve this with a JPEG as these are loaded into EVE as RGB565 bitmaps (or  L8) which do not include an alpha layer (transparency), this is required to make sections of images transparent.

As you have noted using a command such as blend, this effects the whole image because it cannot determine which sections are the background in a JPEG. It may be possible to utilise a second masking image to mask off the background in your JPEG and then use the STENCIL operation to only draw the section of the image that isn't masked, but this would require an image such as a PNG which utilises an alpha layer to be used as the mask. In this case it may be simpler to modify your original JPEG image in a image processor to include a transparent background and save this accordingly.

Best Regards,
BRT Community

Hello,

Thank you for your question.

It won't be necessary to blend the two images together using the BLEND_FUNC, this is what is causing the image to only show on the darker sections of the back ground image.

You can simply place one image on top of the other so long as the image has an appropriately transparent background, for example the below code places an ASTC image (motorbike) on top of background image:

BITMAP_HANDLE(0)
CMD_SETBITMAP(0, RGB565, 800, 480)
BEGIN(BITMAPS)
VERTEX2F(0, 0)
END()

BITMAP_HANDLE(1)
CMD_SETBITMAP(768000, COMPRESSED_RGBA_ASTC_4x4_KHR, 288, 164)
BEGIN(BITMAPS)
VERTEX2F(6112, 4208)
END()
Please see the attached .png for an example of the above code running in EVE Screen Editor.

Best Regards,
BRT Community

Hello,

Great to hear that it helped and thanks for letting us know,

Best Regards, BRT Community

Hello,

Unfortunately the development team are unable to share the methodology used to produce the .raw file form the ASTC file at this moment in time.

However it is possible to view .raw files within our EVE Screen Editor utility directly, by adding the .raw file as content, after whihc you can click and drag this onto the screen to generate preview.

Please see the attached screen shot of a .raw file from an 4x4 ASTC conversion being previewed in EVE Screen Editor.

Best Regards,
BRT Community

Hello,

Thank you for your question, I have queried the development team on the relationship between the .astc and .raw outputs when performing an ASTC image conversion.

You can find the astcec.exe utility and eab_tools.exe utility within the installation folder for EAB, generally this is in the following location:

C:\Users\Public\Documents\EVE Asset Builder\tools

Best Regards,
BRT Community