I noticed a possible issue with the Digic6 build changes while working on the G5X port.The FONT_WIDTH and FONT_HEIGHT values change in gui_draw.h based on the THUMB_FW value.Unfortunately gui_draw.h is included by lib/font/rbf_font.c and many of the modules & games.All the lib & module code is supposed to be platform independent and is only built once by the autobuild process (based on the first camera settings - A1000).This means that for an autobuild the Digic6 cameras will have the wrong value for the font size built into the lib code and the module code.
I think it would be better to keep the FONT_WIDTH and FONT_HEIGHT values constant at their current values (8x16) and handle the Digic6 scaling within the gui_draw.c code and platform settings. This way the rest of the code continues to work with the same CHDK 'virtual' co-ordinate system.I'm doing this for the G5X which has yet another drawing system (32bpp bitmap, with X2 scaling in both directions).
The FONT_WIDTH and FONT_HEIGHT values change in gui_draw.h based on the THUMB_FW value.Unfortunately gui_draw.h is included by lib/font/rbf_font.c and many of the modules & games.All the lib & module code is supposed to be platform independent and is only built once by the autobuild process (based on the first camera settings - A1000).
I'm doing this for the G5X which has yet another drawing system (32bpp bitmap, with X2 scaling in both directions).
[QuoteI think it would be better to keep the FONT_WIDTH and FONT_HEIGHT values constant at their current values (8x16) and handle the Digic6 scaling within the gui_draw.c code and platform settings. This way the rest of the code continues to work with the same CHDK 'virtual' co-ordinate system.I'm doing this for the G5X which has yet another drawing system (32bpp bitmap, with X2 scaling in both directions).I'd be interested in seeing that new drawing system. I was thinking about using the RGBA buffer(s), but have not attempted to make an implementation.If yours proves to be a usable alternative, we could remove the D6 related mess from core/gui_draw.c (and elsewhere) and implement the new system on all D6 ports.
Quote from: philmoz on 05 / November / 2017, 00:56:15The FONT_WIDTH and FONT_HEIGHT values change in gui_draw.h based on the THUMB_FW value.Unfortunately gui_draw.h is included by lib/font/rbf_font.c and many of the modules & games.All the lib & module code is supposed to be platform independent and is only built once by the autobuild process (based on the first camera settings - A1000).I'm probably missing something, but this seems like a much bigger problem than just font size. All code for thumb2 platforms should built separately from the arm platforms (objects in .o2 instead of .o) so it has been assumed in a lot of places that THUMB_FW is safe to use in "platform independent" code.
QuoteI'm doing this for the G5X which has yet another drawing system (32bpp bitmap, with X2 scaling in both directions).If it needs yet another drawing system, the above mentioned THUMB_FW assumption goes out the window. I knew this would be problem, but was hoping it wouldn't be so soon.
Although it works the main problem is it destroys the Canon UI and I have not found a way to trigger it to refresh.On the G5X there is only one buffer, and to erase the CHDK UI (e.g. leaving ALT or menu) I clear this buffer - this also wipes the Canon UI elements which don't get redrawn unless a significant event happens (enter & leave Canon menu for example).
fc1b9218: 483c ldr r0, =0x5fe80000
You're right. Testing current autobuild on sx280 indeed shows broken RBF fonts (the are drawn ~half size).
Now I'm confused again.
Quote from: philmoz on 05 / November / 2017, 16:08:55Although it works the main problem is it destroys the Canon UI and I have not found a way to trigger it to refresh.On the G5X there is only one buffer, and to erase the CHDK UI (e.g. leaving ALT or menu) I clear this buffer - this also wipes the Canon UI elements which don't get redrawn unless a significant event happens (enter & leave Canon menu for example).I see, that's less than ideal.I've been meaning to ask the following for a while.What do you see in the camera's RAM at 0x5fe80000 (uncached) and beyond that?If the g5x worked like the m10, the end of physical RAM would be assigned to YUV and opacity buffers.The address comes from here (100c):Code: [Select]fc1b9218: 483c ldr r0, =0x5fe80000I found this when doing the m10 port - while looking for equivalent parts of the firmwares.
And another question: In shooting modes where the focus rectangle is moving around; is it drawn on that single RGBA buffer?
I've been meaning to ask the following for a while.What do you see in the camera's RAM at 0x5fe80000 (uncached) and beyond that?If the g5x worked like the m10, the end of physical RAM would be assigned to YUV and opacity buffers.The address comes from here (100c):Code: [Select]fc1b9218: 483c ldr r0, =0x5fe80000I found this when doing the m10 port - while looking for equivalent parts of the firmwares.
When you draw the CHDK stuff on the YUV layer does it appear below the Canon UI elements?
Started by NewbieToobie General Chat
Started by enveetee General Discussion and Assistance
Started by kim.diedrichsen.7 General Chat
Started by alvm DryOS Development
Started by reyalp « 1 2 ... 7 8 » General Discussion and Assistance
