Ashley's Forum Posts

  • I tried enabling the override already with very weird results. You would get randomly stuck in the ground for example. And since it doesn't fix the different speeds anyway, doing the events without TimeDelta would be basically the same, right?

    Sounds like a bug in your code - by chance, without override, you might get the same sequence of timedelta values - so I doubt that is directly caused by timedelta override. And yes, your application becomes framerate dependent again. However, you can still use timescaling, and you have the useful ability to turn off the override and go framerate independent again!

    [quote:1f2b8n6i]Using round(.X) etc like Arima suggested is a quite good method and gives better results. But still you may get stuck where you shouldn't or detectors that are supposed to stop when they overlay solid objects actually stop 1 pixel before. Therefore other events may not be triggered...

    I wouldn't advise this purely on the basis it will make motion less precise and you lose the smooth rendering.

    [quote:1f2b8n6i][quote:1f2b8n6i]MMF suffers exactly the same problems regarding refresh rate and speed of gameplay as Construct

    But then I don't understand why my MMF stuff seems to run exactly the same speed on the tested 60 and 85hz with no special settings, just plain set X to X + 1 stuff. I know I'm stupid but I don't really get it.

    I think by default it uses 50fps fixed framerate, V-Sync off (so the display tears). 'Fixed framerate' is a misleading name, because the gameplay speed is still completely framerate dependent anyway: if a low-end computer can only run the game at half the intended framerate, the game only proceeds half as fast. And bleh, tearing displays aren't nice :-

    [quote:1f2b8n6i][quote:1f2b8n6i]If you absolutely insist on it being pixel perfect (and I still struggle to get my head round why this is absolutely necessary)

    Like it says in the wiki:

    "However, some specific games (such as low-resolution pixel-drawn retro games) require movements to be exact to the pixel."

    At least I'd like to get close to the pixel perfect optimum. Maybe I should just start using many more pushout events or whatever you may call them.

    Yeah, I wrote that - but I'm starting to disagree! You might argue that in your game your player can jump exactly 32 pixels high so you fill your level with 32 pixel high blocks to jump over. Then you turn on timedelta, and you get a 3% random variation, which means 50% of the time you jump ever so slightly less than 32 pixels, and you can't clear the obstacle. I think the correct action in this case is to design a game with 30 pixel high obstacles! In other words, allow for the small random variations. I can't see how this would be a serious issue if you are just starting out your game. I think it would make very little difference - and then you can use motion blur, timescaling, v-sync quality display, framerate independent runtime, etc. etc...

  • MMF suffers exactly the same problems regarding refresh rate and speed of gameplay as Construct - there are just different options available to handle it. In Construct, I strongly recommend you code your game to simply take in to account the 2-3% random variation caused by timer inaccuracies. It's not much and shouldn't affect your game much. If you absolutely insist on it being pixel perfect (and I still struggle to get my head round why this is absolutely necessary), you can enable the TimeDelta override in Advanced application properties. You can have your game V-syncing for high display quality, and have TimeDelta return a constant value so it plays out identically every time. However, this means your game will run faster on 85Hz monitors than 60Hz monitors. I have heard of 120Hz monitors, so it could be as much as twice as fast. But that's why TimeDelta exists. It's designed to solve that problem

  • I personally just use number variables for flags - 1 for on and 0 for off. I'm perfectly comfortable using it considering I'm from a programming background, but if you prefer, you could just as easily use text like "yes"/"no", "y"/"n", "on"/"off", "true"/"false" etc...

    If you use a number you can toggle it with 1 - value (1 - 1 = 0, 1 - 0 = 1), or with text you could still use: value = "yes" ? "no" : "yes"

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • There's no need, if you set a text object's text to a number, it is automatically converted to text.

  • Looks like a really innovative game

  • Objects can still go that far when bounded scrolling is on. You just can't scroll that far. If you want to limit how far it can go though, you could do something like:

    + Sprite X is greater than 10000

    -> Set sprite X to 10000

    Also note because positions are stored as floating point values, at such high numbers as 2,000,000,000 you'll probably start to lose precision on the pixel scale. I wouldn't advise letting anything go that far!

  • Hotfix for those that want it.

  • This will be fixed in the next build!

    This bug doesn't exist in 0.97.5, so you can always roll back if it's keeping you.

  • It just looks like C# with a gaming API - in other words, all programming. That's not what Construct aims to be - but possibly a good one to go for if you want to program your game!

  • It's intended that the object bar entirely replace the object list in the layers bar. Since the object list in layers was quite buggy, it was removed when the object bar was functional - but you're right, there's no longer an equivalent to Z ordered view. I think we plan on re-adding features like sorting by Z order to the object bar before 1.0... in the meantime, you can either go back to an old build if it's that important, or just hold on a bit longer

  • This error would not be caused by the fullscreen setting. It's caused by one specific plugin. It would be really helpful if you could find out which plugin is causing it, otherwise it's really hard to do anything about it.

  • 'Play' doesn't reset the position when done - you can either Set Position to 0 just before playing, or just load again on pressing space (if the cache is enabled, the second time you press space it just loads from memory so will be faster). I'll try and correct this for the next build. Also note there's an expression to get the last autoplayed channel, so you can change the pan/volume/etc of autoplayed sounds.

  • Post it as a bug report... I'm very busy these days I'm afraid, I don't know when I can have a look at fixing it, and I don't know when any of the other devs might have the chance to have a look either. I think you'll have to try and find a workaround for now...

  • There was update this August.

  • I think it's XAudio2 causing the error. If they update to the latest version of DirectX, it should fix it. Let me know if it works.