Yes they are still on the cards, they are just not in a state to be presented for use - this is not everything it is just everything that is ready for public viewing - The Debugger only just made it in at the last minute when we deemed it usable enough to start getting feedback, this is not finished features it is a current snapshot so we can get feedback from everyone.

Is this spine and the 2d animation runtime still on the table for 1.3? Having not even a mention of it in this scares me a little...

Spine and 2D animation runtime?

Yes they are still on the cards, they are just not in a state to be presented for use - this is not everything it is just everything that is ready for public viewing - The Debugger only just made it in at the last minute when we deemed it usable enough to start getting feedback, this is not finished features it is a current snapshot so we can get feedback from everyone.

Russell

Makes sense. Also as my previous post, don't get me wrong. I enjoy new updates and features, I just think new features are less... important

than bugs that have been around since the beginning of time and misleading and lack there of in info via the help file.

EDIT: Not sure if anyone besides me has looked into the help file for networking lately... but it's info is quite lacking.

The debugger looks pretty awesome too but for me personally it's a bit like revamping the sprite editor, after a decade of doing without, I've gotten very used to it haha. I like the sprite editor enough. (although psd import would be sweet.)

Hope to see HTML5 networking and more attention for HTML5 (mobile) audio happen at some point, although in all honesty, javascript extensions does allow anyone to build these things themselves.

Right now the debugger is not for the YYC as far as I understood. Will this come later on? Because I guess extensions are only available for the YYC, and so we won't be able to use the debugger together with extensions? Will this be possible at some point?

Right now the debugger is not for the YYC as far as I understood. Will this come later on? Because I guess extensions are only available for the YYC, and so we won't be able to use the debugger together with extensions? Will this be possible at some point?

Extensions are not limited to the YYC. They are currently limited to iOS and Android, yes, but not the YYC targets only...

What I really really like about the new Draw events is the new Draw_Begin event.

Occasionally I like to put code in the Draw event, but the moment you put any code in a draw event, Game Maker stops drawing the object's sprite for you, and you need to manually draw the sprite yourself. This really dumps on performance.

Now I can put code in the Draw_Begin event without being concerned about drawing the image myself.

I'm going to have trouble remember that the Draw_begin is Draw Begin and not Begin Draw, like the Step events.

0

If the Bible truly is inspired by God, you would think that somebody as omnipotent and all-knowing would have known to get his message out using TCP instead of UDP.

I think it is a good thing that they are creating this EA version. They can build it off of the same code base, so it isn't like they have to maintain two different programs. And we get the benefit of running things seperately. We can try new features without ruining our projects(assuming you backup first, right!!!). And the trick is that we can stay on a fully stable(ish) version at the same time. This will lead to more people actually using the beta versions because many people don't risk it so they don't mess up projects. Worse, the ones who really need the new functionality, the serious indie developers, are the ones who are least willing to update, and yet are the ones who not only use the software more thoroughly(at least in my opinion), and therefore should be the ones to be able to do more testing. This EA version will allow that kind of thing to happen. That will lead to more and faster bug reports, which will hopefully lead to more and faster bug fixes.

1

My KBInput system is now on the marketplace here. It wraps up nice and tight GMStudio's input system into a few function calls making a user configurable input system that works the same regardless of what inputs the player has chosen including keyboard, mouse buttons, and gamepad/joysticks using DInput/XInput. The support forum topic for it is here.

Oh, man. I should get to bed, but now it looks like I have to go and download the Early Access.

I have yet to check out the implementation, but I'm incredibly happy to see push notifications and improved IAPs.

I'm also wondering about the vector sprites - this text: "it will for the most part allow the assets to come in unchanged, and be used just like any other GameMaker sprite" - suggests that you can create a sprite sheet on the fly from vector data based on the device resolution. This would be excellent because bitmaps are still more efficient to draw... Only SWF support at the moment apparently, and no fancy run-time conversions to bitmaps. Oh well.

Edit: Awesome - there's an http_request(url) command for full header access. You guys have been listening.

Edit 2: Judging from the manuals only, I'm going to be satisfied with the IAP and Push notification implementations. Great job, people.

It's wierd, cause for my project it's not starting at all, but when I checked another PC, it's OK then (Except that there is index out of bounds exception at start). But since it's EAP and Debugger is still not finished, I don't think it's worth to report that, cause it will be probably fixed.

0

Previously game developer at YoYoGames, Currently PHP developer in DB-Team
Programming and working with: GML/C#/PHP/JS/MySql/CSS/HTML

Please send us example projects that are causing you problems, as that is the whole point of the Early Access version it will allow us to improve and finalise features before they are placed into stable

Just report them as bugs - and make sure you mention they are in the Early Access version - Help -> Report a bug

I am trying to load a SWF but their edges become aliased, even with Quality setting to 100, I can't seem to be able to get anti-alias to work. Did not post a bug report because I assume maybe this is not implemented yet?

you would need to have anti-aliasing enabled on the destination surface for that to work (we are looking at ways of making the edges softer but there are patents stopping us using the most obvious methods)

You could also render to a larger surface and scale it down with interpolation on and that has a similar effect at the expense of memory bandwidth and memory.

(we are looking at ways of making the edges softer but there are patents stopping us using the most obvious methods)

Aww really? There are patents for that? o_O

I thought SWF AA was going to be implemented out of the box (based on the quality setting or a GGS/GML setting), I mean what's the benefit of using SWF if it's going to have jaggy edges when scaled and NOT scaled?
Might as well export a PNG sequence from Flash.

The quality setting governs how round the curves are (which depending on how big the image is displayed could be fairly rough for small images or need a lot of tessellation to look good if large).

The Anti-Aliasing is a rendering setting and the GPU will do this if the render target has it set up, or you could fake it by having a large 2x or 4x render target and then scale it down (as I said above) - any anti-aliasing that we could do would be a fudge using partially transparent triangles on the edges of the triangles we are rendering, this looks better (but still not as good as proper anti-aliasing), this is what ScaleForm does (and has the patent for).

SWF has advantages as it currently stands but if it is not working for you then don't use it - we present it as an option to do things that could not be done before, over time with everyones input we will make it better but we are not forcing you to use it.

We are looking to implement something approaching AA out of the box, but the main thing to remember is that this is not all finished yet and we will improve things as time goes on.

Regarding patents, have you thought of using SVG instead which is open source? You could try converting the SWF frames as SVG graphics using a SWF2XML converter. Having the frames as SVG, which is basically XML, might allow for better manipulation from within the IDE as well in the future.

Does YoYo have any plans for targeted testing as opposed to the existing "report bugs as you go in everyday development" casual approach? Some features, such as Android and iOS extension support, are things that require skills not present in most GMS users. Without targeted testing from skilled users, the final v1.3 product may end up containing features that have received inadequate testing, if any at all.

I'm sure you've heard enough of my complaints about SVN on GMS, and it demonstrates exactly why the existing approach is a problem when it comes to verifying large-scale new features. When the SVN mechanism debuted in GM:HTML5, there was a severe lack of users with existing working knowledge of SVN, and with it a glut of user-end testing. The result? When real users started using it in GMS, they immediately ran into blockers and serious usability bugs that were not discovered or reported early, simply because the whole feature was not being actively tried out by anyone when first offered. Until recently, it was easily the most poorly done part of the entire GMS program.

For each new v1.3 feature, I suggest getting at least one or two dedicated/expert-level users who have experience in relevant subject areas as testers and KB article writers (e.g. graphic designers for vector graphics, native Android/iOS programmers for extensions, etc.). This allows user perspectives to enter the development process early in a balanced manner, and delegating bug-hunting and FAQ documentation to them allows a greater focus on fixing broken functionalities. Such experience will also allow these users to gain early experience using the new features, which would likely benefit their personal work and make them more valuable in team projects.

Personally, I am comfortable with targeting the debugger, new drawing events and recent fixes in the SVN integration, so sign me up if you are interested.

There really are more experienced developers using studio than "just you", and we do get bugs back from them as well, but the only way to get the real volume of responses that we require, is just sticking it out there. There are tens of thousands of Studio users, and they can all test much better than the handful of "targeted" developers. That said, we do give our special builds to individuals now and then when the case warrants.

YoYo team: is there any way to cancel locally scheduled notifications? For example, if your notification was aimed to let the user go back to the game after a certain time period, but the user has already done just that?

Does anybody know how this will effect screen effects? Previously we had to set the view to a surface in the End Step event then in the Draw event you can use surface_copy to do screen effects, but the article seems to say you can now directly access the buffer instead of creating a surface? I'm not sure.

YoYo team: is there any way to cancel locally scheduled notifications? For example, if your notification was aimed to let the user go back to the game after a certain time period, but the user has already done just that?

Good question! I don't think there is... seems like something we should be able to do though, so file a suggestion!

Does anybody know how this will effect screen effects? Previously we had to set the view to a surface in the End Step event then in the Draw event you can use surface_copy to do screen effects, but the article seems to say you can now directly access the buffer instead of creating a surface? I'm not sure.

Flexibility is the name of the game here... You CAN use the post draw events for full screen rendering and for surface manipulation, but you can also do it the other way (actually, many other ways!). Using standard draw event you can target specific views and control the draw size and other things, while this new event permits you to target the full screen easily, but at the base resolution of the back buffer. Both can be used, and both are valid, but which you use will depend on your needs and how you like to use them. Basically GMS is giving you multiple options so that you can choose the "best fit" for your game and programming style.

Thanks for replying Nocturne though I'm still a little confused. Say I was doing a simple screen blur effect where I just overlay a copy of the screen with reduced transparency, do I still need to assign the view to a surface then use surface_copy to grab a screenshot? Or is there now some way of redrawing the buffer or something?

The Early Access program asks for my license key. Does this mean it's going to show up as one of the three devices I'm allowed to use GM:S on, even if it's on the same computer as my regular GM:S installation?

The limit is 3 machines, not 3 installs. you can install as many times as you like on the same machine.

What about people who upgrade their computers on a regular basis. I reckon I have upgraded

my computer at least 2 times since I started using studio, + I used it on my secondary PC, so might have used up the

3 machines. so when I upgrade my main PC next time my key will be blacklisted ? I would certainly not be happy if that happened.... I have always beena legit, paid user of GM, I would like to continue to be...

The limit is 3 machines, not 3 installs. you can install as many times as you like on the same machine.

What about people who upgrade their computers on a regular basis. I reckon I have upgraded

my computer at least 2 times since I started using studio, + I used it on my secondary PC, so might have used up the

3 machines. so when I upgrade my main PC next time my key will be blacklisted ? I would certainly not be happy if that happened.... I have always beena legit, paid user of GM, I would like to continue to be...

You're not going to get blacklisted. People have been doing that since the Game Maker 8.1.

0

If the Bible truly is inspired by God, you would think that somebody as omnipotent and all-knowing would have known to get his message out using TCP instead of UDP.

The limit is 3 machines, not 3 installs. you can install as many times as you like on the same machine.

What about people who upgrade their computers on a regular basis. I reckon I have upgraded
my computer at least 2 times since I started using studio, + I used it on my secondary PC, so might have used up the
3 machines. so when I upgrade my main PC next time my key will be blacklisted ? I would certainly not be happy if that happened.... I have always beena legit, paid user of GM, I would like to continue to be...

it 3 machines at once limit, not a 3 machines ever limit.

0

No matter what, cute is justice. If you're watching shows without moe, you should really be questioning your life decisions. The creation of 2D anime girls is the pinnacle of human achievement.

So, I have been using the early access build for a while, and have started to build a simple project in it.

Assuming my Studio license applies to it(as the build is pro version) can I release/sell/whatever the program I make? I remember when GM: HTML5 came out there was issues about this, just wondering if this is the same.