Haven't said much in a bit, so I thought I might clarify what's going on with me at the moment.
Firstly, schoolwork's coming up and demanding a lot from me in these next few weeks. Good news is however, once that's done I've got four weeks off in which I plan on pushing a solid release of all the other projects I've dropped (the Thunder Force Music Mod for Xeno Fighters R, and my music MIDI remasters I haven't finished, of which there are at least three).
Having said that, I have still been working a bit on GMOSSE though with little visible results. Scanlines are now switchable (both horizontal and vertical) from the Options Menu and I've worked out all of the draw-related kinks I've found as a result of implementing it, however I've noticed they are performance-intensive on my legacy PC. It also plays with some of the drawn text I use that uses c_black as well, so its not quite ready yet. I fixed the crashing bug with 64-bit Windows 7 machines (those cursed things are trouble for anything gaming) and I've also made some progress on the memory leak related stuff, and will improve the memory test object I've made as I go through the other big change explained below.
I've come to realise that the use of object controllers by themselves isn't particularly friendly to people learning how to manipulate GMOSSE. It's still a lot better than stuff like Hello Engine IV with strands going everywherewhichwaywhenmindfuckInceptionmuch, but I've come up with a brilliant idea to make it better. I don't know if it'll actually work or not but the end result will hopefully be:
- ONE persistent controller instead of 30-something
- All big "engine features" (ie TATE) changed to standalone scripts
- the controller calls all of the scripts
- a personal debug mode can be added around the scripts so that on user input one script at a time will be loaded (so code problems can be narrowed down easier) and perform a fullload memory test if desired
Now frankly I dont think that exactly ONE controller object will be able to handle absolutely everything I do especially considering the current problems I've been having with some objects doing 'too much within Step event' as it is, but I may still go ahead with this to a lesser extreme anyway so that there will be less to go around, and the 'engine' itself can be made more easy to modify or insert into another person's game engine. There's also the matter of small code conversions throughout the engine that will compensate for levels that use views to move around (a lot of my drawing events currently use hardcoded variables, they will need to be changed to ie view_xview[0]+220 for x position instead of just 220).
Also, as a side project for school I've been using a derivative of GMOSSE for making a nicely presentable dialog script of a customer to a call centre technician (I make up the lines). While doing this I made another behaviour pattern for the stars that closely simluates Gleylancer's Continue screen;

Speaking of 'continues' I've also decided I'll add it in as a function as well, with two behaviours for either within-the-game-screen style ala Raiden Fighters or restart-from-checkpoint like Gleylancer. There is currently no work-in-progress code of this besides an obj_continue that I've put into the EXPERIMENTAL folder which contained the first pass of the star behaviour code.
Also, I'll be damned if I make another release with the same old boring level. I've started work on a second boss which currently does nothing different other than use S20-TBL's Doom behaviour type, but if I come up with bright ideas to go along with that it'll make the first boss look like a ghost town. I'm crap with drawing stuff so it may very well be just a bunch of round balls again though I promise to make it look somewhat different. If I don't make a second level entirely I'll probably completely overhaul the existing one to look and run more like a bullet-hell Gleylancer stage. While I'm thinking in tangents, the Gleylancer ship's gone absolutely nowhere either, I haven't even made a replacement sprite for its currently crappy appearance and its even glitchier now than it was in MK-IV (I have one case of the ship slowing down framerate to something shocking just by being picked) but I have an idea for it, in the same style I've done Xonochrome and Arxtyan.
Finally, while mucking around with some animated pictures and stuff earlier tonight I got a brilliant idea:

I reckon it looks friggin awesome in animation.

(also, made the instance count and FPS display switchable via debug option in config, not accessible from menu)
I'll even make a display-only mode and upload a video of it in action to YouTube if anyone's that interested in it. I can also do demos of what the scanlines look like among other things, just put in the request.
Big rant finished. Expect a MK-V release in like, September, or this time next year.
