Yes I am!
Here it is!
Ahh! It's like a flashback of Cosmosis!
I'm finding that I'm spending a lot of time on things that are not directly related to accomplishing milestones. But then the milestones are entirely centered on forwarding gameplay rather than extraneous elements which one can get lost in. The milestones then are encouraging me to "build a game" not "build an engine", and this is a good thing. I just have to pay attention to them. And by this I mean that I've not gotten navigation working -- there may be some terrible errors in my trig, I found today. Terrible errors.
(I'm regretting getting-a-D-in and dropping-out-of that trig class halfway through my junior year of high school. Long story, but I ended up in more or less community college to finish high school and spent my time hating math for the next 5 years until I took a programming class... in art school. I hated grammar for like 4 years too until I took an English class in college. The problem was attitude (and the school institutions, I'd say) -- I was so angry at school and in general throughout high school (because it and other people were awful) that I didn't really learn as much as I should have and now wish I had. But I digress.)
Let me discuss non-milestone things I've worked on.
There is now a camera class that zips the viewport around to center on wherever was right-clicked. Eventually this should focus on the Player's ship, or better yet on whatever is defined as the target entity (which will contain a Position State with coordinates).
Also, the camera is 'soft' in that it isn't directly latched to the target, rather it moves the center of the view toward the target gradually. I want to make it so that if the target starts getting away from the focus, the camera will speed up so that the target is never far from the center of the screen. For objects which are moving, the camera could focus somewhat ahead and in the direction they are traveling.
Particles and Slowness
As shown, particles do indeed fly around. It gets pretty slow when I have a few hundred particles in there, and this upsets me. Is Python doomed to do OpenGL slowly? (Probably.) Does Pyglet take care of any of these problems or am I kidding myself? (Who knows.) More on this in the last section.
There are now set rates for updating the GameState and rendering, and everything that happens should scale it's action properly by the Timer's delta. I do still need to actually add a proper sleep function in here.
The rendering gets slow when I have a few hundred particles flying around and, as I said, this is worrisome.
Maybe I'm just doing things wrong -- but then it's a bit unclear how one is supposed to use Pyglet: the documentation is slightly worse even than Pygame. And Pygame, at least, has been out for some time, and is based on SDL which has documentation itself that mostly carries over. This begs the question of investigating OpenGL documentation, and that I am doing, but damn is it ever difficult itself, and more confusing because I'm not sure exactly what and how Pyglet does things and what I could/should be handling myself. I find myself wondering how anyone could possibly learn this, and how anyone could learn it well enough to do things properly, not just at all! (Answer: Years of experience and a deep understanding of what's going on, surely. I just don't have those things.)
Maybe I'm just overwhelmed. ...and maybe I should be turning my particle graphics into Pyglet's texture class instead of drawing them straight-up from the image class, but that's just a guess because I'm not sure quite what the image class does. If it's creating textures on the fly all the time, that'd be terrible. Perhaps I need to take a look at Pyglet's code.
At least I think I've gotten these transformation things kinda figured out.
It's going to take some time to get really cookin' with OpenGL, but I'm working on it.