Announcement

Collapse
No announcement yet.

Unvanquished Is Rewriting, Modernizing The Quake 3 Engine

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Unvanquished Is Rewriting, Modernizing The Quake 3 Engine

    Phoronix: Unvanquished Is Rewriting, Modernizing The Quake 3 Engine

    The Unvanquished open-source game is one of the most fascinating open-source game projects as they've strived for fundamental improvements in the ioquake3 engine and also to deliver high quality art assets and in-game content. Unvanquished is powered by the Daemon Engine, which is derived from the ioquake3 engine at its core -- the open-source version of id's Quake III engine. With the original code being the better part of two decades old, the developers are seeking to modernize and rewrite the code-base...

    http://www.phoronix.com/vr.php?view=MTQ2MjM

  • Irritant
    replied
    Originally posted by JS987 View Post
    Quake 3 engine is outdated. Xonotic has better engine.
    This is the annoying shit that I am so sick of seeing. This is a thread about Unvanquished and the progress they have made. If you want to extoll the virtues of Xonotic, post on a Xonotic thread, or start a new one. This shit is getting older than your grandma's panties.

    Leave a comment:


  • c117152
    replied
    Originally posted by IanS View Post
    To the best of my knowledge it is implementation-dependant in all the C standards. Most compilers will expect a return type of int for main though some may allow something like void.
    Yap. It's a working, cross-platform, production, open-source compiler. Though like I said, it's not all standard.
    Besides, Even in ANSI C (http://www.iso-9899.info/wiki/The_Standard) and ISO C (http://www.iso.org/iso/catalogue_det...csnumber=17782) the main() return types are optional. It's just not very clear if you're not used to reading and implementing standards.
    To be specific, in C99 (http://atrey.karlin.mff.cuni.cz/proj...rr/doc/c99.pdf), "5.1.2.2. Program startup", the phrasing is:
    ...

    The function called at program startup is named main. The implementation declares no prototype for this function. It shall be defined with a return type of int and with no parameters:
    Code:
    int main(void) { /* ... */ }
    or with two parameters (referred to here as argc and argv, though any names may be used, as they are local to the function in which they are declared):
    Code:
    int main(int argc, char *argv[]) { /* ... */ }
    or equivalent; or in some other implementation-defined manner
    ...

    So, what happened is that most implementers figured the "or" only applied to the parameters. Where, in fact, it applied to the entire subject of the sentence. That is, the "other implementation-defined manner" overrides both whole "defined with a return type of int and with no parameters" and not just "and with no parameters".
    In the following section, "5.1.2.2.3 Program termination" it's made rather explicit:
    ...

    If the return type of the main function is a type compatible with int, a return from the initial call to the main function is equivalent to calling the exit function with the value returned by the main function as its argument; reaching the } that terminates the main
    function returns a value of 0. If the return type is not compatible with int, the termination status returned to the host environment is unspecified.
    Forward references: definition of terms (7.1.1), the exit function (7.20.4.3).

    ...

    The key here is "If the return type of the main function is a type compatible with int,". That is, it's not guaranteed that you have to return int. And if you don't, you're going to need to use the exit(). Which I did.

    By the way, I've never seen a fully standard compatible compiler. Even GNU C has some violations. And of course, the most popular, Microsoft Compiler is filled with poor, miss, and downright obtuse violations.

    Now, the next hint is that I didn't make any mistakes. That code compiles and runs without any errors.
    Last edited by c117152; 09-20-2013, 03:34 PM. Reason: grammer and typos

    Leave a comment:


  • IanS
    replied
    Originally posted by c117152 View Post
    While I've lost interest in the thread, I'll have some fun with this one and give you another clue: You only return from main() in ANSI C...
    To the best of my knowledge it is implementation-dependant in all the C standards. Most compilers will expect a return type of int for main though some may allow something like void.

    Leave a comment:


  • c117152
    replied
    Originally posted by n3wu53r View Post
    Did you seriously just use void main()........
    While I've lost interest in the thread, I'll have some fun with this one and give you another clue: You only return from main() in ANSI C...

    Leave a comment:


  • curaga
    replied
    For that matter, I built your struct example using 4.7.1 -O1.

    The stripped sizes were 2.2kb and 2.4kb, the runtimes 2ms and 4ms, repeatedly. Perhaps some parts are different on Windows, like using mscvrt.dll.

    Leave a comment:


  • curaga
    replied
    I said "in almost all cases". Hello world clearly doesn't apply, do something with actual functions and actual work. Build some existing open source program with more than few lines.

    Leave a comment:


  • mrugiero
    replied
    Originally posted by ciplogic View Post
    Are you sure that if you write the same construct will give to you a different size?
    I never stated so, it was the one I quoted. I told him (I didn't check what he said, though) that if that was true, it was still unfair, because you should disable features enabled by default that you don't use. Until now, I haven't programmed in C++ yet, I just read the differences to C, which I did code.

    Also, I don't expect C++ to be harder to parse and compile if the constructs are simple. It could be, because it allows you to make more complex constructs syntactically, but if you don't, the compiler should behave, AFAIK, pretty much as the C one.

    Leave a comment:


  • ciplogic
    replied
    Originally posted by mrugiero View Post
    To be fair, if you don't use such features on your program, you should disable them. Not disabling what you don't use is just laziness, and harms the user for nothing.
    The things are even better when are measured.

    So, I will go on the lazy side and I will write a minimalist printf coding in a C respectively in a C++ file.
    The result on Windows, is the following:
    http://snag.gy/fztNT.jpg

    In short: 32.5 KB for both.

    Let's add some class (in C a struct):
    http://snag.gy/gV6y4.jpg

    Still: 32.5 KB

    Are you sure that if you write the same construct will give to you a different size?

    My original quote was:
    So, let's clarify, C++ will give to you basically the same performance as C with a similar coding style.
    To reproduce the result use a release build for both configurations, I used GCC/G++ 4.7.1 with -O1 (you can pick O2 if you find it more convenient).

    Leave a comment:


  • mrugiero
    replied
    Originally posted by curaga View Post
    No it won't, by default. Compile almost any C code as C++, and it will run slower, unless you manually disable both exceptions and RTTI. It will also compile slower and produce a bigger binary, though the binary size is also somewhat alleviated by manually disabling the mentioned features.
    To be fair, if you don't use such features on your program, you should disable them. Not disabling what you don't use is just laziness, and harms the user for nothing.

    Leave a comment:

Working...
X