Inside3D!
     

No QuakeC Quake?
Goto page Previous  1, 2, 3  Next
 
Post new topic   Reply to topic    Inside3d Forums Forum Index -> Engine Programming
View previous topic :: View next topic  
Author Message
mh



Joined: 12 Jan 2008
Posts: 909

PostPosted: Tue Feb 23, 2010 9:43 pm    Post subject: Reply with quote

Supa wrote:
This thread really should be stickied.

I think FrikaC's point in that thread was crucial. QC has been tested for almost 14 years now, it's been abused until it's screamed for mercy, it's limits are known, the gamecode/engine interaction is predictable, and I'd add that there is a significant existing knowledge base to draw on. You can't say the same about any other language in the context of Q1 gamecode.
_________________
DirectQ Engine - New release 1.8.666a, 9th August 2010
MHQuake Blog (General)
Direct3D 8 Quake Engines
Back to top
View user's profile Send private message Visit poster's website
Stroggos



Joined: 14 Apr 2009
Posts: 43

PostPosted: Tue Feb 23, 2010 11:00 pm    Post subject: Reply with quote

A lot of you seem to be asking why I'm dong this. The simple answer to this is to make Quakes game logic more modifiable. As mh said the limits in QuakeC are known and rather well documented but if I take the QuakeC game code and port it to the OOP language that is C++ the possibilities are pretty well endless.
_________________
Dont even try to port Quake 4 to the ipod
Back to top
View user's profile Send private message
frag.machine



Joined: 25 Nov 2006
Posts: 728

PostPosted: Wed Feb 24, 2010 12:16 am    Post subject: Reply with quote

I share the idea that QuakeC is the better approach to deal with game logic, mostly because it's a language running into a well controlled sandbox - this translates to both high security and portability. It truly implements the "write once, run anywhere" motto from Java. That said, as a modder I'd love to see improvements to the language itself. It's far from complete, and the absence of things like truly integer types makes me sometimes to write things I am not proud of Smile. And again, some simple model of inheritance would be a great evolutionary step, and once the modding community realize its potential it would become essential. Maybe something as Javascript does, allowing you to create an entity by "cloning" another (thus not requiring the formal declaration of a class).
_________________
frag.machine - Q2K4 Project
http://fragmachine.quakedev.com/
Back to top
View user's profile Send private message Visit poster's website
Sajt



Joined: 16 Oct 2004
Posts: 1026

PostPosted: Wed Feb 24, 2010 8:19 am    Post subject: Reply with quote

Name one thing you could do in an OO language that you can't do in QuakeC, or would take notably more lines of code than in QuakeC...? I haven't ever felt the need for inheritance, for one thing.

Anyway, porting it to C++ is first and foremost a colossal waste of time for very little, if any, or more likely no gain.

It seems that most people who want C++ simply aren't familiar with QuakeC. There is nothing wrong with QuakeC at a paradigm level.

Some minor things could be easier in QuakeC (proper built-in dynamic strings, integer support...) but at this stage in Quake's life there's no point creating a non-backwards-compatible variant. We all know how few mods are actually made these days, and I can't imagine any notable ones in the future would not be written in QuakeC.

If you're concerned about the bleeding edge of performance, entity networking bandwidth, functionality, or whatever, there has actually never been a problem in any of these areas with the existing technology.

However, I'm not going to tell you what to do with your time. At the least, it may be a learning experience for you (or for whoever attempts the "port"). And hey... maybe by the time you're done dissecting and removing the innards of QuakeC you'll realize how good it actually 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
View user's profile Send private message
Error
Inside3D Staff


Joined: 05 Nov 2004
Posts: 558
Location: VA, USA

PostPosted: Wed Feb 24, 2010 10:20 am    Post subject: Reply with quote

I too am not trying to deter you from doing the unspeakable... but things I think about this:

* QuakeC made Quake a great modding platform. Without it, no one would have made mods, or even kick started the "modding your game" frenzy that ensued afterwards that a lot of game companies picked up on.

* No one would be interested in it. Sorry to say it, but it's true. At least on these forums. (purely an educated guess)

* QuakeC is simple, yet powerful enough to make high end games. A lot of people start programming with QuakeC. I had next to no knowledge of programming in 1996-1997 when I started coding in QC.

* The only benefit I could see for this is that it would be more suited for making a "professional" game and selling it to the masses. Not for Quake.
_________________
Inside3D : Knowledge Is Power
Darkplaces Documentation Wiki
Back to top
View user's profile Send private message Send e-mail Visit poster's website AIM Address Yahoo Messenger MSN Messenger
Spike



Joined: 05 Nov 2004
Posts: 944
Location: UK

PostPosted: Wed Feb 24, 2010 11:43 am    Post subject: Reply with quote

You're free to do what you want in your own engine, however...
Without gutting out QC entirely and revamping the bulk of the engine, you'll just end up with compatibility layers.

You would gain the ability to attach a debugger to your game code, yes.
You would gain the ability to invoke native, 3rd-party (closed) code. Although if it is closed then good luck with those GPL obligations.
You would also gain the ability to leak memory, and corrupt your stack.
You would loose the ability to save games easily, any sample code for quake would not work as-is, you'd have to tell linux, mac, etc users 'sorry but my mod won't work on your computer'.

And this is after you've taken the time to rewrite half the engine, rewrite your gamecode from scratch, replicated the old entity behaviour (if you care, if not then enjoy making your own maps too).

Good luck with it though, if you decide to do it. It should be fun. I just hope you're good at bug hunting - there are a lot of assumptions in quake.
_________________
What's a signature?
Back to top
View user's profile Send private message Visit poster's website
frag.machine



Joined: 25 Nov 2006
Posts: 728

PostPosted: Wed Feb 24, 2010 4:58 pm    Post subject: Reply with quote

Sajt wrote:
Name one thing you could do in an OO language that you can't do in QuakeC, or would take notably more lines of code than in QuakeC...? I haven't ever felt the need for inheritance, for one thing.


- Try to use a float to hold flags with more than 23 bits. I can hear lots of modders souls screaming for integer support;

- What about being able to toggle on/off a bit flag in the float I mentioned above without using the ugly flags = flags - (flags & FL_FOOBAR) hack ? Am I asking too much ?;

- Try not having to replicate every possible entity field in all others, even it's not really necessary (why you have .enemy in a info_notnull ?);

- What if, for example, you could have some "generic walking monster entity" and then derivate all other monsters behavior from this template, coding only the parts that are really different from each other (like attacks, death animations, etc) ? You already have some ready-to-use of this, but in a procedural way (every time your monster runs or walks you need to manually calls ai_run() or ai_walk()). Inheritance would help a lot to remove repetitive code;

- And what about truly array support without compilers hacks ?

Sajt wrote:
Some minor things could be easier in QuakeC (proper built-in dynamic strings, integer support...) but at this stage in Quake's life there's no point creating a non-backwards-compatible variant. We all know how few mods are actually made these days, and I can't imagine any notable ones in the future would not be written in QuakeC.


If nothing of this really bothers you, great. I know many things I cited above are not exclusive from OO languages, but the point stands: QuakeC stills lacking a lot of useful resources. And the argument that "few mods are actually made these days" IMO only serves to justify not stalling the evolution of QuakeC, as long you stills backwards compatible - which is nothing actually that hard.
_________________
frag.machine - Q2K4 Project
http://fragmachine.quakedev.com/
Back to top
View user's profile Send private message Visit poster's website
Willem



Joined: 23 Jan 2008
Posts: 73

PostPosted: Wed Feb 24, 2010 5:27 pm    Post subject: Reply with quote

I'd settle for not having to juggle the stupid "self" variable like a basketball.
_________________
www.wantonhubris.com
Back to top
View user's profile Send private message Visit poster's website
c0burn



Joined: 05 Nov 2004
Posts: 158
Location: Liverpool, England

PostPosted: Wed Feb 24, 2010 5:32 pm    Post subject: Reply with quote

Willem wrote:
I'd settle for not having to juggle the stupid "self" variable like a basketball.


This isn't something inherent to QuakeC - id just got sloppy and called functions that referenced the self global instead of accepting an entity parameter.
Back to top
View user's profile Send private message Visit poster's website AIM Address MSN Messenger
Spike



Joined: 05 Nov 2004
Posts: 944
Location: UK

PostPosted: Wed Feb 24, 2010 6:55 pm    Post subject: Reply with quote

frag.machine wrote:

- Try to use a float to hold flags with more than 23 bits. I can hear lots of modders souls screaming for integer support;

FTEQCC supports an int datatype, and can generate relevent opcodes to handle those ints.
#pragma target FTE
#define int __integer
You now have an 'int' type.

frag.machine wrote:

- What about being able to toggle on/off a bit flag in the float I mentioned above without using the ugly flags = flags - (flags & FL_FOOBAR) hack ? Am I asking too much ?;

self.flags |= MYFLAG;
self.flags &~= MYFLAG;

frag.machine wrote:

- Try not having to replicate every possible entity field in all others, even it's not really necessary (why you have .enemy in a info_notnull ?);

FTEQCC can overlap fields. See previous topic.
Note that a certain level of safety is provided by entities never being truely null - variable fields requires variable allocations. In QuakeC, all nulls are valid.

frag.machine wrote:

- What if, for example, you could have some "generic walking monster entity" and then derivate all other monsters behavior from this template, coding only the parts that are really different from each other (like attacks, death animations, etc) ? You already have some ready-to-use of this, but in a procedural way (every time your monster runs or walks you need to manually calls ai_run() or ai_walk()). Inheritance would help a lot to remove repetitive code;

You would still need to specify how far each step takes the monster. They don't all move at a linear speed, but rather lurch forward based upon how far their animation takes them. The function name being present specifies their behaviour during that frame. So a monster in pain will step backwards... or will it step forwards perhaps? Different amounts in different frames?

frag.machine wrote:

- And what about truly array support without compilers hacks ?

See the thing above regarding ints? FTEQCC can do true arrays, too, as well as indexing pointers if you want dynamic arrays.

And yes, using globals for arguments is evil incarnate. All the demons that invaded in doom and early quake clearly invaded id's coding style too.
_________________
What's a signature?
Back to top
View user's profile Send private message Visit poster's website
frag.machine



Joined: 25 Nov 2006
Posts: 728

PostPosted: Wed Feb 24, 2010 7:31 pm    Post subject: Reply with quote

Spike wrote:
frag.machine wrote:

- Try to use a float to hold flags with more than 23 bits. I can hear lots of modders souls screaming for integer support;

FTEQCC supports an int datatype, and can generate relevent opcodes to handle those ints.
#pragma target FTE
#define int __integer
You now have an 'int' type.


Can the generated progs.dat be used in vanilla Quake ? Not trying to be arrogant here, I am asking because I really don't know. Actually, this question can be extended to all other topics I pointed.

Regardless the answer, since the features exist in FTEQCC/FTEQW we agree that they are useful but lacking in "normal" QuakeC, and saying that "QuakeC is good enough" is simply not correct.
_________________
frag.machine - Q2K4 Project
http://fragmachine.quakedev.com/
Back to top
View user's profile Send private message Visit poster's website
Spike



Joined: 05 Nov 2004
Posts: 944
Location: UK

PostPosted: Wed Feb 24, 2010 9:03 pm    Post subject: Reply with quote

frag.machine wrote:
Spike wrote:
frag.machine wrote:

- Try to use a float to hold flags with more than 23 bits. I can hear lots of modders souls screaming for integer support;

FTEQCC supports an int datatype, and can generate relevent opcodes to handle those ints.
#pragma target FTE
#define int __integer
You now have an 'int' type.


Can the generated progs.dat be used in vanilla Quake ? Not trying to be arrogant here, I am asking because I really don't know. Actually, this question can be extended to all other topics I pointed.

Can native gamecode be used in vanilla?
_________________
What's a signature?
Back to top
View user's profile Send private message Visit poster's website
Stroggos



Joined: 14 Apr 2009
Posts: 43

PostPosted: Wed Feb 24, 2010 9:32 pm    Post subject: Reply with quote

Spike wrote:
You're free to do what you want in your own engine, however...
Without gutting out QC entirely and revamping the bulk of the engine, you'll just end up with compatibility layers.

You would gain the ability to attach a debugger to your game code, yes.
You would gain the ability to invoke native, 3rd-party (closed) code. Although if it is closed then good luck with those GPL obligations.
You would also gain the ability to leak memory, and corrupt your stack.
You would loose the ability to save games easily, any sample code for quake would not work as-is, you'd have to tell linux, mac, etc users 'sorry but my mod won't work on your computer'.

And this is after you've taken the time to rewrite half the engine, rewrite your gamecode from scratch, replicated the old entity behaviour (if you care, if not then enjoy making your own maps too).

Good luck with it though, if you decide to do it. It should be fun. I just hope you're good at bug hunting - there are a lot of assumptions in quake.


I don't care too much about Linux users but I will port it to MacOS simply because it's a great development platform. Also it would be somewhat faster.
_________________
Dont even try to port Quake 4 to the ipod
Back to top
View user's profile Send private message
dreadlorde



Joined: 24 Nov 2009
Posts: 86

PostPosted: Wed Feb 24, 2010 10:41 pm    Post subject: Reply with quote

Stroggos wrote:

I don't care too much about Linux users but I will port it to MacOS simply because it's a great development platform. Also it would be somewhat faster.

Way to be a dick.
_________________
Ken Thompson wrote:
One of my most productive days was throwing away 1000 lines of code.

Get off my lawn!
Back to top
View user's profile Send private message AIM Address
Baker



Joined: 14 Mar 2006
Posts: 1538

PostPosted: Wed Feb 24, 2010 10:42 pm    Post subject: Reply with quote

Stroggos wrote:
I don't care too much about Linux users but I will port it to..


No known released Quake engine projects, no known released QuakeC projects, no known released maps ....

Stroggos wrote:
i know this is a really noob programmer question but what it a quote??? im very new to C and ive only been working with it for about two weeks!


http://forums.inside3d.com/viewtopic.php?p=16021&highlight=#16021

Errr ...

You might learn something from trying to do this project, but this just isn't something that seems reasonable for your level of experience and you might consider a starting point like making a QuakeC mod first and debugging it to understand the mechanics of QC and then level up from there.
_________________
Tomorrow Never Dies. I feel this Tomorrow knocking on the door ...


Last edited by Baker on Wed Feb 24, 2010 10:46 pm; edited 2 times in total
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    Inside3d Forums Forum Index -> Engine Programming All times are GMT
Goto page Previous  1, 2, 3  Next
Page 2 of 3

 
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