itch.io

Yeah, it should work in any version after 2.3
Give it a shot and report back!

Try hitting Z. It can change the size of the window.   Though when I press Z the sliders still work for me, so that may not be the issue

If you are talking about in the Palette Editor, select the first new palette and instead of pressing "new" select "duplicate." This will give you a copy of that palette and you can modify or leave whichever colors you want

Yeah, as long as you aren't planning on using the layer swap feature, that should be fine.

Odd. In all honesty, you really should be using animation curves now...

Haven't ran into too many issues myself performance wise. Typically shader performance is "gated" by how often you are calling shader_set and shader_reset more than just about anything else.  Vertex batch count isn't usually a good measure of how "performant" anything is. I've had something running at 60fps with my batch count in the thousands.
Other issues can be your application surface size.  Your art may be low res, but if you've upscaled your app surface size to get sub pixels, you are doing more work. You could be swapping 4 to 16 times the number of pixels than you really need to. Other concerns are palette sizes. If your palette has tons of colors, then that's more colors the shader needs to search through to find a match (or it ends up going through all of them when there is nothing to match)

There are lots of ways to improve performance, but it's all going to be very, very specific to your project. I'd recommend asking on the GM Discord server when you have time to sit down and work on it. Lots of people there that can help you figure out exactly what is slowing you down and how to improve it.  Best case scenario would be you working on said "lower end" machine, or setting up a use case where you are experiencing the performance issues yourself.

https://www.microsoft.com/en-us/download/details.aspx?id=35

It's at the bottom of the downloads list.

I assume so... They are just variables that are present in the struct, so you can use them however you see fit.

Hmm. Yeah, I don't know anything about Clickteam, unfortunately. I have converted this shader to work with straight HTML5/ReactJs successfully, so I know conversion is possible... but I can't speak to how easy it would be to convert to CT.

It is possible, yes.
The thing about any collision system is it ultimately comes down to "can I move here? Yes or no." right? That's what place_meeting is.
TDMC allows you to define your own place_meeting function, which you can make as complicated as you want. So: yes, totally possible. Obviously not something that it does "out of the box" but changing how you define the collision check function is all it really takes.

Good suggestions. If I ever get around to building the next version, these will be in there!

I'm not sure what a "bayer" is, but you could probably make it work. You have full control over how the silhouettes draw to the screen. It doesn't even have to be the same sprite if you don't want. Right now it just calls draw_self() for those objects, but you could make it run any code.

Yeah, that's fine

I haven't experimented with Steam Input myself. If it requires something outside of what GM already supports (keyboard, gamepad, mouse) then this isn't going to handle it. Might want to look into Juju Adam's "Input" library. If anything is going to have Steam support, it's that.

Yeah, that is one of the downsides of the State Machine pattern. Because each state fully encapsulates everything that object is doing in any one step, that means anything that is shared is duplicated.

I often write functions like "move_and_collide" which would handle gravity and collision and all that. These "helper functions" are defined globally and available in any state on any object. Sometimes I'll allow those functions to accept arguments such as "in this state the gravity is .2, where as in this state the gravity is .3" or have them return results such as "I've hit the ground or a wall" so that the state can react accordingly.

Yeah, if you set up a "direction" input type, you can check the "direction" property of that input. So it supports "360" directional input.

So you need to combine those two palette sprites into one sprite. Brown one on the left, green one on the right. That's what your pal sprite should look like.
If that doesn't work, I recommend joining the GM Discord server and asking there. I could look at your project if you'd like.

I could be, but it really depends on what you want changed. The system is pretty "locked in" so something that might seem like a modification or an adjustment could mean a full re-write.  Feel free to hit me up on Discord to chat. My DMs are open to those who are members of the GM Discord server: https://discord.gg/gamemaker

I would need to see your sprite and your pal sprite to figure out what might be going on.

Just working on the documentation, then it should be ready to go. I'm hoping by the end of the week!

Technically true, but pinhole is maybe even a bit of an exaggeration.
The system is sort of designed to be instantiated on game start and then just... stay in place for the duration of the game. So you should never re-init the system, and you don't need to clean up the stack when the game is closed because the OS will clean up any and all memory the game is using.

You are welcome to call ds_priority_destroy in the game_end event if you'd like, but I just thought it unnecessary.

Hmm.  That may be a typo. You shouldn't need to pass the ID (which is normally the enum you use to define or switch to a state) since it should be drawing the "current" state. Sorry about the confusion.

Whenever you see "<unknown_object>." 99% of the time, that's a 2.3 issue.  You have a script file that doesn't have "function <functionName>(<arguments>){" at the top like you should for all script resources on the most recent version of GameMaker

Difficult to say.  My life is currently a shitstorm and game dev has taken a back seat to just about everything.

Hopefully things calm down soon.

So, check out this tweet:
https://twitter.com/Pixelated_Pope/status/1516815617109635073?s=20&t=VWha6dl9I8t...

Just call that function in your step event before movement_and_collision (or after or both, honestly) and you'll never get stuck in a wall and freeze the game ever again

Yeah, maybe I need to include a tile collision example in the project itself.  And then I can run my own tests and such.

Yeah, using "tile collision" is a VERY important piece of information when reporting an issue :D

Yeah, I tried that exactly location in the room and it just doesn't work at all with keyboard or controller because the player is embedded in the wall from the start.  If you wanna send me a link to your example, I'd take a look

Okay, I don't see the same issue.  Define "high speed", which corner, basic or advanced, which controller method?

Everything seems to be working for me.  What exactly are you experiencing?

Oh, yeah.  If you drop the player on a wall, it's likely not gonna move.  Seems to happen to me for both keyboard and controller... because the player is stuck in the wall you dropped them on.
This is something you can solve with a "get out of the wall" function easily enough, and not really something I plan on fixing as part of this package.

No, you don't need the first one.  Just the ones labeled HTML.  In fact, if you build for HTML with the non-html shader in your project, there's a good chance the game will yell at you.  You'll have to remove it from your project completely because Yoyo doesn't allow you to specify assets per export, unfortunately.

I'll take a look!

If you can draw it to the screen, pal swapper can change  the colors.  And palettes can be built in surfaces, so you don't have to use pal sprites if you don't want.

I was hoping that the issue would sort of "auto resolve" with the new floating point collision detection.  Though I haven't tested recently with those changes.  I had a solution in the past, but it was very complicated, and it's much easier to set your speed to 1.251 or something.
And as a rule, we don't worry about performance until there is a tangible issue.  So as far as I know, there is nothing to be concerned about performance wise.

Yeah, don't use image angle.  You need a different variable for your sprite angle, and then you draw the sprite using draw_sprite_ext with that angle variable.
image_angle rotates your collision mask, which is usually a very bad idea

Awesome!  Yeah, it's really exciting to know that at least someone is using that feature.  I'll definitely include it in the next version, and make sure it doesn't have the same issue you found here.

Hmm, yeah... to be perfectly honest, the queue system is by far the least "exercised" part of TrueState.  I never found a good personal use for it (and was planning on removing it from TrueState 3), and I most definitely did not test it in conjunction with the lock system.  

I'd say if you got it to work, I'd be surprised if there was any real impact on other systems if you haven't already noticed them.