Ashley's Forum Posts

  • [quote:ylkky4wy]You know, the more I think about bounded scrolling... rotating and zooming seem to be implemented with unbounded scrolling in mind

    You're right, really - there are some relatively tricky problems with bounding and zooming/rotating. Firstly the maths becomes a bit of a headache with bounding limits. Secondly, you have to think about layers, which is the cause of the bounded zoom not working as you want. It's a known problem - it works fine in the middle of a large layout even with bounded scrolling, it's only when you come to the edge of the layout. Since you can zoom layers independently, then zoom the entire display, if you zoom in to 200% the display could be zoomed to 50% which means you still have to have the usual bounds. When bounded scrolling is on, it should never display anything outside the layout boundaries. It's possible to detect this situation though, so I can probably fix it (it's just a bit boring, heh).

    The 180-degree quirk is a rounding error, yes. I thought I fixed it, but I guess not - when you rotate the screen 180 degrees the math sometimes has rounding errors like being 0.00001 of a pixel outside of the layout, which counts as outside the layout, which means go back to 0 degrees. Again annoying to fix. Of course the easiest workaround for all in the mean time is to use unbounded scrolling, and add your own scroll boundaries (possibly just as solid objects or something the player can't move past).

  • for example is 'Compare private variable' condition evaluated for every object of the required type every cycle, or only when the variable actually changes

    All events except triggers are evaluated every cycle for each instance. It still performs very well. Also, often events don't impact performance anyway.

    [quote:xuxvomh8]On the other hand, this "scroll first, zoom later" thing seems a bit counterintuitive

    Huh? What do you mean? As far as I know, zoom works relative to the scrolled position, so at any zoom level with unbounded scrolling, the object you are scrolling to should always be in the centre. Maybe there's a bug stopping that from working normally. Upload a .cap perhaps?

    [quote:xuxvomh8]

    Split screen games aren't currently supported, unfortunately, and as far as I know there's no way to do what you want with multiple views.

    Aw, it's a pity. Well, Rome wasn't built in a day... By the way, is it possible to implement it as a plugin via SDK?

    It could probably be done, but the runtime would need a few changes. I was hoping the Layout object (which can display a different but not the same layout) could be upgraded to do this soon.

    [quote:xuxvomh8]I could add it to the wiki, if you like

    Please, feel free to edit the wiki. The more people add to the wiki the more time I can spend coding instead of documenting. You'll need a SourceForge account to edit (and I need to pre-approve you so let me know your SF username).

  • I think only certain motherboards support it. Check the features/manual/whatever, it should tell you if using two RAM sticks instead of one is faster. If it doesn't support it, I guess it wont make a difference.

  • Looks like a bug in the box-on-fine-collision test. For now, just use per pixel for both as a workaround - the performance is still very good with per pixel.

    Can you submit it as a bug to the tracker?

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Yeah I like dkdoom's versions, I'll make it an option anyway so it won't change the default.

  • XAudio2 was only recently released in a DirectX update, so we kind of have to guarantee everyone has the latest DirectX so sound can work. Also, newer DirectX updates have newer D3DX builds which have bug fixes. Still, the more time that passes by, the less of a problem it'll become. I might be able to figure out a way to compile the runtime with the DirectX update built in so it wouldn't be a problem.

  • Done an article on Construct keyboard shortcuts. See it here:

    Keyboard Shortcuts

    (That's not https this time )

    Even I didn't know a few of these, so check them out! One or two (involving the Enter key) are implemented in the next build, so they won't immediately work in 0.98.3.

  • Hey everyone,

    We're thinking about changing the look of the event sheet editor, to a new 'clean' skin. Here's a preview:

    Events before

    Events after

    Do you like the new skin better? I think it should be an option anyway, but which should be the default? Could anything be changed to make it better? Feel free to draw some mockups if you want to come up with your own design, too. There's no proper 'skinning' engine on the event sheet editor yet, so it'll be difficult to change it significantly from what it already is, so bear that in mind.

  • Just to add a bit more info to what others have already said:

    1. Most behaviors have their own actions, conditions and expressions. You can access these through the tabs that appear when the object is picked in the event wizard dialog.

    2. I think the best solution for now is to use the function object. You could use a function like "SpawnEnemy" which spawns the enemy and does the startup actions on it. I thought about adding 'On created', but didn't think it'd be useful since it's identical to following the create object action with other actions. Maybe you're right though - I'll see if I can add it.

    3. I think in the latest builds the Tiled Background can scale the texture inside, but only if it's a power-of-two sized texture (eg. 128x128, 256x256...)

  • Try doing it when timer equals 500ms or something instead. That should work OK. I'm guessing it's just start of layout that doesn't work.

  • It was two lines in the source code, heh. All I had to type was this:

    		// Family passed: pick a random sub-type
		if (pType->IsFamily())
			pType = pType->teams[(unsigned int)(Random() * (double)pType->teams.size())];[/code:8mcyr0hx]

No problem to add little things like this

  • Yeah, I can get Physics going in pixels-per-second when I figure out the math, but it would change every existing .cap...

    You divide by timedelta because you want to apply a total-force-per-second, not a force-per-frame. For example (picking easy numbers), say you want to apply 10 newtons/second of force. At 1 fps, that's 10 / 1 = 10 newtons per frame. At 2 fps, that's 10 / 2 = 5 newtons per frame, which adds up to 10 newtons per frame again.

    Physics itself is a bit fussy about floating point precision and framerates. Generally it's stable in the 30-120fps range. Outside of that I think you'd start getting weird rounding errors in the timestep.

  • There's no issue to having as many angles as you want in Construct (or shouldn't be, anyway, unless there's a bug). Hopefully we can get this implemented.

  • One day I'll remember the http thing...

  • Allow multiple decks. This probably shouldn't be runtime-editable because removing a deck in mid-air is messy and underdefined. A property "number of decks" that defaults to 1 seems more plausible. Also, I don't expect users to want to know which specific deck a card came from; so a "draw pile" with two decks could simply(?) have two copies each of the numbers 1..52.

    Couldn't you just use separate Card Game objects?