Drasa, exactly.

Scidave, I'm not specifically trying to achieve the kind of "force field" I described, I just thought of a random example that wasn't "destructible terrain".

It doesn't - that's the whole point. If you place an object that doesn't have a solid attribute on top of an object with a solid attribute, the solid attribute still applies at the parts where the objects overlap. With this kind non-solid attribute I'm describing, it'd mean that the solid attribute of the object underneath wouldn't be in effect as long as the player is overlapping the object with the non-solid attribute.

So for example, if you'd create a player sprite and put a "force field" around him that doesn't have a solid attribute, you'd still be stopped by objects with solid attribute. If you put this kind of non-solid attribute to this "force field", it'd mean no solid object would stop the player, as the solidity is getting cancelled by the non-solid "force field" around the player.

So what I'd basically want is a non-solid attribute. What would it do? Basically it means that if you have an object that has the solid attribute and then put another object on top of it with a non-solid attribute, you can then move within the object with the non-solid attribute. This would basically allow destructible environment without the usage of Canvas object, making destructible environment much more feasible for large layouts.

A commissioned work me and my friend have been creating for a school: It's basically an isometric exploring game where you can walk around the school, talk to people, explore things (like how you can take a look at the pool table, it'll pop up a vectorized / stylized photo of it along with some information).

The game is about 99% finished at the moment, it still needs some minor bugfixing and we're looking into getting it translated into a couple more languages (right now the game is in English, Finnish and Norwegian, we intend to have at least Swedish and Hungarian in addition to these).

My friend does all the graphics, I do the code, we've both worked on the levels. I have to say, isometric is an absolute bitch to work with, but damn, the result looks pretty nice.

And now for the screens:

<img src="http://planar-studios.com/img/niilu_screenshot_1.png">

<img src="http://planar-studios.com/img/niilu_screenshot_2.png">

<img src="http://planar-studios.com/img/niilu_screenshot_3.png">

<img src="http://planar-studios.com/img/niilu_screenshot_4.png">

> also you can check 4 events at a time instead of just 1.. Something like a block of events

>

It's nowhere near that simple - multithreaded programming is a pretty complex area. If one of the events in any way depends on a result from a previous event, or in any way writes to or reads from any part of the computer's memory that is also accessed by one of the other events being executed, it will not work (due to out of order execution). Since events are defined as always being run from top to bottom, it's pretty difficult to thread that, since I reckon almost all events will depend on the events before them being completed.

I was actually thinking about this a while ago, and thought about something like possibly having separate "core event sheets", so to say, which would be run in parallel and if there are not enough cores for the various "core sheets" the user could define the order in which they are executed.

With separate event sheets the fact that you can't rely on events in the other core sheets would be clear for the end users and I think it would make multi-threaded event running pretty understandable for pretty much anyone too. From what I've understood from multi-core programming, you'd have to wait for all the core sheets to be executed before going through them again, but even if you'll have to wait for the slowest core sheet to be processed it'd still be faster if other parts of the code have been gone through already.

Then the users could just code some independent parts of their code in these "core sheets" - like AI processing in one core sheet, etc. I can't really say how useful it would be in the end, but I think it would have potential.

Rich, what I basically wanted to do was turn a list with this:

english.dat

finnish.dat

Into this:

english

finnish

I figured out that LineData is separate thing from LineText, but now my question mainly is that why can't I alter the actual LineText, only LineData?

Construct in general is missing quite a lot of things in regard of creating applications (and using application rendering), but those really belong to a separate topic, and this particular problem was about doing a multilingual game. In any case, I managed to get around this by adding my edited lines to another ListBox, but in the future it'd be nice not to have to do this.

Yeah, I know. Then again, floating position scrolling was actually broken before as well: It just became worse in 0.99.3.

Well, rounding the X&Y positions of visible sprites fixed the problem for him too, so floating positions of sprites seem to have caused the error for him.

The sprites do have large blank space around them (larger than 1px) so this could be probably done but considering that the game has like 500 sprites it would indeed be quite a hassle - in any case, all the rendering problems are now fixed.

Also, Ashley, I didn't notice that things were so broken because I was working in a layout with no scrolling - we only noticed it after lots of additions.

In the end though everything is actually better than before since now even all the minor rendering flaws caused by floating point scrolling that were in the previous builds are gone, making the end result look better than before.

Oh my god, round() did the trick. Everything works perfectly now!

Except for my friend is still experiencing some weird rendering issues, like pictured below:

http://img190.imageshack.us/img190/7717 ... eringw.png

Any idea what could cause it? Surely float X/Y position of the sprite shouldn't be an issue?

1. No, the game does not use the Window object at all.

2. No, everything is 100% - no zooming is used anywhere.

3. No, Z features are not in use.

Basically it seems that the position and scale of sprites is flickering and changing constantly when moving for some reason, but why would scrolling cause this?

That's an ingame capture, so it's certainly not only in the layout editor

In any case, resizing those particular walls a bit solved the problem for them, but then there's the general funkiness of drawing that causes problems like this:

http://img13.imageshack.us/img13/158/horrifying2.png

Notice how the level edges are all dented (when they're supposed to be straight), it happens at certain locations, and when moving, the graphics constantly "flicker" between broken and non-broken for various things. At one point, the drawing of some sprites is broken, in another point, the drawing of other sprites is broken. This has happened at a minor scale so far with previous builds too, but in 0.99.3 it's more broken than ever.

And I wanted to use the new features of 0.99.3 - in retrospect, I shouldn't have.

EDIT: Also, basically all sprites use the alpha channel (in other words, they have antialiasing drawn to the sprites itself). Could this be part of the cause?

Okay, so I'm at the verge of despair right now, because me and my friend have been working on an isometric game. Then we upgraded our Construct to 0.99.3, and coded quite a lot of things. Now we notice that it has horribly broken a lot of the graphics in the game:

http://img13.imageshack.us/img13/9471/horrifying.png

The walls have been positioned right next to each other with array paste. They're not the only thing that are broken: Other sprites appear horribly mangled and look disgusting.

What on earth changed in 0.99 that basically completely broke rendering of sprites right next to each other? Is there any possible way to fix it, as this is quite a letdown for us, especially since the game is like 99% complete - we'd have to go back to about 80% were we to restart work from an earlier build.

We've been using V-sync (which makes the game run at 60FPS for both of us) with Point sampling all the time. Setting the game to run at Unlimited fixes the problem for me, but not for my friend, and I wouldn't like to use this as a solution anyway.

What on earth could we do? Putting "padding" walls behind the walls that are broken would only partially solve this - some sprites would still be mangled. Is there any possible way to make newer construct caps openable in older builds, particularly 0.98.9?

This is seriously the worst thing that has happened to us with this project. Any kind of help would be appreciated.