"When one is a 'cultural critic', however, facts and reason are not too important."
- Peter Klein
More pages: 1 ... 11 ... 21 ... 31 ... 41 ... 51 ... 61 ... 71 ... 81 ... 91 ... 95 96 97 98 99 100 101 102 103 104 105 ... 111 ... 121 ... 131 ... 141 ... 151 ... 161 ... 171 ... 181 ... 191 ... 201 ... 211 ... 221 ... 231 ... 241 ... 251 ... 261 ... 271 ... 281 ... 291 ... 301 ... 311 ... 321 ... 331 ... 341 ... 351 ... 361 ... 371 ... 381 ... 391 ... 401 ... 411 ... 421 ... 431 ... 438
Query Failedanusha
Thursday, December 8, 2011

they has do sex with that boy
�RiC
Monday, December 5, 2011

I just can underline what Ashkan said: Its a lesson to be learned. Ok, I never did a big software project yet, but I know what a rewrite can be. It can be a blessing if you overhauled every bit of it in your head already and typing becomes just shedding it into the keyboard... and yes: it can be a pain in the ass if you have doubts in certain parts.. thats when the hacking starts.

So I'd also say: it depends! and learning that is very important.
Humus
Saturday, December 3, 2011

sqrt[-1], yeah, one reason I'm not entirely happy with where things were going with Framework4 is that I decided to "do things right", which meant "do it the DX11/GL3/4 way". For my demos I'm not so sure it's necessarily the right way though. I've been setting individual shader constants by name, which is readable and nice for rapid prototyping. I changed to using constant buffers, which ended up being less convenient on many levels. It's never going to matter performance-wise for my stuff, so I ended up questioning this approach in the end. I've been influenced a little too much by the way of thinking I apply at work where I'm dealing with a real large-scale game engine.
(Yes, I got your email. You got reply. )
Humus
Saturday, December 3, 2011

Nick, yeah, it's probably not entirely wasted. Spent too much time away from the important stuff, but there are of course some good stuff in there as well.
Humus
Saturday, December 3, 2011

Ashkan, rewriting software components is fine, but a complete rewrite from scratch of whole systems is almost never a good idea. I'm all for continuous refactoring of code to clean up various forms of messes that invariably sneak into code, but dropping all to start clean tends to create many unforeseen problems, even beside the obvious time issue. The messiness of old code is usually overestimated and the cleanliness of new code vastly overestimated. The advantage of continuous refactoring is that you always have running code that can be shipped available. And should you find that the new code wasn't so much better, which will almost guaranteed happen for some parts in a large system, you can always back out of it with minimal loss. If you're halfway through a big rewrite when you discover you went down the wrong path, then you're pretty screwed.
Gregory
Saturday, December 3, 2011

what I'm expecting to see in Framework4 is a state of the art and dx 11 init

some unquestionable source code reference people can point at. there is no such thing around (no don't even think about nehe)
sqrt[-1]
Friday, December 2, 2011

I have always been a fan of your frameworks - the interface have always been very concise. (I use it all the time to test stuff out)

(you got my email about the OpenGL bug recently in the shader compiler?)
Rob L.
Friday, December 2, 2011

"Or maybe I'll just copy Framework3 to a new folder and call it Framework4, and then start refactoring things from there?"

Yupp, that's what I do most of the time. Otherwise you can't really test things, have side-by-side tests to verify things work as expected or even better.

Alternative: A few years ago I ripped out the window management from my framework and implemented a separate system in a stand-alone application from scratch. New interfaces and all, but it didn't do anything else, just create a window with an OGL context. After that I put that into my framework, updated all applications and got a nice, new and clean window management system. It's good to have your code modular and with very little dependencies (internal and external), so you can replace components without too much headaches.

Although, at work we just had to rewrite all of our new technology from scratch, because the old code base was such a mess and was too much integrated with other outdated and by that time unsupported code. I don't mind writing "boring" code, but I made sure I write all the "basic" things (game engine and low level systems) first anyway and rendering last. ;D

So, a rewrite can be good sometimes, but it is very rarely really necessary.

Best regards!
More pages: 1 ... 11 ... 21 ... 31 ... 41 ... 51 ... 61 ... 71 ... 81 ... 91 ... 95 96 97 98 99 100 101 102 103 104 105 ... 111 ... 121 ... 131 ... 141 ... 151 ... 161 ... 171 ... 181 ... 191 ... 201 ... 211 ... 221 ... 231 ... 241 ... 251 ... 261 ... 271 ... 281 ... 291 ... 301 ... 311 ... 321 ... 331 ... 341 ... 351 ... 361 ... 371 ... 381 ... 391 ... 401 ... 411 ... 421 ... 431 ... 438