shmups.system11.org

Shmups Forum
 
* FAQ    * Search
 * Register  * Login 
It is currently Sat Aug 19, 2017 6:25 pm View unanswered posts
View active topics



Post new topic Reply to topic  [ 314 posts ]  Go to page Previous  1 ... 7, 8, 9, 10, 11
Author Message
 Post subject: Re: G.M.O.S.S.E - MK-VIII R2 (29/7/14) Joystick fixes and mo
PostPosted: Fri Jan 08, 2016 4:34 pm 


User avatar

Joined: 08 Feb 2009
Posts: 4813
So I started from scratch and did nothing to the numbers at all and somehow it just works. And it works in GM8 too even though I'm sure I used this exact code before and it didn't work.

Image

In other news these pillows on the wall are very comfortable.
_________________
Projects: G.M.O.S.S.E / Warbird A13:02 / Zenohell / XII STAG Hi-Score Thread


Top
 Offline Profile  
 
 Post subject: Re: G.M.O.S.S.E - MK-VIII R2 (29/7/14) Joystick fixes and mo
PostPosted: Thu Jan 14, 2016 5:52 am 


User avatar

Joined: 08 Feb 2009
Posts: 4813
In another move straight into the "what the F^&* was I thinking beforehand" territory, I've gone and made several changes to the parent/child structure of enemy parent objects to better improve code consistency and also better support distinction between collidable and non-collidable enemies.

The existing structure basically revolved around obj_en_parent being the main enemy type, and obj_en_ground then having code to fight against being dragged along the screen by the camera controller and the player hitbox colliding with it as if it were a normal enemy. There was also checks on both enemy object->player shot and player shot->enemy object collision events for z depth which obviously was overkill and not necessarily making a lot of sense - a leftover from a much bolder plan regarding 3D enemies. I won't go into details as to what this implies here but obviously this isn't ideal use of inheritance or effective programming at all.

The new system fixes all this. The camera iterates only through obj_en_air now so obj_en_ground children stay in world space as they should. The collision events on obj_en_parent's side no longer check z depth but instead a boolean (or as close as GM will let me to a bool) can_collide which is default set to 1. Child objects simply declare their health in Create followed by event_inherited() which will initialise the parent's related variables and then from there it can override them as it should - for instance obj_en_ground overrides can_collide which means players can fly over said object without colliding as they should (the previous code before worked fine but this is a *better* solution).

I also added a can_damage check in obj_en_parent's events which allows for invulnerable enemies at the flick of a switch. This was originally going to lead to obj_en_wall being a child with can_collide=1 and can_damage=0 but I decided that keeping the wall as an inanimate object with collisions was more efficient than having every wall-based object run enemy code checks that weren't going to be used. For now the only objects that override can_damage are the Omake bosses which have their enemyHP value manipulated by a timer, this stops the jittering effect seen when shooting them.

Now that obj_en_air is being effectively used now this also means that you can make weapons like homing lasers that will prioritise air-based enemies over ground types. obj_en_parent then is only directly used for objects that are themselves extensions of another enemy. For example the Stage 1 platforms consist of obj_en_plat which is a child of obj_en_air and 4 obj_en_platTURs which are direct children of obj_en_parent. The turrets don't need to be obj_en_air children because their positions are being directly manipulated by obj_en_plat anyway.

My next and last area of attack before cracking down on stage 3 is the wobble scroll code. trap15 said it best a while ago, it really should be manipulated by something other than a fixed function formula that is obscure to understand. I'm hoping by calculating an ideal speed value for the x position to be manipulated by, along with keeping tabs on maximum distance from the camera's own x position that clamping the view x and just manipulating the view relatively with keyboard commands will just work. This is the last thing really standing in my way for effective 2P support that doesn't fuck with the view, I just need to think it through more. If anyone has suggestions for handling this please let me know.
_________________
Projects: G.M.O.S.S.E / Warbird A13:02 / Zenohell / XII STAG Hi-Score Thread


Top
 Offline Profile  
 
 Post subject: Re: G.M.O.S.S.E - MK-VIII R2 (29/7/14) Joystick fixes and mo
PostPosted: Fri Jan 15, 2016 5:39 am 



Joined: 15 Nov 2013
Posts: 30
For scrolling in the x dimension or "wobble", I did a calculation based on the player's x position on the screen each frame. So if the player is in the center, then the wobble is centered. If the player is all the way at the left, then the wobble is all the way left. For 2-player, I take the average x position of the two players and use that for the calculation. Then, you probably want to have a maximum speed at which the wobble can scroll if a player dies so that it does not suddenly snap to the new calculated position. For multiple layers of parallax, I apply an additional factor that affects how far each layer scrolls relative to the others.


Top
 Offline Profile  
 
 Post subject: Re: G.M.O.S.S.E - MK-VIII R2 (29/7/14) Joystick fixes and mo
PostPosted: Fri Jan 15, 2016 1:11 pm 


User avatar

Joined: 08 Feb 2009
Posts: 4813
That actually sounds a lot like the current system I have, but mine has become a fair bit more convoluted than I'd like. For reference here's my code:

Code:
// camera Create event
w = max_w/(max_w-240);

// End Step
if instance_exists(obj_player)
then view_xview[0] = x+floor((obj_hitbox.x - x)/w)-x_o
else if max_w > 240
    {
    if xview > x+floor((max_w-240)/2) then view_xview[0] -= 1;
    if xview < x+floor((max_w-240)/2) then view_xview[0] += 1;
    }

TL;DR magic numbers ahoy

x_o is a variable that compensates for the view being offset by 40 pixels when rotated (long story there). max_w is the maximum width you can travel in sprite size notwithstanding, which in my rooms are 320 pixels. Right now it works nicely but my attempts at working two hitbox x positions into have led to very iffy results, and changing max_w dynamically in a way that something like Gradius Gaiden does in its final stage leads to a sudden snap as you describe. How much simpler is yours?
_________________
Projects: G.M.O.S.S.E / Warbird A13:02 / Zenohell / XII STAG Hi-Score Thread


Top
 Offline Profile  
 
 Post subject: Re: G.M.O.S.S.E - MK-VIII R2 (29/7/14) Joystick fixes and mo
PostPosted: Sat Jan 16, 2016 9:56 pm 



Joined: 15 Nov 2013
Posts: 30
I had to revisit some old code. Mine's not simpler. What I am doing is similar, except that I am processing things in small time chunks (my game runs based on fixed time steps, with multiple time steps calculated per frame as necessary) and making calculations based on the time chunk. I am doing all position and scrolling calculations in floating point. I have a maximum speed for wobble move (and it is faster than the player speed). Then, I find the target x scroll position based on player x or average of player1 and player2, or center if everyone is dead. Then, move towards that based on the time chunk and max speed. Then I also clamp the position to the target x if it is within a certain range so that it doesn't oscillate or jitter.


Top
 Offline Profile  
 
 Post subject: Re: G.M.O.S.S.E - MK-VIII R2 (29/7/14) Joystick fixes and mo
PostPosted: Sat Jan 16, 2016 10:39 pm 


User avatar

Joined: 31 Aug 2009
Posts: 7179
Location: San Jose, California, USA
A number of arcade games just shift the screen scroll a fixed amount when the player directions are being held, and bounds players within the display screen. So when two players are in, they both affect the screen scroll. Whether this is what you'd like to do is another question.

Another solution I've seen is a "fixed function" scroll, where the scroll position is directly tied to the player X (or in case of 2P, the average of the X positions). To avoid the "jumping", they will just spawn the player back at the same X they died at.
_________________
@trap0xf | daifukkat.su/blog | scores | FIRE LANCER
<S.Yagawa> I like the challenge of "doing the impossible" with older hardware, and pushing it as far as it can go.
<Shepardus> whoever reached the fourth loop in zing zing zip is the modern day sisyphus


Top
 Offline Profile  
 
 Post subject: Re: G.M.O.S.S.E - MK-VIII R2 (29/7/14) Joystick fixes and mo
PostPosted: Wed Feb 17, 2016 1:52 pm 


User avatar

Joined: 08 Feb 2009
Posts: 4813
I think trap15, I'll probably come up with something closer to your first suggestion as this allows for more freedom in player spawn positions. For now I've dropped plans on it while I've got other things in the works.

One thing I got fed up with recently was a lack of loop point support in audio, long story short I made an Audiere wrapper which is my first foray into C/C++ and have since removed GMFMODSimple entirely out of GMOSSE. The DLL is called GMALP for lack of a more creative title, and removes the last critical part of this that's even remotely anti-dev-friendly regarding licensing. All that's really left to replace in the resource department is the Gleylancer voiceovers and a couple of altered sounds, not counting music files.

The music DLL is a little less fleshed out than I'd like. It supports multiple loop points but the indexes for them are kept in an internal sorted list in Audiere namespace that I can't reliably track from the outside without making my own separate sorted list with the same behaviour, which I don't know how to do yet. I also have no idea how to remove something that's been loaded into memory back out again manually, so naturally using the streaming option is not only recommended practice but essential. In GMOSSE's case it works well enough to adopt and hopefully I'll get around to improving it some more over time - GMOSSE's abstracted music controller code means you can if you wish replace it and stick in a GM-friendly audio engine of your choice without changing actual game code.
_________________
Projects: G.M.O.S.S.E / Warbird A13:02 / Zenohell / XII STAG Hi-Score Thread


Top
 Offline Profile  
 
 Post subject: Re: G.M.O.S.S.E - MK-VIII R2 (29/7/14) Joystick fixes and mo
PostPosted: Tue Feb 23, 2016 8:22 am 



Joined: 23 Apr 2008
Posts: 148
@rfeese (@BPzeBanshee)
your method is exactly how i would suggest approaching the camera scrolling / wobble prob, too. though i disagree in that i think it's very simple solution. just set a target position based on both player's pos and/or other factors and then try to scroll to it by some fixed amount every tick, nothing complicated here

so something like this:
Code:
target_pos = get_target_camera_pos(p1, p2)
camera_scroll = target_pos - camera_pos

// avoid overshoot
if camera_scroll >= 0
    camera_scroll = min(camera_scroll, FIXED_CAM_SCROLL)
else
    camera_scroll = max(camera_scroll, -FIXED_CAM_SCROLL)

camera_pos += camera_scroll
// clamp to bounds
camera_pos = min(max(camera_pos, MIN_CAM_POS), MAX_CAM_POS)


anyway, keep up the great work BPzeBanshee, and kudos to you for keeping your engine open source. it's a shame there's so little open source stg dev, i think it's pretty much just you, Noah! (one-two), and Kenta Cho (that's all i'm aware of at least). also, hows about proper linux support one of these days, i'm keeping my fingers crossed


Top
 Offline Profile  
 
 Post subject: Re: G.M.O.S.S.E - MK-VIII R2 (29/7/14) Joystick fixes and mo
PostPosted: Tue Feb 23, 2016 11:32 am 


User avatar

Joined: 08 Feb 2009
Posts: 4813
Thanks for the support and the code advice!

e_tank wrote:
also, hows about proper linux support one of these days, i'm keeping my fingers crossed

The shift to Studio has made this very viable now with a little bit of work. The main obstacle I can see is figuring out how to compile GMALP and if necessary Audiere for a Linux environment so you can still have music with loop point support.

If you aren't fussy about that though, an aspiring GM Linux dev can just replace the calls to GMALP functions with the internal ones, switch the USE_SANDBOX var in scr_main_init() to 1, and it'll cross compile for Ubuntu just fine - Zenohell (which was built from GMOSSE and then ported separately to Studio) DID work on a VirtualBox Ubuntu setup in testing but exporting of Debian installer packages (which I think are needed to be accepted for Steam/Ubuntu Software Center) are currently screwed.
_________________
Projects: G.M.O.S.S.E / Warbird A13:02 / Zenohell / XII STAG Hi-Score Thread


Top
 Offline Profile  
 
 Post subject: Re: G.M.O.S.S.E - MK-VIII R2 (29/7/14) Joystick fixes and mo
PostPosted: Thu Nov 03, 2016 12:00 am 


User avatar

Joined: 24 Oct 2013
Posts: 82
Hi! I recently picked up Game Maker Studio, and I was curious if there was any build of GMOSSE that would be useable in GMS rather than Game Maker 8.1 Pro. Please forgive me if there's a simple way to perfectly import the July 2014 build from the OP into GMS that I'm not aware of; naively clicking "Import" made it immediately throw up a window of script errors pointing out obsolete functions.


Top
 Offline Profile  
 
 Post subject: Re: G.M.O.S.S.E - MK-VIII R2 (29/7/14) Joystick fixes and mo
PostPosted: Thu Nov 03, 2016 4:49 am 


User avatar

Joined: 08 Feb 2009
Posts: 4813
Hi horaceappleton! At the present moment there isn't a public release for GMOSSE that works under Studio but fear not - I do have it working under Studio now, it just needs a bit more time before I can release.

My current plan coming Monday is to bring over the changes from this renderer overhaul to make the render system more feature packed and also readable for all involved, clean up everything I've been messing with and get a release out at some point after that, stage 3 be damned.
_________________
Projects: G.M.O.S.S.E / Warbird A13:02 / Zenohell / XII STAG Hi-Score Thread


Top
 Offline Profile  
 
 Post subject: Re: G.M.O.S.S.E - MK-IX (30/11/16) GM:Studio at last!
PostPosted: Wed Nov 30, 2016 11:55 am 


User avatar

Joined: 08 Feb 2009
Posts: 4813
Ok guys it's out. About damn time, I know.

Image

Last day before my next work week so I won't have the chance to get a video up. Changelog was way too long so I summarised it in the readme.

Download: Dropbox / Mediafire

I also have the original soundtrack folder that made use of Gleylancer and Crue Ball tunes. If you wish to use that download from here, extract to your GMOSSE folder and select the config file for it from the Audio Options ingame.
_________________
Projects: G.M.O.S.S.E / Warbird A13:02 / Zenohell / XII STAG Hi-Score Thread


Top
 Offline Profile  
 
 Post subject: Re: G.M.O.S.S.E - MK-IX (30/11/16) GM:Studio at last!
PostPosted: Tue Jul 11, 2017 4:02 am 


User avatar

Joined: 11 Jul 2017
Posts: 1
Alright as I begun trying to work on my Danmaku style game, I been trying to work with G.M.O.S.S.E but I can't quite seem to figure out why the game's music just wont load.

I've even tried using the basic music archive distributed with it but still no dice. It just won't load the OGG in game when I run it from the project itself.

Is there a reason for this or a way to fix it? Am I doing something wrong that I'm missing?


Top
 Offline Profile  
 
 Post subject: Re: G.M.O.S.S.E - MK-IX (30/11/16) GM:Studio at last!
PostPosted: Tue Jul 25, 2017 11:20 am 


User avatar

Joined: 08 Feb 2009
Posts: 4813
Could be a few things but can you confirm for me as to whether it works when you export it? I suspect it'll work as intended when actually run from an exported exe rather than the Play button which splits the game's working directory up into several different folders.

EDIT: I got the music to play from the Play button but to get it going but you'll need to consider two factors:

1) At least on my machine it seems GM:Studio 1.x's importing of things into Included Files is bugged - you'll need to include your music.ini as well as your audio files (ie. the music folder) AND make sure they've shown up in the datafiles folder of your .gmx folder system afterwards. It didn't copy over for me so I had to manually copy them into the folder.
2) Once you get this working, because of the way GM does its sandboxing through the "Play button" compile this will copy your music folder into a new temp folder every time you run it - obviously not ideal for rapid prototyping at all. There is an option in Preferences > General > "Automatically clean Temp Data on Shutdown" that will nuke the folder the temp folders are kept in once you close the IDE but it's still not ideal when devving for hours at a time.

For these two reasons the "best practice" method I use to develop GMOSSE is to Export to ZIP (takes about as much time), unzip to a folder with the inis/music and run the game from there. GMS2 was giving me similar troubles a while back, I think it might be the same bug. Will investigate later.
_________________
Projects: G.M.O.S.S.E / Warbird A13:02 / Zenohell / XII STAG Hi-Score Thread


Top
 Offline Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 314 posts ]  Go to page Previous  1 ... 7, 8, 9, 10, 11

All times are UTC


Who is online

Users browsing this forum: No registered users and 6 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
Jump to:  
Space Pilot 3K template by Jakob Persson
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group