View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000088 | Gorilla3D | Bug Reports | public | 2020-05-09 10:06 | 2020-08-05 13:01 |
| Reporter | administrator | Assigned To | administrator | ||
| Priority | urgent | Severity | major | Reproducibility | sometimes |
| Status | resolved | Resolution | fixed | ||
| Product Version | 0.8.2.x | ||||
| Target Version | 0.8.2.x | Fixed in Version | 0.8.2.x | ||
| Summary | 0000088: Black forms on android, when no Gorilla component is used | ||||
| Description | If GorillaViewport is on the main form, things so far work on Android. however if the main form does not have gorilla components, and gorilla components are on a different form, when the app runs the main form is completely black. Components are there, for example if there is a Tedit that I manage to touch, the keyboard does appear - but it's all black. Remove all references to Gorilla components on that second form, and things (tbuttons, tedits, tmemos, etc) display normally on the main form. | ||||
| Tags | No tags attached. | ||||
| Delphi-Version | 10.3.3 | ||||
| OpenGLVersion | OpenGL 4.3 | ||||
|
|
By refactoring rendering pipeline, regarding WBOIT rendering, the default FBO handling changed. So at some situations no default FBO was bounded. This leads to black context rendering. > Testing not finished yet! The black forms also appeared on windows platform under specific circumstances. On evaluating FMX TEffect component usage on TGorillaViewport some problems occured. The main problem is the different texture memory alignment of DirectX and OpenGL. On windows Gorilla3D still uses bitmaps handled by D3D canvas and DirectX. This allocates image buffers with 32 Byte row alignment. Instead in Gorilla3D and OpenGL we use 1 Byte row alignment. So the DirectX-OpenGL interaction is not fully supported. I've implemented a dirty hack, because FMX internal canvas and filter classes are not allowed to be overwritten. The solutions adjusts viewport control width to a multiple of 32. This leads to larger rendering area on odd control width. Other FMX controls will then be not adjusted correctly anymore. Until Embarcadero do not allow to overwriter certain code, this problems remains unsolved. |
|
|
Another bug detected. TBlendFactor and TBlendEquationFunc enumeration types used OpenGL constant values directly. On FMX no blending settings are available by default. So TBlendFactor and TBlendEquationFunc values were zero, which lead to invalid OpenGL values. I separated enumeration values from OpenGL values and introduces conversion methods in TBlendFactorHelper and TBlendEquationFuncHelper classes. Also default values for FMX are now set. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2020-05-09 10:06 | administrator | New Issue | |
| 2020-05-09 10:06 | administrator | Status | new => assigned |
| 2020-05-09 10:06 | administrator | Assigned To | => administrator |
| 2020-08-05 10:10 | administrator | Note Added: 0000091 | |
| 2020-08-05 13:01 | administrator | Status | assigned => resolved |
| 2020-08-05 13:01 | administrator | Resolution | open => fixed |
| 2020-08-05 13:01 | administrator | Fixed in Version | => 0.8.2.x |
| 2020-08-05 13:01 | administrator | Note Added: 0000092 |
