Daiz's Forum Posts

  • 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.

  • So basically, at the start of the layout, I have an event that lists the names of .dat files in a folder to a listbox, then I have an subevent that happens immediately afterwards:

    ListBox: 494 For each line

    ListBoxSet line ListBox 0 .CurrentIndex data to GetToken(ListBox 1 .LineText(ListBox 2 .CurrentIndex),1, ".")[/code:7y7v5245]

    Basically this should strip every line from the ".dat" at the end of it, but for some reason, it doesn't seem to work. It works if I change "Set line data" to "Add line", so the "For each line" is most certainly run, but it doesn't seem to edit the line data for some reason. Later, when I try to do this (still a subevent to "Start of layout"):

    ListBox: 494 For each line
System: 0 ListBox 0 .LineText(ListBox 1 .CurrentIndex) Equal to global('language')

    SystemSet global variable 'languageindex' to ListBox 0 .CurrentIndex

    ListBoxSelect line ListBox 0 .CurrentIndex[/code:7y7v5245]

    It doesn't seem to work either. I basically want to look for a line that is equivalent to the global string 'language' and set a global value called 'languageindex' to the line number of it, yet it doesn't change the value of 'languageindex' at all. Neither of these events do not work even if I put them as independent events instead of subevents.

    Any help?

    EDIT: Okay, so apparently LineData != LineText. I managed to partially fix it by changing it to LineData, but then it wasn't working when I tried to read the LineData later on. Now, the real question is: Why the heck can you not alter the actual line text?

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Bumping my own thread with some more stuff...

    Okay, the first thing which has bugged me for quite a while is the fact that when you click a button to hide / lock layer, it selects the layer. This should not happen, as if you're hiding / locking a layer, you most likely won't want to add stuff to that layer. It's a real pain in the ass when I'm working on levels with lots of layers that need to match up, then when I check an upper layer (by making it visible and invisible) the layer selection should stay at the layer I was originally on, not change to the layer I just showed / hid / locked / unlocked.

    Also, you still can't press enter as a keyboard shortcut "Finish" in the expression editor. You can do this for Next, why couldn't you do it for Finish?

  • While Construct is quite a powerful tool, there's a few usability issues that make working harder than it should be. These issues are mainly in the Event Sheet Editor.

    First of all, you can't create subgroups inside groups directly. If you want subgroups, you have to create a group outside groups and then drag it into another group. Not good.

    Another things about groups: Please add a "New event" button to the end of each group! It's incredibly annoying to try create events into right places when at worst you'll have to make them to the end or start of code and then move into the right place or copypaste another event and change conditions. Right-clicking on an event and having a "Insert event" in the context menu wouldn't hurt either.

    Copypasting actions is also working kinda funky: If you copypaste actions into a condition that already has multiple actions, the actions will be always placed after the first action, and not moved to the end of the actions.

    Creating a new event by clicking on the left side of an event and then pressing the "new event" also tends to create the event somewhere where it clearly shouldn't be, like the start or end of the code, especially if you do this with an event that's located in a group.

    One of the most important things: You can't press enter and have it register as "Finish" when creating actions! This is one of the most annoying things in the Event Sheet editor and slows down work a lot.

    Power alone isn't enough if it's a pain in the ass to take use of it, so I'd say focusing on usability issues is quite important.