Mercurial > ldforge / changelog

Phased out FOREACH macro in favor of C++11-style for iteration.

• Mon, 25 Mar 2013 17:04:18 +0200
• by Santeri Piippo <crimsondusk64@gmail.com> [Mon, 25 Mar 2013 17:04:18 +0200] rev 70
• Phased out FOREACH macro in favor of C++11-style for iteration.

Simplified configuration code. Use a std::vector object to contain config pointers and have config objects register themselves upon creation instead of relying on a cfgdefs.h. Removed sections, all configurations are just simply written one after another now.

• Mon, 25 Mar 2013 16:05:03 +0200
• by Santeri Piippo <crimsondusk64@gmail.com> [Mon, 25 Mar 2013 16:05:03 +0200] rev 69
• Simplified configuration code. Use a std::vector object to contain config pointers and have config objects register themselves upon creation instead of relying on a cfgdefs.h. Removed sections, all configurations are just simply written one after another now.

Further fixes to bad color handling. Allow main color be represented with arbitrary transparency.

• Mon, 25 Mar 2013 15:20:56 +0200
• by Santeri Piippo <crimsondusk64@gmail.com> [Mon, 25 Mar 2013 15:20:56 +0200] rev 68
• Further fixes to bad color handling. Allow main color be represented with arbitrary transparency.

57181.dat (Philo's model of the XL-motor) showcased a new problem.. there was no handling of unknown colors which led into crashes. Added stdout warnings, also added mid and dark stone colors

• Mon, 25 Mar 2013 01:04:20 +0200
• by Santeri Piippo <crimsondusk64@gmail.com> [Mon, 25 Mar 2013 01:04:20 +0200] rev 67
• 57181.dat (Philo's model of the XL-motor) showcased a new problem.. there was no handling of unknown colors which led into crashes. Added stdout warnings, also added mid and dark stone colors

Restructured inlining to use a proper caching.. one cache per sub-file reference? What was I thinking? *whacks self with a 55295.dat*

• Mon, 25 Mar 2013 00:44:11 +0200
• by Santeri Piippo <crimsondusk64@gmail.com> [Mon, 25 Mar 2013 00:44:11 +0200] rev 66
• Restructured inlining to use a proper caching.. one cache per sub-file reference? What was I thinking? *whacks self with a 55295.dat*

Reverted changes on LDSubfile::getContents, I had a temporary, hackier solution there and forgot to change it back

• Sun, 24 Mar 2013 21:45:19 +0200
• by Santeri Piippo <crimsondusk64@gmail.com> [Sun, 24 Mar 2013 21:45:19 +0200] rev 65
• Reverted changes on LDSubfile::getContents, I had a temporary, hackier solution there and forgot to change it back

Considerably improved sub-file inlining. Use a matrix class instead of double[9], educated myself on what matrix multiplication actually is and fixed the algorithm up. Aside from I/O problems, 32551.dat is correctly rendered now.

• Sun, 24 Mar 2013 21:41:24 +0200
• by Santeri Piippo <crimsondusk64@gmail.com> [Sun, 24 Mar 2013 21:41:24 +0200] rev 64
• Considerably improved sub-file inlining. Use a matrix class instead of double[9], educated myself on what matrix multiplication actually is and fixed the algorithm up. Aside from I/O problems, 32551.dat is correctly rendered now.

Implemented the inline action to expose inlining to the user. Also added a `deep inline` action to inline subfile recursively down into polygons and lines only.

• Sun, 24 Mar 2013 18:03:33 +0200
• by Santeri Piippo <crimsondusk64@gmail.com> [Sun, 24 Mar 2013 18:03:33 +0200] rev 63
• Implemented the inline action to expose inlining to the user. Also added a `deep inline` action to inline subfile recursively down into polygons and lines only.

Got inlining working. 3002.dat renders properly now! Now just to iron out the bugs and hone the behavior..

• Sun, 24 Mar 2013 01:05:59 +0200
• by Santeri Piippo <crimsondusk64@gmail.com> [Sun, 24 Mar 2013 01:05:59 +0200] rev 62
• Got inlining working. 3002.dat renders properly now! Now just to iron out the bugs and hone the behavior..

If editing contents of a gibberish object, show the reason for the gibberishness in the dialog. Clamp the bounding box scale to at least 1.0 so that polygons are visible in new files.

• Thu, 21 Mar 2013 18:26:57 +0200
• by Santeri Piippo <crimsondusk64@gmail.com> [Thu, 21 Mar 2013 18:26:57 +0200] rev 61
• If editing contents of a gibberish object, show the reason for the gibberishness in the dialog. Clamp the bounding box scale to at least 1.0 so that polygons are visible in new files.