assets/developer-notes/stephanie-gawroriski/2017/02/12.mkd

   1 # 2017/02/12
   2
   3 ## 06:57
   4
   5 So what I can do now is event handling, such as which keys and whether things
   6 were tapped or similar.
   7
   8 ## 07:19
   9
  10 What I need is class specific instances.
  11
  12 ## 07:21
  13
  14 I mean of displayables, but that might not really be needed as much since it
  15 would complicate a few things but make some things a bit easier.
  16
  17 ## 07:34
  18
  19 LCDUI only supports a single mouse button so at least when it comes to the
  20 game I will need to handle these situations to perform right click actions,
  21 along with dragging the selection box if possible. The game should be playable
  22 regardless of how capable ones device is.
  23
  24 ## 07:47
  25
  26 I suppose the next thing I need before I can implement some part of a game
  27 would be key handling. Once I have that I can use stuff such as the keyboard
  28 to move the viewport around and such. One thing I also need to consider is
  29 that a device could be pointer only.
  30
  31 ## 07:51
  32
  33 For such devices, the best thing to do in this case would be to have
  34 indicators for actions and such on the screen to allow the viewport to shift
  35 along with telling units to do things. The game should be fully playable with
  36 a mouse. However, with command buttons and such, when a unit is selected those
  37 can be used to provide a menu for those actions instead. So for example when a
  38 worker who can build stuff is selected, the command "Build" would become
  39 available. Then that command could be executed to place a building or similar.
  40 I would need one active command to always be the game's menu, while another
  41 command would be for the selected unit for example.
  42
  43 ## 07:56
  44
  45 So I will be needing commands in the future, but for the most part only after
  46 units are implemented.
  47
  48 ## 09:22
  49
  50 Must make pointer and key events their own interfaces because `CustomItem`
  51 also uses them.
  52
  53 ## 10:54
  54
  55 AWT does not have a means of detecting repeated keys and is pretty different
  56 across platforms when it comes to keys. As such, I will need to wrap this
  57 into a more sane system that should work hopefully.
  58
  59 ## 11:16
  60
  61 At least on Linux, repeated keys are just constant presses. I can probably
  62 ignore typed keys.
  63
  64 ## 11:57
  65
  66 Looks like I will need non-standard keycodes. For example there are codes for
  67 many keys just do not have codes at all.
  68
  69 ## 12:02
  70
  71 I will just pick a number and rely on name translation for them.
  72
  73 ## 12:20
  74
  75 I should not grab tab though, because I will want to traverse things such as
  76 the command buttons for Swing or perhaps other interfaces. So what will be
  77 next is the translation of keys to key names via the keycode, this way I can
  78 handle unknown keys and such.
  79
  80 ## 12:57
  81
  82 I wonder if it would be faster for me to draw to an image first rather than
  83 using AWT directly. Basically, instead of an `AWTGraphicsAdapter` it will
  84 just be a new class. Also considering that, I can move the code in image out
  85 into a generic class that can just draw to some kind of array. Then I can
  86 adapt that code for graphical displays without involving images. So for
  87 example there would be a graphics drawer that draws directly to a framebuffer
  88 to show what is on the screen.
  89
  90 ## 13:21
  91
  92 Now I am going to see, if drawing to a `BufferedImage`'s `int[]` array is
  93 faster than using `AWTGraphicsAdapter`. If it is, then it will be a keeper.
  94
  95 ## 13:33
  96
  97 Wow, drawing into the buffer, I get very fast speeds when rendering. So this
  98 is definitely much better.
  99
 100 ## 14:11
 101
 102 So now that I have fast graphics, keyboard input, and pointer input I should
 103 be able to start working on getting the game up and running. Alternative I can
 104 poke the JIT for a bit perhaps, or eat some food.
 105
 106 ## 14:43
 107
 108 Not too sure what to do for the JIT however.
 109
 110 ## 14:53
 111
 112 I should have some very old images I drew a long time ago, which can be used
 113 rather than redrawing them.
 114
 115 ## 15:48
 116
 117 I did find them. Also the RGB slice drawing must be changed into tiles. I am
 118 going to need tile drawing for the drawers that allow for sprite rotations and
 119 such. This means that I will need to draw a linear array of RGB data as a
 120 column for example.
 121
 122 ## 16:14
 123
 124 Actually I need to handle the alpha color.
 125
 126 ## 16:21
 127
 128 Now I wonder how blending on top of an image with no alpha would work. I would
 129 need it for sprites and it just does not make sense to not use alpha at all for
 130 drawing in `Graphics` to not have it. For example `SRC_OVER` is enforced for
 131 the most part and `SRC` is not permitted. So this must mean that everything is
 132 blended all the time, just that the destination never gets its alpha channel
 133 set at all.
 134
 135 ## 16:25
 136
 137 The documentation says _The opacity of the destination pixel cannot be_
 138 _reduced using this blending mode, and thus it may be used on images and_
 139 _surfaces that do not support alpha channels as their pixels are already_
 140 _fully opaque._ So this is how it works. I just need a destination alpha
 141 OR which enforces this.
 142
 143 ## 16:40
 144
 145 I wonder if there is a fast divide by 255.
 146
 147 ## 16:48
 148
 149 But thinking about it, maybe I should just divide by 255 and let the JVM
 150 handle it. I can do some multiplication magic when it comes to division so
 151 that a multiply is used instead.
 152
 153 ## 16:57
 154
 155 Does not seem that drawing some fog over pixels is that slow.
 156
 157 ## 16:58
 158
 159 However, if the fog box is large enough then it slows down much.
 160
 161 ## 17:02
 162
 163 Using dotted lines might be faster in the long run and provide the equivalent
 164 effect.
 165
 166 ## 17:07
 167
 168 And dotted lines are much faster, not as nice looking but good enough at
 169 run-time.
 170
 171 ## 18:47
 172
 173 During development, I could use a map in the corner of sorts to find my way
 174 around the game.
 175
 176 ## 19:04
 177
 178 Currently would be a gimmick, but an automap would be useful right now. I can
 179 use it to navigate my way around the level so that I know where the viewport
 180 is. I could also allow it to instantly change the viewport to a new location
 181 when it is clicked, which is much faster than holding down keys.
 182
 183 ## 19:08
 184
 185 Probably in the future, I will need a low-resolution mode for very small
 186 screens such as those that are really tiny. I can figure that out when I get
 187 to that point however.