G.M.O.S.S.E - Now on Github! (29/3/24)

[Rozyrg]

Yeah, I really need to get off my ass and put in a decent pause system now.
(Speaking of laziness, I *finally* got around to doing some optimizations for XYX today, cutting the step events out of enemy/player bullets and such, which I got a nice speed boost out of.)

As for the sound problem, I can't remember when I started doing this; but at some point I just made it have to stop a sound currently playing for it to be played again. With a lot of the same stuff playing over and over (explosions, enemy shots, etc.), the level of audio chaos going on grows very quickly. I don't know if it's related to the particular problem you're having, though.

[BPzeBanshee]

Yeah, I really need to get off my ass and put in a decent pause system now.
(Speaking of laziness, I *finally* got around to doing some optimizations for XYX today, cutting the step events out of enemy/player bullets and such, which I got a nice speed boost out of.)

As for the sound problem, I can't remember when I started doing this; but at some point I just made it have to stop a sound currently playing for it to be played again. With a lot of the same stuff playing over and over (explosions, enemy shots, etc.), the level of audio chaos going on grows very quickly. I don't know if it's related to the particular problem you're having, though.

Well currently I'm using GMFModSimple and using sound effects played multiple times for explosions, then setting max volumes for sounds based on their groups or sound instances specifically so that combined they dont go over a certain volume. There's probably more room for improvement on my end but really if a person does things the normal sane way with GMOSSE as a template (one explosion sound effect for an explosion, not 5 or 9000 ) they wont have this issue.
The real killer for me at the moment is this damn rotation/pause problem. I dont think it's fixable.

[BPzeBanshee]

G.M.O.S.S.E MK-III is out!



Get it here!

Changelog from off the top of my head:
- INI file support. The obj_optionsmenu controller handles changing settings ingame while obj_maincontroller handles loading and making use of the variables from config.ini
- Pause menu support. This was a bitch to do and should be implemented with caution. TATE on any rotation will work with the background_create_from_screen trick now as well.
- Ship Selection menu, with scrolling text to boot.
- Speaking of ships, you can now play as a Space Invader!

Bugfixes:
- Scoring fix, so now its not relevant to how many shots you can pump into an enemy unlike MK-II
- What I mentioned before regarding the background_create_from_screen in the pause menu. Spent today working on that and figured out the kinks.
- Rearrangement of music groups and stuff so that loading is done when necessary (pausing, going back to ship select and picking a new ship wont trigger another set of loading files)
- added bomb count, not really a fix since I just couldnt be bothered before
- Changed afterimage handling from Step event back to SHIFT key - with the pause menu implemented it lead to being able to spit afterimages without slowing down
- Other fixes Ive fixed ages ago and since forgotten about

To do:
- convert enemy attack patterns to timelines for ease of edit, loopability and consistency
- add some kind of input file support using external timelines, still figuring out if its possible
- more ships (I have ideas for this....)
- more levels, one of which will use nothing but Pinwheel for bullet patterns (have ideas for this too....)
- more options in the INI config
- intro screen?
- level transition/handling via controller object
- convert all position handlings to be either relevant to the object or view_yview et al. 0,0 wont work on stages that are larger than view size and use that for scrolling.
- add delay in pause menu so as to not crash the game by pressing ENTER and Z rapidly
- redo comments for everything, currently you're going to have to be quite literate in GM to figure out GMOSSE but its still not as hard to understand as Hello Engine 4

Report bugs/suggestions/feedback!

EDIT: Ive suddenly noticed that setting Interpolation between colours in the Global Game Settings does wonders for the appearance of this in TATE. Makes the afterimages look a little bigger than what they already are in some cases though.
EDIT2: I found the GML function for interpolation between colours and implemented it for when you TATE 270 and 90 degrees. It makes the text a lot easier to read and the ships themselves dont look nearly as distorted. While it's not perfect I think I can safely say that short of doing surfaces which are eww to me this is the best possible method of TATE you're going to get in Game Maker 8. Hopefully 9 will fix the weird crap I've had to figure out workarounds for and give us pixel-perfect view rotation.

[BPzeBanshee]

Bump

I've made some more progress on GMOSSE. No release yet, and currently I haven't made any new levels, but when MK-IV gets released you can expect these changes:

I've recoded the boss. I decided against using timelines and concluded that the idea of using timelines for it was some kind of unconscious excuse for stupid willy-nilly programming.
Now everything works based on a global attack_pattern variable and is all more clearly interlinked. There is documentation for every single line of code within the boss objects (obj_boss, obj_orb & obj_orb2) and besides a few minor timing-related variables it behaves exactly like how the old code did and also as properly intended (the looping of the first three phases was bugged in the old code).

I've also implemented a new ship and finalising the touches for it as I get time for GMOSSE day by day. It's the Swordfish, a ship sprited and designed by Gun6 and ZeroFollower0 of the Mushroom Kingdom Fusion forums for an extra ship to be implemented in Xeno Fighters R. I don't know if it will ever realise it's original reason for creation but I've brought it to life in GMOSSE.


It behaves more like traditional shmup ships in the way that it actually turns left and right when moving in that direction as was sprited. The code for that is in the ship's own Step event, and can be duplicated for any new ship that has a similar sprite design. Currently it uses sound effects from Revenge of Shinobi but if I really get annoyed by that I'll whip up some more appropriate sound effects for it later on in the distant future (not like the developers of that game will complain about me using sound effects from a near-on 20 year old game anyway). It also slows down to 1 pixel per step speed when FIRIN ITS LAZOR and is currently the only ship in GMOSSE with a bomb that actually deals damage.

Not that it reflects in actual code or sprites withing GMOSSE itself yet, but I've planned to make two more ships in the style of popular games. One will be the ship from Gleylancer (since this entire engine is graphically inspired by it albeit vertical) which I need to figure out how I'm going to draw vertical sprites for, and the other ship I've already started working on its weapon for in a random GMK file I made to simulate this LOCK SHOT I keep hearing about.

Just today I've also coded in a transition controller object that does the same thing as GM's 'fade to black' default room-to-room transition, but with way better peformance. And it's tweakable and moddable, so it can fade to any colour (it does it off of a 2x2 coloured pixel sprite that is stretched across the screen) or to an actual picture if you so wish. If anyone requests it I can try and make different default behaviours for it so it could either fade to black or do something like how Xeno Fighters R does. I suspect I might have problems with it like when I did the pause menu regarding TATE so I'll playtest that out when I get the chance.

Finally, I've added an option in the options menu to turn off the hitbox. It simply switches a global variable like how I did the fullscreen stuff but the main actual affecting code of hitbox visibility is within the Create and one of the Step events of the hitbox object itself. If anyone has some handy suggestions for any other options to add let me know.

Expect this and probably more in MK-IV of GMOSSE. If you have any tips suggestions or something decent to add feel free to post.

[Observer]

Lock-on reticles ala RayForce, coupled with guided laser/missiles. If you add a ship that can do that (and allows use of custom lock-on reticles) I'm set to make a shooter in the long term.

Also, since this is Gamemaker, how does it fare with huge bullet counts?

[BPzeBanshee]

Lock-on reticles ala RayForce, coupled with guided laser/missiles. If you add a ship that can do that (and allows use of custom lock-on reticles) I'm set to make a shooter in the long term.

Also, since this is Gamemaker, how does it fare with huge bullet counts?

Well I did mention I'd like to make a Ketsui ship and some of the theory behind that should be able to be used for a RayForce ship. There's a couple of things I'd like to do regarding levels and the other ships I'd like to get out of the way that I've been planning first but once that's done I can certainly have a go. I wouldn't know how to do the serpent-like lasers though, somehow I suspect it's going to be a very crude initial implementation when I do do it.
As for bullet count, GMOSSE runs at full speed with the boss of the test stage racking up the instance count to something like 200 objects+ on my legacy machine. This may change in the future and will vary depending on what the bullets are doing I suspect. The only drops in framerate I get is with loading something externally like just after the voice at the ship select screen says "Stick to it, and believe in your power!".

[S20-TBL]

As long as the engine isn't dealing with large objects, it shouldn't be a problem. I once had my game tallying up around the same bullet count as yours and there was hardly any slowdown, except on a really old Pentium IV (and even that didn't have too many problems). I recently discovered, though, that objects with large sprites not only have to have the sprites externalized, but deleted from memory as soon as the object is destroyed. If you don't do this the game will rack up insane RAM usage over time and slow down horribly.

This happened on a Dual Core netbook with a native Intel GPU--thankfully the slowdown wasn't as bad as I initially thought it would be, but it was still terrible. The CleanMem DLL helps, but it can only be restricted to certain intervals, e.g. room start and end, as far as the warnings of the people on the GMC forums go.

[BPzeBanshee]

This too is a point of concern but also one I'm familiar with. I've been semi-careful about design choices in GMOSSE because of my legacy machine's requirements. In fact, my previous unreleased (to Shmups forum anyway) game project was made with such little care of performance (with huge sprites and images of up to the game's resolution of 800x600) that the last time I ran it on my legacy machine it:
- came up with 0x000000 errors when playing, and then;
- blew up one of my RAM cards
- gave me the Blue Screen of Death and;
- broke Windows XP, requiring I reinstall everything, remove my GRUB bootloader which has made my Lubuntu harddisk useless till I reinstall that OS and have a pathetic 256 MB of RAM as a result
- and since some parts are sensitive to touch it was a bitch to even get the machine to show anything on the screen once I moved it.

Bottom line: GMOSSE runs comfortably for now, and I'll be damned if it doesn't stay that way.
That means particle effects and surfaces are a no-go zone for GMOSSE.
I noticed that in the initial stages of developing the test stage for GMOSSE making the background scroll fast enough would lag the framerate too. Newer stages may have to remain with simple backgrounds if this becomes the case with future releases.

[S20-TBL]

Yeah, particles slow a lot of things down. Though I don't really reject them altogether, there's a certain point at which you just have to cease using them any more than you have to due to memory restraints. And they tend to be visually distracting sometimes.

As for surfaces: the main reason why I don't want to use them is because they (for some reason) disable mouse input unless something else is done. As far as creating seamless tiling and scaling goes they're pretty OK, but I found I can also do that by carefully adjusting the game's window port size. The real kicker with surfaces is that not every computer or GPU supports them.

[BPzeBanshee]

Yeah, there's more than one way to skin a cat with Game Maker and I simply won't use ways that are glitchy or otherwise hog performance. The fading transition object I made is a fine testament to this since the fade effects used by Game Maker's D&D transition types run horribly on my legacy machine and my method is lagless AND moddable.
I see no need for scaling either, as I think the 'blurry' fullscreen mode that some people complain about actually makes the game look a bit better on my eyes. I don't like seeing Xeno Fighters R in all it's pixelness on Intel GMA hardware for example, but I blame that on Intel GMA.
Any real cool effects that can be done with particles can also be rendered to a sprite anyway - I know one person who made an explosion creator that uses truckloads of particles and objects (in GM6 of all editions) to come up with nice explosion sprites for an RTS game mod. If he can do that I can do just that when I want cool trippin' fireworks.

For the record, my legacy machine settings (from the top of my head) are as follows:
Intel Pentium III Coppermine, 1 Ghz
256 MB RAM (1 chip, had 512 then chip 2 blew up)
nVIDIA RIVA TNT2 M64 AGP graphics card, 32 MB video memory

Most games including Xeno Fighters R and MAME games from 1997 onwards have performance issues on this machine largely due to the graphics card being renowned for underperforming, but also due to RAM constraints and CPU speed. If I can make GMOSSE remain playable on this machine the entire time it's in development then in theory it should run on most if not all machines as well, which would make it a perfect base for making a game using it as a base.

[nimitz]

Thanks to Udder for pointing me out to this thread, This is a really neat project. Thanks BPzeBanshee for taking the time.


One question tough, Is it free to use in any way (as in no GPL crap)

[BPzeBanshee]

Thanks to Udder for pointing me out to this thread, This is a really neat project. Thanks BPzeBanshee for taking the time.


One question tough, Is it free to use in any way (as in no GPL crap)

Lol GPL. I've heard that license was quite 'draconian' anyway.

I'm calling my license the 'Banshee License' - use GMOSSE as a template and then let me know via some credits somewhere (credits for the creation of GMOSSE itself can be seen by pressing F1 or 'View Readme' on the main menu), and if you feel like it let me know so I can actually playtest your game!

Thanks for your support!

[S20-TBL]

I'm calling my license the 'Banshee License' - use GMOSSE as a template and then let me know via some credits somewhere (credits for the creation of GMOSSE itself can be seen by pressing F1 or 'View Readme' on the main menu)

"If you don't credit me, Miles Edgeworth will crawl out of your monitor and prosecute you to the full extent of the jam."

I already credited you in mine BTW; I used the spread shot snippet Alluro gave you.

[agustusx]

I just started tinkering around with GM7 again and when I upgrade sometime in the next month or so I'll have to give this a shot. Seems pretty neat.

[BPzeBanshee]

I'm calling my license the 'Banshee License' - use GMOSSE as a template and then let me know via some credits somewhere (credits for the creation of GMOSSE itself can be seen by pressing F1 or 'View Readme' on the main menu)

"If you don't credit me, Miles Edgeworth will crawl out of your monitor and prosecute you to the full extent of the jam."

I already credited you in mine BTW; I used the spread shot snippet Alluro gave you.

LOL
I like that idea, expect licence info in GMOSSE MK-IV along those lines.
Actually, that gives me an idea...

@augustusx:
I wouldve made a GM7 one but I didn't think it was worthwhile due to GM7's memory leak issues etc anyway. I do eventually plan on making a 'GMOSSE Lite' but that task will only begin once I'm satisfied this engine template is complete. Looking forward to hearing your feedback.

[Rozyrg]

That's pretty impressive you got that kind of performance testing on a Pentium III. .. and I thought my netbook was good for low-spec testing. Seeing my games run on that thing would probably bring me to tears.

I'm all for simple backgrounds too; but you can get away with some fairly complex looking stuff without too much of a hit by having one object controlling the scrolling parts (mine just stays put and draws the bg graphic multiple times based on several 'moving' variables) and empty objects for detailed sections whose speed/position can be maintained elsewhere.

The problem I've run into is when you have lots of smaller background elements that need to move with the screen (ie. explosion craters.) I just can't find a way to keep them where they should be without using step events... which, combined with a screen full of enemies, gets expensive pretty quick.

[BPzeBanshee]

Implement FPS displays in your games and I'll be more than happy to try them out. I did try ZPF some time ago and couldn't be certain if it wa running at full speed or not since I had nothing to check at the time as a reference.

Thanks for the view on the backgrounds too - when I make a land-based level in the future I'll see what method I come up with to keep things smooth. That idea will give me something to try out first.

[S20-TBL]

Reagarding backgrounds, it kind of depends on what type of level design you're going to do. I'm approaching design using the classical hori methods from R-Type and Gradius, so what I do is design an entire level first on paper, block out the walls in the editor using solid objects, create a special tileset for the walls and other unique objects, externalize the backgrounds and use a specialized camera object that changes scrolling direction and speed using pre-placed objects and special flags. The player ship is them programmed to follow the camera object's movement automatically, retaining a constant "scrolling" motion even when stationary.

With CAVE-styled horis and most verts, unless it's something of an Image Fight-type scenario with walls and everything, I think the best method for detailed levels would technically be a variation of XFR's. Tile the detailed sections, use tiled backgrounds, then scroll everything in the desired direction. I think XFR even deletes entire layers of tiles during boss fights, such as during Stages 1, 2 and EX-6, exposing a repeating background layer. I don't know what happens during the end of 3-B Vietnam though.

[BPzeBanshee]

Nice idea, but the problem is I suspect that this handling of backgrounds is the main reason why most levels in XFR cause lag on my machine, and I won't implement anything too complex that's beyond my understanding to make anything look nicer. There's also the manner of draw functions I've coded so far being hard variables instead of view_xview+number stuff due to my stupidity so when I get to making such a level I'll be redesigning a few things again.
Having said that I'm not too familiar with tiles etc so I may use that idea too in future. Before I was just thinking "design the lot in pieces and then put it all on one background so GM's drawing less", but that could have it's own issues too. An idea I had for GMOSSE way later down the track was for the game to start in one of two environments - one being vertically-scrolling as it is now and one being horizontally scrolling with a different set of ships and hopefully not-so-different controller objects to give an idea of how to code a hori shooter in GM as well, and then build other shooter types into the mix if the need arose.
As I said, I'll investigate this further down the track. I really don't want to implement something that will lag the legacy machine though, high-performance and simple is one of my main goals.

[S20-TBL]

It seems that the more backgrounds you load at once, the higher the memory usage will become whether or not you've externalized them. I have a level sized around 4000x1600px that only began with around 16MB RAM usage, despite there being around 9 layers of tiles in it compassing 2 whole tilesets. I'm guessing the reason why is because I loaded only 2 backgrounds in the level. Comparatively, I have a level that is around 380x4000px, but with only 4 tile layers, only 1 tileset used and all 8 backgrounds occupied. The startup ram usage was around 36-38MB, though it remained constant throughout. I have yet to investigate this further myself.

[BPzeBanshee]

Based on what you said, more backgrounds = more memory usage. In early builds of GMOSSE I found the game to lag when I set the background to scroll at higher than a certain speed, though that may have been a combined result of a few variables I was mucking with at the time. Currently I still have sprites to externalise as well, and I really don't want to use more than 1 background as it is.

I think you and I both have some investigating to do, but I won't be able to touch GMOSSE for a little while yet. Homework, and Deathsmiles. More so Homework.

Eventually I'm just going to compile a whole list of various crap I've decided I want to eventually have in GMOSSE, and it's going to have some insane ideas probably ripped off from various games.

[nimitz]

Quick question: Is it normal that the whole screen becomes blurry when in tate and the text becomes pretty much unreadable. Must be the stretching algo that is used...

[BPzeBanshee]

Quick question: Is it normal that the whole screen becomes blurry when in tate and the text becomes pretty much unreadable. Must be the stretching algo that is used...

This is part of the problem I've been having with TATE for a while now. In the current development MK-IV of GMOSSE I enable Interpolation Between Pixels when rotated at 90 or 270 degrees which helps with readability, but can't figure out how to improve the code for those angles.

The actual code itself is rather hacky in the sense that it uses manipulation of some variables to compensate for the glitched scaling effect that happens when using view_angle[0] = (number) at those angles. It's not "blurry" on my computer but distorted in such a way that the text is difficult to read and the graphics look stretched in some manner. Interpolation Between Pixels sorta makes things nicer to look at with those angles but to my knowledge it's as good as it's gonna get in Game Maker. See the 'User Defined' events for obj_maincontrol and the Room Creation code for each room to see the code. Also if you're going to seriously change anything with regards to that you may break the Pause Menu graphically when rotated, since pausing uses deactivation of instances after making use of 'background_create_from_screen' and drawing according to angle and altered placement variables.

[S20-TBL]

BPzeBanshee: I've fiddled around with SuperSound for a bit, and I think I may be able to help you with creating scripts for near-perfectly looping music. Unlike the FMOD plugin SuperSound actually requires the coder to do a bit of hard (and dare I say unintuitive) math for manipulating sound file positions; FMOD simply uses percentages.

The DLL also provides its own volume integer for any files loaded through it, so I believe it will be easy to add separate BGM and SFX volume manipulation in the Options using SuperSound (SFX volume is easy to tweak in GM alone). I'll test it first on my end though, don't want to promise anything yet at this point.

[BPzeBanshee]

BPzeBanshee: I've fiddled around with SuperSound for a bit, and I think I may be able to help you with creating scripts for near-perfectly looping music. Unlike the FMOD plugin SuperSound actually requires the coder to do a bit of hard (and dare I say unintuitive) math for manipulating sound file positions; FMOD simply uses percentages.

The DLL also provides its own volume integer for any files loaded through it, so I believe it will be easy to add separate BGM and SFX volume manipulation in the Options using SuperSound (SFX volume is easy to tweak in GM alone). I'll test it first on my end though, don't want to promise anything yet at this point.

Sounds good! All volumes are handled within GML using GMFMODSimple scripts currently along with the various filters used, and I still have no idea how to get percentages from music files for GMFMODSimple so a method where I can input the specific time point for a music file is actually easier for me. Probably speaking too early, though any option to get off GMFMODSimple's back would be quite the neat addition providing the replacement works just as well to GMOSSE.

Also, a shout to cool sprite peoples out there watching this thread: If anyone's interested in helping me out (please?) I need some help doing spriting for the new ships I plan on adding to GMOSSE. I have no idea as to how to go about redrawing the Gleylancer ship and the Tiger Schwert looks difficult to implement with the top rudder being animated while standing still and yet moving along with the ship's direction too. The RayForce ship looks out of my league graphic-wise at this point.

[S20-TBL]

Sounds good! All volumes are handled within GML using GMFMODSimple scripts currently along with the various filters used, and I still have no idea how to get percentages from music files for GMFMODSimple so a method where I can input the specific time point for a music file is actually easier for me. Probably speaking too early, though any option to get off GMFMODSimple's back would be quite the neat addition providing the replacement works just as well to GMOSSE.

I finally fixed it and got both the SFX and BGM volume adjustments to work properly. There WAS a bit of a problem, though, and that's the fact that both Game Maker's internal sound algorithms and SuperSound seem to handle volume levels exponentially.

To sum it up, anytime your volume levels go below 50%, sounds become barely audible. At all. You might as well mute everything. Going from 50% to 75% only marks a slight increase, and it's the levels from 75% to 100% that dramatically pump up the volume. I had to come up with as simple a math solution as possible that would keep sounds audible at all times except when the volume levels hit zero. I don't know if FMOD does this, but given that SS is free for commercial use and won't bog the user down with monetary demands for using MP3s if he decides to go that route, I think it will have to do for now.

And OGG is wicked awesome. I'm definitely not complaining about that tidbit.

[BPzeBanshee]

Sounds good! All volumes are handled within GML using GMFMODSimple scripts currently along with the various filters used, and I still have no idea how to get percentages from music files for GMFMODSimple so a method where I can input the specific time point for a music file is actually easier for me. Probably speaking too early, though any option to get off GMFMODSimple's back would be quite the neat addition providing the replacement works just as well to GMOSSE.

I finally fixed it and got both the SFX and BGM volume adjustments to work properly. There WAS a bit of a problem, though, and that's the fact that both Game Maker's internal sound algorithms and SuperSound seem to handle volume levels exponentially.

To sum it up, anytime your volume levels go below 50%, sounds become barely audible. At all. You might as well mute everything. Going from 50% to 75% only marks a slight increase, and it's the levels from 75% to 100% that dramatically pump up the volume. I had to come up with as simple a math solution as possible that would keep sounds audible at all times except when the volume levels hit zero. I don't know if FMOD does this, but given that SS is free for commercial use and won't bog the user down with monetary demands for using MP3s if he decides to go that route, I think it will have to do for now.

And OGG is wicked awesome. I'm definitely not complaining about that tidbit.

Strange volume issue indeed. I hope it's not too much fidgeting.

Dunno what the big deal is with OGG to be honest, I've never noticed any difference in file size and the only thing that's happened as a result of Alluro changing all the music in XF-R to OGGs is a reduction in quality that made me think I had another pair of broken earphones when I first tested v0.10.

[S20-TBL]

OGG files handle data compression a bit differently from MP3s. I've been playing GuwangeDash for a bit and noticed the music quality was actually quite decent. I checked its audio files, which were comprised of 48kbit, 44KHz OGGs. Then I decided to experiment with one of my own tracks: I took one of my 1.1MB 128kbit, 44KHz OGG files and played it to check the quality, then created a 64kbit, 44KHz version from the same raw file I made the original from. The differences ended up being ridiculously small and it shaved off half of the filesize to boot (1.1MB to 704kb).

Thing is, though, if your OGG file was converted from an MP3, the sound quality lowers since OGG's data compression takes away additional bytes that the MP3 compression didn't affect. Maybe that's what happened to the XFR tracks?

Anyway, there's one last bit I need to fix with the music file handling. I'm experimenting with a bunch of global variables now, and while it's remotely successful, I still have to add some more code and run some more scenario testing for dealing with changing music and turning sounds on/off.

[BPzeBanshee]

Interesting results, I suppose its just how I go about doing the conversions that affects stuff on my end. I must admit I was kinda harsh on the OGGs for XF-R, from what I've seen in those files Alluro has done additional quality-lowering (64 kbps from the 96 kbps for Ship Select menu makes quite the difference) as well as loop removing et al to improve on file size which I think is probably for the better.
I see no reason in this day and age to make those kind of compensations, in fact the only reason I've used OGGs in GMOSSE is to avoid the copyright crap behind the MP3 container format for GMOSSE as a base (got no problems with deriative games using MP3s of their own), and due to original file format of the audio currently in GMOSSE being raw WAV files I recorded directly from Kega Fusion.

Here's hoping you succeed with this new sound engine of yours. If its easy enough for me to use I'll probably be inadvertently doing a stress test on it by putting it in GMOSSE in place of the GMFMODSimple coding.

[BPzeBanshee]

I uploaded a video of what I've managed to do so far for GMOSSE MK-IV here: http://www.youtube.com/watch?v=pxINb5ry8Bs

The intro is to be considered WIP, I haven't really timed everything right for it just yet. Still want to add a fancy GMOSSE logo and other pictures to it too.
Nimitz sent an edited version of GMOSSE to me earlier in the week with joystick support (that for some reason doesnt work) along with internal highscore handling and conversion of key-based events to ids within Step events that were slightly broken with holding SHIFT, but I haven't implemented any of that just yet. Hopefully once I get this other essay of mine out of the way I can actually fix up and implement the cool stuff into the current build of GMOSSE.

But yeah, boss behaves exactly like it used to but is way better for looking at code-wise, and the transition object is complete. This video was recorded from me playing it on the Mac, current speeds at GMOSSE are mostly fullspeed except for load delays at the beginning of starting the game and pressing Z at the main menu. Haven't worked on the R-Gray yet (I think that's what the RayForce ship was called) but it is planned once I perfect the others.