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
Jabor
Jul 16, 2010

#1 Loser at SpaceChem

Vanadium posted:

I can't really argue with the rest of your points. But just to be clear...
try! takes a Result<> and either evaluates to the value in the success variant, or it returns the value in the error variant from the function invoking try!, which it gets to do because it's a macro. So on error it returns early, and otherwise it continues in that it doesn't return early, and the code using try! can be written much as if it didn't have to deal with Result<>s as long as it returns the right kind of Result<> itself.

Seems less useful than if Result<> just behaved like a proper monad IMO.

Adbot
ADBOT LOVES YOU

Jabor
Jul 16, 2010

#1 Loser at SpaceChem

Sweeper posted:

I don't want to declare every object as mutable because a map it contains is mutable. I'd like to hide that implementation detail from the consumer...

If you're doing something that modifies your object, you're going to need it to be mutable. This is by design. Having a function that modifies your object out from underneath you despite only taking a read borrow would defeat the entire purpose of the borrow checking and blow all of those safety guarantees out of the water.

Whether a function changes an object isn't an "implementation detail" to be hidden away, it's an inherent part of the contract of that function.

Jabor
Jul 16, 2010

#1 Loser at SpaceChem
It sounds like you literally want futures and async/await. What makes you say that it feels like a "round peg and square hole scenario"?

Jabor
Jul 16, 2010

#1 Loser at SpaceChem
What do you want to do if your machine legitimately has multiple actively-used IP addresses? What are you using the IP information for?

My gut feel is that you should look at the routing tables to figure out what interface is used to reach some well-known public address, and then pick the IP address associated with that interface.

Jabor
Jul 16, 2010

#1 Loser at SpaceChem
Doesn't WideCString convert to a *u16? Why do you have u32 in there?

Jabor
Jul 16, 2010

#1 Loser at SpaceChem
Nevermind, my web search linked me to an ancient version of the crate docs. That always trips me up.

Why are you using a Vec? Can't you just create your double-pointer by using & on the raw pointer?

Jabor
Jul 16, 2010

#1 Loser at SpaceChem
If you write the straightforward "loop over every pixel in the framebuffer and replace it with the transformed version" code, Rust will auto-vectorize it for you if you turn on the compiler optimizations.

If that's still not fast enough I would take the ten seconds to figure out how to set up a GPU context before spending minutes-to-hours trying to parallelize and optimize the inherently slow option further.

Jabor
Jul 16, 2010

#1 Loser at SpaceChem
Presumably your game is using some sort of centralised input manager instead of directly querying keyboard state, yeah? That's the logical place to add this sort of functionality.

Basically when recording a demo, the input manager logs all the inputs every simulation frame. When playing back a demo, it returns inputs from the demo file instead of polling the input devices on each frame. The rest of your code doesn't need to care about whether it's a demo playback or not.

If your game simulation is independent of framerate then that's really all you need to do.

If the game simulation is framerate-dependent then you're probably in for a bit of a headache, since you'll need to store the frame timings in the demo file as well and use those instead of the real time when playing it back.

Jabor
Jul 16, 2010

#1 Loser at SpaceChem
For a range that includes both endpoints, you have ..= (which looks a bit strange but is pretty clear in practice).

Adbot
ADBOT LOVES YOU

Jabor
Jul 16, 2010

#1 Loser at SpaceChem
Isn't a "mixin" essentially just:

code:

struct MyType {
  //...other fields
  mixin_delegate: MixinDelegate,
}

impl MixinTrait for MyType {
  fn mixin_func(self: &Self) {
    self.mixin_delegate.mixin_func();
  }
}
?

Are you looking to do that delegation with less typing or something?

You certainly could write a macro for that easily enough. In fact it looks like someone already did, though I've never used it so can't speak to whether it's any good.

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