README - cepheid - An Aurora 4X clone

README (5877B)
      1 # Cepheid
      2 
      3 This is an ISC-licensed "clone" of the game Aurora 4x.
      4 
      5 A cepheid is a radially pulsating star. It also isn't the name of another game.
      6 
      7 ## Concessions
      8 
      9 Aurora and this game have both made many concessions when it comes to physics
     10 and astronomy in order to make something playable. Some of them are listed here
     11 (excluding fictional tech like jump points).
     12 
     13 Physics:
     14  - The movement of ships solely relies on their max speed: there is no
     15    acceleration, nor gravitational effect.
     16 
     17 Astronomy:
     18  - Retrograde orbits are not modelled. (Where they exist in the solar system:
     19    eg, Triton and Phoebe, they are modelled as prograde orbits).
     20  - All system bodies are assumed to be spherical.
     21  - All oribts (excluding comets) are assumed to be spherical.
     22  - Comets "orbit" in a straight line extending outward from the centre of a
     23    star.
     24 
     25    (Actually, newer versions of Aurora do model elliptical orbits, but not the
     26    official release as of writing this).
     27 
     28 See the "lore" for trans-newtonian elements on the Aurora wiki:
     29 	https://aurorawiki.pentarch.org/index.php?title=Trans_Newtonian_Elements
     30 
     31 ## Why are you making this?
     32 
     33 I've always been interested more in how video games work than actually playing
     34 them, hence I'm trying to build on from the ground up. An aurora 4x clone makes
     35 sense as it requires very minimal artistic ability, as most of the "graphics"
     36 can be done in code.
     37 
     38 ### Raylib
     39 
     40 I selected raylib as I was hoping it would be a good enough abstraction layer
     41 between X11/opengl/etc and "draw a line here". My opinion so far is that it's
     42 alright.
     43 
     44 I can definitely say it's easy to use when you're using it as intended, as
     45 raylib handles most data structures itself, and doesn't require any allocation
     46 of data. There's no raylib_ctx_init(), and passing the same struct to every
     47 single function (when functions need to be aware of some context there is
     48 usually a BeginSomething() function that will tell raylib to be aware of that
     49 until the EndSomething() later on, which is a pretty sweet way of handling
     50 things).
     51 
     52 raygui, however, is an absolute piece of shit, IMO. I find the whole
     53 "modulization" thing pretty dumb: all components of raylib have the same
     54 dependencies - you save practically nothing from splitting it up into multiple
     55 parts. The .a/.so and .h model works fine for raylib itself, so why does raygui
     56 have to be implemented in a header when it could all be present in raylib.so? As
     57 far as I can tell, the only way to style the gui (that won't cause you to rip
     58 your hair out) is to use a styling program written by the author. As of the
     59 start of this project I couldn't find the source code anywhere, and the only
     60 place that it could be run was online. I'm sure I could've asked somewhere, but
     61 at that point I couldn't be bothered trying to deal with raygui and decided to
     62 implement my own.
     63 
     64 Honestly, I'm kind of happy that I didn't go with raygui, as writing my own gui
     65 has been fun.
     66 
     67 raylib has other issues though. I said earlier that it's good if you "use it as
     68 intended". That's because there are plenty of small features that could be very
     69 handy but the author decided shouldn't exist.
     70 
     71 One example of this is support for multiple windows, this is a feature that has
     72 been created (https://github.com/raysan5/raylib/wiki/Use-multiple-windows)
     73 before. I understand why this hasn't been merged with raylib itself - it
     74 wouldn't work with the web as a target - but still, I don't care about the web,
     75 and I don't care to maintain a fork of raylib for this project, why can't it
     76 just be there for the targets that do support it? The only visible change to
     77 anyone using raylib would be to BeginDrawing(), but there could instead be a
     78 BeginDrawingWindow() function that takes a context id, and produce a warning if
     79 both BeginDrawingWindow() and BeginDrawing() are used in the same program.
     80 
     81 Another issue is the handling of keyboard input. In order to get text input, the
     82 GetCharPressed() function exists, which returns a wchar_t. Great, right? No.
     83 Because it doesn't return backspaces. Even though they are ASCII characters.
     84 Okay, so I can just use IsKeyPressed() right? Nope, because that won't deal with
     85 they key being held down. So instead I have to implement a function that counts
     86 frames and every n frames says it's pressed. So I just have to find the delay
     87 that X11 uses between emitting key presses when a keys is held and hardcode
     88 that, right? Nope. Nope. Nope. Because X11 has settings which allow you to
     89 change that, and since raylib is meant to be dealing with X11 I can't query
     90 that, so what should be a setting that applies globally to all X11 applications
     91 doesn't apply to cepheid because I can't make it.
     92 
     93 raylib also isn't very good at drawing big shapes. For example, the orbits of
     94 planets. By default raylib only draws rings with 36 segments, which really isn't
     95 enough when less than 1° is shown on screen (ie, zoomed into a planet). Cranking
     96 up this number indiscriminately isn't a very good idea either, as the
     97 performance goes bye bye. So yet again, I'm having to fight with raylib to try
     98 to get it to work somewhat well. The solution at the time of writing (701a5de)
     99 is a function that calculates the number of segments to draw based on the
    100 radius, and estimates at what degrees the ring should start and end at (see
    101 ui_draw_ring). Along with that, draw_orbit() does various checks to prevent
    102 unecessary drawing in the first place. With this I'm able to get 60fps on a
    103 "Intel i5 M 520 (4) @ 2.400GHz"'s integrated GPU displaying all the planets in
    104 the solar system, but turn it on for all the dwarf planets and asteroids...
    105 
    106 I would have hoped that raylib with deal with this for me.
    107 
    108 After seeing this blog post,
    109 https://www.bit-101.com/blog/2022/11/coding-curves-03-arcs-circles-ellipses/
    110 I'm considering writing my own function for drawing orbits, but this will depend
    111 on the performance of drawing a lot of lines.