R0J0hound's Forum Posts

  • Add wid_switch to the container WID_SUPPLY is part of. You probably should add all the related stuff to the container too.

    Then just remove the pick by uid stuff. That will solve your current picking issues. Without that fix, event 3 in prefabs wouldn't know which supply the switch relates to, so the first one is picked.

  • Oh it ate my message…

    Anyways, the two ways I know of to render to a texture is with a drawing canvas or with the snapshot canvas action.

    For the drawing canvas way and the amount of parts it would simplify things a lot to add all the part sprites to a family (say partFamily). Then to paste them by zorder it would be something like: 

    for each partFamily ordered by partFamily.zorder ascending
— drawingCanvas: paste partFamily

    That would use the blend modes just fine and the background would be transparent as long as the canvas started transparent before pasting.

    The second way would be to make the background transparent, snapshot the canvas, then wait till that finishes before changing anything back. That would capture things exactly as it’s rendered. To make the background transparent you’d basically have to make a transparent hole all the way down through the bottom layer. Easy way to do that could be to have all the parts on a transparent layer and make all the other layers invisible before snapshotting the canvas. Main con with that method is it will make a flicker since it has to render like that for at least a frame to snapshot.

    As to the other scaling stuff, it could be a non issue if you just render the cars at normal scale and then just scaling the image after. Or when placing parts just multiply the offsets and sizes by a scale when placing stuff. Third way would be to place everything at normal scale, then picking all the parts and scaling that. The part family would help with that. Scaling would just take a center position to scale around, a scale factor, and a few actions: 

    Set x to (self.x-centerX)*scale+centerX
Set y to (self.y-centerY)*scale+centerY
Set size to (self.width*scale, self.height*scale)

  • Collisions could be possible by using a mesh distort on a separate invisible object. For example for a polygon with N points you’d need a mesh of size (N/2, 2). Then (0…N/2, 0) would be set to the first half of the points and (N/2…0,1) would be the second half (note the index order is reversed). I say invisible because while it won’t render nicely, it will have a correct collision polygon.

    Just an idea at least. You already provide expressions for getting points so it’s something users could do.

  • You can limit the slider's position with the clamp expression with the height of the slider and the height of the slider's slot. Actually scrolling an area depends on the height of the scrollbox height and the height of the area inside it. Masking it requires some blend mode juggling. 

    frame: destination-out
spritefont: detination-over
slot: normal
slider: normal
frameOverlay: destination-over

    Then events could look like this:

    You'd just need to update the height of the spritefont if you added more lines.

    c3p example here:

    dropbox.com/scl/fi/ela3v0bemybwdwzamyows/scrollbox.c3p

    The amount of vertical scrolling is semi arbitrary, but you could calculate it to only be a few lines at a time instead of a percentage.

  • Maybe something like

    Every tick

    —sprite: set frame to self.framecount-1-(time*self.animationSpeed)%self.framecount

    The speed has to be a positive value but that would play the animation in reverse order.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Probably the closest C3 feature is "custom actions" which are like functions that are attached to an object type. It's just as easy to add as an actual function. Right click on the event sheet and select "add function" or "add custom action".

    Besides that, you could probably implement the logic in some different ways that work better with C3 events. For example, You could skip functions entirely, or only use them to not have duplicate stuff.

  • If the squares are sprites it’s just a matter of looping over them in order. You can use “for each ordered” to do that or if you placed the instances in a specific order then a normal “for each” could work.

    One way to do the events could look like this: 

    Var out=“”
Var x=0
Var y=0

On button clicked
— set out to “”

On button clicked
For each sprite ordered by 1000*sprite.y+sprite.y ascending
— set x to loopindex%8
— set y to int(loopindex/8)
— add (x=0)?”BITMAP “””:”” to out
— add sprite.animationFrame=0?”.”:”#” to out
— add (x=7)?””””&newline:”” to out

    Or basically loop over the squares a row at a time and output a . Or a # depending on the frame. Then, as citron mentioned, just add the Bitmap, quotes and newline when at the start or end of a row.

  • The actions that call the function are the ones to look at if you want to know how it specifies the uid to use.

    Since c2 functions don’t know what was picked when you called them you often need a way to specify what instance to pick. Passing an object’s uid as a parameter is one way to do that.

    As a minimal example it could look like this: 

    On function: “rotate90”
Sprite: pick by uid function.param(0)
— Sprite: rotate 90 degrees

Start of layout
For each sprite
— call function “rotate90” (sprite.uid)

  • That’s a pretty cool idea. Erase a hole and draw in the hole. I’ll be adding that to my toolset.

    Edit:

    Main limitation of that method is the mask needs to be completely contained within the object's pixels. And it doesn't work on transparent layers with force own texture. Still pretty cool.

  • You’re probably referring to the scissor cut feature that webgl has that was one of the things that c3’s renderer batched. It was never an sdk feature, but a way to use it was found before sdk2 (which walled a lot of stuff away). Anyways, all it did was limit rendering to a bounding box on the screen. I don’t think that really helps solve the masking issue unless all you want to do is mask by a rectangle.

    The issue you have is the mask isn’t covering all the objects underneath. Using layers you can effectively first draw the mask to a full screen texture and use the blend mode on that.

    You can do the masking by having a layer with two sub layers. You’d put all the objects you want to mask in the first sub-layer, and the mask object in the second sub-layer. Just have normal blend modes on all the objects, but use the “destination in” blend on the second sub-layer itself.

    You could likely do it by drawing objects to a drawing canvas as well. But you’d still need two of them since you need to make the mask cover everything you want to mask.

    I don’t think it’s really something that’s feasible to do from the sdk from what I can tell.

  • The browser doesn't provide much control with how it rasterizes text. Unless Construct wanted to do their own rasterizer with the freetype library or something like that.

    Here's an updated example that draws text and outlines using an sdf based sprite font. It's a tad simpler than the previous one, but lets you specify font size and colors. Only issue is there are some limits with how big of an outline you can have depending on the generated sdf image.

    dropbox.com/scl/fi/tt071d610pfzqfyda8czj/tiledbg_based_sdf_text_with_outline.c3p

  • If you only have a limited amount of text like that you could just pre-draw the text to images. I'm sure there are programs with font rasterizers that don't glitch like the one in some browsers.

    If your text can be a lot of different things you could instead try using a spritefont to do it. To do the outline you'd have two spritefonts, one for the outline, and one for the normal text. You'd just draw the outline first and place the text over it.

    Here's a test of that idea. I didn't use a generator that is easily adaptable to the spritefont object, but it's simple enough to use a tilebg to draw it char by char. There is some tighter kernelling in the json, but I didn't bother with that. The outline width is baked at 10px.

    dropbox.com/scl/fi/lzm4uaui3n7vs34tqt08v/tiledbg_based_text_with_outline.c3p

    As an exercise you can make the text scalable. You just need to multiply most values by a scale number. However, that would change the outline width as well.

    You could also extend the idea by using an sdf spritefont. There is a threshold effect that could be used to convert the sdf to crisp letters. Also, you could use the same sdf to draw outlines with dynamic widths. You'd have to test to see if that effect is up for the job.

  • This looks familiar somehow...

    What we do know is an outline effect works by coloring transparent pixels if there are pixels around it that aren't transparent on the texture.

    Maybe since the effect samples pixels far from the pixels on the sprite it could be sampling pixels from other sprite sheeted images.

    So maybe the effect isn't clamping the sampling to to just within the current sub-texture.

    If that is the case then either the effect could be modified, or we could take advantage to how the c3's effect compositor works to avoid sampling beyond the frame (sub-texture). You could do that by adding another effect to the object, and order that to be before the outline effect. When there are multiple effects the first effect is drawn to a temporary texture and that is used as input for the next one. With that nothing would be beyond the image to possibly sample.

    Anyways, just an idea.

  • If you're just doing it in events without behaviors, you will also need to handle the collisions with events too. That involves checking for an overlap with obstacles and then moving out of the obstacle and maybe updating the velocity.

    There are many ways to do that, but one way to do an event based movement for a jump with gravity would be: 

    on any key pressed
-- sprite: set vy to -100

every tick:
-- sprite: add 100*dt to vy
-- sprite: set y to self.y+vy*dt

sprite: y > 400
-- sprite: set y to 400
-- sprite: set vy to 0

    That last event acts as the collision detection and response for a ground at y=400. Likely you'd want to collide with actual objects but that would get more involved.

    One possible solution could be to move backwards till no longer overlapping. or in the case of landing on some ground you'd move it up. 

    on any key pressed
-- sprite: set vy to -100

every tick:
-- sprite: add 100*dt to vy
-- sprite: set y to self.y+vy*dt

sprite: vy>0
while
sprite: overlaps ground
-- sprite: set y to self.y-1
-- sprite: set vy to 0

    You'd likely want something similar when moving up, left, and right, just need to go backwards by pixel steps (or smaller steps to have smaller gaps). A common technique is to handle horizontal movement first, then vertical movement.

    Instead of moving backwards in steps it is possible to calculate exactly how far to move the object to not be overlapping, but that's less trivial to do.

    You could also utilize a behavior that has control turned off as a quick way to handle the collision response for you, but you get less control, and usually they work better when it's that behavior that moves the object.

  • You only need to access node transforms. Objects and bones are just nodes in glb files.