/vr/ - Retro Games

>>7428781
>I sometimes wonder, though, if I'm going against the flow. Perhaps Ken added his cache system in response to other teams request for a memory manager? Maybe the group file code was asked for by the Duke Nukem team? These fears usually turn out to be unfounded, since other teams report similar problems as a result of Ken's "updates."

>I realize that most of the problems I've been describing with Ken are highly historical in nature, and there's no way to change the past. What can and must be done though is to make Ken more responsive to our needs. He needs to work WITH us, not against us. I don't know why he is so combative, but I can guess -- ego. He probably feels about his code the way a lot of programmers do: it's okay to criticize your own code, but for anyone else to do so is blasphemy. I used to be that way until I realized that a lot of the suggestions people were making to me were actually right.

https://tcrf.net/Proto:Blood/Alpha_Demo#GEORGE.TXT

>>7405428
Both. Required reading for Ken and Build:
https://tcrf.net/Proto:Blood/Alpha_Demo#GEORGE.TXT
>...Everything with this system was going fine until we discovered that Ken has some engine flaws in dealing with sprites that use origin based centering. The clipmove() function doesn't work, and neither does hitscan(). These two functions are pretty much essential to doing anything with the engine. I could rewrite them, of course, but that would be a few days to weeks out of our schedule, depending on how many more bugs and design problems crawl out of the woodwork.

>We had waited a few months before switching to the new origin based centering, so I was quite surprised to find such fundamental problems with it. We called up Ken and told him about it, and he said he didn't think anyone was using it, but he really didn't know. We asked him to fix it.

>Tonight I called up Ken because of the group file problems, and because we still don't have a fix for the clipmove() or hitscan() problems. Ken he wasn't going to fix it and we should go back to using the old centering mode. This is totally and completely unacceptable. We've already invested time and effort (need I say money?) into using something, and we're not about to waste more regressing.

>Ken understands algorithms, and he understands graphics. What he doesn't get is how to design SYSTEMS. Everything he does to the engine is a piecemeal enhancement to something that should have been designed right from the beginning. The memory system is a poignant example of this. It is a hack, like most of his code, and not very robust. From what I've disassembled of the group file code (trying to figure out a way to eliminate or replace it), it too demonstrates plentiful opportunities for crashing the system -- pointers being freed without validation, files being closed without verifying the handle, etc.

>>7384017
>I sometimes wonder, though, if I'm going against the flow. Perhaps Ken added his cache system in response to other teams request for a memory manager? Maybe the group file code was asked for by the Duke Nukem team? These fears usually turn out to be unfounded, since other teams report similar problems as a result of Ken's "updates."

>I realize that most of the problems I've been describing with Ken are highly historical in nature, and there's no way to change the past. What can and must be done though is to make Ken more responsive to our needs. He needs to work WITH us, not against us. I don't know why he is so combative, but I can guess -- ego. He probably feels about his code the way a lot of programmers do: it's okay to criticize your own code, but for anyone else to do so is blasphemy. I used to be that way until I realized that a lot of the suggestions people were making to me were actually right.