Closed kazimuth closed 9 years ago
I noticed that you merged the camera assembly into a single object, or at least that's what it looks like from the scripts. Don't do this. It's important that there is a different object for each Axis of rotation, to make movement easier, and to make sure the rotation stays predictable.
On Thu 7 May, 2015 9:26 am James Gilles notifications@github.com wrote:
Start making things multithreaded. I'm starting out by splitting GameMap into smaller classes with async-style interfaces; submit requests each frame, and pull updates from a completed task queue each frame. These can be switched to use multithreading internally later.
There's some unnecessary stuff in here right now, I'll remove it. This is very much not ready to merge in general, I just wanted to make sure you're
aware of it.
You can view, comment on, or merge this pull request online at:
https://github.com/JapaMala/armok-vision/pull/10 Commit Summary
- Merge branch 'cleanup' into rearch
- Start pulling network stuff out of GameMap
- Inprogress
- Don't actually need a block request queue, only need one (since denotes a region)
- Pull connection code into new class
- Configure camera to work with new connection class
File Changes
- D Assets/GameWindow.cs https://github.com/JapaMala/armok-vision/pull/10/files#diff-0 (67)
- D Assets/GameWindow.cs.meta https://github.com/JapaMala/armok-vision/pull/10/files#diff-1 (8)
- A Assets/MapGen/CameraMovement.cs https://github.com/JapaMala/armok-vision/pull/10/files#diff-2 (52)
- R Assets/MapGen/CameraMovement.cs.meta https://github.com/JapaMala/armok-vision/pull/10/files#diff-3 (4)
- D Assets/MapGen/CameraRotate.cs https://github.com/JapaMala/armok-vision/pull/10/files#diff-4 (29)
- D Assets/MapGen/CameraRotateVertical.cs https://github.com/JapaMala/armok-vision/pull/10/files#diff-5 (42)
- A Assets/MapGen/DFConnection.cs https://github.com/JapaMala/armok-vision/pull/10/files#diff-6 (249)
- R Assets/MapGen/DFConnection.cs.meta https://github.com/JapaMala/armok-vision/pull/10/files#diff-7 (4)
- M Assets/MapGen/GameMap.cs https://github.com/JapaMala/armok-vision/pull/10/files#diff-8 (348)
- M Assets/MapGen/MapSelection.cs https://github.com/JapaMala/armok-vision/pull/10/files#diff-9 (3)
- M Assets/MapGen/Tiles/TileShape.cs https://github.com/JapaMala/armok-vision/pull/10/files#diff-10 (2)
- M Assets/Start.unity https://github.com/JapaMala/armok-vision/pull/10/files#diff-11 (412)
- M ProjectSettings/QualitySettings.asset https://github.com/JapaMala/armok-vision/pull/10/files#diff-12 (11)
Patch Links:
- https://github.com/JapaMala/armok-vision/pull/10.patch
- https://github.com/JapaMala/armok-vision/pull/10.diff
— Reply to this email directly or view it on GitHub https://github.com/JapaMala/armok-vision/pull/10.
Okay, I'm removing that now.
Any other things I should avoid? I'm still pretty new at Unity.
Also, question: what's the difference between the values in net_view_info and the posXBlock, posXTile, etc.?
Next I'm planning on pulling the meshing code from GameMap
into a new class - MeshFactory
or something.
Instead of just updating the meshes each frame, GameMap
will submit BlockMeshRequest
structs to its member factory, call factory.Process()
each frame, and fetch the newly created meshes with factory.PopMeshUpdate()
. The factory will start out doing the meshing synchronously, but it can be switched to using a ThreadPool
for work later.
Does this seem reasonable? I'm trying to avoid making GameMap into a tangled mess of mutexes and other threading nonsense.
Yeah, separating the mesher from gamemap is a good idea. Maybe even making the central map storage a singleton, to ease access?
On Sun 10 May, 2015 10:43 am James Gilles notifications@github.com wrote:
Next I'm planning on pulling the meshing code from GameMap into a new class - MeshFactory or something. Instead of just updating the meshes each frame, GameMap will submit BlockMeshRequest structs to its member factory, call factory.Process() each frame, and fetch the newly created meshes with factory.PopMeshUpdate(). The factory will start out doing the meshing synchronously, but it can be switched to using a ThreadPool for work later.
Does this seem reasonable? I'm trying to avoid making GameMap into a tangled mess of mutexes and other threading nonsense.
— Reply to this email directly or view it on GitHub https://github.com/JapaMala/armok-vision/pull/10#issuecomment-100585658.
I was thinking of doing that, actually. It shouldn't ever be necessary to have multiple maps, right?
I was making the MapDataStore static, but I realized that if we want to mesh things in multiple threads then we'll need to mediate access to it somehow. Having loads of contention over a single array didn't seem like a good idea, so I made MapDataStore sliceable; there's one that represents the main map, but smaller ones can be created to hold smaller chunks of the map, and handed off to meshing threads.
I also made MapTile a struct, even if it wasn't super necessary, and moved it to MapDataStore.Tile (since they're kinda inseparable now).
Things are coming along! Currently fixing some bugs with coordinates in the new meshing system, then I'll move on to the actual threading part.
This works! Stuff runs silky-smooth. No tests or anything but we don't have those yet anyway.
Start making things multithreaded. I'm starting out by splitting GameMap into smaller classes with async-style interfaces; submit requests each frame, and pull updates from a completed task queue each frame. These can be switched to use multithreading internally later.
There's some unnecessary stuff in here right now, I'll remove it. This is very much not ready to merge in general, I just wanted to make sure you're aware of it.