assets/developer-notes/stephanie-gawroriski/2015/06/08.mkd

   1 # 2015/06/08
   2
   3 ***DISCLAIMER***: _These notes are from the defunct k8 project which_
   4 _precedes SquirrelJME. The notes for SquirrelJME start on 2016/02/26!_
   5 _The k8 project was effectively a Java SE 8 operating system and as such_
   6 _all of the notes are in the context of that scope. That project is no_
   7 _longer my goal as SquirrelJME is the spiritual successor to it._
   8
   9 ## 08:40
  10
  11 Up early.
  12
  13 ## 11:54
  14
  15 Looking at GCC's preprocessor, #defines do not do any processing or
  16 translating when defined, so they are straight through for the most part. This
  17 simplifies things for me greatly. The only thing I have to handle is when the
  18 defined macros are actually used.
  19
  20 ## 14:01
  21
  22 I do not believe the Java3D is rootable into a specific interfaces package
  23 similar to how java-jsr353-interfaces is. So for Java3D I should have a base
  24 class which then has plugin providers to give a 3D surface. This way for
  25 varying platforms I can have a software renderer, or use existing hardware.
  26
  27 ## 14:14
  28
  29 So basically there will be my JSR926 implementation which will use dynamic
  30 providers. There will be basic multiple interfaces for example a software
  31 renderer, one which uses Vulkan, and another for say the Nintendo 64's
  32 graphical hardware. If there is modern shader hardware such as the Radeon 9800
  33 then it should use a common interface similar to Gallium and the Java3D code I
  34 have uses that. For older fixed function hardware which is not as capable as
  35 newer hardware, there would be specific things for it. I would say that Java3D
  36 would be the core 3D graphics interface available.
  37
  38 ## 18:23
  39
  40 Using lambdas will greatly simplify how my resequencing is done.
  41