Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!


1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


Zipster

Member Since 11 Mar 2000
Offline Last Active Today, 08:48 PM

Posts I've Made

In Topic: Best way of ensuring semantic type consistency?

Today, 06:05 PM


I'm more referring to unit differences in this case.  That said, you bring up a good point.  I've seen "Dates" and "Durations" (or some variant of the term) used to resolve that pretty successfully, yeah.  Unless you're referring to times being fully unit aware in general, such as being able to call "TimeDelta.seconds", then that's another way to do it, but it's significantly more heavyweight.  You need a bunch of static factories for each measurement and such.

As far as being unit-aware, you could probably just get away with providing a robust interface for working with multiple units. For instance, the type could store everything at the highest resolution you care about internally (milliseconds, microseconds, etc.), and any overloaded operators would operate in that unit, but expose an interface for operating in other units. Think TimeSpan and DateTime from .NET.

 

I'd say the hardest part is making sure all your engineers actually remember to use the special time types instead of raw integers biggrin.png


In Topic: Best way of ensuring semantic type consistency?

Today, 05:10 PM

As far as time is concerned, you're typically dealing with either an absolute point in time, or a difference between two times. So the same way you have points and vectors in a mathematics library, I'd have Time and TimeDelta types in my time library to clearly communicate the semantic differences between the two. For instance, you wouldn't be able to add two Time's together, subtracting two Time's would result in a TimeDelta, etc. It may seem a little heavyweight at first, but it doesn't take terribly long to implement and will prevent a lot of common bugs when dealing with "absolute" versus "relative" measurements.


In Topic: dllimport/dllexport with multiple depending shared libs

18 February 2015 - 03:45 PM

Does bar.DLL attempt to call any of the methods it's supposed to be importing from foo.DLL? The linker is pretty aggressive about making sure it doesn't import/export what it doesn't think it has to.


In Topic: What are the recommended places to store save data?

17 February 2015 - 03:18 PM


If only we had a tool... that users run before playing a game for the first time... that could could ask them where they want their saved games?
 
Nah. That'll never happen.

Or something they can run at any time to migrate their data, that's possibly even available from an in-game advanced options menu.

 

It would still be nice to have a consistent default, though. I can't count the times I've played the Save Game Hunt meta-game mellow.png


In Topic: What are the recommended places to store save data?

17 February 2015 - 01:53 PM

On Windows, I've seen a lot of games use the "My Games" folder as well for save games and other data, however it doesn't appear to be as standardized as the other folder paths. There's also SHGetKnownFolderPath which you can call with FOLDERID_SavedGames to get a folder specifically for save games, however this appears even less used than the others.

 

A quick Google search reveals this informative post detailing the best place to put data for each platform (mostly mirrors what's already been said here). Unfortunately though, there still seems to be a lot of difficulty in getting everyone on board with the same "standard" data paths, especially on Windows, since there are a ton of folders that have been added over the years where you could arguably put "user data" and not necessarily be wrong, even if it isn't in line with everyone else.


PARTNERS