Get mouse coordinates on a rotated "grid"

Show off your games, demos and other (playable) creations.
User avatar
Jasoco
Inner party member
Posts: 3725
Joined: Mon Jun 22, 2009 9:35 am
Location: Pennsylvania, USA
Contact:

Re: Get mouse coordinates on a rotated "grid"

Post by Jasoco »

dusoft wrote: Fri Mar 15, 2019 8:20 pm Maybe also check this:
http://clintbellanger.net/articles/isometric_math/
It's not Isometric though. It's free rotation. Isometric math only accounts for a specific angle. But it will come in handy if I ever want to do isometric again.
Nelvin wrote: Fri Mar 15, 2019 9:52 am Hm so far haven't used it (my game is built using 0.10.2) but I've just tried a small hacky version and it seems to work as expected. See the .love file attached.
It works both, using the transform object and the helper function of love.graphics. The one in love.graphics obviously only as long as it represents the desired state, i.e. if you push/pop in your love.draw at the end and try to transform the coordinates somewhere else, it won't work.
This seems to be the most promising. It's not working properly with my current transform settings but it does feel like it'll work once I figure it out. Possibly. (At least I have my trusty getPixel-based system if I can't figure it out.)

Edit: I got it! I was having a problem for a while. I couldn't get the transforms in the proper order to make it match up but I figured it out. Thank you so much guys! I didn't know the functionality I needed existed in Löve already and I'm so glad it does.

Now I just have to figure out what to do with this cool engine I have.

poke1024
Prole
Posts: 6
Joined: Tue May 01, 2018 2:25 pm

Re: Get mouse coordinates on a rotated "grid"

Post by poke1024 »

You should be able to use
https://love2d.org/wiki/love.graphics.i ... sformPoint

Something like:

setup_your_transforms()
draw_your_world()
gx, gy = love.graphics.inverseTransformPoint(love.mouse.getX(), love.mouse.getY())

gx, gy should then be coordinates of your (innermost) rectangle.
User avatar
dusoft
Party member
Posts: 492
Joined: Fri Nov 08, 2013 12:07 am
Location: Europe usually
Contact:

Re: Get mouse coordinates on a rotated "grid"

Post by dusoft »

Jasoco wrote: Sun Mar 17, 2019 3:55 am
dusoft wrote: Fri Mar 15, 2019 8:20 pm Maybe also check this:
http://clintbellanger.net/articles/isometric_math/
It's not Isometric though. It's free rotation. Isometric math only accounts for a specific angle. But it will come in handy if I ever want to do isometric again.
Sure, but 45 degrees could be easily changed to any degrees and calculation algo is similar.
User avatar
Davidobot
Party member
Posts: 1226
Joined: Sat Mar 31, 2012 5:18 am
Location: Oxford, UK
Contact:

Re: Get mouse coordinates on a rotated "grid"

Post by Davidobot »

Really cool little engine! Do you use the new 11.x features for it, or 2d-voxels?
PM me on here or elsewhere if you'd like to discuss porting your game to Nintendo Switch via mazette!
personal page and a raycaster
User avatar
Jasoco
Inner party member
Posts: 3725
Joined: Mon Jun 22, 2009 9:35 am
Location: Pennsylvania, USA
Contact:

Re: Get mouse coordinates on a rotated "grid"

Post by Jasoco »

Davidobot wrote: Mon May 06, 2019 5:41 pm Really cool little engine! Do you use the new 11.x features for it, or 2d-voxels?
It's just using normal Löve transform stuff, but obviously the mouse position stuff is 11 only I think. Either way it's just drawing transforming and drawing large images multiple times layered to give the effect of 3D or voxels. The problem is that it's very very taxing. While Löve can draw thousands of small images pretty fast, trying to draw a bunch of really big images is really slow. So it limits the size of the world I can draw. Plus obviously every "pixel" in height is a single image drawn multiple times to fill in the whole pixel height then there's like 16 or 32 layers in height to draw so you're looking at a lot of images. Then there's also the entity layer where each entity that is mobile (i.e. not part of the world itself) would have to be redrawn for every layer of the 3D sprite stack.

It's just a silly experiment I was working on. If I keep the world size small, like 64x64 tiles, I could make a puzzle game or have a world that's just broken into pieces and it would still run nice and fast.

You have to remember. Each tile is 16x16 pixels. Then the world is 64x64 or 32x32 or whatever so you're at 16 * 64 = 1024 ^ 2. Then you have to do it 16 times for each layer on the Z axis. (Or Y axis if this were actually a 3D engine as Y is always the up and down and Z is back and forth but that's another subject) So you have 16 1024x1024 pixel images being drawn about 6 times for a total of 96 large 1024x1024 images PLUS the entity layer which is the same exact thing PLUS the ground layers that I haven't even mentioned yet. So upwards of 200 large images for a 64x64 tile world. Shrink it to 32x32 and you cut it into 1/4th the amount and it's a bit faster. Not to mention I have a dGPU in my MacBook Pro so who knows how it will run on most machines. lol

Either way it's a fun project and I would love to actually do something with it some day. Most recently, as of months ago as I haven't touched it in a long time, I was working on A* pathfinding which makes it even slower if you have a large world and need to find a path from one corner to the other. So a smaller world is better for that. I have an A* library I've been using that I edited to support coroutines but it still causes slowdown and longer frame times. So I need to find one that can work with Threads instead possibly. A way for each entity to start up its own thread, sit and wait in the game loop in a "waiting" state while it waits for the thread to finish finding the path and sends it back to the main game thread.
User avatar
raidho36
Party member
Posts: 2063
Joined: Mon Jun 17, 2013 12:00 pm

Re: Get mouse coordinates on a rotated "grid"

Post by raidho36 »

You can optimize it by drawing each Z layer into a canvas without drawing images multiple times to simulate thickness, and then draw the canvas to the screen while using a shader that will sample up to certain number of pixels above its current pixel if there's nothing there. This will "extend downwards" all bottom edges a certain number of pixels. Or indeed you can use actual 3d models for this, which will work the fastest.

A* speed can be improved by using jump point search. Additionally, if you don't particularly care about shortest possible path but rather shortest possible search time, you can give it stronger distance function, so that it will always try closest squares first - which usually works just fine even in mazes, but is many times faster than "complete" search.
Post Reply

Who is online

Users browsing this forum: No registered users and 42 guests