Greetings all!

I've been playing around with the bitmap distortion matrix and masking to produce an isometric pseudo-3d display using the EVE3.  It's still pretty raw, and while I've yet to boil it down to a library that takes care of the matrices and masks, I am getting some pretty impressive results using a single texture to create the effect.

I'm evaluating the approach by revamping a pong clone from black and white to something slightly more modern looking.

While there is certainly a cost in terms of setting up the stencil buffer state and manipulating the matrices, this approach appears to exercise the EVE3 where it shines.

In theory, similar techniques could be used to produce more aggressive 3d texturing, however all bitmap distortion is limited to affine projections thus producing a result comparable to to first-gen Playstation.  I likely won't bother exploring that due to the amount of stencil manipulation required to split any quads into two affine textured triangles, and the somewhat ugly result that the non-perspective distortion would result in.

Has anyone else here played with the bitmap distortion to achieve this or similar effects?

Cheers!

Yes, the shadow/highlight effect on text in the widgets.

In particular, setting a font color of black causes the text to look smeared due to the shadow color matching the font color.

Sure enough... after decoupling the display and touch timing in my own code, changing the touch mode to continuous does now show the threshold being enforced.

Any reason this appears not to work when running touch in frame mode?

As those suggested state machines will need to be duplicated or extended for each of the existing screens (again, legacy software migration), this is a solution that would require completely restructuring the existing codebase.  That is one of the things on my todo list, however, it will not be done to work around the EVE chip's swap behavior.

In the end, this will likely move to a co-processor command buffer managed on the MCU, using DMA to feed the FIFO.  Using the self-modifying command stream I mentioned in another thread, this can at least be built in MCU RAM without waiting on completion by the co-processor, or guessing at the resulting display list snippet sizes.

As stated earlier, my concern is not delays in updating the display, it's managing the SPI communication time.  The transfer times are fine as they are, up until the FIFO overflows due to RAM_DL contention.

The other ways I see this issue being managed are:

• Moving screen initialization logic into each screen's event loop, waiting for the last swap request to be completed before initializing the new screen.  This would allow the automation logic to still execute if the FIFO was at risk of overrun, and is a much more conservative change to the existing code.
• Build the entire screen-initialization command list in RAM_G, and feed the FIFO from there.  This would have the advantage of shifting the RAM burden to the EVE, which has a much larger capacity than the MCU.  It also would prevent the FIFO from filling, as CMD_DLSTART would be cached in RAM_G along with the reset of the new-screen initialization.
• Abandon the co-processor widgets and build new screens directly in RAM_G

I'm a bit surprised that the with the contention around RAM_DL and suggested swap behavior which exacerbates this contention that there is no way to either track the scanout progress, or to abort pending operations to make the co-processor available.  Either of these would allow the cost of a pending swap to be managed. 

In the meantime, writing zero to the REG_DLSWAP register is giving me exactly the behavior I'm looking for until I either A: encounter the 'unpredictable-behavior' mentioned, or B: proactively migrate to a MCU command buffer and DMA.

Very well then.

Is there any other alternative which doesn't require switching to line swap?

I see no way to determine when a frame is nearing completion (no register showing the current vertical position in scanout).  Heck, the only way I can see to switch from a frame-swap to a line-swap is by replacing CMD_SWAP with CMD_MEMWRITE.

Is there perhaps a way to abort all pending operations and begin populating the command FIFO in less than the frame interval?

Cheers!

Hey all,

Perhaps this is a question for the Bridgetek folks, but I'm looking for a way to rapidly cancel pending operations and first up is the frame-swap if one has been scheduled.

I've found that the swap can be aborted allowing dependent operations to proceed by writing a zero to REG_DLSWAP.  While my testing looks good, the documentation specifically states not to write 0 to this register.

I'm interested in using this to rapidly begin a new screen without waiting for the previous swap (and corresponding CMD_DLSTART) to complete.  Any specific reason this particular operation is specifically prohibited in the doc?

Hey Rudolph, first off I'd like to thank you for engaging whether or not this trick is necessary or even useful.

The main problem this is meant to solve is prediction of the size of a snippet produced by a series of co-processor commands, or in my case, by higher-level API calls which make use of widgets plus our own display elements.  In the source code you linked earlier, you're building a snippet once during initialization, and getting the size upon completion.  This works well enough for static snippets, but generalizing this approach to snippets that are updated between frames requires synchronization between the EVE and MCU.

Writing the snippets direct to RAM_G as you mentioned would avoid the problem of RAM_DL contention, but as you point out, introduce a new problem of ensuring that the snippets are not modified during the CMD_APPEND calls.  Though, this problem is simply mitigated by double-buffering the snippets on update.  Moot point though, as this is not an option provided by the co-processor.

Pre-calculating multiple states of snippets, and appending the desired one based on MCU state is the closest to what I sought out to accomplish.  The main issue here becomes that the API I'm building has more than two states per button as we also allow non-touch navigation using a d-pad.  With a highlight state added to support the d-pad the number of per-button states increases from two to four, and quickly becomes impractical should other states be added.  In our use-case, we also use different colors/blinking to indicate other state through the appearance of the buttons.

Re-issuing all the draw commands each frame where the screen is updated is probably the safest workaround.  I'll admit, the main reason I didn't pursue this method is that we have some screens where very little changes per frame, and others where most of the screen content is dynamic (mostly text, but not all).  Again, the goal is to provide a consistent API that handles these two cases in a uniform way.  Also, in the case of text, the most SPI traffic efficient way to update a large number of text fields is using CMD_TEXT, provided the text strings are more than a few characters.  Obviously, this is no longer true if the screen content is static and can be loaded to flash ahead of time.

With regards to allocating enough space for worst case size, that's exactly what I'm doing.  But due to the desire to save these snippets to ram, and the structure of the append command, the actual size of the snippet is still required.  It is required both for the copy to RAM_DL, and for the corresponding CMD_APPEND.

The primary advantage of this approach is the number of snippets can be arbitrarily large, with no impact on the amount of SPI traffic.  In essence, it allows arbitrary granularity on how many elements are updated as a batch or snippet.  Managing worst case performance can then be tackled by splitting larger snippets into smaller ones, updated less often.  The commands sent by the MCU do not change regardless of how many snippets are created.

Perhaps your constraints aren't the same as the ones I'm managing in my own work?

For what it's worth, developing this trick and dealing with the FIFO wraparound didn't take much time at all.

Cheers!