MH philosophy of engine coding

[Baker]

I've largely avoided posting in the forums for --- I don't know --- 2 months?

Anyway, back when I stopped posting I realized that to make the serious progress I want with Engine X and ProQuake I needed to adopt MH's philosophy of engine coding.

Yeah, I might have released countless ProQuake updates during the summer, but to get serious transformative features completed takes time.

And my past approach to attack pebbles instead of the ant-hill itself wasn't going to be fast enough in the end.

So my current approach is working on a great deal of change in "batches", rather than tackling 1 or 2 minor issues every update.

My target date is December 25th. I may have an engine release or 2 before that, but the big one is going to be Christmas followed by another one around April.

Yes, some people might be annoyed by the gap between updates but I am putting getting progress achieved over "talk". Talk is good, and reporting bugs is important. But so is making real progress. The time it takes to polish up an intermittent release can be better spent writing new features and taht is exactly what I plan on doing.

So if posts go unanswered (they will) or private messages go unanswered (they are going to go unanswered) don't be offended. I want to see real and substantive new features as a standard part of what at least the online NQ part of the community here wants to see.

And I wasn't going to be able to deliver it by working on small things here and there, nor does posting in the forum really accomplish any engine coding.

I know not everyone is going to read this post, last time I disappeared for a couple of months I had a few "Why are you ignoring me?" messages. I've gotten used to it and I understand this will happen again.

But for those of you who read this post and take the time to understand I'm not going to be reading my private messages often or at all, thank you for letting me have time to work on things I hope will benefit our community.

[mankrip]

I know how you feel; some of my most productive years were when I had no Internet access at home.

Getting used to your own code is also more important than implementing others' solutions, because it helps you become a better programmer - and this helps a lot when the time to implement those solutions finally arrives.

Currently my goals are quite "simple": Fix all critical bugs (the ones that makes the game crash) introduced by me, fix most bad behaviors introduced by me, avoid introducing any critical bugs, get code versioning working, etc. - all small steps towards a point where I can start adding hardware acceleration and work heavily on my TC.

Goals change, and the path to reach them may also change sometimes; that's understandable.

Good luck!

[Baker]

Mk,

4 years ago I had no internet access for a month and wrote a clone of Paint Shop Pro 4 (my favorite version). 5 years ago --- Yikes! --- I had no internet access for 2 months and wrote a [shitty] Windows web browser ... omg the things I didn't want to know about fonts but was forced to do deal with!

So yeah, you nailed it.

It all comes down to focus.

While I won't be posting here, I will be posting at Inside3d. Not because I don't love the QuakeOne participants but rather because my inbox accumulates a crapton of questions here ("How do I turn on mouse look?" --- dude, why didn't you post that in the forums?) and at Inside3D.com people don't do that (plus I ask questions for how to standardize stuffs in a generally accepted way, yada, yada).

So yeah ... solace is a good thing to get results with engine coding. You'd know. (To those that don't know: MK wrote the first Q1 transparent water software rendering code for his Makaqu engine).

[StatiC]

my inbox accumulates a crapton of questions here ("How do I turn on mouse look?" --- dude, why didn't you post that in the forums?)

eheheh, ill bet some are shy and dont wanna ask publicly about one of the simplest things in quake... like, what is d_input for ?!?!? id hate to ask that here (dunno y even)

MK got a cool avatar

[golden_boy]

I am putting getting progress achieved over "talk". Talk is good, and reporting bugs is important. But so is making real progress. The time it takes to polish up an intermittent release can be better spent writing new features and taht is exactly what I plan on doing.

So true.

Doing > talking. I know that firsthand.

Good luck.