search

RosaryMala / armok-vision

A 3d realtime visualizer for Dwarf Fortress
MIT License
319 stars 27 forks source link

Multithreading #10

Closed kazimuth closed 9 years ago

kazimuth commented 9 years ago

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.

RosaryMala commented 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

Patch Links:

— Reply to this email directly or view it on GitHub https://github.com/JapaMala/armok-vision/pull/10.

kazimuth commented 9 years ago

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.?

kazimuth commented 9 years ago

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.

RosaryMala commented 9 years ago

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.

kazimuth commented 9 years ago

I was thinking of doing that, actually. It shouldn't ever be necessary to have multiple maps, right?

kazimuth commented 9 years ago

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).

kazimuth commented 9 years ago

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.

kazimuth commented 9 years ago

This works! Stuff runs silky-smooth. No tests or anything but we don't have those yet anyway.