G.M.O.S.S.E - Now on Github! (29/3/24)
Re: G.M.O.S.S.E - MK-V (15/08/2011) New stage, and more!
Hey,
just so you know, I read somewhere on the GM forum that they are planning to redo the sound system by the time GM9 (and I'm hoping GM Studio by the end of the year?) gets out.
I'd argue sound is perhaps not the most important GMOSSE feature, don't feel bad about it.
That TATE mode dll you're talking about sounds interesting, since for HI0 i've been working with some rather strange resolutions (some levels have a different windowsize) and broke my head on trying to adjust the GMOSSE Tate script.
Eventually it looked like I wasn't going to get it to work so i ditched the entire matter.
Btw, I've recently started on my next game, in which I'll need a lot of sound code. I'm currently trying GM Bass, which is working quite well at the moment for my (initial) purpose.
just so you know, I read somewhere on the GM forum that they are planning to redo the sound system by the time GM9 (and I'm hoping GM Studio by the end of the year?) gets out.
I'd argue sound is perhaps not the most important GMOSSE feature, don't feel bad about it.
That TATE mode dll you're talking about sounds interesting, since for HI0 i've been working with some rather strange resolutions (some levels have a different windowsize) and broke my head on trying to adjust the GMOSSE Tate script.
Eventually it looked like I wasn't going to get it to work so i ditched the entire matter.
Btw, I've recently started on my next game, in which I'll need a lot of sound code. I'm currently trying GM Bass, which is working quite well at the moment for my (initial) purpose.
Hyperspace Invaders II: Pixel Edition - Available on STEAM NOW!
-
BPzeBanshee
- Posts: 4859
- Joined: Sun Feb 08, 2009 3:59 am
Re: G.M.O.S.S.E - MK-V (15/08/2011) New stage, and more!
I do hope this is the case with GM9, the current stuff they have is pathetic in this day and age (though I have heard that in GameMaker:HTML5 there is OGG support so there's been some work done already). Thanks for the advice though, I think I'll just follow it and scrap the project for the time being - as it stands the current method already works despite not being feasible for other platforms and is pretty neat now from the first time I rewrote everything for it.Atomhead wrote:Hey,
just so you know, I read somewhere on the GM forum that they are planning to redo the sound system by the time GM9 (and I'm hoping GM Studio by the end of the year?) gets out.
I'd argue sound is perhaps not the most important GMOSSE feature, don't feel bad about it.
That TATE mode dll you're talking about sounds interesting, since for HI0 i've been working with some rather strange resolutions (some levels have a different windowsize) and broke my head on trying to adjust the GMOSSE Tate script.
Eventually it looked like I wasn't going to get it to work so i ditched the entire matter.
Btw, I've recently started on my next game, in which I'll need a lot of sound code. I'm currently trying GM Bass, which is working quite well at the moment for my (initial) purpose.
If you need help with getting TATE in your game feel free to send what you have and I can try and rack my brains around putting it in. The DLL I mentioned doesn't do TATE but changes the resolution of the game under your command at runtime as opposed to how Game Maker does it by default which cannot be changed once in-game. The TATE script in GMOSSE requires a bit of an idea of how to manipulate the variables around for different resolutions and some resolutions work better than others (somehow the creator of Shining Armour managed to pull it off on a 1024x768 without even stretching or doing anything besides view_angle = 90).
As for your next game, I've taken a look at GM Bass and like SuperSound its functions are basic compared to GMFMODSimple but its got more than enough for a shmup especially with straightforward file playing, volume handling (if memory serves) and pausing/resuming. Pieterator uses it for Aero Flux - good call there.
![Smile :)](./images/smilies/icon_smile.gif)
Re: G.M.O.S.S.E - MK-V (15/08/2011) New stage, and more!
I also decided to ditch TATE because not all of the game modes would benefit from it + the size changes to a square gamefield sometimes so yeah... not much use for TATEBPzeBanshee wrote: If you need help with getting TATE in your game feel free to send what you have and I can try and rack my brains around putting it in. The DLL I mentioned doesn't do TATE but changes the resolution of the game under your command at runtime as opposed to how Game Maker does it by default which cannot be changed once in-game. The TATE script in GMOSSE requires a bit of an idea of how to manipulate the variables around for different resolutions and some resolutions work better than others (somehow the creator of Shining Armour managed to pull it off on a 1024x768 without even stretching or doing anything besides view_angle = 90).
![Smile :)](./images/smilies/icon_smile.gif)
I intend to have a go at audiovisual gameplay, I thought GM Bass was pretty extensive actually... All I need for now is to be able to extract the volume, and that seems to work ok.BPzeBanshee wrote: As for your next game, I've taken a look at GM Bass and like SuperSound its functions are basic compared to GMFMODSimple but its got more than enough for a shmup especially with straightforward file playing, volume handling (if memory serves) and pausing/resuming. Pieterator uses it for Aero Flux - good call there.
I would go for Fmod if it weren't for the license...
Oh and it's not going to be a pure shmup, but more of an abstract racing game with bullet patterns here and there. Anyway I'm a long way from done.
![Wink ;)](./images/smilies/icon_wink.gif)
Hyperspace Invaders II: Pixel Edition - Available on STEAM NOW!
-
BPzeBanshee
- Posts: 4859
- Joined: Sun Feb 08, 2009 3:59 am
Re: G.M.O.S.S.E - MK-V (15/08/2011) New stage, and more!
Do let me know when you get it done so we can play it. Probably won't be that popular here but I'm sure it'll fit in with the "Development" theme of this subforum. ![Razz :P](./images/smilies/icon_razz.gif)
![Razz :P](./images/smilies/icon_razz.gif)
-
BPzeBanshee
- Posts: 4859
- Joined: Sun Feb 08, 2009 3:59 am
Re: G.M.O.S.S.E - MK-V (15/08/2011) New stage, and more!
I JUST GOT INPUT REPLAY FILES FOR GAME MAKER WORKING. ![Very Happy :D](./images/smilies/icon_biggrin.gif)
Expect such functionality in GMOSSE MK-VI.
![Very Happy :D](./images/smilies/icon_biggrin.gif)
Expect such functionality in GMOSSE MK-VI.
Re: G.M.O.S.S.E - MK-V (15/08/2011) New stage, and more!
Input replays you say!?
I had thought of a fairly simple way to do this before; but with some less-than minor hassles to overcome along the way (mostly creating a replay-specific game state.) Curious what the breakthrough for you was.![Wink ;)](./images/smilies/icon_wink.gif)
![Shocked :shock:](./images/smilies/icon_eek.gif)
I had thought of a fairly simple way to do this before; but with some less-than minor hassles to overcome along the way (mostly creating a replay-specific game state.) Curious what the breakthrough for you was.
![Wink ;)](./images/smilies/icon_wink.gif)
-
BPzeBanshee
- Posts: 4859
- Joined: Sun Feb 08, 2009 3:59 am
Re: G.M.O.S.S.E - MK-V (15/08/2011) New stage, and more!
I'd actually had a test file independent of GMOSSE for some time now where I could get the player ship to move around while recording its input, and then have a second object do the exact same thing based on the recorded input while it was within memory, but could not figure out how to save the input strings to a file and then read it again. This was due to me being an idiot and now I've gotten a less crude build going. It uses the same method of input as GMOSSE does so adding the fire/bomb/focus buttons are a breeze and putting it into the game via an alternate parent player object and a single controller will be easy to do. Not sure whether I want to include recording of the pause button though.Rozyrg wrote:Input replays you say!?![]()
I had thought of a fairly simple way to do this before; but with some less-than minor hassles to overcome along the way (mostly creating a replay-specific game state.) Curious what the breakthrough for you was.
Here's the build if you're interested - http://www.mediafire.com/?cjqfr26qa7x9dr9
Note that it works based on the method of input I use for GMOSSE. If you use key events within the events tab in Game Maker for movement you could replace the "global.jleft = 1" stuff for actions based on the queues to whatever the simulate key press command is and in theory that should work too.
As for "replay-specific game state", I plan on doing it in GMOSSE by an option in the main menu which will spawn the input replay controller, and some small modifications to the parent player object. This is all theory though, I haven't actually touched GMOSSE itself in regards to input replays but have been modifying quite a few bits of it for something else which I'll discuss in detail when I'm ready.
-
BPzeBanshee
- Posts: 4859
- Joined: Sun Feb 08, 2009 3:59 am
Re: G.M.O.S.S.E - MK-V (15/08/2011) New stage, and more!
Small update:
I got input replays working in GMOSSE. Currently you have to have the 'recording' tag in the config ini set to 1 to do a record play and 2 to play back a record but I will implement a proper menu function for it before MK-VI.
The main problem I'm having with it now is that GMOSSE uses random variables everywhere and this is affecting the playback somewhat. Initially it was so bad a stage complete run would be a crap run where you died halfway through the stage when you didn't really or something. I fixed that by adding an extra queue for the current random seed that is used every step which the game uses on playback, but now there's still something a bit off as a run I did where I got 1.3 mil at the end of the stage is played back as a 1.17 mil run or something - it's like I've missed a few enemies in the input replay that I hit to get the difference in score. Furthermore, I did a run of only half of the stage and the scores between recording and replaying were the same so I'm theorising it's something at the later part of the stage. I suspect that what might be happening is that two enemies (asteroids + spinning enemies) are being spawned at the same time on the same frame and the queue is only taking one of these resulting in placements of the enemies being different. Ideally the best solution for this would be to either sync the spawning of the asteroids so that they don't spawn at the same frame as the other enemies or just remove randomisation of it entirely and hardcode a huge amount of different spawning x variables for the lot which will be a pain.
More to come when I investigate, for now more testing and an English essay.
EDIT: Tried runs with Arxtyan and Swordifsh and comparing screenshots of the score to the input runs they dont seem to be any different from eachother. Invader, Busterhawk and Xonochrome on the other hand go way off. I would think that my theory stands for Xonochrome and Busterhawk but I have no fucking clue why the Invader would cause anything to screw up in terms of the random seed changing twice per frame as it uses no random functions at all. Ragequit.
I got input replays working in GMOSSE. Currently you have to have the 'recording' tag in the config ini set to 1 to do a record play and 2 to play back a record but I will implement a proper menu function for it before MK-VI.
The main problem I'm having with it now is that GMOSSE uses random variables everywhere and this is affecting the playback somewhat. Initially it was so bad a stage complete run would be a crap run where you died halfway through the stage when you didn't really or something. I fixed that by adding an extra queue for the current random seed that is used every step which the game uses on playback, but now there's still something a bit off as a run I did where I got 1.3 mil at the end of the stage is played back as a 1.17 mil run or something - it's like I've missed a few enemies in the input replay that I hit to get the difference in score. Furthermore, I did a run of only half of the stage and the scores between recording and replaying were the same so I'm theorising it's something at the later part of the stage. I suspect that what might be happening is that two enemies (asteroids + spinning enemies) are being spawned at the same time on the same frame and the queue is only taking one of these resulting in placements of the enemies being different. Ideally the best solution for this would be to either sync the spawning of the asteroids so that they don't spawn at the same frame as the other enemies or just remove randomisation of it entirely and hardcode a huge amount of different spawning x variables for the lot which will be a pain.
More to come when I investigate, for now more testing and an English essay.
EDIT: Tried runs with Arxtyan and Swordifsh and comparing screenshots of the score to the input runs they dont seem to be any different from eachother. Invader, Busterhawk and Xonochrome on the other hand go way off. I would think that my theory stands for Xonochrome and Busterhawk but I have no fucking clue why the Invader would cause anything to screw up in terms of the random seed changing twice per frame as it uses no random functions at all. Ragequit.
-
BPzeBanshee
- Posts: 4859
- Joined: Sun Feb 08, 2009 3:59 am
Re: G.M.O.S.S.E - MK-V (15/08/2011) New stage, and more!
Another update:
All randomisation in bullet patterns, player weapons and enemy placement have been removed, the scr_inputs() call was changed from Begin Step to Step and now all the ships appear to work fine for input replay files except for Arxtyan who due to random variables in lock shots and something else I can't put my finger on has started behaving erraticly when runs using it are recorded for input. I would've thought removing random variables would've solved it but something else is throwing it off. Sometimes I get accurate plays with it if I don't play for long and when I do fullrun stages I either get a different score when playing back or it just dies and game overs way before it should. Yet another headache for me to solve.
Also, I probably asked about this before but it's 10 PM here and I can't recall doing such - anyone got a good idea of how to get wobble scrolling to happen that still works when TATEd? I'd like to get a stage using wobble scrolling for next release working but the current method I have (and frankly I must admit I MacGuyvered it in from another guy's project without permission to try so I wont use it) just isn't working for me.
On the bright side though, the game's a lot more easier to play for score compared to how it used to be, and a bit more predictable. On a good day I can get past 2 million points when I clear the stage.
All randomisation in bullet patterns, player weapons and enemy placement have been removed, the scr_inputs() call was changed from Begin Step to Step and now all the ships appear to work fine for input replay files except for Arxtyan who due to random variables in lock shots and something else I can't put my finger on has started behaving erraticly when runs using it are recorded for input. I would've thought removing random variables would've solved it but something else is throwing it off. Sometimes I get accurate plays with it if I don't play for long and when I do fullrun stages I either get a different score when playing back or it just dies and game overs way before it should. Yet another headache for me to solve.
Also, I probably asked about this before but it's 10 PM here and I can't recall doing such - anyone got a good idea of how to get wobble scrolling to happen that still works when TATEd? I'd like to get a stage using wobble scrolling for next release working but the current method I have (and frankly I must admit I MacGuyvered it in from another guy's project without permission to try so I wont use it) just isn't working for me.
On the bright side though, the game's a lot more easier to play for score compared to how it used to be, and a bit more predictable. On a good day I can get past 2 million points when I clear the stage.
-
BPzeBanshee
- Posts: 4859
- Joined: Sun Feb 08, 2009 3:59 am
Re: G.M.O.S.S.E - MK-V (15/08/2011) New stage, and more!
I'm still having problems with Arxtyan and I'm about this close to just ragequitting outright and breaking my keyboard even further than what I have but despite completely redesigning it and leaving not a single line of code untouched it still does not behave properly when playing back from an input file. There's anything from 150 to OVER 9000 difference in score when I do a stage clear.
S20-TBL's been sending me some real cool stuff though which has been implemented, if I can get Arxtyan working properly with inputs while reflecting some of the additions I'll make a video to demonstrate.
By the way, Arxtyan's weaponry is a lot less Ketsui and bit more like this at the moment (subject to change).
S20-TBL's been sending me some real cool stuff though which has been implemented, if I can get Arxtyan working properly with inputs while reflecting some of the additions I'll make a video to demonstrate.
By the way, Arxtyan's weaponry is a lot less Ketsui and bit more like this at the moment (subject to change).
-
BPzeBanshee
- Posts: 4859
- Joined: Sun Feb 08, 2009 3:59 am
Re: G.M.O.S.S.E - MK-V (15/08/2011) New stage, and more!
I give up.
Blaspheming God and draining all my blood from my body with cuts in my wrists in a tribute to Satan would not get Arxtyan to behave consistently with input replays.
Summoning the Necrowizard wouldn't do it. I think Stephen Hawking would probably create a black hole that will destroy the planet December 21st next year if he tried to fix this.
That being said, I've done too much to Arxtyan to change it back to its Ketsui form so it's now a [Dodonpachi/Raiden Fighters] hybrid ship.
In the meantime I've experimented with other things, namely a platformer demonstration whose death on collision handling is pretty bad and *3D within Game Maker OMFG* whose collision checking is even worse.![Razz :P](./images/smilies/icon_razz.gif)
Bit off-topic to GMOSSE itself but I'm also in the process of finally uploading V3 of the Thunder Force Music Mod for Xeno Fighters R. I'll make a post in the XF-R thread when I'm done with the upload and the video to go with it.
Blaspheming God and draining all my blood from my body with cuts in my wrists in a tribute to Satan would not get Arxtyan to behave consistently with input replays.
Summoning the Necrowizard wouldn't do it. I think Stephen Hawking would probably create a black hole that will destroy the planet December 21st next year if he tried to fix this.
That being said, I've done too much to Arxtyan to change it back to its Ketsui form so it's now a [Dodonpachi/Raiden Fighters] hybrid ship.
In the meantime I've experimented with other things, namely a platformer demonstration whose death on collision handling is pretty bad and *3D within Game Maker OMFG* whose collision checking is even worse.
![Razz :P](./images/smilies/icon_razz.gif)
Bit off-topic to GMOSSE itself but I'm also in the process of finally uploading V3 of the Thunder Force Music Mod for Xeno Fighters R. I'll make a post in the XF-R thread when I'm done with the upload and the video to go with it.
Re: G.M.O.S.S.E - MK-V (15/08/2011) New stage, and more!
Interesting, d you maybe have a website going with your works? Feel free to spill the info on your new experiments, i like the fact that you're also using GM for other things.BPzeBanshee wrote: In the meantime I've experimented with other things, namely a platformer demonstration whose death on collision handling is pretty bad and *3D within Game Maker OMFG* whose collision checking is even worse.![]()
Hyperspace Invaders II: Pixel Edition - Available on STEAM NOW!
-
BPzeBanshee
- Posts: 4859
- Joined: Sun Feb 08, 2009 3:59 am
Re: G.M.O.S.S.E - MK-V (15/08/2011) New stage, and more!
I don't but I was considering at one point;Atomhead wrote:Interesting, d you maybe have a website going with your works? Feel free to spill the info on your new experiments, i like the fact that you're also using GM for other things.BPzeBanshee wrote: In the meantime I've experimented with other things, namely a platformer demonstration whose death on collision handling is pretty bad and *3D within Game Maker OMFG* whose collision checking is even worse.![]()
A) restyling this thread into a "BP's Projects" thread like Rozyrg does, or
B) creating a new "BP's Projects" thread where I'd pretty much put anything and everything
The problem with that is that this thread has gone on for a while as is and I'd like to keep it that way, and I'm not sure option B would comply with Development-specific rules but if people are interested I'll make one and keep it Development-orientated and see what happens.
In other news, after making a long wall of text on a new guy's thread it occured to me that I haven't been quite consise about what materials I've taken from other games. I said once before I'd come up with a precise list and clearly I've forgotten to do that so I'll come up with what's on top of my head now and add it into the readme accordingly (and credits when I make a proper scrolling credits);
1. Swordfish's sprites are from Gun6 and ZeroFollower0's proposal to add a fifth unique ships into Xeno Fighters R which was never realised, upon given permission I implemented this in MK-IV if memory serves. The sound effects for it are shamefully stolen from Revenge of Shinobi (not that anyone noticed until now, and yes this these will be replaced just as Arxtyan's has been several times).
2. The warp background seen in GMOSSE's main menu is actually a color shift of the sky tunnel background seen in Xeno Fighters R, which in turn I have reason to believe is taken from Strikers 1945 III. It's been altered enough from the original that I don't think it'd really matter to change it but if I find a good alternative method to come up with such effect myself I'll do it [read: low priority].
3. The music is recorded directly from the original Japan release of Gleylancer via Kega Fusion 3.64, and the intro music is altered from its original length. I've mentioned this a few times in the history of this thread but there's next to no evidence of such in the actual engine which I'll fix when I add custom music support (since I'm using GMFMODSimple it'll probably use a similar format to how Alluro's done it for XF-R).
4. There is also an explosion sound in GMOSSE that is directly from Gleylancer as well but I've never used it for anything and will probably remove it in MK-VI.
5. The asteroid graphics are heavily edited versions of the ones seen in Gleylancer's stage 1. I'll probably replace these in the next few releases since basic rocks are pretty easy to make with Universe (what I've used for the planets).
I've not included Invader in that list because the Space Invader sounds along with the Space Invader alien ship featured in GMOSSE is obviously from Space Invaders. I shouldn't need to explain this in more detail, it's obviously stated in the ship selection screen. This is not changing unless I feel GMOSSE gets a bit too full in its ship roster, he's a tribute ship after all. I'll include anything else I actually remember later but generally the list is very small, and that's deliberate, and for good reason.
-
BPzeBanshee
- Posts: 4859
- Joined: Sun Feb 08, 2009 3:59 am
Re: G.M.O.S.S.E - MK-V (15/08/2011) New stage, and more!
TLDR version:
I'm not supporting GM:HTML5, the boss' canister patterns are getting nerfed and the new lock shots implemented for Arxtyan/Xonochrome are getting taken out. What does all this have in common? They're hurting legacy PC performance, breaking Rule #1 of this project.
Detailed version:
Bit of a revelation I just had tonight;
I was looking for some info on Game Maker:HTML5 and came across a pirated copy that I decided to see whether it worked or not. It's a bit unstable but it worked enough for me to test out GMOSSE using the new Game Maker runner that Yoyogames were so happy about.
Not only did the existing font look different (Lucida Sans Unicode looked nothing like Lucida Sans Unicode), but upon testing the bleeding edge latest code it ran worse on the legacy PC than in GM8. Now to be fair I was a pirate in trying this out, but I certainly won't be using this program anytime soon until I hear otherwise. Apparently Rozyrg's buying it for Christmas and hopefully he can compile a Windows build of GMOSSE using an updated legal GM:HTML5 when/if he gets it, and I can run the build on my legacy PC once more to test for performance. Frankly I doubt it.
To be very specific in my testing results I compared running the outputted EXE of GMOSSE compiled in GM:HTML5 against an EXE compiled in GM 8.0 (which I've used since the beginning of this project). You know when a game's running borderline because it's not smooth and shaky but still running at a claimed 60 FPS? That's what the GM:HTML5 EXE was doing all the time, and upon using Xonochrome's new focus shot (which itself is a performance issue so it's getting removed anyway) the game hits ~57 FPS.
Then there's this:
![Image](http://img847.imageshack.us/img847/3568/fuckthisshitn.png)
The boss' canister-of-bullets attack phase bumps the FPS down as low as ~35 FPS when using the focus shot. The GM8 EXE on the other hand ran rock solid up till the canister patterns where it was more like ~42 or so using the focus shot. Shooting nothing at all with the canister attack reduces FPS down to like ~50 which breaks one of my prime directives so the canister attack is getting nerfed anyway. Even with these changes the performance difference between builds is indisputable, so I won't put efforts into GMOSSE to support GM:HTML5 specifically unless there's some serious optimisation done on GM's end.
Notice I wasn't very precise about Xonochrome's focus shot? Well Arxtyan's new focus shot is a direct code transfer from this submission I got earlier last month which changed Xonochrome's focus shot first, I'll explain more in time but since its creator and I have both discovered performance issues with the function I'm taking it out but will keep the source code separate from GMOSSE itself for future reference.
I'm not supporting GM:HTML5, the boss' canister patterns are getting nerfed and the new lock shots implemented for Arxtyan/Xonochrome are getting taken out. What does all this have in common? They're hurting legacy PC performance, breaking Rule #1 of this project.
Detailed version:
Bit of a revelation I just had tonight;
I was looking for some info on Game Maker:HTML5 and came across a pirated copy that I decided to see whether it worked or not. It's a bit unstable but it worked enough for me to test out GMOSSE using the new Game Maker runner that Yoyogames were so happy about.
Not only did the existing font look different (Lucida Sans Unicode looked nothing like Lucida Sans Unicode), but upon testing the bleeding edge latest code it ran worse on the legacy PC than in GM8. Now to be fair I was a pirate in trying this out, but I certainly won't be using this program anytime soon until I hear otherwise. Apparently Rozyrg's buying it for Christmas and hopefully he can compile a Windows build of GMOSSE using an updated legal GM:HTML5 when/if he gets it, and I can run the build on my legacy PC once more to test for performance. Frankly I doubt it.
To be very specific in my testing results I compared running the outputted EXE of GMOSSE compiled in GM:HTML5 against an EXE compiled in GM 8.0 (which I've used since the beginning of this project). You know when a game's running borderline because it's not smooth and shaky but still running at a claimed 60 FPS? That's what the GM:HTML5 EXE was doing all the time, and upon using Xonochrome's new focus shot (which itself is a performance issue so it's getting removed anyway) the game hits ~57 FPS.
Then there's this:
![Image](http://img847.imageshack.us/img847/3568/fuckthisshitn.png)
The boss' canister-of-bullets attack phase bumps the FPS down as low as ~35 FPS when using the focus shot. The GM8 EXE on the other hand ran rock solid up till the canister patterns where it was more like ~42 or so using the focus shot. Shooting nothing at all with the canister attack reduces FPS down to like ~50 which breaks one of my prime directives so the canister attack is getting nerfed anyway. Even with these changes the performance difference between builds is indisputable, so I won't put efforts into GMOSSE to support GM:HTML5 specifically unless there's some serious optimisation done on GM's end.
Notice I wasn't very precise about Xonochrome's focus shot? Well Arxtyan's new focus shot is a direct code transfer from this submission I got earlier last month which changed Xonochrome's focus shot first, I'll explain more in time but since its creator and I have both discovered performance issues with the function I'm taking it out but will keep the source code separate from GMOSSE itself for future reference.
Re: G.M.O.S.S.E - MK-V (15/08/2011) New stage, and more!
I'm honestly not surprised that's the case, if for no other reason than that, under intended circumstances, you'd be running the game on top of and within a web browser. Ok, maybe not necessarily when you're doing test runs; but it's still something to take into account. Just having a browser open on my netbook will cause a hit in performance for pretty much anything GM-made.
Whenever I get my copy, I'm starting fresh and with something as simple as possible. Already cooking up some gfx for it, too...
I'll be happy to give GMOSSE a try with it and see what happens, though.
...although I'll probably be leaning more towards the results my (negligibly faster) Vista desktop gives given the whole browser thing.
Whenever I get my copy, I'm starting fresh and with something as simple as possible. Already cooking up some gfx for it, too...
I'll be happy to give GMOSSE a try with it and see what happens, though.
![Smile :)](./images/smilies/icon_smile.gif)
-
BPzeBanshee
- Posts: 4859
- Joined: Sun Feb 08, 2009 3:59 am
Re: G.M.O.S.S.E - MK-V (15/08/2011) New stage, and more!
Actually none of those tests were running in a browser. You see, GM:HTML5 actually exports both Windows and HTML5 - the latter seemed to crash on my machine, probably due to me being a pirate and trying-before-I-buy, but it exports to Windows just like GM8 does with the exception of the GMX file format saving and the aforementioned issues.
As for HTML5 performance, try this - http://www.kevs3d.co.uk/dev/asteroidsbench/
Google Chrome is by far the best browser for running anything HTML5-related so use that when you start developing, but you can use that benchmarker test to get some figures for how well your machine/browser runs HTML5 apps (I got a Benchmark Score of 2021 and Average FPS of 43 for comparison). And I'm not saying it because I'm a Google Chrome fanboy - I looked this stuff up earlier when GM:HTML5 was first announced and the difference between Chrome and the rest was staggering.
EDIT:
Why didn't I think of this before. Instead of drawing the lines on the screen by code for scanlines, why don't I just make an image that overlays the screen and does the exact same thing? DUHHHHHHHHHH
Of course I'll keep the old code commented out but expect this method to be applied for scanlines in next release, which will result in improved performance when using scanlines (currently vertical scanlines kills GMOSSE's framerate but horizontal doesn't as much for some reason - having a simple 320x320 image rotated for scanlines will reduce CPU usage significantly). Why did I click to this just now? Well I was looking at Odd Mobs Arrange Zero's menu and that's exactly how Gustav does it, except he's got a bit more happening in the image than just lines. I might ask him for usage of that picture because it looks a lot more convincing than simple lines.
As for HTML5 performance, try this - http://www.kevs3d.co.uk/dev/asteroidsbench/
Google Chrome is by far the best browser for running anything HTML5-related so use that when you start developing, but you can use that benchmarker test to get some figures for how well your machine/browser runs HTML5 apps (I got a Benchmark Score of 2021 and Average FPS of 43 for comparison). And I'm not saying it because I'm a Google Chrome fanboy - I looked this stuff up earlier when GM:HTML5 was first announced and the difference between Chrome and the rest was staggering.
EDIT:
Why didn't I think of this before. Instead of drawing the lines on the screen by code for scanlines, why don't I just make an image that overlays the screen and does the exact same thing? DUHHHHHHHHHH
Of course I'll keep the old code commented out but expect this method to be applied for scanlines in next release, which will result in improved performance when using scanlines (currently vertical scanlines kills GMOSSE's framerate but horizontal doesn't as much for some reason - having a simple 320x320 image rotated for scanlines will reduce CPU usage significantly). Why did I click to this just now? Well I was looking at Odd Mobs Arrange Zero's menu and that's exactly how Gustav does it, except he's got a bit more happening in the image than just lines. I might ask him for usage of that picture because it looks a lot more convincing than simple lines.
-
BPzeBanshee
- Posts: 4859
- Joined: Sun Feb 08, 2009 3:59 am
Re: G.M.O.S.S.E - MK-V (15/08/2011) New stage, and more!
![Image](http://img402.imageshack.us/img402/599/screenshot100f.png)
New image-based scanlines, with next to no performance hit especially compared to Game Maker itself drawing lines. This screenshot was taken on the legacy PC, which ran the game with vertical scanlines at full speed compared to ~40 FPS before with code-drawn lines.
In addition, I nerfed the final boss pattern and also the purple bullet explosion the second orb emits when on low health.
Finally, I reverted Arxtyan to it's MK-V form with the exception of some minor changes in code (image_angle = direction wasn't working for the first frame even though the code was exactly the same as it was in MK-V, but putting that after direction = whatever fixed it). Adding recording and forcing of the random seed did not fix input replays for Arxtyan unfortunately, so I totally give up on that.
-
BPzeBanshee
- Posts: 4859
- Joined: Sun Feb 08, 2009 3:59 am
Re: G.M.O.S.S.E - MK-V (15/08/2011) New stage, and more!
Not much to show in screenshots, but I just got wobble scrolling working and using less lines of code than pretty much everything else I've seen in this forum while behaving near exactly like how Alluro's wobble scrolling (and indeed Cave and Raiden Fighters games) works. Furthermore, it works when rotated which other methods I've seen (including Xeno Fighters') do not.
Two lines of code which I can remember off the top of my head and if you so wanted could probably be further cut down to 1 line:
How did I come up with 4 you ask? Well actually at first I got it by guess, but think of it like this: The room's width that I tested with (when using wobble scrolling) is 320 pixels and the view's width (at all times in GMOSSE) is 240 pixels.
320 / 240 = 80, which is the range in pixels that the view can move around to cover the screen according to player position. So the difference between the view being as far left as it can be on the screen, and as far right as it can be on the screen, is 80 pixels. So the actual object that controls the view in wobble scrolling is only ever going to be in 80 different spots.
But it has to keep an eye on the player at all times, and then there's the manner of if the wobble's too fast it can make some people sick (apparently anyway, I never had issues with original Raiden). Now the player ship itself can only be within the x-range of 320 pixels anyway, so if you divide the player's maximum x-range (in this case it's also the room width) by the range in pixels that the actual view can move around you get 4. Thus, setting the view controller's x position to whatever the player's position is divided by 4 gives you a number within 80.
Why is the '- global.x_offset' there? Well for those who aren't familiar with it already, the method of screen rotation (TATE) that I got to work properly results in an offset of 40 pixels due to the view dimensions and the altering of them to rotate the view of the room while still fitting the actual room in the screen (using view_angle[0]=whatever by itself will leave parts of the room outside the visible view). Unlike Shining Armour which is a standard 4:3 resolution game where flipping will fit the 3:4 gameplay screen in the window perfectly I have to adjust the various view variables which technically does a bit of squishing and stretching, thus the distortion. This also means that for the view_xview[0] variable the actual range in going from left of the room to the right of the room is no longer 0 to 80 but -40 to 40, which is why the offset is there - if the player ship was as far left as it'd go without technically going outside the room and I didn't account for the offset then when I rotate the screen the actual view would be misplaced, especially if the controller object was at something like x = 80 (as far as it'd go on yoko, global.x_offset is set to 0 when on yoko) and then rotated (x_offset is set to -40, so as far right as it'd go on yoko - 40 = actual end of the room).
Another note: if you're using a different resolution other than 240x320 (which is what I use) then obviously you'll need to figure out what to divide the player's position with by yourself, which is a simple equation of room_width (or room_height or whatever your upper limit of the screen is if you're making a horizontal shmup) divided by the view width/height to get the difference between the view and the room size, and then dividing that answer by the maxmimum view width/height again. At least that's how I make sense of it, I haven't tried anything besides 4 yet.
Sorry if that sounds like a Charlie Sheen rant, by the way. My mind indeed fires in ways that are not from this particular terrestrial realm.![Very Happy :D](./images/smilies/icon_biggrin.gif)
Will probably edit later instead of quadruple posting too.
EDIT: Forgot to mention that I changed the sprites of the asteroids from their Gleylancer incarnates to this:
![Image](http://img713.imageshack.us/img713/1034/screenshot100ys.png)
Honestly if you can't tell the difference between purple and orange after that you should get your eyes checked. That being said if you have suggestion do let me know.
I also finally fixed the hitbox not staying within the view, it's now always 2 pixels off from the view border (ie. for stage 1 its x is between 2 and 238 inclusive). I might change this to 1 in the future because I don't like seeing gaps but consider this fixed. I had one person on an earlier build (like MK-II) of GMOSSE claim he was somehow rendered invincible because he managed to get the hitbox outside the room even though I couldn't replicate it, but this should definitely fix it.
EDIT2: Stage 1 now uses wobble scrolling. The jumping jack enemies spawn relative to your view position to [piss you off/not break the 3D look that happens when they spawn from the other side of the room and jump in at a fast speed] but pretty much everything else now uses absolute variables using global.x_offset and global.y_offset to account for any possible displacement in screen rotation. It's pretty amazing but I gotta test it out on my legacy PC before I call it official to be sure that wobble scrolling doesn't kill it too (I don't see why it would, but I'm a paranoid prick and I like to check everything against the target machine to be sure).
I'm hoping to get MK-VI out for a Christmas release featuring sound volume control among various other fixes and additions but don't hold me to it. It's the 22nd here and I'm not sure I want to release this before doing Stage 2 (or something significant).
EDIT3: I raged hard when trying to play with Invader - popcorn enemies were its complete utter doom. So I added a focus shot that has a fast firerate, approximately the same attack power as one of the Invader's standard bullets, and approximately the same width, with the result being a ship that's actually competent at shooting the popcorn enemies if used correctly. It basically works something like the wide line shot in Infinity Gene.
I also redid the options menu and the config file handling, now instead of one [General] tag you've got four tags which contain all of the relevant variables, and all of them are now configurable in the Options Menu in separate sections. This means that input replay control is slightly easier to go and change when you restart and debug mode is able to be switched off from in-game as well. There is now also volume control, so you can change the volume of all sound effects, background music and voices, but hopefully you shouldn't need to change them as I've now gone through a bunch of them and turned them down where necessary - emphatic complained about the explosions so they're reduced along with the overlapping enemy shot sounds, and nearly every ship has had its sounds reduced in some way as well as the voices are now more louder because I couldn't hear them clearly over the existing sounds before.
Oh, and I haven't tested Invader with input replays using its new weapon behaviour either, nor have I tested the use of wobble scrolling on the legacy PC - I hope I didn't break it somehow.
Two lines of code which I can remember off the top of my head and if you so wanted could probably be further cut down to 1 line:
Code: Select all
// Begin step
x = (obj_playerhitbox.x/4)-global.x_offset;
// End step
view_xview[0] = x;
320 / 240 = 80, which is the range in pixels that the view can move around to cover the screen according to player position. So the difference between the view being as far left as it can be on the screen, and as far right as it can be on the screen, is 80 pixels. So the actual object that controls the view in wobble scrolling is only ever going to be in 80 different spots.
But it has to keep an eye on the player at all times, and then there's the manner of if the wobble's too fast it can make some people sick (apparently anyway, I never had issues with original Raiden). Now the player ship itself can only be within the x-range of 320 pixels anyway, so if you divide the player's maximum x-range (in this case it's also the room width) by the range in pixels that the actual view can move around you get 4. Thus, setting the view controller's x position to whatever the player's position is divided by 4 gives you a number within 80.
Why is the '- global.x_offset' there? Well for those who aren't familiar with it already, the method of screen rotation (TATE) that I got to work properly results in an offset of 40 pixels due to the view dimensions and the altering of them to rotate the view of the room while still fitting the actual room in the screen (using view_angle[0]=whatever by itself will leave parts of the room outside the visible view). Unlike Shining Armour which is a standard 4:3 resolution game where flipping will fit the 3:4 gameplay screen in the window perfectly I have to adjust the various view variables which technically does a bit of squishing and stretching, thus the distortion. This also means that for the view_xview[0] variable the actual range in going from left of the room to the right of the room is no longer 0 to 80 but -40 to 40, which is why the offset is there - if the player ship was as far left as it'd go without technically going outside the room and I didn't account for the offset then when I rotate the screen the actual view would be misplaced, especially if the controller object was at something like x = 80 (as far as it'd go on yoko, global.x_offset is set to 0 when on yoko) and then rotated (x_offset is set to -40, so as far right as it'd go on yoko - 40 = actual end of the room).
Another note: if you're using a different resolution other than 240x320 (which is what I use) then obviously you'll need to figure out what to divide the player's position with by yourself, which is a simple equation of room_width (or room_height or whatever your upper limit of the screen is if you're making a horizontal shmup) divided by the view width/height to get the difference between the view and the room size, and then dividing that answer by the maxmimum view width/height again. At least that's how I make sense of it, I haven't tried anything besides 4 yet.
Sorry if that sounds like a Charlie Sheen rant, by the way. My mind indeed fires in ways that are not from this particular terrestrial realm.
![Very Happy :D](./images/smilies/icon_biggrin.gif)
Will probably edit later instead of quadruple posting too.
EDIT: Forgot to mention that I changed the sprites of the asteroids from their Gleylancer incarnates to this:
![Image](http://img713.imageshack.us/img713/1034/screenshot100ys.png)
Honestly if you can't tell the difference between purple and orange after that you should get your eyes checked. That being said if you have suggestion do let me know.
I also finally fixed the hitbox not staying within the view, it's now always 2 pixels off from the view border (ie. for stage 1 its x is between 2 and 238 inclusive). I might change this to 1 in the future because I don't like seeing gaps but consider this fixed. I had one person on an earlier build (like MK-II) of GMOSSE claim he was somehow rendered invincible because he managed to get the hitbox outside the room even though I couldn't replicate it, but this should definitely fix it.
EDIT2: Stage 1 now uses wobble scrolling. The jumping jack enemies spawn relative to your view position to [piss you off/not break the 3D look that happens when they spawn from the other side of the room and jump in at a fast speed] but pretty much everything else now uses absolute variables using global.x_offset and global.y_offset to account for any possible displacement in screen rotation. It's pretty amazing but I gotta test it out on my legacy PC before I call it official to be sure that wobble scrolling doesn't kill it too (I don't see why it would, but I'm a paranoid prick and I like to check everything against the target machine to be sure).
I'm hoping to get MK-VI out for a Christmas release featuring sound volume control among various other fixes and additions but don't hold me to it. It's the 22nd here and I'm not sure I want to release this before doing Stage 2 (or something significant).
EDIT3: I raged hard when trying to play with Invader - popcorn enemies were its complete utter doom. So I added a focus shot that has a fast firerate, approximately the same attack power as one of the Invader's standard bullets, and approximately the same width, with the result being a ship that's actually competent at shooting the popcorn enemies if used correctly. It basically works something like the wide line shot in Infinity Gene.
I also redid the options menu and the config file handling, now instead of one [General] tag you've got four tags which contain all of the relevant variables, and all of them are now configurable in the Options Menu in separate sections. This means that input replay control is slightly easier to go and change when you restart and debug mode is able to be switched off from in-game as well. There is now also volume control, so you can change the volume of all sound effects, background music and voices, but hopefully you shouldn't need to change them as I've now gone through a bunch of them and turned them down where necessary - emphatic complained about the explosions so they're reduced along with the overlapping enemy shot sounds, and nearly every ship has had its sounds reduced in some way as well as the voices are now more louder because I couldn't hear them clearly over the existing sounds before.
Oh, and I haven't tested Invader with input replays using its new weapon behaviour either, nor have I tested the use of wobble scrolling on the legacy PC - I hope I didn't break it somehow.
-
BPzeBanshee
- Posts: 4859
- Joined: Sun Feb 08, 2009 3:59 am
Re: G.M.O.S.S.E - MK-V (15/08/2011) New stage, and more!
Good news: sound effect, music and voice volume control is now implemented. In addition, the options menu has been revamped and (along with some modifications to the pause menu and such) you can now enable/disable debug mode along with setting the switch for input replaying/recording/actingnormally. The scrolling code has been reduced to one line with a few extra additional lines to account for it gradually moving towards the center of the room if the player ship dies. I'm considering removing it though in favour of the obj_lifecontroller (where the player spawns) being set to the center of the current view regardless of its position instead, like how it is in XOP - I don't want to lock myself out of the possibility of alternate stage progression depending on what side of the screen you're on at one point, and having the view getting moved to the center of the room when you die during that is going to be problematic.
Bad news: Swordfish and Arxtyan both are now having issues with behaving reliably when playing back from an input file. I didn't notice Swordfish having the issue before till now. This means that out of the 5 available ships only 3 actually behave properly. The one thing I noticed in common between these two ships is the altering of its image when moving left/right - Arxtyan's image_angle is altered while Swordfish's current sprite index is changed according to which animation frame is required. One could deduce this is the source of the problem, but I commented out the code for both and while I can't say for Arxtyan since I reverted it to its MK-V form (with random variables in key parts of its lock shot) Swordfish behaved no differently. If anyone thinks they might be able to help me out with this let me know.
Bad news: Swordfish and Arxtyan both are now having issues with behaving reliably when playing back from an input file. I didn't notice Swordfish having the issue before till now. This means that out of the 5 available ships only 3 actually behave properly. The one thing I noticed in common between these two ships is the altering of its image when moving left/right - Arxtyan's image_angle is altered while Swordfish's current sprite index is changed according to which animation frame is required. One could deduce this is the source of the problem, but I commented out the code for both and while I can't say for Arxtyan since I reverted it to its MK-V form (with random variables in key parts of its lock shot) Swordfish behaved no differently. If anyone thinks they might be able to help me out with this let me know.
-
BPzeBanshee
- Posts: 4859
- Joined: Sun Feb 08, 2009 3:59 am
Re: G.M.O.S.S.E - MK-VI (1/01/2012) Input Replays, new fonts etc
GMOSSE MK-VI is out! See original post for download links and such!
Vid and download links: http://www.youtube.com/watch?v=003l7QThOfw
Sorry for seeming rushed.
http://www.mediafire.com/?ezp6nwgehpecru3 - avatar images for anyone who cares. Goes right from original size up to 4x (around 128x128).
Vid and download links: http://www.youtube.com/watch?v=003l7QThOfw
Sorry for seeming rushed.
http://www.mediafire.com/?ezp6nwgehpecru3 - avatar images for anyone who cares. Goes right from original size up to 4x (around 128x128).
Re: G.M.O.S.S.E - MK-VI (1/01/2012) Input Replays, new fonts etc
Hi BPzeBanshee, I´m a completely newbie when it comes to game programming (I´ve used to mess around with QBasic when I was a small kid and did a little proto-shmup in some old version of Game Maker about 5 years ago), so excuse the question - what exactly does GMOSSE do? Is it some kind of template that you can use to build your own shmup on?
Here´s what I wanna do:
- Create my own sprites, bullet designs, bullet patterns and bosses
- Create multi-sprite-segment bosses, in the vein of Garegga and Batrider bosses
...and just basically dump that into a template and keep working from there. I basically just want to experiment with my own bullet patterns, boss design and fiddle with some pixel art
I´m on a Mac now but I´ve been considering to put Windows via Bootcamp on here as well so that I can retire my old huge PC that currently runs shmupmame etc. I´ve read that Game Maker also has a Mac version, it lacks a few features but since this will likely be more of a little hobby on the side I´d rather not have to boot into Windows all the time. So I´m a bit torn - is there some big deciding factor between these two OS versions that I should keep in mind?
It looks like GM has made a lot of improvements in the last few years, the stuff in your video looks very smooth and, well, arcadey
Oh, and easy is it to compose these multi-segment animations in GM (say, have a mechanical arm made of several pieces reach out)? I don´t really have a lot of spare time at the moment, but recently I´ve been really itching to do some little game design stuff just for the pure fun of it. In any case, congrats on your work so far, looks very impressive![Cool 8)](./images/smilies/icon_cool.gif)
Here´s what I wanna do:
- Create my own sprites, bullet designs, bullet patterns and bosses
- Create multi-sprite-segment bosses, in the vein of Garegga and Batrider bosses
...and just basically dump that into a template and keep working from there. I basically just want to experiment with my own bullet patterns, boss design and fiddle with some pixel art
![Smile :)](./images/smilies/icon_smile.gif)
I´m on a Mac now but I´ve been considering to put Windows via Bootcamp on here as well so that I can retire my old huge PC that currently runs shmupmame etc. I´ve read that Game Maker also has a Mac version, it lacks a few features but since this will likely be more of a little hobby on the side I´d rather not have to boot into Windows all the time. So I´m a bit torn - is there some big deciding factor between these two OS versions that I should keep in mind?
It looks like GM has made a lot of improvements in the last few years, the stuff in your video looks very smooth and, well, arcadey
![Mr. Green :mrgreen:](./images/smilies/icon_mrgreen.gif)
Oh, and easy is it to compose these multi-segment animations in GM (say, have a mechanical arm made of several pieces reach out)? I don´t really have a lot of spare time at the moment, but recently I´ve been really itching to do some little game design stuff just for the pure fun of it. In any case, congrats on your work so far, looks very impressive
![Cool 8)](./images/smilies/icon_cool.gif)
THE BULLETS ARE NOW DIAMONDS!
-
BPzeBanshee
- Posts: 4859
- Joined: Sun Feb 08, 2009 3:59 am
Re: G.M.O.S.S.E - MK-VI (1/01/2012) Input Replays, new fonts etc
Hi there!Hi BPzeBanshee, I´m a completely newbie when it comes to game programming (I´ve used to mess around with QBasic when I was a small kid and did a little proto-shmup in some old version of Game Maker about 5 years ago), so excuse the question - what exactly does GMOSSE do? Is it some kind of template that you can use to build your own shmup on?
You're actually not the first person to ask this - I think the way I've approached describing this can be a bit confusing, but you have indeed nailed it right on the mark. GMOSSE serves as a template - clueless with making advanced shmups in Game Maker? This will give you a good idea of how it can be done. Maybe you're making a Gradius game but have no clue how to make those trailing options? GMOSSE has code to show how that can be done. It's not a MUGEN or Dezeamon but you can certainly make your own game out of using it as a shell if you so wish.
For what you want to do it's definitely not only possible, but relatively easy to do considering how Game Maker handles sprites and such, especially now in GM8. Multi-sprite-segment bosses are possible too (I've seen it done and I believe Rozyrg has bosses like that in some of his games) but I currently have no working examples of such unfortunately (the platform-like enemies dont really count methinks, but that's the basic idea for how you'd start coding such) - that'll definitely be an issue to tackle in future releases. I think that'll probably be your biggest challenge should you start.
Definitely get a Bootcamp Windows setup going if possible. I've done it with the family Mac and haven't looked back since. I'd recommend keeping the old PC for testing purposes though but then I'm a little bit of a hoarder - you could check your game's performance by running it under both machines for example so it still gets some use.I´m on a Mac now but I´ve been considering to put Windows via Bootcamp on here as well so that I can retire my old huge PC that currently runs shmupmame etc. I´ve read that Game Maker also has a Mac version, it lacks a few features but since this will likely be more of a little hobby on the side I´d rather not have to boot into Windows all the time. So I´m a bit torn - is there some big deciding factor between these two OS versions that I should keep in mind?
It looks like GM has made a lot of improvements in the last few years, the stuff in your video looks very smooth and, well, arcadey
For the GM4Mac vs standard GM though, I know of no one who has GM4Mac here so if you got it I'd probably be getting as much help from you as I'd be giving.
![Razz :P](./images/smilies/icon_razz.gif)
Thanks! A lot of people have helped in giving it the arcade look - the explosions are S20-TBL's work (if you haven't seen it already check out Papilio which is brilliant) and so are most of the bullet patterns/scripts, while the newly implemented arcade fonts are Emerald Master's art, and the uncanny performance a combination of CleanMem and my OCD for performance and simplistic code vs prettiness and complex junk like surfaces. I think you'll have a lot of fun mucking around with this for a game project and I'm certainly willing to help if you have any issues.It looks like GM has made a lot of improvements in the last few years, the stuff in your video looks very smooth and, well, arcadey
Oh, and easy is it to compose these multi-segment animations in GM (say, have a mechanical arm made of several pieces reach out)? I don´t really have a lot of spare time at the moment, but recently I´ve been really itching to do some little game design stuff just for the pure fun of it. In any case, congrats on your work so far, looks very impressive
Re: G.M.O.S.S.E - MK-VI (1/01/2012) Input Replays, new fonts etc
Thanks for the detailed answers. Once I have some more free time again I will get Bootcamp ready and buy a copy of GM8 and start messing around with GMOSSE ![Very Happy :D](./images/smilies/icon_biggrin.gif)
![Very Happy :D](./images/smilies/icon_biggrin.gif)
THE BULLETS ARE NOW DIAMONDS!
-
BPzeBanshee
- Posts: 4859
- Joined: Sun Feb 08, 2009 3:59 am
Re: G.M.O.S.S.E - MK-VI (1/01/2012) Input Replays, new fonts etc
Great stuff!
In the meantime, I mucked around with some of the 3D stuff and I managed to get visual effects similar to Gekrindan's weird scrolling tube thing using 3D on a 2D plane. Wasn't terribly easy to do, in fact the most hardest and annoying thing was to just get the damn star background looping.
Download GMK and EXE here - http://www.mediafire.com/?ppvkmqxdhylg64p
I realise now it's not Mode 7 but that's what I was originally trying to come up with when I came up with this instead. Similar concept though. And no, this isn't going into GMOSSE, I'm pretty sure the legacy PC will cark it if I tried. Actually I'll try the test out right now as I have to get off due to storms anyway.
EDIT: Not happy. It ran 60 FPS once it started.......the actual 'infinitely spinning container' had empty space where there was meant to be some of the transparent blue, and the actual cylinders weren't correctly seamless so there were huge gaps between each one that spawned, same goes with the background. In fact I swear the background behaves differently on each computer I've tried it on.
3D in Game Maker sucks, I'm going back to 2D experiments.![Sad :(](./images/smilies/icon_sad.gif)
In the meantime, I mucked around with some of the 3D stuff and I managed to get visual effects similar to Gekrindan's weird scrolling tube thing using 3D on a 2D plane. Wasn't terribly easy to do, in fact the most hardest and annoying thing was to just get the damn star background looping.
Download GMK and EXE here - http://www.mediafire.com/?ppvkmqxdhylg64p
I realise now it's not Mode 7 but that's what I was originally trying to come up with when I came up with this instead. Similar concept though. And no, this isn't going into GMOSSE, I'm pretty sure the legacy PC will cark it if I tried. Actually I'll try the test out right now as I have to get off due to storms anyway.
EDIT: Not happy. It ran 60 FPS once it started.......the actual 'infinitely spinning container' had empty space where there was meant to be some of the transparent blue, and the actual cylinders weren't correctly seamless so there were huge gaps between each one that spawned, same goes with the background. In fact I swear the background behaves differently on each computer I've tried it on.
3D in Game Maker sucks, I'm going back to 2D experiments.
![Sad :(](./images/smilies/icon_sad.gif)
-
- Posts: 1
- Joined: Tue Jan 24, 2012 8:36 am
Re: G.M.O.S.S.E - MK-VI (1/01/2012) Input Replays, new fonts etc
Yo just was googling my name and what do i find. my ship sprites. glad to see its working for you. the Ship is Spike's Ship from Cowboy Bebop. Just wanted to Thank you for using it. Hope your SHMUP gets alot of fame when its done.
-
BPzeBanshee
- Posts: 4859
- Joined: Sun Feb 08, 2009 3:59 am
Re: G.M.O.S.S.E - MK-VI (1/01/2012) Input Replays, new fonts etc
Thanks for the support! I believe you or someone else informed me that it was from Cowboy Bebop, but not having seen the shows myself I knew not much else.Zerofollower0 wrote:Yo just was googling my name and what do i find. my ship sprites. glad to see its working for you. the Ship is Spike's Ship from Cowboy Bebop. Just wanted to Thank you for using it. Hope your SHMUP gets alot of fame when its done.
-
BPzeBanshee
- Posts: 4859
- Joined: Sun Feb 08, 2009 3:59 am
Re: G.M.O.S.S.E - MK-VI (1/01/2012) Input Replays, new fonts etc
All may seem quiet, but I'm not dead yet! However I will be back at school tomorrow so chances are things are going to be slow/dead for quite a while especially considering it's my last year.
Here's a vid highlighting the most obvious bits of what I've done so far!![Very Happy :D](./images/smilies/icon_biggrin.gif)
The current changelog that I've typed down so far:
A small note about the walls: at the moment they just block the player but that has weird sideeffects as I couldn't get it to work quite like how Deathsmiles does player-wall collision handling, so I think I'll stick with convention and make it so that hitting the wall kills you.
Speaking of stage 2, have a look at this:
![Image](http://img840.imageshack.us/img840/696/gmossestage2.png)
As you can see, the walls are being implemented there. There is a symmetrical constant column on the left side of the screen as well. You can also see the new health and bomb sprites as made by Kaiser and slightly edited by me. Just as Stage 1 was heavily based on a stage from Gleylancer, this stage will too - specifically Stage 4 which features a midboss of sorts and various placements of walls to provide somewhat of a navigational challenge. Now Busterhawk's Bound Shot is actually useful too, for as soon as I put in the walls I made sure the Bound Shot reflected off said walls instead of treating it as another enemy and destroying itself.
By the way, there's no enemies yet, but the plan is to follow pretty close to how Gleylancer did it since I see nothing immediately wrong with the design. Code-wise the actual stage will be done a bit differently from Stage 1, as I'll have to adjust the speeds of the walls and the backgrounds on-the-fly to give the illusion of speed increase as well. The boss will also be something similar to the version in Gleylancer, but ONLY popping up walls and shooting stupid ball things is kinda lame so I plan on making the ball things quite evil, possibly using some of S20-TBL's radical custom bullet types that he implemented, and maybe that obj_boss2 script I've had as a experiment test for the last two releases.
Here's a vid highlighting the most obvious bits of what I've done so far!
![Very Happy :D](./images/smilies/icon_biggrin.gif)
The current changelog that I've typed down so far:
Code: Select all
* All of the enemy sprites have been redone by Kaiser.
* Pre-made death images for enemy sprites removed, and all old sprites removed. Noticable filesize decrease.
* Boss death is redone - it flashes above and below its explosions and drops to the bottom of the screen.
* Fixed a bug in the transition handler where it did not draw across the correct section of the screen for the first frame in wobblescrolling rooms.
* Begun work on Stage 2 - in addition, Stage 1 now transitions to Stage 2 after completion.
* obj_lifecontroller and obj_scorecontroller have been modified to become persistent objects which are deleted when not in the required rooms. This fixes the score/lives/bombs getting reset between rooms.
* Asteroid sprites have been modified to look less round. Background asteroids now use image_xscale = choose(-1,1) etc to appear more random, while attacking asteroids do not (random variables).
* Walls objects are now in GMOSSE. They're basically enemies but in a separate category and the child wall objects set their health to 999 every step so you can't kill them.
Speaking of stage 2, have a look at this:
![Image](http://img840.imageshack.us/img840/696/gmossestage2.png)
As you can see, the walls are being implemented there. There is a symmetrical constant column on the left side of the screen as well. You can also see the new health and bomb sprites as made by Kaiser and slightly edited by me. Just as Stage 1 was heavily based on a stage from Gleylancer, this stage will too - specifically Stage 4 which features a midboss of sorts and various placements of walls to provide somewhat of a navigational challenge. Now Busterhawk's Bound Shot is actually useful too, for as soon as I put in the walls I made sure the Bound Shot reflected off said walls instead of treating it as another enemy and destroying itself.
By the way, there's no enemies yet, but the plan is to follow pretty close to how Gleylancer did it since I see nothing immediately wrong with the design. Code-wise the actual stage will be done a bit differently from Stage 1, as I'll have to adjust the speeds of the walls and the backgrounds on-the-fly to give the illusion of speed increase as well. The boss will also be something similar to the version in Gleylancer, but ONLY popping up walls and shooting stupid ball things is kinda lame so I plan on making the ball things quite evil, possibly using some of S20-TBL's radical custom bullet types that he implemented, and maybe that obj_boss2 script I've had as a experiment test for the last two releases.
-
BPzeBanshee
- Posts: 4859
- Joined: Sun Feb 08, 2009 3:59 am
Re: G.M.O.S.S.E - MK-VI (1/01/2012) Input Replays, new fonts etc
Anyone have experience with engines like Danmakufu? I figured out a way to externalise all code so that you don't even need GM itself to modify the code that's run, but I'm not so sure plain GML code is the way to go, nor have I made much consideration for security (though encryption/decryption of said external code files is in via the ultracrypt DLL).
I'd like some advice on this if possible, because while externalising all running of code allows for more freedom for those who don't have GM I'm not sure if it's for the best interests of accessibility - I'd have to basically reinvent the wheel to make anything user-friendly otherwise it WILL be another obscure unfriendly oddball thing like Danmakufu is.
I'd like some advice on this if possible, because while externalising all running of code allows for more freedom for those who don't have GM I'm not sure if it's for the best interests of accessibility - I'd have to basically reinvent the wheel to make anything user-friendly otherwise it WILL be another obscure unfriendly oddball thing like Danmakufu is.
-
BPzeBanshee
- Posts: 4859
- Joined: Sun Feb 08, 2009 3:59 am
Re: G.M.O.S.S.E - MK-VI (1/01/2012) Input Replays, new fonts etc
Been quite frustrated with this and everything in life in general lately which is why I haven't updated.
First off, Arxtyan is no more. Fear not, I made a replacement fifth ship (and you can also see at attempt at improving menu readability too):
![Image](http://img85.imageshack.us/img85/7145/arxyne1.png)
![Image](http://img826.imageshack.us/img826/5643/arxyne2.png)
![Image](http://img27.imageshack.us/img27/131/arxyne3.png)
Yeah, after nearly a year since a member suggested a Rayforce ship I finally put one in. Due to engine design choices it doesn't lock on to enemies 'below' the ship like in Rayforce, but other than that and the lasers not behaving exactly the same with turning and speed it's close. It's certainly possible for me to implement that function, not to be confused with limitations, but I just don't particularly want to redo enemy handling YET AGAIN. I will do it if people seriously want it, though it's probably something you're better off doing yourself once you have the knowledge if you want to make something as visually complex as Rayforce.
Regarding input replay fixes, I changed input replays from using queues to a list. I'm not sure if it does much to memory at this point but where Arxyne was once not working it now does. Unfortunately Swordfish still won't work with input replays, but testing the other ships shows no change. I did however notice that when speeding up a playback of Xonochrome it ended up with a different score at the end, but when running it at normal speed afterwards it was fine. Beware of the fastforward button (+).
Also, in case I forgot to mention, stage 2 now looks like this:
![Image](http://img19.imageshack.us/img19/9879/stage21.png)
Still no enemies in-game yet but Kaiser's drawn up a few which I'll use. There'll be a midboss and a less stupid version of Gleylancer Stage 4's wallspawning thingy for the main boss and a lot of wall-based obstacles. Expect Stage 2 to play very differently from Stage 1 where you had a lot of space and scoring involved chaining till the boss. Stage 1 now transitions to this stage at the end, walls work and will kill you on collision, and Busterhawk's bound shot is now useful for something.
In other news, I've fixed up a few more bugs I've noticed with the score and life controller that appeared after making them persistent objects. They were keeping the chain count, countdown, score, lives and bomb count after restarting a stage. I fixed this so that restarting on Stage 1 gives you the default stock like it should, and for any other stage it'll set it to what you had upon entering that stage to begin with. For example, if you reached Stage 2 with two lives and six bombs and 2,500,000, wasted a life and got your bombs reset, and killed a few enemies, upon hitting "Restart Stage" you'd be back to two lives, six bombs, and 2,500,000. No restart milking, no restartitis.
In addition to this I've also been trying to fix up the layouts of a lot of the old code, and the naming structure. Afterimage and outline pictures are no longer inconsistent and confusing and go by the format of spr_<ship>_<aft/out>. Xonochrome's filename stuff got shortened too. If statements are properly spaced in most places now - the main exception is the highscore system that Nimitz implemented which I avoided since it has long lines in it and a LOT of brackets that would probably make things worse. I did however add a Ship variable to what's outputted on the highscore table, so now the highscore will tell you what ship you used in order of which one appears in the ship selection menu (Arxyne is 5 - Xonochrome is 1, etc).
EDIT: Just had a question put to me regarding whether using Gleylancer's music for background music material is a good idea. I thought the company died and I doubt there'll be an issue, but this did make me realise I haven't quite stated such outright. A plan in the long run is to add custom music support similar although more crude to how Xeno Fighters does it (that game gets a LOT right IMO) which will show proper credits.
First off, Arxtyan is no more. Fear not, I made a replacement fifth ship (and you can also see at attempt at improving menu readability too):
![Image](http://img85.imageshack.us/img85/7145/arxyne1.png)
![Image](http://img826.imageshack.us/img826/5643/arxyne2.png)
![Image](http://img27.imageshack.us/img27/131/arxyne3.png)
Yeah, after nearly a year since a member suggested a Rayforce ship I finally put one in. Due to engine design choices it doesn't lock on to enemies 'below' the ship like in Rayforce, but other than that and the lasers not behaving exactly the same with turning and speed it's close. It's certainly possible for me to implement that function, not to be confused with limitations, but I just don't particularly want to redo enemy handling YET AGAIN. I will do it if people seriously want it, though it's probably something you're better off doing yourself once you have the knowledge if you want to make something as visually complex as Rayforce.
Regarding input replay fixes, I changed input replays from using queues to a list. I'm not sure if it does much to memory at this point but where Arxyne was once not working it now does. Unfortunately Swordfish still won't work with input replays, but testing the other ships shows no change. I did however notice that when speeding up a playback of Xonochrome it ended up with a different score at the end, but when running it at normal speed afterwards it was fine. Beware of the fastforward button (+).
Also, in case I forgot to mention, stage 2 now looks like this:
![Image](http://img19.imageshack.us/img19/9879/stage21.png)
Still no enemies in-game yet but Kaiser's drawn up a few which I'll use. There'll be a midboss and a less stupid version of Gleylancer Stage 4's wallspawning thingy for the main boss and a lot of wall-based obstacles. Expect Stage 2 to play very differently from Stage 1 where you had a lot of space and scoring involved chaining till the boss. Stage 1 now transitions to this stage at the end, walls work and will kill you on collision, and Busterhawk's bound shot is now useful for something.
In other news, I've fixed up a few more bugs I've noticed with the score and life controller that appeared after making them persistent objects. They were keeping the chain count, countdown, score, lives and bomb count after restarting a stage. I fixed this so that restarting on Stage 1 gives you the default stock like it should, and for any other stage it'll set it to what you had upon entering that stage to begin with. For example, if you reached Stage 2 with two lives and six bombs and 2,500,000, wasted a life and got your bombs reset, and killed a few enemies, upon hitting "Restart Stage" you'd be back to two lives, six bombs, and 2,500,000. No restart milking, no restartitis.
In addition to this I've also been trying to fix up the layouts of a lot of the old code, and the naming structure. Afterimage and outline pictures are no longer inconsistent and confusing and go by the format of spr_<ship>_<aft/out>. Xonochrome's filename stuff got shortened too. If statements are properly spaced in most places now - the main exception is the highscore system that Nimitz implemented which I avoided since it has long lines in it and a LOT of brackets that would probably make things worse. I did however add a Ship variable to what's outputted on the highscore table, so now the highscore will tell you what ship you used in order of which one appears in the ship selection menu (Arxyne is 5 - Xonochrome is 1, etc).
EDIT: Just had a question put to me regarding whether using Gleylancer's music for background music material is a good idea. I thought the company died and I doubt there'll be an issue, but this did make me realise I haven't quite stated such outright. A plan in the long run is to add custom music support similar although more crude to how Xeno Fighters does it (that game gets a LOT right IMO) which will show proper credits.
-
tiaoferreira
- Posts: 252
- Joined: Fri Aug 21, 2009 9:29 pm
- Contact:
Re: G.M.O.S.S.E - MK-VI (1/01/2012) Input Replays, new fonts etc
Is there a playable demo for download? Post link, please.