LÖVE

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.

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.

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.

Really cool little engine! Do you use the new 11.x features for it, or 2d-voxels?

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.

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.