| Commit message (Collapse) | Author | Age | Lines |
|---|
| | |
|
| |
|
|
|
|
|
| |
Before there was an extra data type for rectangular rooms. This is now
changed, with the rectangle tool remaining, to create these often
required rooms faster, but the data type is just a normal polygon that
is generated from a rect to reduce redundancy.
|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The polygon room tool used a convoluted process for determining what the
user actually wants to draw. I have changed to the polygon graph
instead, which makes the checks easier and restricts the user a bit
less. In the process however I found a serious problem with my handling
float, so everything needed to change to margin compares (which I of
course should have done in the beginning. Guys, take the warning
seriously and don't ignore it for ten years like I did. It will come
back to haunt you.. apparently) instead of direct equality.
|
| |/ |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |\ |
|
| | |
| |
| |
| |
| |
| | |
Before, the deletion tool was not targeting polygons. I also took the
liberty to broaden the functionality of the surface trait, which now can
check if a rectangle or polygon is contained.
|
| |/ |
|
| | |
|
| |
|
|
|
|
| |
It's still kind of strange to use the polygon tool, but at least it
seems stable enough so I'm confident enough (and sick enough of it) to
release it into the wild.
|
| | |
|
| | |
|
| |\ |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| | |
Previously, the algorithm to check, if a line-segment is inside a
polygon did not have a special case for when the start or end of the
segment is on a polygon corner. In case this corner is reflexive,
checking against one line between this corner and an adjacent one may
not be enough.
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| | |
The math module was starting to be mostly polygon files and functions,
so those got their own subfolder to make the math module less of a mess.
|
| | | |
|
| | | |
|
| | | |
|
| |/
|
|
|
|
|
| |
When adding the polygon room tool, a problem with drawing polygons
arised. Drawing a simple, but nonregular polygon is not something that
is supported by raylib, so further additions to the math library are
needed.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
The algorithm before was really not working for a lot of edge cases and
very difficult to adapt. This version is definitely not the be-all and
end-all, but it should work for most (well, hopefully all) cases. After
refactoring and hopefully simplifying and straightening out the logic a
little more, it should be verifiable.
|
| |
|
|
|
| |
..except for one super super edgy edge case, but I wanted to get this
algorithm out into a commit before I ruin it completely (probably)
|
| |
|
|
|
| |
Fixed the last warnings and ran clippy on the project. Fixed where
appropriate and taught clippy otherwise. Now runs through clean.
|
| | |
|
| | |
|
|
|
In order to be able to save and load the map, a major rework of the code
seemed necessary, since Vector2 and Rectangle of raylib do not implement
serialize, and it seems cleanest to use the serialize/deserialize traits
of serde, to save for instance to RON. ToolShed was renamed to Editor,
since it should better show, that it does quite a bit more than harbour
tools. The map data is now centrally saved in the editor, instead of
decentralised in the tool structs.
|
