Most critical component of an engine?

[Baker]

What do you feel is the most critical component of an engine?

My opinion is that it is the texture manager --- managing the textures uploaded --- because if you don't have this one in place, it places severe limitations on the flexibility of things you can do.

[And it the focus on my current battle. The FitzQuake texture manager requires data be validated prior to passing data over and then, upon passing data over, indicates where the data came from and the manner of which it can be reloaded.]

Still, my perception is likely altered by my current challenges and maybe my next answer to this question might be something like the network code, as I might have said video mode switching back in 2007, for instance, as an answer to this question.

[mh]

The filesystem.

Closely followed by memory management.

Or perhaps it's the other way around?

Without those nothing works.

[Spike]

there is no single most important component.

the single most important aspect of an engine is imho either its look and feel, or how capable it is of accepting new gamecode that do cool things.

the second is only important if you have mods willing to target only your engine, thus the first must be appealing before the second is even relevant.

pk3 vs pak is unimportant, pak is fine. you get better compression from using the right data formats instead, which also provides better in-memory cache performance (skeletal models beats vertex animations).

memory management is important in any application. but there's no need for anything other than malloc/free if they're used properly, as they should be more than capable of managing your engine's memory. valgrind greatly helps with that. the only time you actually need memory management is when your libc is from the dos days.

a texture manager is no different from, say, a model manager, a sound manager, a shader manager, an entity manager, a cvar manager, a command manager, etc. In FTE, everything is drawn via a shader (supposedly), so the texture manager code itself doesn't really need to be that complex. To be honest, just some code to call glGenTextures and glTexImage would probably be enough. The shader code does the rest. Again, if the memory is released individually, then the code doing that releasing will have no problems at all calling glDeleteTextures too.

imho, look and feel is the most important *aspect*. An example is the console particles in ezquake that make me want to vomit any time I see them. I don't know if they're still enabled by default, I dare not try it just in case.
what are engines most known for? generally its the graphics. directq is known for getting good framerates on intel cards, fitzquake is known for being faithful to the look of software, proquake is known for, urm, not changing looks from glquake, tenebrae/darkplaces is known for its realtime lighting, telejano/qmb are probably most known for their particles. sure, they have mapper features, or modder features, etc etc, but the easier it is to make it look how the respective targetted audience want it, the more likely it is to be popular within that audience, be it faithful, glitzy, or visually apealing.
In QuakeWorld, the overriding factor of the popular engines has generally been 'the engine with the most visible enemy players, the highest framerate, or the lowest latency/smoothest is the most popular engine'. Again, all look and feel.

[andrewj]

[mankrip]

[Baker]

[dreadlorde]

[andrewj]

[Irritant]

[revelator]

[mh]