controller terminology. Part of #197.
Holding off on touching PhaseType and all of the serialized
seattle_traffic_signals format, since this will all change in Kyle's PR
anyway.
* maintain whitespace in text (except trailing)
Note, until https://github.com/RazrFalcon/resvg/issues/317 is addressed,
trailing space does not affect the size of the text bounding box.
* remove space-holders now that spacing is preserved
not split by direction. Update many callers, and lock down the
visibility of the old methods.
Tested a few maps manually to make sure there's no behavioral diff. Only
problem right now is the z-order of adjacent lanes covering up half of
the white stripe sometimes. Have some ideas to fix that later, and not
_super_ important in the meantime.
- Cut off the one-way markings before the end of the road, to stop stomping over turn markings
- Draw turn arrows to every road, not each lane
- Only draw turn arrows when a lane is restricted from going to some
outbound lane. At most intersections, all turns are legal, so don't draw
anything.
[rebuild]
data is regenerated. (Ideally screenshots would also be automated, but
that's a little trickier.)
_NOW_ regenerate all data! The only diff anywhere is the binary map
format, so there's confidence the last few commits haven't changed
anything.
the API (#245), and beef up the Python example.
Impact to prebaked file size is tiny -- for lakeslice, the original
intersection_thruput is 2MB and the new traffic_signal_thruput is 435KB.
[rebuild]
new trips, then seeing the impact they'll have on the normal weekday
scenario. So how much externality would be caused by a bunch of new
trips if some building is built?
Demo showing the whole flow: https://youtu.be/adpED0KGQ7Q. Why do those
few trips at the beginning impact some later trips so much? Who knows.
Likely parking spots get gobbled up.
a zone per hour. This is part of support for some kind of congestion
charging experiments. This step just rearranges the data to define the
cap and makes a UI to edit it. Not enforcing the cap yet.
- Need to draw a background underneath the curved text
- Sometimes the text is "upside-down" relative to what's expected; we
should be able to reverse the polyline sometimes to deal with that. But
when?
"compressing" empty space between intersections. The result is a little
unexpected sometimes, but it's an improvement over the previous thing.
@michaelkirk suggested a variation in Slack that I'll try soon.
- wire up the flag to skip building contraction hierarchies in one-shot
importer. 406s to import london without, 230s by skipping CH
- lazily render zoomed parking lot details. 72s and laggy X11 mouse
before, 42s and no GPU melting after
- add my script for stress-testing the importer
trips as a Scenario to later re-run. This is useful for quickly defining
"test cases" for development, and it's a start to a UI for letting
players specify (and eventually share) traffic patterns they define.
combining primitive transitions into sequences.
Brief context on the state/transition system: The game crate is
organized as a stack of states, with the topmost one being active.
Transitions manipulate this stack. For example, the stack might look
like: [main menu, sandbox mode, edit mode, traffic signal editor, signal
picker]
OriginalBuilding was to refer to buildings in a stable way across
different maps and across OSM updates. Recently, OsmID and friends
appeared. The double layer of wrapping is an annoying API.
Not regenerating map data yet; about to do the same thing for
OriginalIntersection
when the window is resized. This is a bit unexpected if done
interactively in-game, but not unreasonable.
This mostly fixes the issue that sometimes happens starting with --dev.
When the resize happens late on X11, the minimap looks initially better,
but still cut off horizontally. Zooming in and out fixes it. (Before,
even zooming in/out would keep it tiny, because base_zoom was never
reset.)
Previously it was not clear (to me at least) when a value used
in layout was in units of logical pixels vs physical pixels.
This lead to some ambiguity about where to scale values, and lead to
some values being scaled more than once or sometimes not at all, leading
to inconsistent layouts across DPI's.
The intent of this change is to solve this ambiguity by having the ui
clients work *exlusively* with logical pixels.
To achieve this, we consolidate all scaling to the graphics backend.
We translate all PhysicalPositions from the windowing libraries to
LogicalPixles.
Our own types: ScreenPt, ScreenDim, etc. are all in logical units.
In some places, I replaced passing raw floats with a corresponding
Screen* type to clarify that the units are in logical pixels.
now, just switched everything to must_* variants, but this paves the way
for handling failures.
... except for rendering pedestrian crowds -- I _think_ I saw a crash
from that, and it's easy to have a fallback there
