R
renex
Guest
The only thing I ask for is loop points.
What do you mean?The only thing I ask for is loop points.
As I said before in another post, "Good thing we have the Marketplace, right?"This has been solved many times by many people.
As I also said before in another post:There's no magic bullet for implementing delta time corrective factors
Still a good example too, nice one.Delta Time works fine (Even with it's inconsistencies every once in a while), however, there is incompatibilities with some features, such as Particles, and Physics (afaik, if you guys know how to get rid of these problems, I would love to hear, since my game uses both! Thanks!)
Oops, sorry, missed that one. Yes, not being able to adjust the procession rate for particles is annoying.As I also said before in another post:
Don't feel bad. I also spent a long time trying to figure out how to bring it back and it was very frustrating. I took me a while to notice the 'Room' dropdown menu appeared when I had my room tab in focus. It's not available otherwise.Well, I guess I was looking in the wrong place's xD
Audio loop points, yes please. This would be a very useful thing for pretty much everyone.I'm assuming he means loop points for audio. I've been wanting these for aaaaaaaages too. Maybe Santa will be kind this christmas.
Can someone explain to the uniformed (me) what issues this causes? I didn't even know bgr existed or that order mattered. Is it merely just the order you input colors for code or is there something deeper behind it?Still using bgr to colours instead of rgb is a pretty big miss for me. Even if it's probably for backwards compatibility.
Standard hex format is #rrggbb so if your taking your colour from a colour picker or another resource you either have to manually input the colour bits in the make_colour functions or swap the bits manually (Or do as I've done and write a script to swap the bits for you). GameMaker uses the format bbggrr instead (A few other programs seem to use the format as well but they are the minority). It also uses a $ sign instead of a # for denoting hex but at least that's just 1 thing to change.Can someone explain to the uniformed (me) what issues this causes? I didn't even know bgr existed or that order mattered. Is it merely just the order you input colors for code or is there something deeper behind it?
For the header thing can't you just create your own snippet? GameMaker at least supports snippetsHIT and MISS seems a little harsh as we are in beta I am expect some enhancements moving forward but in the spirit of this thread I will maintain the same format.
HIT: The new editor is a vast improvement over the previous but I feel it is still lacking in areas for power users.
MISS: No automatic outlining
MISS: No region support
MISS: No auto format document
MISS: No configurable template for custom header for new scripts
MISS: No configurable template for document coding standards
MISS: No invoke entire intellisense list
MISS: No Intellisense filtering
MISS: No Add-in/Extension method support for extending the editor functionality and behavior
Yep, afraid that's why.... it would - simply put, have broken ALL game imports from 1.x and that was too much. We can change a lot, but with colours just being "numbers" there was no way to "fix up" old colours. So didn't happen.Still using bgr to colours instead of rgb is a pretty big miss for me. Even if it's probably for backwards compatibility.
I ended up just writing one, I think it's in some of my marketplace assets actually. Though it'd be nice to have one inbuilt.you could make a swap function to swap the r and b vals
var C = argument0 ;
return (C & 0x000000ff) << 16 | (C & 0x0000FF00) | (C & 0x00FF0000) >> 16
That's the one I was referring to, submitted in 2014.I have a bug for "getter" functions here: http://bugs.yoyogames.com/view.php?id=15941 Hopefully it'll be addressed in GMS2.
Or you can target the most common cases (e.g. in hex and D&D) and offer a drop-and-go way to fix the other hard-coded numbers.Yep, afraid that's why.... it would - simply put, have broken ALL game imports from 1.x and that was too much. We can change a lot, but with colours just being "numbers" there was no way to "fix up" old colours. So didn't happen.
I program in Visual Studio all day and expect functionally typically found in modern day IDE's. I am just making a quality of life wish list of things I would find helpful and I think others might also.yeah, a little description for all those would be great... Though the custom header if is what I assume it is, it would be great to have new functions created with a template that include the new doc style
This is already a feature but the setting for it has accidentally gone missing from the preferences panel in this release.Though the custom header if is what I assume it is, it would be great to have new functions created with a template that include the new doc style
Hmm, gotta say I agree with this one - I think it causes more problems than it solves.Still using bgr to colours instead of rgb is a pretty big miss for me. Even if it's probably for backwards compatibility.
But, just because something's been a certain way for a long time, doesn't mean it's the best way. And again, break away from the chains of 1.X, PLEASE. I'd rather not waste time making functions and processing multiplying matrices when they could be "perfect" (for me, or any 3D dev) from the start. At least give us more build order functions if you don't want to break compatibility!If you need a different matrix build order, you can of course build a translation matrix, and a scale one and a rotation one, then apply them in any order you like using the matrix stack.
This function was in 1.x so its order won't be changing. I've used this order for...well...decades now, and it's worked fine for everything I've thrown at it, but as I say just use these functions to build 3 separate matrices and then use the stack to combine in the order you need. Use a script if you still want an all in one function.
var mT = matrix_build_identity();
mT[0] = argument6;
mT[5] = argument7;
mT[10] = argument8;
return matrix_multiply( mT, matrix_build(argument0, argument1, argument2, argument3, argument4, argument5, 1, 1, 1) );
Okay, the way the matrix builds works not just for single things, but for hierarchical objects. Translation should always come last in a build so that an object rotate/scale etc does not interfere with the translation around the world, unless it's a child of another object, at which point it's getting multipled by another one of these matrices, and the translation will then be rotated and scaled correctly.But, just because something's been a certain way for a long time, doesn't mean it's the best way. And again, break away from the chains of 1.X, PLEASE. I'd rather not waste time making functions and processing multiplying matrices when they could be "perfect" (for me, or any 3D dev) from the start. At least give us more build order functions if you don't want to break compatibility!
Not to sound like a big meany bum, but my matrix works perfectly?Okay, the way the matrix builds works not just for single things, but for hierarchical objects. Translation should always come last in a build so that an object rotate/scale etc does not interfere with the translation around the world, unless it's a child of another object, at which point it's getting multipled by another one of these matrices, and the translation will then be rotated and scaled correctly.
It's this order for a reason. Now, the rotation order (doing X then Y then Z) is up for grabs as that depends on your game and how your doing things, but as I said for a general order this works fine, I've used it for 20 years+ now. But for transformation and scaling, this or order is correct for proper hierarchical objects (single, or parent/child items). if it doesn't work for you then you can create a few scripts - as you have done, and do whatever you like. As long as we're not blocking you from doing your own thing, then as an API, it's fine.
Personally, I think your matrix build is wrong, you should not be applying translation before a scale/rotation and that means you can't place a spinning object correctly in the world - as it's origin is moving due to the translation having been rotated. But if you have a system working for you, great, you can keep doing that using your scripts.
I suspect we will add simple translate/scale/rotate creation code to make you a matrix of that type, but not a different "all in one" build, but your obviously welcome to do your own. in YYC it'll probably be just as quick as it's all maths stuff.
Yes, because the parent object is already not at 0 - I'll say it again: I test everythingAs I said, if it works for you great - you can make scripts to do what you need to do, but we're not gonna add every combination or order that everyone wants because that's a huge matrix for something that is easily solved by each person.
Out of curiosity... if your parent object isn't at 0... does it still look like this? (just curious)
Or you can make a function that allows us to build 4x4 matrices on a entry-wise basis, that can support any transformation in any order.As I said, if it works for you great - you can make scripts to do what you need to do, but we're not gonna add every combination or order that everyone wants because that's a huge matrix for something that is easily solved by each person.
I was aware of the array method, but I'm glad you've pointed it out.There is a function to do that as a matrix is just an array of 16 numbers so the array literal operator will do that.
We have discussed internally adding in some more matrix convenience functions.
Russell
I'm not sure now is the time, but in a future major update when GML and the runner get more of an overhaul it might be.now is the time
What other time is there to overhaul GML and the runner? Surely not while GMS 2 is out of beta and used at a production-level capacity.I'm not sure now is the time, but in a future major update when GML and the runner get more of an overhaul it might be.
I've been hearing "it's impossible in 1.x" excuses for the last three years. Now we're going to say Yoyo didn't have enough time to plan ahead to make changes in GMS2? I can't buy that. 2.0 is a great opportunity to make big changes to GML and GM in general. I'd rather see Yoyo improve GM as much as possible than try to keep things backwards compatible with GMS1. GML has barely changed at all since I first used the program as a kid like fifteen years ago. I say throw all the old garbage conventions away and start completely fresh!The other time is after 2.0 which is almost solely focused on the IDE, not the planned changes for the rest of GMS coming in the future. It would be great to have those changes in 2.0 but the decision to create compatibility scripts has delayed some things. Obviously that decision highlights their desire to keep things as functional as possible for users moving their projects to the new system. GML has a lot of growing still to do. It's going to take time.
And when do you foresee this happening?I'm not sure now is the time, but in a future major update when GML and the runner get more of an overhaul it might be.
That is really odd... probably best you submit a bug report (if you haven't already).The font rendering in the IDE makes it very annoying and zooming at all looks horrible.
I'd rather see Yoyo improve GM as much as possible than try to keep things backwards compatible with GMS1
it's now or never.
YYG, and I presume this is after significant consultation with community members, have taken the implicit stance that they want to create as much continuity as is possible between GMS1 and GMS2 to help users transition to a better IDE. It is this IDE that will serve as the launch pad for bigger ideas. It has already given us a new sprite editor, a new tile system, and a new room editor. Do we want to buy into future improvements on that basis?Obviously that decision highlights their desire to keep things as functional as possible for users moving their projects to the new system.
1. Shaders are not part of the beta. That shouldn't be a miss.1. I miss some built in shaders/effects for people with no or limited coding experience, i know atleast one other game engine that has some pre installed shaders for people to use.
2. I think they should not focus on backward compability, if someone has started a project in 1.x then why cant they finish there product there?
i think it whuld be better to focus on the future for 2.0 and GML with even better performance and more features
3. The image editor is amazing, but i think we're still missing some feautres the old editor had
4. An "ingame/editor" particle editor whuld be cool aswell to have
While having any positive non-zero number evaulate as false seems backwards to me too, this really is heavily mitigated by 'doing it right'. I can't think of any possible reason any half-decent coder should be using if statements whose conditions return anything other than 0 or 1 without being aware of what gets evaluated as true or false. You're asking for undefined behaviour. C++ might accept any non-zero integer as true, but that's not the only way other languages handle it.Big Giant Fat Butted Slimey MISS:
Continuing to support false as any number (including negative numbers) less than 0.5 and supporting true as any value Greater than or equal to 0.5.
Yes, I know that you are continuing to support it for backwards compatibility reasons. But now is the time, at the expense of compatibility to get rid of this convention.
False (<0.5) and True (>=0.5) was a bad idea when Mark implemented it 17 years ago and it's still a bad idea. It is confusing to beginners, non-intuitive to the experienced and probably incompatible with every other computer language known to humans. This abomination needs to go.
i mightself thought until I saw that post that true was 1 and false was 0 and NEVER EVER ran into any kind of problem.While having any positive non-zero number evaulate as false seems backwards to me too, this really is heavily mitigated by 'doing it right'. I can't think of any possible reason any half-decent coder should be using if statements whose conditions return anything other than 0 or 1 without being aware of what gets evaluated as true or false. You're asking for undefined behaviour. C++ might accept any non-zero integer as true, but that's not the only way other languages handle it.
if( whatever() > 0 ){ /* wow it works */ }
Indeed but the fact is, if you come from any other language, the logical way is 0 = false, anything else = true.i mightself thought until I saw that post that true was 1 and false was 0 and NEVER EVER ran into any kind of problem.
I mean if your function returns 0.1 and you want that to give true in an if statement, why not do the logical way :Just an idea :3Code:if( whatever() > 0 ){ /* wow it works */ }