Index | FAQ | Search | Memberlist | Usergroups | Profile | Log in to check your private messages | Log in | Register

QuakeC 2.0 - better, stronger, faster Goto page 1, 2 Next

| Inside3d Forums Forum Index -> QuakeC Programming

View previous topic :: View next topic
Author | Message
--- | ---
frag.machine Joined: 25 Nov 2006 Posts: 728 |

Posted: Thu Jul 29, 2010 5:34 pm Post subject: QuakeC 2.0 - better, stronger, faster |

Consider this a project design exercise. Also, I am not sure if this should be here or in engine programming. Since we are only talking about concepts, let's hang here for now. After reading a good number of discussions here and other places about modders requests that usually requires non-standard engines extensions, I've been thinking about how QuakeC already is powerful, but at the same time how it could be even more.
IMO QuakeC was designed to deal with anything related to game logic, but at the same time this goal was very constrained by some poor design decisions (unavoidable in any pioneer project, and Quake pioneered in a lot of aspects) and in great part by the targeted hardware constraints. The core QuakeC itself is alright, but for current standards we could/should be doing more things in the game logic side, turning the engine itself a more thin and neutral layer of software between the game and the hardware. And a simpler software layer is easier to improve, to make adherent to future standard changes (QSB1 ? QSB2 ?), etc.
Paraphrasing the old TV series: gentlemen, we can rebuild QuakeC and make it better than was before; better, stronger, faster (okay, maybe not the faster part, but still ).
For example, I don't see a good reason for not moving the entire protocol handling (both client and server side) to QuakeC. It's already partially there anyway, and this could be the answer to all mods requesting custom protocol support: "take the standard protocol defined in protocol.qc and add your own custom messages freely, along with your QuakeC to handle it. Don't worry about breaking compatibility anymore". Following the same reasoning, adding some 2D support to client side would be enough to allow any modder to create its own UI in QuakeC. Those 2 aspects alone are responsible for a lot of engine modifications requests, so IMO the Right Thing(tm) to do is: let's move that to QuakeC and let's the modder deal directly with that. It's already done in this way in most of the games nowadays.
Now, I can hear Spike yelling: "CSQC!CSQC!". Yeah, CSQC has a good part of this - but the idea here is not restricted to client-side: it's a shift from currently hardcoded game logic engine-side to adding enough resources in QuakeC so it can handle the task - both in the server and the client.
I think that if we limit the initial scope to what is required to recreate all current WinQuake/GLQuake features, could be easy to delimit where things begins and ends, contrary to the dreaded QSB 1.0 spec - in other words, something quite feasible.
Opinions ?
_________________
frag.machine - Q2K4 Project
http://fragmachine.quakedev.com/

Back to top |

Sajt Joined: 16 Oct 2004 Posts: 1026 |

Posted: Thu Jul 29, 2010 8:09 pm Post subject: |

(Post was irrelevant, I misunderstood the topic) _________________ F. A. Špork, an enlightened nobleman and a great patron of art, had a stately Baroque spa complex built on the banks of the River Labe. Last edited by Sajt on Fri Jul 30, 2010 4:13 am; edited 1 time in total

Back to top |

Chip Joined: 21 Jan 2009 Posts: 314 Location: Romania |

Posted: Thu Jul 29, 2010 8:14 pm Post subject: |

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.
_________________
My Projects: Quake 1 Mods | OpenQuartz 2 | ChipQuake

Back to top |

frag.machine Joined: 25 Nov 2006 Posts: 728 |

Posted: Thu Jul 29, 2010 8:31 pm Post subject: |

Chip wrote:
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.

Let's take the network protocol part as an example. The current implementation is divided between QuakeC and C code. The main primitives to read/write bytes, chars, floats, etc. are already there, and some are even already available in vanilla QuakeC (the write*() stuff). What lacks is to define a event (much like the way the engine already calls PlayerPreThink() for example) to treat the network receiving part (something like OnMessageReceived()) with a switch or a big if-else chain to treat every received message - and of course, the required set of builtins to interact (most of which are already there). So, I'd dare to say that pretty much 70% of the code already exists and maybe 60% already is part of the standard Quake engine.
Do you remember an old tutorial teaching to change the engine so any unknown command from console would be redirected to QuakeC ? That's a fine example of what I am talking about.

Chip wrote:
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.

No doubt the QuakeC size would grow up. But while I think such improvements would be desirable, they're not actually required. Besides, original progs.dat is far bigger than what really needs to be because repeats ad nauseam a lot of animation code that could be shared among monsters, for example.

Chip wrote:
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.

As I said, I think is doable; never said it would be easy.
But again, I've seen people adding much more sophisticated stuff to the engine, and that wouldn't be the hardest challenge ever found.
_________________
frag.machine - Q2K4 Project
http://fragmachine.quakedev.com/

Back to top |

Spike Joined: 05 Nov 2004 Posts: 944 Location: UK |

Posted: Thu Jul 29, 2010 10:42 pm Post subject: |

CSQC does add a custom ent protocol. Basically the engine does still decide which ents are visible/added/changed/removed, and stuff, but requires the ssqc to write the entire data payload, including what sort of ent it is, which fields have changed, etc.
Its a pain in the arse. Sane QC coders let the engine do it all automatically for them. Crazy QC coders would do it with stuffcmds if they couldn't do it with writebytes. So its less fun all round.
_________________
What's a signature?

Back to top |

Sajt Joined: 16 Oct 2004 Posts: 1026 |

Posted: Thu Jul 29, 2010 11:05 pm Post subject: |

Oh, whoops. If you were just suggesting (relatively) minor augmentations to QuakeC, ignore me. I got a little carried away... _________________ F. A. Špork, an enlightened nobleman and a great patron of art, had a stately Baroque spa complex built on the banks of the River Labe.

Back to top |

frag.machine Joined: 25 Nov 2006 Posts: 728 |

Posted: Fri Jul 30, 2010 12:32 am Post subject: |

Sajt wrote:
Oh, whoops. If you were just suggesting (relatively) minor augmentations to QuakeC, ignore me. I got a little carried away...

No problem. As I said in the start, let's consider this an exercise. Your work seems interesting.
_________________
frag.machine - Q2K4 Project
http://fragmachine.quakedev.com/

Back to top |

Sajt Joined: 16 Oct 2004 Posts: 1026 |

Posted: Fri Jul 30, 2010 4:12 am Post subject: |

I'm not sure what you mean by project design exercise. I guess you mean trying to create an iterative set of tutorials, adding this feature first, then that, then that, working from inside the Quake engine. In which case my post was irrelevant because it's more of a drop-in replacement for several parts of the engine without any mercy for the crusty old systems.

frag.machine wrote:
...The core QuakeC itself is alright, but for current standards we could/should be doing more things in the game logic side, turning the engine itself a more thin and neutral layer of software between the game and the hardware. And a simpler software layer is easier to improve, to make adherent to future standard changes (QSB1 ? QSB2 ?), etc.

Planning to build off QuakeC and maintain backward compatibility could be a nuisance and a major roadblock. And if you are going to break compatibility, it would probably be a better idea to just rewrite the whole thing from scratch. If you want real revolution, you must kill the tsar. So... I guess I'm asking for clarification on what exactly you are thinking of and how far you are willing to go to implement your vague slogan of "bigger, better, faster" or whatever it was.
_________________
F. A. Špork, an enlightened nobleman and a great patron of art, had a stately Baroque spa complex built on the banks of the River Labe.

Back to top |

Downsider Joined: 16 Sep 2008 Posts: 477 |

Posted: Fri Jul 30, 2010 6:28 am Post subject: |

Fuck the original Quake-C, let's implement Python on both client and server, port over the original Quake-C to Python, and have a ball with our new, much supported, much time-tested, just as portable, virtual machine.

Back to top |

gnounc Joined: 06 Apr 2009 Posts: 120 |

Posted: Fri Jul 30, 2010 9:04 am Post subject: |

Sajt, that project sounds awesome. lol, python-Quake. I'd be down for that.

Back to top |

Sajt Joined: 16 Oct 2004 Posts: 1026 |

Posted: Fri Jul 30, 2010 10:37 am Post subject: |

gnounc wrote:
Sajt, that project sounds awesome.

You must have spent a long time writing this because I edited out my post hours before you posted this!
As for Python, I can share some opinions on this proposition, but I'm pretty sure that frag.machine wasn't talking about full replacements for QuakeC, so I'll give him a chance to get the thread back on track...
_________________
F. A. Špork, an enlightened nobleman and a great patron of art, had a stately Baroque spa complex built on the banks of the River Labe.

Back to top |

frag.machine Joined: 25 Nov 2006 Posts: 728 |

Posted: Fri Jul 30, 2010 11:43 am Post subject: |

Sajt wrote:
I'm not sure what you mean by project design exercise. I guess you mean trying to create an iterative set of tutorials, adding this feature first, then that, then that, working from inside the Quake engine. In which case my post was irrelevant because it's more of a drop-in replacement for several parts of the engine without any mercy for the crusty old systems.

No, your post wasn't irrelevant at all. I was thinking what would be required to offload as many of the game logic from the engine innards to QuakeC; I think backward compatibility would be desirable (so modders could reuse existing code and skills), but only if it doesn't stand in the way. If your work meets these requirements, then you're in pretty much in the same direction I intend to go - even if you decided by scrapping QuakeC completely and replace it with something more resourceful. So yes, surely your work is quite interesting to me - your approach is just more revolucionary, while I initially was being evolutionary.

Sajt wrote:
Planning to build off QuakeC and maintain backward compatibility could be a nuisance and a major roadblock. And if you are going to break compatibility, it would probably be a better idea to just rewrite the whole thing from scratch. If you want real revolution, you must kill the tsar. So... I guess I'm asking for clarification on what exactly you are thinking of and how far you are willing to go to implement your vague slogan of "bigger, better, faster" or whatever it was.

As I said, retrocompatibility would be desirable (at least in terms of language syntax), but not actually required. So yes, if we are talking about scrapping QuakeC in favor of another script language (with a reasonably small learning curve) and moving as much of the hardcoded game logic to this layer, we are talking about the same thing.
_________________
frag.machine - Q2K4 Project
http://fragmachine.quakedev.com/

Back to top |

frag.machine Joined: 25 Nov 2006 Posts: 728 |

Posted: Fri Jul 30, 2010 11:47 am Post subject: |

Downsider wrote:
Fuck the original Quake-C, let's implement Python on both client and server, port over the original Quake-C to Python, and have a ball with our new, much supported, much time-tested, just as portable, virtual machine.

During a time Carmack considered to use Java for game logic in Quake 3.
BTW, there are a number of ready-to-use language runtimes projects that could replace the QuakeC engine, like SpiderMonkey.
_________________
frag.machine - Q2K4 Project
http://fragmachine.quakedev.com/

Back to top |

goldenboy Joined: 05 Sep 2008 Posts: 310 Location: Kiel |

Posted: Fri Jul 30, 2010 2:59 pm Post subject: |

I think QSB 1 is pretty much meant to be pragmatic, take what exists already, or what can be had for 10% of the effort. I'm not sure what you suggest fits that description. But maybe something for later. _________________ ReMakeQuake The Realm of Blog Magic

Back to top |

mh Joined: 12 Jan 2008 Posts: 909 |

Posted: Fri Jul 30, 2010 3:50 pm Post subject: |

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.
_________________
DirectQ Engine - New release 1.8.666a, 9th August 2010
MHQuake Blog (General)
Direct3D 8 Quake Engines

Back to top |

Display posts from previous:

| Inside3d Forums Forum Index -> QuakeC Programming | All times are GMT Goto page 1, 2 Next
Page 1 of 2

Jump to:

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

Powered by phpBB © 2004 phpBB Group