assets/developer-notes/stephanie-gawroriski/2016/10/10.mkd

   1 # 2016/10/10
   2
   3 ## 08:43
   4
   5 One thing to consider is, how are the OpenGL ES APIs actually even used?
   6 Basically there are no displayable to use with the LCD UI, but there are
   7 contexts and displays. EGLDisplay and such are not Displayables.
   8
   9 ## 08:52
  10
  11 Well for M3G you perform a `bindTarget` on `Graphics` provided by the
  12 `Canvas` or `CustomItem`. So this is rather simple. So the next thing is
  13 how to do this for OpenGL ES.
  14
  15 ## 08:57
  16
  17 So I suppose then this is done with `EGLDisplay eglGetDisplay(Object __a)`
  18 since that is the only thing that makes sense. This means that I will need
  19 some kind of special binding system in the LCDUI code to handle cases where
  20 special cases are bound to. So somehow I will need to make publically
  21 available interfaces.
  22
  23 ## 08:59
  24
  25 And the example uses:
  26
  27         Display display = Display.getDisplay(thisMIDlet);
  28         display.setCurrent(this);
  29
  30 Then there is a call to `eglCreateWindowSurface` which uses a `Graphics`
  31 object. So that is basically all there is, so I can really now start
  32 implementing OpenGL ES and potentially M3G. I just need to think of a good
  33 way to have the special handling of display things. The only thing that I
  34 will need is some way to get the display instance that is currently
  35 being used and perform magical binding to it. And since the M3G code I plan
  36 to have it use OpenGL ES, I only have to implement base 3D rendering code
  37 once.
  38
  39 ## 12:18
  40
  41 So the EGL classes, apart from the interfaces, have package private
  42 constructors. This could complicate things if I want to have software
  43 rasterizer in another project/package. However, hopefully noone will mind
  44 if I make the constructors protected.
  45
  46 ## 12:20
  47
  48 Although, I can always keep it internal. I can have the base classes handle
  49 stuff such as LCDUI and then have software rasterizers and others implement
  50 the actual GL interfaces. I can make it where EGL uses whatever it wants and
  51 where the rasterizers are agnostic to it. The EGL interfaces can be thought
  52 up of system specific interfaces though. So this way the package will manage
  53 the rasterizers. Then the rasterizers will just expose themselves over the
  54 service mechanism. I just will need priorities so that way if a software
  55 rasterizer exists and a hardware one also exists, that the hardware one is
  56 selected first. As long as the hardware rasterizers support rendering to an
  57 off screen buffer, they should not have any issues at all when they are
  58 implemented.
  59
  60 ## 12:32
  61
  62 Actually, GUI can lose Game. This way I can just have a basic `drawGame` for
  63 the most part. Otherwise I will have to setup new UIs whenever a new game is
  64 created, which would be very complex.
  65
  66 ## 13:45
  67
  68 Since the size of a canvas may change when it comes to graphic operations, I
  69 would suppose that `GameCanvas` and `Canvas` `getGraphics` will return a
  70 forwarding `Graphics` instance so that the backing image that has the contents
  71 of the canvas can change, since images cannot be resized.
  72
  73 ## 13:50
  74
  75 Then for the renderer that the game uses, I will need to specify the width and
  76 the height of the game view because it could change and may not be known when
  77 a draw request is made.
  78
  79 ## 15:37
  80
  81 The problem with that though, is that Graphics is private and/or package
  82 private. So really there is no way to really initialize such a thing, except
  83 from the base class using some kind of hidden API.
  84
  85 ## 15:59
  86
  87 So lets see, how do I handle `GameCanvas` getGraphics? Looking at some of
  88 these classes, it makes it seem as if they never heard of interfaces. But
  89 I suppose J2ME was made at a time where interfaces were frowned upon and
  90 you really wanted abstract classes.
  91
  92 ## 16:02
  93
  94 Well, I suppose `Graphics` can just implement the bulk of drawing operations
  95 and then just draw them somewhere. I could cheat though and have another
  96 class.
  97
  98 ## 16:05
  99
 100 Actually I know a way I can cheat, I can have `Displayable` extend a class
 101 of mine that is public. Then instead, I can have an accessor that can access
 102 all the hidden stuff via a static. So this new base for displayable would
 103 allow me to hack it up and allow for what I want.
 104
 105 ## 16:15
 106
 107 Well, I could in theory just break compability in some subtle ways. Well
 108 really, Canvas is double buffered for the most part, which essentially
 109 means that there is a backing image somewhere.
 110
 111 ## 16:26
 112
 113 Well, MicroEmulator makes it public and everything in it just throws an
 114 exception. Personally, I am thinking of breaking compatibility for sanity
 115 purposes.
 116
 117 ## 16:31
 118
 119 Yes, definitely for sanity I will break compatibility. J2ME is a dead
 120 platform and Java ME is not really going anywhere at all. I suppose
 121 99.9% compatibility will be good enough for the most part. As long as
 122 existing code can still run.
 123
 124 ## 17:59
 125
 126 So, you cannot `invokevirtual` an interface. So I can just take the next
 127 alternative, and make all methods in the class abstract instead and make
 128 it public.
 129
 130 ## 18:58
 131
 132 It is unspecified whether `EGLContext.getEGL()` returns the same instance
 133 or a new instance every time.
 134
 135 ## 18:59
 136
 137 However, `eglGetDisplay` works on actual displays. However that can return
 138 the same instance every time essentially. However perhaps that should
 139 actually be unique. A configuration is chosen and a context is created. A
 140 surface is then created from the context. So yeah, the display can return
 141 the same one, but contexts are always different. Basically I can wrap
 142 anything that is done on displays. Well, actually not because displays
 143 can have their own pixel buffers and textures associated with them.
 144
 145 ## 19:04
 146
 147 So EGL is shared, but displays and everything else are unique. Because if
 148 you wanted to get the pre-existing display you can get the current display,
 149 context, and surface.
 150
 151 ## 22:09
 152
 153 I had an idea, I can have annotations and annotate compatbility breakages.
 154 This way it is documented in the source code and I can also potentially
 155 extract that information and automatically use it rather than keeping a
 156 single document.
 157
 158 ## 22:39
 159
 160 Thinking that I may need a simplification of the BasicUI along with the LUI
 161 and LCDUI Display classes, providers, and instances.
 162
 163 ## 22:45
 164
 165 Yes, I can essentially just remove the service lookup and just have basically
 166 a default service if a system property is not specified with a given class
 167 value. I also may need to infact fold the image reading code into the LCDUI
 168 image code, perhaps.
 169
 170 ## 22:49
 171
 172 However, optional projects may be included and others may be missing. So a
 173 default specified handler for when nothing is around might not even work. I
 174 suppose then it can use `ServiceLoader` to make sure it exists. Then I can
 175 also simplify the display system too. Right now I can have displays across
 176 multiple drivers so to speak. Although this can work, it will complicate
 177 things a bit for the most part. But I will need drivers for the following:
 178
 179  * LUI -- Will use terminal code.
 180  * Terminal -- Will assume vt100 and use System.out in the default case.
 181  * LCDUI -- Will use framebuffer by default.
 182  * Framebuffer -- No implementation, but implemented by something.
 183
 184 I see the only implementation of LUI using just the terminal code since the
 185 latter would be much easier to work with anyway. The LCDUI code would get a
 186 bit complicated since it may actually be able to use native widgets and such.