Alright, thanks for the help. I actually just tried an experiment and it worked out marvelously. It doesn't use anything too complicated, it uses the grid snapping I mentioned earlier. All I did was add detection for how close the mouse cursor was to what would be considered a "corner" in the nonexistent box that snaps to the mouse and shift the current tile coordinates by values that I know are correct. For instance, if you are closer to the top right corner of the box, it shifts right by half the width and down by half the height.
Posts by Warguy555
Welcome to our brand new Clickteam Community Hub! We hope you will enjoy using the new features, which we will be further expanding in the coming months.
A few features including Passport are unavailable initially whilst we monitor stability of the new platform, we hope to bring these online very soon. Small issues will crop up following the import from our old system, including some message formatting, translation accuracy and other things.
Thank you for your patience whilst we've worked on this and we look forward to more exciting community developments soon!
Clickteam.
A few features including Passport are unavailable initially whilst we monitor stability of the new platform, we hope to bring these online very soon. Small issues will crop up following the import from our old system, including some message formatting, translation accuracy and other things.
Thank you for your patience whilst we've worked on this and we look forward to more exciting community developments soon!
Clickteam.
-
-
I don't quite know how to translate the conversion into Clickteam Fusion stuff. That's probably one of the main sources of trouble here. I noticed that snapping to half the width and height of the tile gets close, but leaves situations where the snapping isn't fully correct. For example, a 32x16 tile is snapped to (XMouse/16*16, YMouse/8*8). That makes the tile end up in the correct position sometimes, but it can end up in between isometric tiles and isn't properly aligned to the grid. Is there a way I correct what I currently have so it could be used?
-
So, I have had a few issues trying to accomplish pixel isometric grid snapping. I seem to be screwing up some part of the calculation every time I try to do some semblance of grid snapping. I also tried asking the unofficial Reddit page how to do this and, rather frustratingly, my post was flagged as spam. Ideally, I'd like to have snapping that works for tiles of any dimension (or ratio). Currently, I am using tiles that follow a 2:1 ratio of width to height (32px wide and 16px high). Can someone explain how I can get these tiles to properly snap to the mouse coordinates? I'm really having trouble getting it to work and am not that great with certain math stuff. As an extra note, I want it to be a "staggered" isometric grid.
-
Thanks for pointing me in the right direction, Kritter!
-
Does anyone know how you would go about making a segmented worm-type enemy similar to the Eater of Worlds, Wyverns, or Dune Splicers from Terraria? Essentially, for those unaware, they have segments that follow the position and angle of the one in front of them without any gaps in-between them. I also want to have multiple instances of this type of enemy so arrays will not work.
Here are some reference images:
Please login to see this attachment.
Please login to see this attachment.
Please login to see this attachment.
-
Here's a google drive link to the "final" version of the palette swap shader that I wrote for CTF 2.5. Let me know if you have any trouble with it and I'll get right to fixing it asap.
Please login to see this link.
-
Fair enough. I didn't think about doing that with a separate image to get the dimensions for use with the shader parameter. Oh well, at least the shader actually works properly now. Thanks for the input, MuddyMole. Anyway, I am going to finish cleaning up the shader and I'll release a finished version on the Reddit page and possibly in a new thread on the community page.
-
UPDATE 5/20/2021:
I fixed the issue I was having. It was related to the compiler and it works just fine now. Even so, the user has to directly enter the height of the palette image input parameter. That is not desirable but it works. Does anyone know a way to get the height in pixels of an image from a texture/image input inside a shader like that?
Consider the following, a user has to enter 21 if the texture is 21 pixels tall. I want the shader to automatically get the height of the image input parameter so the user only has to enter one numerical value instead of two.
-
I recently wrote a palette swap shader that is functional, I just don't like how you have to specify the v coordinate on the palette. I posted the shader on the unofficial Clickteam Fusion Reddit page and got no response on how to fix the issue. Essentially, the palette image is an image with the x amount of pixels representing the number of colors in the palette, and the y axis is supposed to specify which palette to use. The problem is I want to use the y/height value to determine which palette to use from the image parameter. Currently, you have to manually type in the v coordinate from the UVs instead of just a simple integer that does the math automatically. Does anyone know how to perform such an operation?
Reddit Post:
Please login to see this link.Files:
Please login to see this attachment.