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

[BPzeBanshee]

Hmm, I tried what you suggested. Using the first method still seems to get overwritten by the object's Create event though, so for my object obj_3denemy1 when it changes to obj_3denemy1_alt and "jumps" then lands and changes back to obj_3denemy1 it still ends up having its full HP.

As for your second suggestion I'll try that later, but I'd rather not use it if it causes skipping since I intend on having quite a few objects doing 3D handling and such.

EDIT: Works with one of the things so obviously whatever I was doing before was something stupid on my end. I'll update again when I fix it and possibly the lot.
EDIT2: Yep, me doing shoddy code. Clearly my code within the 3D objects aren't as tidy as I'd like them to be so I'll do a rerun of all of the code and clean up where required. I'm also making some enemies that consist of multiple objects in an attempt to provide some intimidating enemies to add variety from the smaller kinds. The main platform-like one I have now has four cannons on it that will aim at the player and shoot one kind of bullet directly, then spin around spitting a different bullet, and when either the two top cannons or the bottom two are blown off the main platform uses an altered version of S20-TBL's spiral script (its the same but I removed the need for the alarm function).

[BPzeBanshee]

Good news - I fixed the HP problems. Turned out that S20's method of using health worked but then seemed to result in confused variables between objects of the same type, so I used what I came up with for my turrets and assigned a parent variable and stuff. I'm not good at explaining intricate things in text, you'll see it in MK-V with basically all of the 3D enemies (specifically two) that constantly switch back between eachother. There's another 3D enemy but they're kamikaze popcorns anyway and they don't switch back to their 3D-altering counterpart once they've spawned.

Furthermore, most of the new stage is finished. However now GMOSSE no longer maintains a proper 60 FPS running it. I suspect this is a combination of various new things I've implemented, hopefully clipping down on the music (the first stage theme can easily be made to loop like the ship selection theme but I didnt bother to think of doing that so load times are awful) and possibly some altering of visual stuff here and there may get things under control, but I'm worried that I may not be able to rein it in. Currently it behaves much like XYX does on my legacy PC - stutters a bit when loading enemies for the first time, and then runs mostly smoothly afterwards. And on my Uni test machine which is a Pentium 4 with more RAM and an integrated graphics card the music actually stutters between rooms. I wonder if I stopped using the CleanMem.dll maybe it might actually do something.

Another idea might be to externalise enemy graphics too but I'm not sure if that'll do any good. GMOSSE's GMK size is at it's highest yet at 1,067 KB so chances are its own internal memory footprint might have something to do with it.

Also, since I've come to realise that with an actual stage done most of the player ships are unbalanced I've been tweaking them in parts, current changes off the top of my head are as follows:
- Swordfish can now focus its missile shot to ensure all missiles hit target
- Invader's firerate is now object-relative, so point-blanking is efficient and viable for it now. Dropped its damage somewhat to compensate.
- Arxtyan's wide shot is altered and is now actually useful and somewhat powerful too. Damage for it and its lock-shot also altered.
- Xonochrome has remained the same for a while now but since I changed the missiles I reduced their damage as well. Main shot remains the same.
These figures are still subject to change, and I haven't started on the replacement Gleylancer ship either.

Finally, I added an obj_externalcontrol that handles loading of sprites and backgrounds from external sources. Kaiser was looking at the current source for GMOSSE and couldn't figure out where the code for the backgrounds were, which was because I stupidly put them in the intro controller when they should be in a more obvious area. I also fixed all of the effects and stuff going weird when you select Return To Ship Select from the Pause menu, and added the transitioner effect to it as well.

Bottom line, I expect to be able to release MK-V by the end of this month providing schoolwork doesn't get in the way too much. I want three things sorted by then:
- the Gleylancer ship
- the new stage
- the performance issues
Once that's done I'll be happy and everyone else will be too since it's a significant jump from MK-IV in regards to general stability. I'll also add my "Prime Directives" for GMOSSE in the intro somewhere which should give a clear and consise idea as to exactly what the hell GMOSSE is, and what to follow at all times in regards to adding stuff to it.

EDIT: Shortened some of the music, particularly the intro which I edited to go for only half as long while still ending like it should, the stage 1 music is looped and the boss theme is looped with custom loop points (thanks to Capn' Coconuts for the looppoint how-to for Audacity by the way as well). Quality hasn't been affected. This should improve load times slightly. Also finished fixing up that enemy I wanted to recode, haven't really tested on the legacy PC to see the differences yet but chances are there should be improvements. At the very least the enemies make better use of the 3D perspective instead of fancy colour blending and teleporting.

[BPzeBanshee]

Framerate seems more under control now for some reason, probably a combination of reducing loading times by looping music instead of having huge files, externalising Swordfish's laser sprites and rewriting one of the 3D enemies that wasn't really working right to begin with.

One other huge cock-up I realised I did though - writing the spawnpoints and variable controls for the enemies based on view_yview and view_xview by themselves were a REALLY BAD IDEA. Reason being, the game spawns everything off by 40 pixels when the screen's rotated.

So I'm adding some variables to the TATE code and should have new variables global.xview and global.yview that you can use as a reference for spawning enemies instead of hardcoded variables but still adjusting for the offset caused by the bugged rotated view glitch. So for example instead of what I hurriedly did as a workaround for spawn code:

Code: Select all

instance_create(view_xview[0]+global.x_offset+120,view_yview[0]+global.y_offset-32,obj_3Den2);

We shall have:

Code: Select all

instance_create(global.xview+120,global.yview-32,obj_3Den2);

Doesn't seem like much but having a shorter lines make the code easier reading, plus I try to avoid making code in such a way that I have to scroll horizontally anyway (the legacy PC isn't connected to a widescreen monitor and isn't running at high-res so long lines are damn annoying when coding on it). Just so we're clear - the offset that's happening here is not the glitch, its the solution that keeps the screen from being a complete mess when rotated, which I forgot about when using it as a point of reference for spawning objects.

Other than that the level is just about finished minus some tweaks for chain fluency at the end of the stage. I should be able to work on it more for fixing bugs etc in the next few days, hopefully getting onto replacing the broken Gleylancer ship this weekend, with an official MK-V release next week. When that happens I'll announce it here but also try to drum up a bit of support on other places too. I'm even going to start getting a bit of picture advertisement too - avatars and some signature posters and icons, stuff like that. The push to get this out is in the hopes that I can actually get a few classes within my school to playtest it for reporting any serious issues for the purpose of my school assignment which is using GMOSSE as a demonstration of my IT skills and as an aspiring developer.

[BPzeBanshee]

GMOSSE MK-V is out guys!

Big promo thread here - http://shmups.system11.org/viewtopic.php?f=1&t=37925

First post updated with download details. Readme includes more details.

I forgot to mention in the Readme that I also added flashing on low health.

Gotta go for now, get to testing the engine!

Enjoy

[Rozyrg]

I'm definitely impressed with the speed and ship/weapon variety... I see the first stage is really shaping up, too. Good going, man.

I'll try to give it some solid testing time later this week.

[Udderdude]

Are you trying to make it into an actual game at this point?

[Kaiser]

Are you trying to make it into an actual game at this point?

Honestly, I think this new stage was only done for tech-demo purposes. I suppose later revisions will be about having even more managable code in more unified places. But even at this point, it's quite cool to use.

[Udderdude]

I'm just wondering if I should comment on technical aspects or gameplay stuff.

[BPzeBanshee]

Are you trying to make it into an actual game at this point?

Honestly, I think this new stage was only done for tech-demo purposes. I suppose later revisions will be about having even more managable code in more unified places. But even at this point, it's quite cool to use.

Exactly right. Technical aspects such as stability and performance are the primary point of interest.

The goal from here beyond immediate bugfixes is to add further stages of sorts with variance for the type of scrolling shooters available. Eventually I want to get some kind of consistent format going for stage creation which I'm starting to get together with this new stage and possibly add external modding support. If a person wants to contribute a singular stage it shouldn't have to require much difficulty to implement, and with the sound controller being revised this is further closer to its goal but I'm not quite there yet.

As for gameplay, do comment on that as well, but it is secondary to functionality. There's no point in having a stage with fancy stuff if it lags like hell, or crashes, however "unbalanced" it might be. The first stage is admittedly too hardcore and bullet-hellish (nothing easy like how Gleylancer was, in fact chances are Busterhawk's weapons are quite broken as well so further finetuning will be required later on anyway), but other stages will be different in their own way. Also, I'll eventually add weapon upgrade progression and further rebalancing will be required then. The next stage I want to work on will be based on Gleylancer's Stage 4.

[JGcontraman]

Just dled... Will get back to you.

Edit:

May be just me and the fact I'm on a shitty netbook but I feel that the difficulty of this game should be dumbed down a bit. I'm getting shoved up the ass by those blue bullets in the first stage.

With the sound/music, this game is reminding me of some old 16bit shmup i played on the SNES or Genesis btw.

[BPzeBanshee]

Just dled... Will get back to you.

Edit:

May be just me and the fact I'm on a shitty netbook but I feel that the difficulty of this game should be dumbed down a bit. I'm getting shoved up the ass by those blue bullets in the first stage.

With the sound/music, this game is reminding me of some old 16bit shmup i played on the SNES or Genesis btw.

The difficulty of the game isn't exactly meant to be easy, but it is meant to be a demonstration of what can be done using it and Game Maker in general. You'll do better with practice and getting used to a ship for certain. Having said that there will be some minor adjustments to difficulty later on, but don't expect me to change the stage to be a breeze for you .

By the way, you mention running it on a "shitty netbook". How well does GMOSSE run for you anyway?

As for the music, it's from Advanced Busterhawk: Gleylancer which is indeed a Sega Genesis game, the voices used in GMOSSE and some of the sounds used for the 'Busterhawk' ship are also from it as well as the aesthetic attempt at being similar to it. I hope that's not a bad thing.

[JGcontraman]

It runs pretty well surprisingly but I'm sure It would run alot better on my desktop. In fact, I'll try it on my desktop later in the evening and get back to you. I may be wrong about the difficulty since I am playing on a very low performing PC.

And man, yea great choice of music and what not. Gleylancer is a great game.

[Udderdude]

Game runs well, my biggest issue right now is the giant planet that appears in the background. It's very bright and shimmers, giving a very distracting look to it.

[BPzeBanshee]

Game runs well, my biggest issue right now is the giant planet that appears in the background. It's very bright and shimmers, giving a very distracting look to it.

I'll tune the brightness down. Thanks for the tip.

In other news, I figured out the business with the highscore bug, turns out pressing Z after putting in the last letter to submit to highscore multiple times results in submitting multiple times. Haven't touched the GMOSSE source code in a few days due to waiting for feedback but that should be an easy fix.

I've also gotten a suggestion to "increase the negative depth" of the scrolling text so that "stars don't get in front of it". It's actually all text in-game having an alpha of 0.5 for coolness, but I'd like to hear some more views from everyone else as to whether they have issues reading said text before I start changing it.

For difficulty reduction I've decided I'm gonna try increasing the amount of degrees inbetween the red bullets of the jumping shuriken thing and make the platforms only spin green bullets when ALL of the turrets are gone instead of the first two. Might give the white spinning enemies something other than random generation of bullets as well so that their bullets are predictable enough to avoid them. With some modification of the spinning balls that change depth (some of their movement is still buggy and their bullettraps irritate me) I think that will be all that's necessary to balance out the stage to be more accomodating for a first stage. It also means I shouldn't exactly have to code much either.

On top of that I discovered that opening GMOSSE with Game Maker 8 under Windows 7 and then playing it for a bit seems to cause issues with loading/freeing of sounds. It seems exclusive to Windows 7 machines and possibly exclusive to running via Game Maker's play game function instead of compiling it as an EXE in the usual folder. Unfortunately I don't have a Windows 7 machine around home to really extensively test it, and chances are it might just be something with GMFMODSimple itself. That said, you have been warned. Do let me know if you encounter this either playing the compiled EXE or testing the GMK file.

[JGcontraman]

Don't mean to be a dick or anything but I would think this game would of been cooler if you can design your own levels n stuff. Hence the name of it. I would suggest you change the name of the project or make it stand out for what the name is telling most of us (Game Maker Open Source Shmup Engine), because what really comes to mind is designing shmup games with a GUI interface. That would of been so much win. Still this is a well made game. But again, you might want to change the name of the project.

As far as game mechanics goes, this is what I suggest;
-Eventually add your own sound files (especially music for stages)
-Better designed ships (especially enemy units)
-Touch up with level design and make sure the design of the levels themselves does not divert the player's attention.

I know that stuff is probably the last thing on your mind to deal with but it would really improve your game and give it more of an edge.

[EddyMRA]

This is an engine for Game Maker, so you are required to have it in order to use it. In Game Maker, you can edit it to make your own stages, add/change sounds, and make your own ships. Also, you need working knowledge of Game Maker in order to do anything with this engine.

I've also gotten a suggestion to "increase the negative depth" of the scrolling text so that "stars don't get in front of it". It's actually all text in-game having an alpha of 0.5 for coolness, but I'd like to hear some more views from everyone else as to whether they have issues reading said text before I start changing it.

I also suggest making the text be always on top of everything. HUDs and text are typically on top of everything.

[BPzeBanshee]

The HUD/Text is meant to be above everything as it is unless I've messed up somewhere specifically. Clearly the alpha is making it look like it's not so I'll change the alpha back to 1 and get a darker grey to compensate. The alpha change was originally there for the white text to be darker against the black background which in hindsight is silly since I could just put in the colour code. I got this pointed out to me at another forum as well so it'll probably be one of the first things I do for GMOSSE besides the highscore fix when I get back to coding on it.

Don't mean to be a dick or anything but I would think this game would of been cooler if you can design your own levels n stuff. Hence the name of it. I would suggest you change the name of the project or make it stand out for what the name is telling most of us (Game Maker Open Source Shmup Engine), because what really comes to mind is designing shmup games with a GUI interface. That would of been so much win. Still this is a well made game. But again, you might want to change the name of the project.

As far as game mechanics goes, this is what I suggest;
-Eventually add your own sound files (especially music for stages)
-Better designed ships (especially enemy units)
-Touch up with level design and make sure the design of the levels themselves does not divert the player's attention.

I know that stuff is probably the last thing on your mind to deal with but it would really improve your game and give it more of an edge.

Advice and suggestions for GMOSSE is appreciated at this point, so don't feel bad for pressing on.

The direction of GMOSSE has been a little shortsighted in this regard beyond serving as a performance-friendly template for shmups made in Game Maker (and me experimenting with stuff beyond my coding ability), but it's not like I haven't stated what it was beforehand. "Game Maker Open Source Shmup Engine" is exactly that - a shmup engine whose source is freely available for Game Maker. Furthermore there are other engines for creating shmups that aren't based off of Game Maker (see Danmakufu, Dezeamon Plus etc which are completely independent), so steering GMOSSE towards that sort of thing is going a bit away from the original purpose of this project. At some stage I'll rewrite the intro of GMOSSE to clearly state what the "prime directives" of this project are too, that way there won't be any confusion in the future as to exactly what this is.

The idea of making your own stages outside of Game Maker (not a bad idea either) has come across my mind before, and it has been done before in the case of Shining Armour (which is now discontinued with source released, but it's beyond my skill level to implement anything from that game into GMOSSE at this point in time). This will be a function for releases in the very distant future if at all. I've been meaning to make a stage using the Pinwheel external bullet engine that was once promoted here too but I've yet to have gotten around to playing with it yet. That's also for the distant future.

Level design will probably be tweaked here and there where necessary (for example as I mentioned in my last post). Unless someone else beyond just me contributes "better designed ships especially enemy units" for GMOSSE however, they'll probably only be as good in graphical quality as they are now with testers outside myself "putting the finger on the pulse" so to speak.

[JGcontraman]

Yea its good that your tweaking the levels especially. Sometimes I get mistaken of what projectiles are actually in the foreground or the background. Although they are distinctive, it can still be confusing sometimes, especially with the asteroids flying at you. But as far as ship design goes, thats really something rather extra if your up to it.

[BPzeBanshee]

The asteroid sprites are directly taken with some altering from Gleylancer as well, so I'll change those when I get back to coding next week too.

In fact thanks to the reponses from people across two forums now I've got a good list of important things to start changing which I will compile into a proper public list that I'll update all of my GMOSSE-related topics with next week. So far, the font, font alpha, asteroids, planet background brightness, small tweaks in enemies, some strange issue with GMFMODSimple under Windows 7 and the bug in the highscore submission are the main ones I can think of off the top of my head - not bad considering most of those are general graphical nitpicks and/or easy enough to solve. I'm glad it's a lot more stable than MK-IV was, that's for sure.

[BPzeBanshee]

Okay guys, as I said I would, I've come up with a to-do list based on the feedback I received after releasing MK-V. Note that I have not touched most of these issues just yet but as of now will do so when I get the time. Sorry if it seems like a bit of an info dump.

So, in no particular order, the post-MK-V release To-Do stuff and the current status on them is as follows:

- Fix the highscore submit bug
Status: Already fixed.

- Reduce brightness of planet featured in new stage
Status: Haven't gotten around to it yet.

- Change asteroid sprite/colouring featured in new stage
Status: Haven't gotten around to it yet.

- Remove alpha transparency from text, modifying colour text and/or change font
Status: The new font offered by Emerald Master is great but I suspect I'm going to have sizing issues with it when replacing the existing font, as a result this may or may not end up being implemented. I'll check this out on the weekend when I have time along with the alpha/color 'issues'.

- Remove use of bomb display from Busterhawk since it doesn't use bombs
Status: Thanks mjclark for that suggestion. Easy fix, will do that this weekend.

- Adjust difficulty of the platform enemy and the jumping enemy
Status: Haven't touched that yet either. Angle difference between bullets of the jumping enemy will be further increased and the platform enemy will only spin the green bullets when 3 of its turrets are destroyed instead of two. Haven't decided yet on other enemies, this will probably be as far as I go for difficulty complaints for the time being.

- Documentation of where sprites from other games/projects etc are not clearly documented
Status: After discussion with other developers in regards to usage of sprites from other games being passed off as their own material, I think documenting exactly how I've come up with the materials for GMOSSE should be written somewhere. Fortunately I've made the majority of the stuff in GMOSSE myself so the actual not-made-by-me material is countable on my hand and therefore easy to have documented and changed to something better when I deem it necessary. Same goes with sounds except they're even easier to list - me, me, me, and Gleylancer.
None of this has started yet.

The existing To-Do list as seen in MK-V's readme is as follows:

x Change the sound engine (not much of a priority now that the issue's mostly solved but an alternative would be nice)
For those unaware I've had issues going back since the original release due to my handling of GMFMODSimple where sounds/music are loaded multiple times and effects are loaded without being unloaded properly resulting in memory leaks and RAM/page file usage increase. This issue has been since solved, but as it stands GMFMODSimple is proprietary and a non-proprietary alternative would be preferred though this won't change for some time.

- INI file config support options
| Background music volume
\ more to come, when I figure out what they are
Background music volume should be easy to implement since all background music-related sounds are loaded and assigned to one group specifically, and each group's volume can be modified (4 groups in GMFMODSimple by the way).
- More stages
| level with patterns making use of Pinwheel engine
| more Gleylancer stages, with walls (!)
| External level coding support?
| Create level progression controller or handling of some kind
\ more to come, when I figure out what they are
Pinwheel hasn't seen updates or anything relevant to it for quite some time, but hopefully me using it in GMOSSE will change this. I hope to encounter any bugs it might have and report them to the creator of that engine setup and demonstrate yet another way to make bullet patterns.
x WOBBLE SCROLLING
Most of my attempts at doing wobble scrolling have failed miserably. Advice sorely needed here.
x Add more sounds to Invader's bomb
x Find an official name for the Invader if one exists
x put in something ala Rayforce
x redo comments for GMOSSE
x externalise more of the graphics
Getting there, but most small graphics are staying in until I decide otherwise - that said I'd like to try and avoid the source file being too far over 1 MB in size - the last time I had performance issues with the legacy PC and GMOSSE was when the source file was over 1.1 MB and I suspect it may be related to the problems I had earlier.
x add weapon upgrade system
x investigate input recording and playback using external timelines to determine input
Actually I've made some progress in this regard. The issue I'm having now is saving the queues I've used to a file and then creating a queue based on the file again afterwards - I'm sure it's me being an idiot so if any GM expert can pitch in in this regard let me know.
- Music customisation mod ala Alluro's
Self-explanatory. Thanks Kaiser for the idea (we discussed adding additional custom levels to GMOSSE and some small issues came up in regards to where things were placed differently from where you'd expect them to be, specific coding for music was on the top of these things).
x Random ship select and/or integrated unlockable ship functionality
I told Alluro I'd see if I could come up with something like this after stepping on his toes for the unteenth time by asking what the situation with the random ship selection function. The idea is that if you have ships that are unlocked through individual events a variable switch can somehow alter a random generation sequence to ignore certain ship IDs. Currently I haven't touched this yet, this is for a bit of a future release.
- Further renaming of music/sound variables
I started on this, haven't quite finished it yet. Some variables were suspiciously named similar to variable switches and other stuff that's not sound-related - a small spelling error when coding around this could cause serious issues. Still working on this.
x External ship coding support?

Yeah, its a bit of a long list but this is long-term planning as well here for later releases.

[BPzeBanshee]

Project on hold till further notice.

No, I'm not dropping the project, but schoolwork and crap's catching up and I expect to probably not be able to touch this for a while. I'll let this place know first if and when I fix something significant.

[Rozyrg]

The way I do wobble scrolling is pretty simple, just a single global variable.

Control:
-before moving left or right, player obj checks this variable, sees if the required movement will set it above it's maximum or below it's minimum and applies any changes to it.

Everything else:
-screen boundary allowances changed to allow for the extra width.
-spawn positions of ground objects tweaked to allow for the difference in orientation.
-a basic script, something like:

Code: Select all

var xmem;
xmem=x-xmem2 //finds 'original' pos., subtracting prev. wobble value

x=xmem+global.hwobble
xmem2=global.hwobble

(I use a different value for airborne enemies, of course.)

I admit I hardly have all the kinks worked out, though. One issue is performance, of course - having to have minute, per-step position tweaks for lots of things onscreen isn't going to come cheap; but the hit isn't *that* big.

The other big issue is the actual speed of it. Basically, you have to find a speed that isn't too fast to be nauseating; but can still allow your ship to reach the maximum/minimum wobble distance before actually touching the edge of the screen. If you only have one set movement speed, finding the right setting for this probably wouldn't be too nasty; but finding one that works for all possible speeds can definitely be. Plotting out how much extra space is allowed figures into this too, obviously.

Project on hold till further notice.

Oh..

[BPzeBanshee]

I admit I hardly have all the kinks worked out, though. One issue is performance, of course - having to have minute, per-step position tweaks for lots of things onscreen isn't going to come cheap; but the hit isn't *that* big.

Yeah, I can see that being quite an issue. I can see it becoming strange like Tyrian if I got anything within that wrong and such complexity *might* affect the delicate performance I'm trying to maintain. I might ask around about this and experiment when I actually get time.

The other big issue is the actual speed of it. Basically, you have to find a speed that isn't too fast to be nauseating; but can still allow your ship to reach the maximum/minimum wobble distance before actually touching the edge of the screen. If you only have one set movement speed, finding the right setting for this probably wouldn't be too nasty; but finding one that works for all possible speeds can definitely be. Plotting out how much extra space is allowed figures into this too, obviously.

This is the problem I had when I first came up with some form of wobble scrolling - as a result it didn't work very well at all. The code will have to be able to compensate not so much by speeds but by the absolute position of the hitbox/player ship in relation to view.

Project on hold till further notice.

Oh..

Well, better then saying "I'll get stuff done soon like tomorrow" and not fufilling the promise. I expect to be a bit caught up with schoolwork bullshit for most of this month, furthermore my spare time at the moment is either dealing with computer problems or playing games because I'm just a tad burnt out. That said, I still think of GMOSSE every day and discuss it wherever possible - by Term 4 I should have A LOT more time on my hands.

[BPzeBanshee]

Project resumed, but on a bit of a slow time in terms of progress. I had a bit of time to pick off most of the existing nitpicks the other day which goes something like this:

- Reduced brightness of planet featured in new stage (if you still get distracted in MK-VI get your eyes checked)
- Removed use of bomb display from Busterhawk since it doesn't use bombs
- Adjusted difficulty of the platform enemy and the jumping enemy etc
- In case I forgot, I think I fixed the random spinning that happens with Busterhawk's search orbs (honestly I've forgotten if I even touched it or not)
- Found shit to waste time on when people dont complain about anything worthwhile

With the enemy difficulty, the angle difference between bullets of the jumping enemy has been further increased. The platform enemy is also rotated and hitbox modified so you can easily pick off its turrets, and only spins the green bullets when 3 of its turrets are destroyed instead of two. Furthermore, the cracked orb that spitted green bullets aimed at you now spits blue bullets and has no player-relative curve in its small barrage of fire. It still provides a challenge but there's less mean attacks now.
As for the bombs, they still spawn from enemies 'containing' them when you play as Busterhawk though they do nothing besides making the clicking noise upon contact. I might leave it this way should I decide to implement a rank difficulty or something that makes use of collecting them regardless of bomb function.
....now that I think about it I'm pretty sure I fixed the orbs. Rozyrg mentioned something and I got right on it but now I can't really remember fixing it. Man, leaving a project for a while does bad things to your memory.
My Uni course is finished, one of my school subjects is cranking down and the rest are cranking up. Should get more time to do more new stuff for GMOSSE during the school holidays providing I don't get slugged with a bunch of homework. By the way, I signed up for YoyoGame's GMHTML5 public beta so when it gets released tomorrow the first thing I'll do is probably play around with it. I expect compatibility issues and the TATE to be rendered completely broken and possibly speed issues regardless of browser used, but hey .

[BPzeBanshee]

I've started getting into the process of "rewriting" the sound engine yet again.

This time it's not really the structure (still keeping the sound controller and that) but if GMOSSE is ever going to be able to be ported to other platforms via GameMaker:HTML5 or GM4Mac it needs to be able to use Game Maker's default sound commands. Unfortunately as of GM 8.0 Pro the default sound commands are really shit - background music played using them never plays on my Mac running Bootcamp, it lacks OGG support and various other functions, etc. Fortunately the way I'm going about doing this is with a global soundengine variable. It'll read the number from the config (you cannot change this in the options menu, and frankly you should really be experienced or otherwise instructed to do so to want to change this variable) and depending on that number GMOSSE will use commands for a specific sound engine in mind using scripts. For example in its current state, what used to be FMODSoundPlay(global.playershoot) will now be scr_play_snd(global.playershoot) and that script will contain something like this:

Code: Select all

switch global.soundengine
    {
    case 0: sound_play(argument0); break; //GM's default play sound command
    case 1: FMODSoundPlay(argument0); break; //GMFMODSimple play sound command, what GMOSSE has used until now
    }

There'll be scripts to encapsulate sound playing, looping, volume setting, and loading/unloading from memory. There may be effects as well but along with file support and loop points I'm finding there's too much discrepancies between it and how GMFMODSimple does it to be able to accurately redo how GMOSSE used to work using the alternate commands for it. The sounds using the same filter options via Game Maker as opposed to the GMFMODSimple DLL sound completely different, and due to the lacking file support I've had to make MP3s of the background music tracks and cut them so they loop with the entire length of the songs (meaning the boss theme doesn't sound like how it used to).

Hopefully I won't just give up on this, I'm sure it'll be better off in the end. It'll mean should I decide to implement SuperSound and scrap everything it'll be really easy to do once this rehandling of sound commands are finished but I'm not feeling confident about guaranteed working the same across the board for them.

[BPzeBanshee]

I feel like an idiot for not thinking of this before. While bumming at school (free period) I took a look at the code and figured out a way to solve my current set of problems with filter support not being the same across sound engines whilst keeping the current behaviour of sounds intact.

Step 1: Create a sound test menu for all of the sound effects, and rerecord all of the sounds in GMOSSE running with the GMFMODSimple sound engine.
Step 2: Replace old sounds with rerecorded sounds.
Step 3: Remove GMFMODSimple sound filter code.

With this I'll have sounds that sound exactly like how they have been in MK-V, but not actually being filtered at runtime (resulting in a marginal performance increase), thus saving on lines of code and improving compatibility by removing code that doesn't work across the board. WINNING.

From there on, I replace all cases of specific sound scripts used and replace them with a script that determines which sound engine script to use. I've got these for stop (WIP due to GMFMODSimple not having a straightforward stop command), play, free from memory and loop, and now with the filter-related stuff taken out of codeland and into just the audio files themselves that may be all I'll need.

Also, the issue I was having with some sound effects not playing was difference in volume. GM sound engine's idea of 0.225 volume is different from GMFMODSimple's - if you set anything in GM default to less than 0.7 it's completely silent, so I adjusted single-digit volume numbers by adding 8 after the decimal point and 75 after the decimal point for multiple-digit volume numbers.

The other issue I have at the moment is pausing sounds. Game Maker's sound engine is so backwards it only has a rudimentary pause function for MIDI files (setting the tempo of the MIDI to 0), so I'm going to make it so if you run GMOSSE using GM's sound engine instead of the GMFMODSimple DLL the music will not be able to be paused (blank area in container script). Because I'm handling pausing for GMFMODSimple commands through a script I'm going to have to reorganise how I make use of groups. GMFMODSimple has 4 groups - I use group 2 for sound effects, group 3 for voices and group 1 for background music, but the only reason I had groups in the first place was to add filters and group-wide volume settings which I'll also need to scrap and change. I'll need to make a separate container script for volume handling anyway due to what I mentioned above, and in-game filtering is now redundant since the sound files will already be 'filtered' to how I want it on loading, which leaves group 1 for pausing. Currently I'm going to write it so that when you call the script scr_pause_snd when running under GMFMODSimple it'll add the sound you use the script with to group 1 and then pause group 1, but I don't know what kind of issues this will generate long-term so I'm gonna think this one out for a while. Same issue goes for stopping a sound within GMFMODSimple too.

So um, yeah, not dead, just taking a while.

[Atomhead]

I hear you on the sound problem. GM's native audio engine should be torched and rewritten from the ground up if only to support oggs. The volume in there makes no sense at all!
GMFMOD is probably the safest alternative though I really don't like the license costs for that one. For my own game I've tried some of the free GM audio engines, like SG Audio, SAudio and XeAudiere.
SAudio & SG Audio were giving me too much trouble, more so than XeAudiere, so ultimately I decided to go with a combination of XeAudiere and the native GM audio engine*.
That last one forced me to use WAV's (urgh..). Fortunately converting the WAVs to 8bit, and with them being short/loopable tracks, I managed to get the filesize somewhat under control.

What i did to fix the volume problem: I manually tested and played the same file through both engines. Then for each of them I took the values where the loudness sounded the same.
Here's the table, just to show you how f***** it was:
GMvolume = 1.00 XEvolume = 0.76
GMvolume = 0.95 XEvolume = 0.72
GMvolume = 0.90 XEvolume = 0.65
GMvolume = 0.85 XEvolume = 0.35
GMvolume = 0.80 XEvolume = 0.22
GMvolume = 0.75 XEvolume = 0.10
GMvolume = 0.70 XEvolume = 0.07
GMvolume = 0.65 XEvolume = 0.05

Next time though I think I'll give the GMBass/SinBass engines a shot. For now XeAudiere will do.

*sidenote: the problem I was having with XeAudiere is that you HAVE TO put the "Free sound from memory" command in the "End Room" section. So I never got it to work in a way that the same music continues when you switch rooms. In those cases I'm using the GM audio stuff. If you recognise that problem and know of a solution around it, I'd be eternally grateful.

[BPzeBanshee]

Interesting post there Atomhead. When I was first making Game Maker projects I had issues with native GM sound not playing music on certain machines (I've since come to suspect that installing the K-Lite Codec Pack on your computer may fix this but alas I haven't tested yet) I realised GM's default driver was crap due to file support as well anyway so I used Saudio for my first major GM project - eventually I did another release of the game later on using GMFMODSimple after learning it worked better out-of-the-bat than Saudio (I was an idiot and trying it through extension package method, or something).

So I basically learnt GMFMODSimple and stuck with it because it works, its only problem is its licensing and that its hard to debug if a memory leak of some kind arises which is easy to cause with it if you don't code it properly (like I did in previous releases). What I'm doing now will allow for people who already have an idea of what sound engine they want to use to implement it really easy while not modifying/breaking most of the existing code.

For your issue with XeAudiere, I'm not familiar enough with it but that kind of bullshit you mentioned shouldn't be necessary and is obviously somewhat restraining so I'd recommend switching to either the GMBass/SinBass engine you mentioned (Aero Flux uses it and seems to be okay but I haven't looked at the code for it extensively yet) or SuperSound (S20-TBL and Rozyrg use it for their projects if memory serves, they've got a few posts in Development here that can be useful for it).

Oh, and in case anyone was interested in exactly what I've managed to do regarding my previous rant post, Arxtyan now uses non-filtered sounds but the explosion for its bomb is one of the generic explosion sounds which hasn't been converted yet. I'll do the generic sounds next, then the explosions, then the other ships. From there I'll proceed to remove all of the filter code and THEN figure out how the fuck I'm going to do specific sound pausing/stopping within one script without having to do groups. The music seems to go a bit weird when you first play it using GM Default but hopefully that was just the computer I was using, or maybe one of the "sound type" and "preload" options bullshit.

[BPzeBanshee]

Progress update:

The sounds are converted, but just when I thought I'd figured out the difference between GM volume and GMFMODSimple some of the sounds sound way off. It's actually more to do with playing a file that's been altered through filtering still sounding different then filtering it as it plays, but explosions are nigh-unhearable while Xonochrome's shot is quite loud. It seems to be the exception more than the rule as most of the sounds went across the conversion process fine but some just sound completely different despite using same procedure.

I also figured out how I'm going to handle pausing but it requires I go through every sound and change it to "global.<variablename> = <sound script command>" and then when trying to pause, using the global.<variablename> as the 'instance' for which GMFMODSimple will pause using FMODInstanceSetPaused(). Easy to type down, but easy to screw up. I'll leave it for a bit and then work on it.

So um, ragequit yet again. I'll work on it a bit more if not tomorrow within a few weeks, I'm gonna see if I can help give Rozyrg some advice for Flying V among other things.

[BPzeBanshee]

More headaches. I'm seriously considering scrapping the sound rewrite altogether as the inconsistency of support not only between GM Default and GMFMODSimple but GMFMODSimple and everything else is quite annoying.

What I might do in the end if I can't get GMFMODSimple to cooperate is to just go back to what I've got with MK-V but add this alternate sound controller as is and get a variable in the config to allow the MK-V version or the experimental clusterfuck if you change the variable to 0 as opposed to 1 being the release-version GMFMODSimple coding.

In other news I've discovered SinDisplayDLL. I was having problems coming up with an across-the-board way for adding TATE to pietrator's Aero Flux project due to not being able to change the screen resolutions within Game Maker itself (the TATE mode requires fullscreen to work using my way). Won't make use of this yet but I'm noting it here in case I forget.