Arima's Forum Posts

  • Yup, that was me asking that question. Doesn't solve anything for xp users, but good to know for vista users.

  • I just did a bunch of testing to determine the source of a stuttering problem as well, the solution for me was to turn on windows aero, as with it off, Windows's window manager was not hardware accelerated. However, that was a solution for vista, and I don't think it applies to windows 7, but you might want to give it a try if it's not on already.

    Another solution I had quite a while ago was to update my graphics card drivers, which is always worth trying.

  • It's possible you've run into a problem I just discovered - in come circumstances, windows's window manager can run in software rather than hardware accelerated mode. I was getting a consistent stuttering framerate with applications running in windowed mode or as a fullscreen borderless window (which is the method chrome/node webkit uses - true full screen applications like construct classic uses were unaffected), and discovered that the reason for it was because on vista, if you're not using aero, then the window manager is not hardware accelerated. As soon as I turned aero back on, I'm getting a smooth 60 fps with a dropped frame only once every 30 seconds or so. If you're on XP, then I'm not sure there's anything you can do about it, as I don't think it has any options for a hardware accelerated window manager. Windows 7 doesn't have the stuttering problem even if aero is turned off.

  • That's a misconception about all games needing to be free on the ouya due to some somewhat unclear communication during the reveal. All ouya games require SOME free content, such as a demo. The entire games do not need to be free.

  • I've read some people saying that ludei has plans to support the ouya, though I haven't seen an official announcement about that myself. It would be nice if they had an extension system so people could add support for gamestick, nvidia shield, etc.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

  • Yeah, seconded - I've been especially missing pick by comparison for a while.

  • That is explained in detail in the for each tutorial.

  • Ashley - It didn't work as well as I thought it would. Example:

    On left click or touch start

    • set sprite position to touch.x touch.y

    If I left click, it places the sprite at 0, 0. This puts me back in the same position of needing two sets of code for the mouse and touch plugins.

  • Found out what was causing the problem - I forgot to turn off 'use mouse input' in the touch properties, so the or block was running twice. Turning it off made it work properly. Should I file a bug report for that? It seems kind of logical now that I think about it, since the mouse and touch plugins were both registering the mouse click. At least it was simple.

    So yeah, I guess using an or block is fine, and my request is unnessecary. Sorry for the trouble and thanks for the help!

    I have no idea where I got the idea that subevents couldn't be used under or blocks though... Maybe misremembering something about how picking works when there are two conditions for the same object in an or block. :/

  • Also, grabbing parameters from the touch object in a function called by the touch event doesn't seem to work. I suppose I could set them as parameters, but it just seems kind of clumsy in comparison, because then it's kind of hard to remember sometimes what value is set to what parameter and I have to keep looking it up. It also fragments the code tree and forgets picking.

    I'd also like to be able to name parameters, but I seem to remember there was a reason you didn't want to do that, though I don't remember what it was. But I'll cast my vote for them anyway. ^^

  • Ashley - An or block runs the conditions and actions of the event twice. Also, I thought there was some sort of restriction on or blocks preventing them from having subevents - but that doesn't seem to be the case anymore - was that changed at some point or am I remembering wrong?

    newt - because some games require input methods other than buttons?

  • Not really - it still requires two sets of code for registering mouse and touch triggers.

  • Ashley - I know it's doable that way, but then all the code for left clicking has to duplicated, and if any bugs are found, then they need to be fixed twice. If this was implemented, it would be one set of code to maintain.

  • If C2 had the option I mentioned, I wouldn't have to. It would very useful to myself and I think others as well, so we could have one set of code rather than needing duplicate code for both, and it seems like it wouldn't be hard to implement.

  • I'm using the touch plugin for both touch and mouse controls, but there's a problem - 'on touch' fires for left, middle and right mouse clicks, and I have no idea how to differentiate between them as adding a 'right mouse is down' condition doesn't work. I tried adding an 'on right click' event before it to set a variable but it isn't working right, presumably because triggers run out of sequence.

    As it is, it appears the only way to bypass this is to have a mostly redundant set of code for mouse control.

    Something like an extra option in the properties of the touch plugin for use mouse input, instead of yes/no, perhaps yes/no/left click only would work well.