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.