Stone fence
I just finished this a few minutes ago - it took about an hour.
Cobblestone
I guess about a week ago? Maybe two.
Programming
Didn't get anything done today - rather lazy. Still have a few hours left in the day, so I'm going to crack back into the code for a bit more work.
Yesterday and the day before I made great progress finally figuring out a good resource-management system for my game. This is after a week or two of false-starts, and several concepts drawn on paper over the past few months. The end result isn't anything special - but all my prior attempts were either too limiting in capability, or else too generalized to be useful. I've gotten it mostly working already, and yesterday I started connecting it up to the old area-drawing code that I haven't seen in several months. I'm happy with the area-drawing code - it's still stable and clean - but the tile-drawing and image-sharing code that I was replacing just was too clunky.
One bit of code I'm somewhat proud of is a new serializing system I wrote up to replace my old one. The new one is more reusable and a pleasure to use, though there is one annoying thing I'd like to fix later.
The new serializer is heavily template-based for great flexibility, observe:[code=:0]struct MyStruct{ std::tuple, float, std::vector > tupleOfPairsAndVectorsOfStrings; float otherStuff;};//Template specialization for serializing 'MyStruct'.template<>size_t Serialize(Serializer &serializer, MyStruct &tileDetails, size_t pos){ //Automaticly calls the overload for floats. pos = Serialize(serializer, tileDetails.otherStuff, pos); //Automaticly calls the overload for tuples, which in-turn calls the overload for each tuple's member, //which in this case calls the overload for std::pair<> which then calls the overload for std::string and int, //and also calls the overload for std::vector, which calls on each element the overload for std::string. pos = Serialize(serializer, tileDetails.tupleOfPairsAndVectorsOfStrings, pos); //Sound slow? Not when you remember template functions are resolved at compile-time. =P //It shouldn't be any slower than most other serializing methods. return pos;}class Foo{public: Foo(); //Calling Serialize() on class 'Foo' automaticly detects that Foo has a Foo::Serialize() function, and calls that instead. size_t Serialize(Serializer &serializer, size_t pos) { //Calls the Serialize() function for vectors... which automaticly detects the type of element in the vector, //and calls Serialize() for each element in that vector. return Serialize(serializer, this->arrayOfStructs, pos); } private: std::vector arrayOfStructs;};
While not intentional, I think it's also loads faster than my old class, which is a nice plus. I haven't profiled it yet to see.
Better still, I don't have to code almost-identical read and write serializing functions for classes - just one function, that reads OR writes, using the same code. Serialize() depending on the nature of the Serializer passed in, reads or writes using the same functions. And without a bunch branching statements - it redirects to the read or write function using a function pointer.
Using a function-pointer also allows me to redirect to Safe or Fast read functions at run time (or for individual pieces of code), depending on the requirements of the program. If I want to, I could later also add Encrypted read/write functions, or Compressed read/write functions, without changing any existing code, but by just adding the new functions to the Serializer class that handles the incoming bytes.
