Register a SA Forums Account here!
JOINING THE SA FORUMS WILL REMOVE THIS BIG AD, THE ANNOYING UNDERLINED ADS, AND STUPID INTERSTITIAL ADS!!!

You can: log in, read the tech support FAQ, or request your lost password. This dumb message (and those ads) will appear on every screen until you register! Get rid of this crap by registering your own SA Forums Account and joining roughly 150,000 Goons, for the one-time price of $9.95! We charge money because it costs us money per month for bills, and since we don't believe in showing ads to our users, we try to make the money back through forum registrations.
 
  • Post
  • Reply
Simulated
Sep 28, 2001
Lowtax giveth, and Lowtax taketh away.
College Slice

awesomeolion posted:

Thanks for your thoughts! I ended up moving the other parts of the game over to use the physics engine and it already feels like the right approach. So far I'm hoping that keeping as much of my colliders circles as possible will keep performance good. Anyway so far this feels like the way to go :)

That's probably the best approach anyway. Detecting the intersection of even simple shapes can have a surprising number or edge cases, let alone arbitrary polygons. The "cheap" method is to rasterize and check pixels which is shockingly fast on modern hardware.

Using a physics engine is both more general and relies on someone else to have solved all the tricky edge cases with good performance.

Adbot
ADBOT LOVES YOU

Simulated
Sep 28, 2001
Lowtax giveth, and Lowtax taketh away.
College Slice

fankey posted:

Anyone have any experience with the the apparently new limitations on using mulitcast in apps? Our app both sends and receives multicast UDP in order to discover devices on the local network. It appears as though 14.6 broke this. I've found this page https://developer.apple.com/news/?id=0oi77447. That page has a link titled Request the com.apple.developer.networking.multicast entitlement which sends you to an odd page where you have to manually fill things out like App ID, App Name, Description, etc. I would have assumed Apple could have figured out most of this information since the app is registered but whatever. We've filled out the form and added the 'Privacy - Local Network Usage Description' string to the plist but then what happens? We haven't received any confirmation or additional information after submitting the form. At some point does someone wave their magic wand and our app starts working? Will we need to resubmit after they've done whatever they need to do?

The "Privacy - Local Network Usage Description" is required when you are using Bonjour (eg via NWBrowser). This doesn't require any special entitlements and is automatically controlled by the TCC prompt for permission (and can be toggled in Settings). If at all possible I highly recommend using Bonjour. It's open source (see mDNSResponder) and built-in basically everywhere at this point.

The entitlement is if you want direct access to multicast TCP/UDP (depending on device).

Simulated
Sep 28, 2001
Lowtax giveth, and Lowtax taketh away.
College Slice

fankey posted:

We switched from Bonjour to our own discovery method over 10 years ago. It didn't really seem sufficient for modern 3 tier networks. The main issues were (1) it's not routable without an mDNS gateway and (2) the automatic query interval increase means joining 2 'steady-state' networks can mean waiting up to an hour for devices to discover each other. Couple that with the requirement to support Windows with Apples schizophrenic support of Bonjour on Windows I think we made the right choice. It's possible we either misunderstood these limitations or they have since been addressed but it's not clear to me how anyone could use Bonjour beyond a simple flat network.

We did get a response from Apple regarding our usage of multicast so hopefully we'll get a resolution soon.

Great, let me know if you have trouble getting a response and I'll see if I can find the right person to poke.

I assume your users are in corp networks where different devices are on separate VLANs and that's why normal Bonjour wasn't working for you? A lot of commercial WiFi APs, routers, etc have built-in support for Bonjour proxying and management now. You can configure the rules to decide which devices on which VLANs or subsets get shared with others on the service type level, so eg you can allow APs in a specific building to proxy AirPrint advertisements from that building's printer VLAN to the whole building (via all APs and desktop VLANs) but restrict music sharing or AirPlay to be only devices connected to the same AP.

Regarding #2: normally a new service announces itself when connecting so you shouldn't see a delay when browsing for new services and similarly a host looking for new services can query that at any time so it should fine them immediately despite the exponential backoff caching. Moving networks should automatically reset the local cache so if a device moves from one VLAN to another (eg by switching APs) it should clear its own Bonjour cache and there shouldn't be a delay in discovering devices on the new network.

If you have specific scenarios that don't work or other concerns feel free to DM me a feedback number and I can forward this to the networking team.

  • 1
  • 2
  • 3
  • 4
  • 5
  • Post
  • Reply