shmups.system11.org

After some consideration I may actually scrap the whole Ketsui-graphics thing. That ship sorely needs redoing and having a third key for autofire + SHIFT doesn't feel right on the hands nor is a good example. When I can get around to it I'll make sprites similar to what I've done for Xonochrome already while featuring similar weapons (Tiger Schwerts lock shot can be implemented into SHIFT).

I'll also get the internal highscore stuff implemented and have another go at the joystick support stuff. I may need playtesting help with it since the code itself is currently out of my league and I cant get it to work properly by even just playing Nimitz's edit with two different joystick/gamepads.

The way I did joystick support was just to map the buttons to global keyboard events. D-pad and [analog] stick support in GM is fairly OK, although for precision press-release events on the stick you'll need to do a little bit of extra coding (which I have honestly not figured out yet--the last time I did it, a single tap caused the D-pad and stick to register a keyboard_check event nonstop until I tapped them again).

Otherwise, it's the button reassigning that is especially dodgy. I *might* have a solution for it, but I'll need to test it out first.

Well I'm putting joystick support off (and in turn the conversion of keybased events to within Step) till I figure out this new problem I'm having.

I've spotted a memory leak in GMOSSE, which in terms of RAM usage eventually is forced down but the Page File usage goes through the roof after a number of resets. I'm not sure if I can really come up with a solution for this but when I can get time to investigate it I'll be completely redoing how I load sounds, music, and external graphics so I can hopefully solve or at least bypass the issue. I'm also unsure as to whether the CleanMem DLL will be the solution for this since RAM only goes up to an amount and then gets shafted into the Page File usage (which is where my machine has BSODed me in the past due to too much PF usage).
What I've basically done so far is made a obj_memtest which will load all external backgrounds (I dont use external graphics yet but once I figure out how to do it with the SMSPR files for Swordfish's laser I will) then initialise GMFMODSimple and load all the music files used along with sounds. There's a room I've made that when set to first room will have this controlller object the only thing running, so essentially its quarantined all the existing code and objects and serves as a Memory Stress Test.

It's really looking like I won't be able to do a hell of a lot of work on this thing so if anyone's really keen on looking at the changes I can just compile EXEs for GMOSSE running normally, GMOSSE with Nimitz's edits and GMOSSE with my Memory Stress Test running and then just include all the GMKs I currently have for a MK-IV release, but its not really in a state I'm happy with.

I noticed the same issue in my game too. The PF usage increases by 30MB every reset, and more if you simply keep running the game and loading the assets. At startup it snags a hundred MBs worth, then keeps adding 30 whenever I send the game back to the title screen (I don't use the built-in Reset function, btw). Might have something to do with GM creating temporary files somewhere, but I'm not sure.

I managed to reduce it to around 17-20MB every reset by deleting background indices and destroying all objects every end-of-room though or reset, though. It seems that may be the key.

Have you tried using this DLL to keep track of your game's performance? It might come in handy when debugging it.

I experimented a bit with precise press/release stuff for multiple buttons in ZPF; but I couldn't get it to work quite how I wanted. Basically the idea was that you'd be able to 'slide' your finger over from the fire button to the second button without having to consciously release it all the way, activating the beam without wasting a chunk of your meter on a bomb. It went something like:

-Each step a button is pressed, it adds to a special timer
-Releasing a button would reset it's timer to 0

There was a bit more to it than that; but that was the basic idea. So, in theory, pressing one button (timer is 0 or below a set threshold) while another is held down (timer is at maximum) could produce a different effect than just pressing them both together. I dunno if I just set those thresholds too low (considering anything below 60 would be a fraction of a second) or if there was some other technical snafu involved (very likely) or if the intended usage simply contradicted intuitive play.

I'm not entirely sure what you mean precisely Rozyrg but I already have something like that for the Tiger Schwert's main shot. That's how I can tap it for using normal shot and then hold it in for a little bit to get the infamous "lock shot" which uses no extra pods or objects at all. The main issue I'm having with the joystick support is quite simply that it doesn't respond to controls. I don't have the experience or time to really look at it now. That sort of thing is also how I was doing the afterimages of slowdown with the SHIFT key but either I broke something or got annoyed by the delay, so that actual part of code needs a revisit as well.

Also, the Memory DLL looks very interesting and when I can get time to work on this again I'll implement that DLL along with CleanMem when I can get everything straight. Let's just hope I don't start making annual releases like some people I know.

Good news guys! I had some spare time today so I looked at Nimitz's code for the joystick support and turns out the only thing that was stopping anything from "working" was the deadzone at 0 with my not-very-well-centered 360 gamepad and Logitech joystick.

So I changed a few variables around and I got it all magically working! I feel like an idiot for not looking at it sooner.

Anyhow, the changable button scheme for joystick setup is also great but obviously one controller's deadzone is going to be more sensitive than others so I'll make that configurable in the options menu as well as maybe have the option to use a D-Pad instead (it took a little bit but I got my 360 gamepad working quite nicely despite Game Maker using angles for "Point-of-view" button functions) before I import all the cool stuff into the main build. I still haven't had a look at the diagonal restricting and speed modifiers and all that stuff but since that's all in the Step event for the parent obj_player now I should be able to figure out exactly what's changed too.

I know I'm being real slow about all this but I guarantee you'll see a MK-IV release of GMOSSE within six months, promise!

Quick post, I got around to finalising importing of Nimitz's features of GMOSSE into the main build.

For the "wonky" movement feeling I was getting before what I did was:
- fix the afterimage code, it used my old code and I made it use the more "responsive" code for aesthetics
- establish global variables based on Nimitz's commenting for diagonal movement speed within his movement code - it was using global.slowshipspeed - 1 before
- change the variables for global.slowshipspeed, original code would subtract/add this to global.shipspeed to get final ship speed when holding SHIFT and Nimitz's code just uses the variables themselves

So now in the Create events of player ships global.diagspeed and global.sldiagspeed will be needed for each ship as well. I've configured the original ships Xonochrome and Invader to use the same speed for diagonals as normal speed but the main point is that this is configurable for people who actually want limiting on diagonal movement.

Some other things I've done involve:
- instead of using game_restart() use event_perform(ev_other,ev_game_start) and added FMODGroupStop() to the F2 key event
- organised altered objects and rooms into separate folders to help implement into main build
- instead of having the game display "Game Over" and play the Game Over music at the end of a stage it displays "Game Complete!". This is done simply by checking if global.gamecomplete is at 1 or not, which is initialised in the obj_stage1controller.

Obviously the F2 event as it was in MK-III and indeed obj_maincontrol's Game Start event is a large contributor to the memory leak so "restart" handling is going to have to be completely redone. Haven't done the configurable deadzone yet either, but once I do that and I get Nimitz's extra features in the main build I'll start on that. Also, not done digitally yet but I made a small drawing on paper for graphics to replace one of the main ships. It'll probably replace the Gleylancer one but I'm not entirely sure yet. I'm also considering making the Gleylancer ship use a RayForce-like lockon beam for a bomb, moving its speed-change function to SHIFT key.

Now I've got some homework I need finished but providing nothing comes up (no guarantees) I should be able to get into the real hard stuff on the weekend and actually have a release within two months instead of six.

I've been linking GMOSSE all over the place, hopefully some people start using it.

Great stuff! I intend on posting it around at a few other forums I'm aware of as well when MK-IV gets released and I fix the remaining issues I've got with the build.

Quick update:

Configurable Deadzones are now implemented.

Still don't know what the hell to go is with the memory leak but I've avoided using game_restart() entirely for now and just unloaded and reloaded FMOD after the highscores are displayed.

Also, I've mostly finished the replacement for the Tiger Schwert. It looks friggin awesome in my opinion and I stayed up all night to make it behave close to perfect to how the Tiger Schwert would behave in Ketsui (with some minor exceptions ie. graphics and control scheme). Here's some screenshots:


I wouldn't call it a perfect imitation but it's close and looks a lot better in-game and animated. I'm quite happy with it myself.

GMOSSE MK-IV is out!



I'm still not quite happy with the state of GMOSSE as it is but it's still a couple of levels about what MK-III is so I'd best not delay it any further. Get it here.

There's a list of changes in the readme file included in the package, along with current issues.

Main features include the new ships, transition engine, joystick/gamepad support, further enhanced TATE, and a completely recoded boss that I recall off the top of my head.

I'm 99% sure there's going to be bugs of some sort, though by myself I'm not really finding them. Report back to me if you do find any bugs in particular when running GMOSSE.
EDIT: Sure enough I found a bug. I thought I squished it before I uploaded it, but it turns out it was one of two problems which are both a sideeffect of a larger problem I'm still figuring out how to fix.

Playing through a game, then going through the highscores, hitting Start Game and moving Right may crash the game. Most noticably happens with Windows 7.
It's due to my crap workaround handling of GMFMODSimple at the highscores I believe since getting rid of everything for that part made the issue disappear in my tests (code located in Step event of obj_scores).
If anyone encounters this please try and type down exactly what you did and try to recreate the problem.

First attempt at getting scanlines in:

Not going terribly well but the results look somewhat convincing. Skipping frames here and there and doing weird glitchy stuff on the screen, and not like a TV either, but it works. Thanks Shadow Link from YoYoGames forums for the initial code.

I'll be doing more tweaking and probably make the code again from scratch if necessary. In the meantime here's my current modified code (comments are from the original code and I've kept it there for comparison sake, c_black replacing c_red):
- create event


- draw event

Enabling synchronisation to avoid tearing in fullscreen mode slowed the framerate down even on the decent PC that I tested this on at Uni, and forcing the resolution at anything less than 640x480 distorted the entire screen. I think the alpha settings are a bit harsh and 0.3 and 0.15 are probably better.
If someone's more familiar with the nature of scanlines do chip in so I can figure out exactly what settings I'll need to make customisable.

I had to try this out on XYX... and it does look surprisingly good.

Only changes I made were knocking out the screen_refresh() and either leaving the lines on all the time (at an even lower opacity) or adding a delay. Having it go every other step hurts my eyes something fierce.

edit: also took Dave K.'s advice and made them vertical rather than horizontal.

Might have to "borrow" this too.

In complaining to Udderdude about being unable to take screenshots of XOP Black when rotated he went and added scanline support for both vertical and horizontal directions. This is a good piece of functionality and is the first thing I thought of when considering scanlines in GMOSSE. Remember that the initial code I only tweaked from results I found at YoYoGames, and they have some projects listed that attempt to emulate an old TV beyond typical darkened lines for visual scanline effects that look pretty excellent.

You're welcome to 'borrow' it Rozyrg, but if you wait till I actually work on this a bit more I can send you a proper configurable script for this - I'm starting to get rid of duplicate functions within some controllers in GMOSSE and put them into 'Core' scripts to make things easier for the end user to understand what's happening within the GMK and a configurable scanline generator in a script is my plan for this function.

EDIT: Made some progress but this one line at the topleft is annoying me:

Its not easy to see in native res but its damn obvious playing fullscreen on my 1920x1080 monitor or when zoomed in. Haven't figured out why yet but besides that I just followed Rozyrg's advice and got something rather stable and non glitchy going.
And here I was thinking that scanlines were something only surfaces could provide. Thanks Alluro.

Cool. I have it in all the places I need it now, just have to change a simple script, so I'm open to try any new developments you come up with. (and I am giving both of yall credit)

One thing I will go ahead and note, though... if you're drawing any other primitives on the screen, you should probably use draw_get_alpha() and draw_get_color() before you draw the scanlines and have it to revert back to those afterwards. Common cleanliness as far the draw functions go, I know; but still worth noting I think.

I had no idea there was such a thing as cleanness convention in drawing code. I don't suppose you could provide me with an example of what you're talking about, cause that kinda made no sense. :S Why do I need to get the draw colours again after drawing the lines?

Sorry. I just meant cleanliness/neatness in as far as keeping those variables specific to that particular task (drawing scanlines in this case), because they can easily bleed over onto other elements if you're not careful.. especially draw_set_color, since it applies to *all* primitives onscreen.

I probably wouldn't have mentioned it if I hadn't been scratching my head for awhile trying to solve a little glitch that resulted because of that. Basically, every (non sprite) object on my game's pause menu was rendered black because the scanlines' color change was called -after- everything for the underlying shapes had been correctly set, changing them with it.

Anyways, it's probably not a fix you'll need; but I thought I'd share just in case a similar problem cropped up. :3

Ah, okay. I find that only happens with me when I don't set a colour for something in an object's draw event. I'll eventually have running flawlessly in that regard but until then I'm trying to figure out why it won't draw a vertical line on the left side (as seen in picture). Is that happening with you?

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.

Just realised the joystick code in the current release is mixed up. Thanks for not letting me know last month guys.

Anyway, fixed now. Should work across the board regardless of what kind of stick you have.

Yeah man, looks like we finally got em =)

I feel like an idiot. That problem with the scanlines is actually me having an outdated Game Maker version, which apparently has been fixed in subsequent release of 8.1.

Also, got curious after v0.10 of Xeno Fighters R not working on my new computer so I added CleanMem.dll to GMOSSE and made use of its show memory function. It's a little worrying when I see it clean the memory and then just start adding up real fast but its still a lot less than what it was using before, and wasn't causing the error that I thought it would. So I guess it must be something within GmBinFile.dll, so I'll work on adding that later.

EDIT: Got a newer version of GmBinFile.dll that upon placing in the Xeno Fighters folder made things work, so yet again that mysterious error lies within the GmBinFile.dll again. I'll probably still take a look at it for GMOSSE given time since I want to eventually have externalised highscores saved within the game folder. Being an open-source engine obviously having a password within the GMK isn't the best idea but one could change it to something else for their project.

Small update: the Gleylancer ship is more broken than ever I've just noticed - it now distorts time when I play it and throws everything that has been carefully timed in the game off severely. In case I haven't mentioned it already, I'm definitely scrapping it and remaking it from scratch again now that I've got a good example of a working ship that uses pods (Arxtyan).

Also, I think I may have finally nailed the problems with sound and effects doubling on eachother the further you play. CleanMem.dll helps keep the memory and page file usage down while I've rewritten load handling of sounds to be within a new controller, obj_soundcontrol. Since the Gleylancer ship uses Xonochrome's shot sound without actually loading it to begin with the game pops up with an error now if I play it first, while if I play as Xonochrome first then play as the Gleylancer ship no error happens but nothing plays since the file is taken from memory but the variable still exists. I also fixed an error with the Invader that popped up during the process of centralising the sound handling which lead to a few lessons learnt about how GMFMODSimple does things. All of this should be documented where applicable within comments now.

I haven't done extensive testing with my legacy PC yet with how it runs GMOSSE with the CleanMem.dll but things are looking up for stability. I added a line of text to show how much memory the game's using rounded to KB and it's using nothing near the 140+ MB that it used to. Having that update every second though might be a bit performance intensive, and I haven't really tested out GMOSSE under the legacy PC with all of these changes so if I see significant performance drops as a result of CleanMem or anything else I'll be taking it right out.

Oh, and I haven't touched GmBinFile.dll with GMOSSE just yet. I've got a few other ideas for how to redo the high score process and maybe come up with something like Gleylancer's "3D" name insertion to the highscore table before I even think about adding fancy security crap to it.

Tested GMOSSE under my legacy machine after tweaking the memory display text to not refresh every frame (was hogging performance) and GMOSSE still runs at 60 FPS when fullscreen as expected. It's a little bit choppy at times though, mainly with loading between rooms and such. Shouldn't be too much of an issue.

I also had an idea and spent a few hours working on it today - "3D" depth perception handling. The image scale and image alpha in relation to said object's z level is handled with a script (normal size when z = 128) while enemy movement beyond the normal level is handled by a clone object separate from said enemy that has no obj_enemytarget parent so as to avoid collisions and such.

Also, started working on a proper first stage for GMOSSE. The use of this fake 3D stuff is being used a bit in this too for the asteroid attacks I've got planned. Nothing much to actually see yet, I've got some randomly-generated asteroids in working both as background effects using z depth and also as attackable objects (colour-blended in orange to make a clear distinction) that will explode into bits when "killed off", a few attack patterns by existing enemy units showing up and also two new enemies that make use of the fake 3D stuff, though for some reason one of them just disappears and never reappears like how it's supposed to. I'll figure it out.

Once I do that I'll probably either make a new boss or take the existing one and make the new stage the default one for GMOSSE, removing needs for GUI-based Timelines and then implementing appropriate transition handling to other stages. Maybe even a stage select function later on. When I have time.

There's been a little more work on the new replacement stage and I've got ideas as to how I'm planning it all out too but development has currently stalled (school on for the rest of this weekend and making decent enemies are proving to be a bit of a pain). I want the stage to not only work fluently but make good demonstration use of the 3D depth effect script too, while being based on the first stage of Gleylancer. Bitten off a little more than I can chew quickly but mark my words this project isn't dead for sure.

The way you describe the fake 3D makes me think of Galactic Attack, with every level having an extreme use of scaling effects to show the differences in depth between background objects. If nothing else, it just looks cool.

Glad this is still alive and kicking, too. I regret not putting forward any input lately though.

Oh, and maybe you touched on this earlier; but have you found any way around the scanlines being distorted when using view rotation/TATE? I know it's probably just a fault with GM and I don't mind it so much with the graphics themselves (it looks lovely on my LCD monitor regardless); but it really screws up the scanlines. I admit I don't have much experience working with views; but I'm sure there would be a way to draw them separately.

I only was aware of that much when you told me, it's obviously a sideeffect of the same distortion that happens with the view rotation anyway. It is possible to use more than one view I believe so drawing on that view would probably be the solution - I'll try this when I get home or have spare time at Uni.

Also, thanks for the praise on the 3D handling. I can give the standalone script with instructions as to what variables to handle when using the script etc if you so wish. Basically all it does is use a z variable to determine an objects image_xscale and image_yscale, with normal scale at z=128. Hopefully I'll be able to make RayForce-like stages in the future using it, or parallax backgrounds, or enemy entrances like in Shinobi III for the Megadrive. Lots of potential use and it does nothing to performance on the legacy PC from what I've tested, so I figured it'd be a great addition to GMOSSE.

Took a bit more of a look at the scanline problem, and the idea I had for solving it actually (for my knowledge, unless Rozyrg or S20 care to differ) requires surfaces which I refuse to use in GMOSSE.

I just do not trust them one bit.

Also, I had no idea that Galactic Attack was actually another title variation of RayForce. That was precisely my inspiration for the fake 3D handling.

Speaking of which I've found out that I've fucked up with how I've handled the 3D-manipulating objects in such a way that their hitpoints gets restored to full health every time they jump or otherwise change since they're changing as objects. XD
Not sure how I'll fix that yet, the reason I went with different objects to begin with was so that collision detection didn't happen and so that Xonochrome's missile wouldn't go haywire (I still need to come up with some kind of alternative lock-on to variables instead of constantly searching and making up its mind all the time too).

So um yeah, progress has stalled for the time being. I'll see what I can do for it next weekend.

I don't blame you, actually. Surfaces actually increase the bar for system requirements, since older computers have severe GPU-related issues running GM games with surfaces, with some older GPUs and mobos unable to even handle the drawing process. GM games that do have them also have the option to turn them off, like in Ninja Senki.



If I read this correctly: what you're doing is changing one instance into another to handle the fake layered-3D effect for background enemies, a la Layer Section / Galactic Attack / RayStorm / Idon'tknowwhytheychangedthenamethricefordifferentregions. If this is your method, what you could do is have the two instances share the HP variable by making the objects they transform into inherit the current HP variable of their previous form.

For example, say you have one background enemy object scripted to have 300hp, and it gets hit by a lock-on attack that damages it for 100. The enemy then switches over to the foreground plane and changes its object type accordingly. What you could do is assign a temporary variable to the object it changes into during the step in which it switches object types so the engine doesn't get confused. For example, object enemy_type01a changes into enemy_type01b, with both sharing a local variable en_hp for hitpoints. Once it scales up to its actual size to simulate the 3D depth changing, it changes into the second type:



Now, the kick here is that I don't know if the last line will be performed in the same step as the instance_change function. If that is the case, I think you might also be able to do this version, but be warned that it will cause speed hiccups (your game will temporarily speed up if the following event is performed en masse by several objects at once):



I think this should be able to do it, unless I'm mistaken.