QuakeC 2.0 - better, stronger, faster

[frag.machine]

[Sajt]

(Post was irrelevant, I misunderstood the topic)

[Chip]

Not sure if I'm the right person to give an opinion, but this would require strong C knowledge, as it would involve moving large chunks of engine code to QuakeC and convert it to QC syntax and styles. It would also involve writing engine code to parse the newly added QC chunk.

By moving large parts of the engine to QuakeC, the latter would become pretty big really fast, so it would need an additional layer of code, structured in modules and classes and functions, and the traditional QuakeC, where the majority of modders get their hands dirty.

The idea of a lighter engine, and easier to update and maintain seems great, however this might take a while to do, a great knowledge of both C and QuakeC and hundreds of hours of testing.

[frag.machine]

[Spike]

[Sajt]

[frag.machine]

[Sajt]

[Downsider]

[gnounc]

[Sajt]

[frag.machine]

[frag.machine]

[goldenboy]

[mh]

CSQC actually does handle maybe 95% of this, and the next logical step is to reduce the engine to a thin layer between SSQC and CSQC, primarily just handling things like interfaces to the hardware and stuff like sine functions and so on.

But there is a danger and a problem here.

The danger is that the resulting beast would be so huge and complex that it might scare people off too much, and you end up with zero implementation take up. This is already true of CSQC and I don't see any reason why something equally ambitious and huge would be any different.

The problem is that QC as it currently exists is too slow. Now, it's fine for entity counts like in the ID1 maps, and fine for gamelogic like in the ID1 progs, but when you start putting more complex functionality into QC and running more of it, the slowdowns really do pile up. I've already seen cases where SSQC processing alone needs 14ms per frame (on a recent dual-core machine too). This doesn't leave any headroom for the renderer, sound, input, net and client code to run and still be able to make it to 72 FPS.

Granted it was an extreme case, and granted that it was unfinished work (the map wasn't even full-vised) but just be aware that it can happen (and if it can, it will).

So you need to think a little deeper about how you're going to back up this plan with the kind of technology that is capable of running it. Things like multithreading your QC execution (I believe Spike has done some work on that) come to mind.

You also need to think more modularly to avoid the danger; split things into logically discrete components, box things off from each other and eliminate interdependencies. Enable engine coders to pick and choose from a menu of items to implement along a clearly defined path to full implementation, and make each of those items achievable in isolation.

None of this is saying that you're not thinking along the right lines. The physics code, cl_tent stuff, r_part stuff and so on all are good candidates for being handed over to game logic code, and have a more natural home there.