R0J0hound's Forum Posts

  • Sure there is, it's called math.

    The normal way to manipulate 3d points is to just change around the x, y, and z values to transform them. Then you use a perspective transform to map them to the screen.

    You can read about vectors and matrices for the nitty gritty of the math.

    To move you can just add numbers to the position to move them.

    To rotate look up 2d rotation for a formula to do it.

    Scaling is just a matter of multiplying the position by some values.

    For rotation and scaling it's always done around the center 0,0,0. To do it around some other point you need to first move everything over so the rotation point is 0 then after that move the points back be the same amount.

    Perspective in it's basic form is just dividing the x and y by the z.

    You can look around the forum for a few examples. Search for "pseudo 3d" with my username for some various examples. There's also some examples in the tutorials.

  • Looking at the source it uses a pixel array of the canvas and set's pixels individually for all drawing. It doesn't use any of the higher level stuff such as drawImage like most other games in html5 uses. In that regard it's very different than C2. The advantage is it can do those oldschool pixel effects like old dos games, for example the level transition and the dripping blood. Also do to it being low res without any scaling or rotation, per-pixel collisions can be used everywhere. The disadvantage is it has to be low res to keep up the performance, and there is no rotations or scaling of the sprites. Also no doubt they do a lot of tricks to keep things as fast as possible.

    What I got out of it that we might be able to use in C2 is a way to access pixels individually. The canvas kind of does this but things are inefficient. Basically reading pixels is pretty slow but it's much faster to write pixels, although it's probably not compatible with html5's other drawing methods. So maybe a plugin that allows you to manipulate an array of pixels that you can then copy to a texture. Only if events had zero overhead would it perform as well.

  • Here's a python library I made to do it.

    It's basically one for one what cc does when it saves. I've used it to do various things but editing events isn't really a simple thing to do, because .cap files don't store ACEs in a way that's easy to use. It's mainly just numbers and in order to decode it you need to be able to load the plugins to get at the text and such, but I haven't found a good way to do that yet.

  • It's basically soft body dynamics and i've fiddled with it

    here:

    and here:

    It's more like jelly than putty, but I suppose with a lot of tweaking you could correct that. Having two soft objects collide is not solved in either of those capx, so that would need to be done. To do that you'll need some ingenuity of find a paper that has a existing method.

    On the graphics side, the ways you can manipulate sprites is limited to resizing and rotation, although you could do distortions with the paster behavior.

  • lukezero

    I briefly mentioned how above and here is an example:

    https://www.dropbox.com/s/mzjg78cf38zqa ... .capx?dl=1

    /examples27/scratcher_canvas_with_percent_clear2.capx

    The issue is it's slow to check all the pixels in the canvas. I first tried the .AsJSON method but it would make the game freeze up for too long while checking. Next I used the .AlphaAt(x,y) expression, but only checked so many pixels per second to even it out so it wouldn't freeze. The draw back is it would take a bit to check all the pixels. What I settled on was to first paste the canvas to a lower resolution canvas and check the pixels on that so we could do it per frame.

  • It's "this.runtime" that's undefined. The minifier changes the name of "runtime" to something else. The only fix would be to do it in the plugin I suppose.

  • Ashley

    It must be, but no worries, it's purely cosmetic and isn't too bothersome. I'll keep an eye out for a working solution though.

    In regard to buggy drivers I read this post by a guy who worked on nvidia drivers for a bit. It turns out when they update the driver they not only fix bugs in the driver but they also make patches so games relying on the broken driver can still work. It's both fascinating and frightening.

    http://www.gamedev.net/topic/666419-wha ... try5215019

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Webgl2 just is a 2nd iteration of webgl witch is more like newer versions of opengl which can take advantage of newer graphics card features. It will be a while before it's as widespread as the current webgl. I'll maybe get more excited about it when webgl is better supported. Support on my system has been doing the opposite of advancing with newer versions of chrome and firefox completely blacklisting my graphics card so I can't use webgl at all unless I use older versions.

  • You could also do something tricky like this:

    https://dl.dropboxusercontent.com/u/542 ... ctoe2.capx

    But really tic tac toe is rathar simple although tedious. I like to opt for as few object types as possible but you could just as well just make a sprite per location.

    Each sprite will have 3 animation frames "blank", "x" and "o". Be sure to set the animation speed to 0 so the frames don't change.

    Placing an x or o is just a matter of using the event:

    on sprite clicked

    --- set animation frame to 1 or 2

    I used a variable to keep track of whose turn it is, and switched it every time a player placed a piece.

    global number turn=1

    on sprite clicked

    --- set animation frame to turn

    --- set turn to 3-turn

    Setting turn to 3-turn is just a simple way to toggle turn between the values 2 and 1.

    Next comes the tedious part of checking for a win. It's very simple in concept, just look at each row,column and diagonal and see if there's three x's or o's in any of them. This is where you choose an approach you like.

    One way is to use an array that you set from the visible x' and o's. This then makes it simpler to write like other programming languages, so you can check certain locations.

    Here's an incomplete example of a very verbose way of checking for each win, for each player.

    https://dl.dropboxusercontent.com/u/542 ... ctoe3.capx

    Using loops help a lot to simplify things, and blackhornet's tutorial does just that.

    Another way as I have done is to utilize picking to pick a row, column or diagonal in some way like I did.

  • Thanks for the quick fix, but unfortunately I just tested the update and there's no change, the sprite still becomes invisible. So I guess that wasn't the issue in this case. Still it was worth a shot anyway.

  • Problem Description

    On older ati cards (ones that you can't get a driver for newer than 2010) sprites with non-power of two textures become invisible when you make them smaller.

    Attach a Capx

    https://dl.dropboxusercontent.com/u/542 ... e_ati.capx

    Note: this is a ati driver bug so you likely can't reproduce.

    Description of Capx

    This just a sprite with a 200x200 texture resized to 50x50. The result on my radeon x1200 series card is the sprite is invisible.

    Steps to Reproduce Bug

    • Step 1: Create sprite with a non power of two texture size.
    • Step 2: Resize the sprite smaller till it fades to invisible

    Observed Result

    When in the editor and I resize a sprite that has a non-power of two texture, it becomes invisible after shrinking it to a certain size.

    Expected Result

    I would expect the sprite to not become invisible.

    Affected Browsers

    N/A, it is a editor issue.

    Operating System and Service Pack

    Windows vista sp2

    Construct 2 Version ID

    r205 32bit

    Proposed Solution

    The bug has been reported a few times before and always has been closed as a driver bug, which is understandable since something like this is near impossible without being able to reproduce it. But recently I was working on something else in opengl where stuff was invisible and found the cause and a solution.

    Basically the mipmaps aren't being created when using glGenerateMipmap due to an ati driver bug. Usually the solution is to update the drivers but that is impossible on cards like mine. I then stumbled upon this which gives a solution that worked for what I was working on.

    https://www.opengl.org/wiki/Common_Mist ... generation

    [quote:xzoylwwc]Warning: It has been reported that on some ATI drivers, glGenerateMipmap(GL_TEXTURE_2D) has no effect unless you precede it with a call to glEnable(GL_TEXTURE_2D) in this particular case. Once again, to be clear, bind the texture, glEnable, then glGenerateMipmap. This is a bug and has been in the ATI drivers for a while. Perhaps by the time you read this, it will have been corrected. (glGenerateMipmap doesn't work on ATI as of 2011)

  • You could also do something like this:

    choose(0,180)+random(-1,1)*45

    If 45 is two wide reduce it to a smaller number.

  • I don't think the "for each" would be the issue. I'm kind of curious if the "or" us throwing it off when combined with the drag n drop behavior. It shouldn't though. Actually it could be the drag n drop behavior isn't correctly handling multiple objects being dragged at once.

    Until we can prove that one way or another we could get rid of the dragndrop behavior and do it ourselves with events. Like so:

    on sprite2 touched

    --- set id to touch.id

    --- set dragging to true

    dragging is true

    for each sprite2

    --- set position to (touch.XForID(Sprite2.TouchID), touch.YForID(Sprite2.TouchID))

    on any touch end

    pick sprite2 id = touch.id

    --- set dragging to false

  • Yeah that's the changes as I described. Can't see what's amiss. I'm unable to test. :/

    Ok, the general idea for multi touch is each new finger press has an id.

    When you touch a sprite2 the current is saved in a variable so you know which sprite2 goes to what finger.

    The code above is supposed to loop over each sprite2 and basically move to the closest point on the circle near that sprite2's assigned finger.

    But if it doesn't work then I'm kind of stumped until I do some testing on a multi-touch device.