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

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

| Inside3d Forums Forum Index -> QuakeC Programming

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

Posted: Fri Jul 30, 2010 4:44 pm Post subject: |

@MH: I agree with pretty much everything that you pointed here. And that's why I am basically calling this thread a "design exercise": I brought an idea, in a very initial and imature form, to be discussed. That's why I am avoiding to consider some obvious aspects, like QuakeC runtime poor perfomance, which level of backward compatibility (if any) we could expect, or even if it could be applied to an initial QSB specification: I want to first hear about what people think about the idea per se, how they see that being implemented, and compare those ideas with my own pre-concepts.
I've been studying several language runtime and interpreters for some time now, and even without a great experience I can foresee some opportunities for improvement in the current incarnation of QuakeC runtime that could be easily implemented (some even out of the context of this discussion, but let's not derail the thread). And you're right about doing one thing at time: actually, I believe this kind of architectural evolution/revolution can and should be made gradually without prejudice. Also, the Darkplaces QuakeC phys hook system is a perfect example of the kind of thing I want to achieve, and surely will be a good reference. Regarding comparisons with CSQC, I agree that there are a lot of common points, but my intention is to conduct this in a different, more user-friendly way - the idea would be to release not only an engine, but a complete reference implementation: commented QuakeC source, binaries and docs included.
At this moment I am just compiling any insigthful information I can gather, and only then I'll start to take some design decisions.
Thanks all for the valuable tips and comments. I'll work a bit more over what I got so far in this weekend and maybe next week I can be able to bring a more consistent roadmap to what I want to do.
Stay tuned
_________________
frag.machine - Q2K4 Project
http://fragmachine.quakedev.com/

Back to top |

Sajt Joined: 16 Oct 2004 Posts: 1026 |

Posted: Sat Jul 31, 2010 12:10 am Post subject: |

About QuakeC's performance: it is already brushing the ceiling of potential performance by a bytecode interpreter. There are some minor optimizations you could do, such as only doing the runaway loop counter on jumps instead of every instruction. And multithreading also will only "postpone" or chip away at the problem, unless you're on a 64-core machine. (Also, to add true multi-threading you need to be willing to give up on the deterministic nature of Quake running physics on entities in order.) If you want speed, first of all you should get rid of bottlenecks: some stuff SHOULD be left to the engine (physics, some AI). Otherwise, you make a JIT compiler. I personally have absolutely no interest in JIT compilation, because it requires a lot of hard-to-test platform-dependent code, and because you give up a lot of the metadata accessibility that is one of the reasons you'd want to use a scripting language in the first place (or, you can keep it around using hacks and supplementary structures). If a game is designed for 10,000 knights, the whole engine will probably be designed for it and gameplay code will not be script-heavy. We don't need to handle that extreme case in our quest for a general-purpose engine.
My project (which I'll continue and finish regardless of the outcome of this thread) fits a lot of the criteria mentioned here. For example, it supports moving a very large part of game behaviour to the script. However, it will not be backwards compatible with the QuakeC syntax, and it will be totally inappropriate for QSB. I'll probably integrate it into a vanilla Quake engine and offer the diffs as a tutorial, but I doubt it will be used by anyone, because I won't encourage making a Quake engine support both QuakeC and this new language (and I have no interest in how: it would doubtless be extremely convoluted and hacky). It'll be like Tenebrae: break compatibility with Quake and you'll make no friends. Oh well.
As for modularity, I have had bad experiences with this in the past, trying to make things modular that should not be. My scripting language must be integrated with the resource manager (aka precache system), the file system, the memory manager/wrappers, the networking layer, buffered i/o streams, and more. So I moved all of these "low-level" things into a single module, which I call a "backend". Modularizing within the backend (for example, separating the scripting language and the networking layer) would be a disaster.
Another note on my scripting language: as a design decision, you can't distribute compiled progs. You can only distribute the source. They are compiled on demand (and cached somewhere in the user dir), so the progs themselves can contain platform-dependent code (byte order, as a trivial example), and you don't have to do a huge loading stage to check for tampered progs.
Another note, contrasting the Python suggestion: my language is fascistically static-typed (more so than C/C++), and contains game specific features (e.g. entity replication). I like dynamic-typed languages for some things like rapid prototyping and certain kinds of applications, but I believe static-typed languages are more appropriate for games.
_________________
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 |

gnounc Joined: 06 Apr 2009 Posts: 120 |

Posted: Sat Jul 31, 2010 3:20 am Post subject: |

Sajt wrote:

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!

I tend to keep tabs open and take a nap before I get back to them. That might have been what happened here.

Back to top |

Dr. Shadowborg Inside3D Staff Joined: 16 Oct 2004 Posts: 726 |

Posted: Sat Jul 31, 2010 2:46 pm Post subject: |

I agree with gnounc. Sajt, that project sounds awesome! _________________ "Roboto suggests Plasma Bazooka."

Back to top |

leileilol Joined: 15 Oct 2004 Posts: 1321 |

Posted: Sat Jul 31, 2010 3:29 pm Post subject: |

if it's going to break compatibility you'd better at least have a damn software engine to use it with _________________

Back to top |

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

Posted: Sun Aug 01, 2010 12:21 am Post subject: |

I've running some profiling in FitzQuake 0.85 with a custom stress map and got some interesting results. I'm still sorting thru the data so I can release a more complete analysis, but looks like PF_traceline and SV_MoveToGoal are the main bottlenecks when the number of monsters grows. And that's interesting, because both functions have in common lots of calls to SV_RecursiveHullCheck. I am pretty sure that is correct to expect benefits in the QuakeC runtime overall performance with any improvements on this part of the code. Well, time to study more deeply this part of the code...
_________________
frag.machine - Q2K4 Project
http://fragmachine.quakedev.com/

Back to top |

Sajt Joined: 16 Oct 2004 Posts: 1026 |

Posted: Sun Aug 01, 2010 3:03 am Post subject: |

I think LordHavoc implemented a simple, regular "areagrid" specifically to speed up the 10,000 knights level (a ton of entities in an open space). But you should be profiling the QC. I don't remember if vanilla Quake's QC profiler counts instructions or just function calls (the former is what you want). In any case I'm pretty sure DarkPlaces (as usual) has a very feature-rich QC profiler. Combine that with profiling the builtins (e.g. checkclient, traceline) using a regular machine code profiler to get a sense of how the Quake QC source could be rewritten to be faster.
Dr. Shadowborg: Yeah, but you should know I'm probably never going to implement CSQC in GoldQuake... Fortunately a bunch of other people are interested in software engines all of a sudden. Maybe Baker will make a software engine with CSQC.
leileilol: Indeed, I was going to implement it in the vanilla sources.
_________________
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 |

Dr. Shadowborg Inside3D Staff Joined: 16 Oct 2004 Posts: 726 |

Posted: Sun Aug 01, 2010 5:31 pm Post subject: |

Sajt wrote:
Dr. Shadowborg: Yeah, but you should know I'm probably never going to implement CSQC in GoldQuake... Fortunately a bunch of other people are interested in software engines all of a sudden. Maybe Baker will make a software engine with CSQC.

I'd already more or less figured that this was the case anyway.
I'm still VERY MUCH interested in this new language you're cooking up though.
_________________
"Roboto suggests Plasma Bazooka."

Back to top |

Display posts from previous:

| Inside3d Forums Forum Index -> QuakeC Programming | All times are GMT Goto page Previous 1, 2
Page 2 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