Dean
New Member
Posts: 7
|
Post by Dean on Mar 10, 2016 16:48:30 GMT -8
Hi, I'm fairly new to GD2, but so far I'm very impressed with what it can do and how easy it is to work with. That being said, I'm hoping there exists a library providing a console-like text box.
What I have in mind is a subclass of Print that you init by specifying a font and rectangle to draw into. You can then send text to it and it handles display, including line-wrap and scrolling. Ideally it would have options for fg/bg color, including transparent bg so it could be an overlay.
If nothing like that already exists, I might put one together. In case I go this route, are there any built-in monospace fonts? [EDIT] Looks like font 16 might be monospace... [/EDIT]
Thanks, - Dean
|
|
Dean
New Member
Posts: 7
|
Post by Dean on Mar 12, 2016 13:49:00 GMT -8
I've been looking into doing this myself, and the right way to go about it appears to be a TEXT8X8 or TEXTVGA bitmap. The Print subclass would just manage the contents of that bitmap. The bitmap could then be drawn like any other bitmap object, with color and transform effects in place.
This has the added benefit that wouldn't eat up precious RAM from the Arduino (the bitmap would be stored in FT800 RAM).
I can encode console bitmaps as fixed assets easily enough and just modify their contents at runtime, but I was curious if any thought has been given to memory management for dynamic assets? It appears that all the asset header files define ASSETS_END, which seems to be the highest address in video RAM used by the library. Is it safe to make use of RAM above this point, or will it collide with anything else?
Thanks, - Dean
|
|
|
Post by jamesbowman on Mar 16, 2016 17:00:12 GMT -8
Perhaps let the user define the address of the TEXTVGA bitmap in the begin() call? With a default of zero?
So if you have assets then .begin(ASSETS_END) would set it up correctly.
|
|
Dean
New Member
Posts: 7
|
Post by Dean on Mar 16, 2016 17:51:34 GMT -8
Yep, that is pretty much what I had arrived at. For common cases 0 or ASSETS_END is the right answer, and for anything more dynamic the user gets to decide.
Another question:
I've been using cmd_memset() to clear a line when the cursor first lands there, but I've noticed it seems to get behind other operations (sometimes significantly behind). I've added calls to finish() in a few key places to block until the async operations catch up, and that does seem to work.
However, is memset+finish the best way to go about clearing 30 to 60 bytes? Would I be better off just clearing the line by looping on wr()? I just don't have enough experience with this chipset to know which approach is makes more sense...
Thanks, - Dean
|
|
|
Post by jamesbowman on Mar 16, 2016 18:07:59 GMT -8
Cool!
Yes, using commands is almost always better than direct writes, so the FT800 can be doing the work.
In fact I try do avoid doing direct writes at all, because it gets very confusing mixing commands with direct writes, just as you mention. You can use a command to write a byte like this
GD.cmd_memwrite(addr, 1); GD.cmd32(d8);
and 16-bits like this:
GD.cmd_memwrite(addr, 2); GD.cmd32(d16); when using pure commands like this, you need to do a GD.flush() at the end to make everything visible -- GD.finish() shouldn't be necessary.
|
|