What are you working on?

Discuss anything not covered by any of the other categories.
toneddu2000
Posts: 1395
Joined: Tue Feb 24, 2009 4:39 pm
Location: Italy

Re: What are you working on?

Post by toneddu2000 »

frag.machine wrote:They said in the description the engine is based on idtech3, so it's Quake 2.
but..look at the description on QEXPO2016 page, just above the first series of images
Meadow Fun!! - my first commercial game, made with FTEQW game engine
mh
Posts: 2292
Joined: Sat Jan 12, 2008 1:38 am

Re: What are you working on?

Post by mh »

idTech3 is Quake 3, not 2.

idTech2 is Quake 2; idTech 1 is Doom. The Quake engine doesn't have an idTech number but can be considered an earlier version of 2.

So in 2016 it was based on FTE; in 2018 it's based on Quake 3; simple explanation: the team switched engine.
We had the power, we had the space, we had a sense of time and place
We knew the words, we knew the score, we knew what we were fighting for
toneddu2000
Posts: 1395
Joined: Tue Feb 24, 2009 4:39 pm
Location: Italy

Re: What are you working on?

Post by toneddu2000 »

mh wrote:So in 2016 it was based on FTE; in 2018 it's based on Quake 3; simple explanation: the team switched engine.
yeah, that could be the explanation. Sure it's a hell of work to switch engine when in the 3-persons team there's only one programmer! :) Plus, dealing with Quake3 means dealing with pure C instead of quakec. I wonder why they switched..

Since I'd like to make a "real" game with FTE(and not just shitty techdemos like I did so far..), I'd like to know which "weakness points" of FTE make them switch to Q3. And, moreover, which version of Q3 :lol:
Last edited by toneddu2000 on Mon Apr 16, 2018 12:41 pm, edited 1 time in total.
Meadow Fun!! - my first commercial game, made with FTEQW game engine
Baker
Posts: 3666
Joined: Tue Mar 14, 2006 5:15 am

Re: What are you working on?

Post by Baker »

toneddu2000 wrote:lus, dealing with Quake3 means dealing with pure C instead of quakec. I wonder why they switched..
Probably so they could use pure C instead of QuakeC. :razz: :razz:

Q2, Half-Life went from QuakeC to C/C++. If Carmack thought qc was the way to go, Q3 would have used QuakeC. :lol:

I'm not knocking QuakeC. But debugging in Visual Studio is surreal bliss.
The night is young. How else can I annoy the world before sunsrise? 8) Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..
toneddu2000
Posts: 1395
Joined: Tue Feb 24, 2009 4:39 pm
Location: Italy

Re: What are you working on?

Post by toneddu2000 »

sure Baker, C is much much more powerful compared to scripting language (and compared to quakec in frist place) but, sure you've noticed that all modern commercial game engines (so all the companies which profit came from SELLING the engine and not games) have at least a scripting language (or at least a visual scripting language) in their offer. That's because of indie sector. In a AAA company, I'd agree with you. There's no need for scripting language, because the lead developer uses his 6/10 programmers to build the scaffolding of the game (one for the editor, one for the rendering part, one for the gameplay, etc.) but with three guys, with one of them doing programming AND graphics, textures(check their website) and so on, using C and all the problems related to it, it seems quite difficult to me. With FTE, you simply don't care about engine stuff and just concentrate on your game.
At least that's my opinion
Baker wrote:But debugging in Visual Studio is surreal bliss.
:biggrin:
Meadow Fun!! - my first commercial game, made with FTEQW game engine
Baker
Posts: 3666
Joined: Tue Mar 14, 2006 5:15 am

Re: What are you working on?

Post by Baker »

Doesn't Unity use .NET for game logic? I think Valve's Source engine uses C++. Source engine is not open source at all, so you are touching game logic.

https://developer.valvesoftware.com/wik ... cal_Entity

When you are using either of the above, you aren't concerned with engine code. Just events and such.

And almost certainly a Q2 DLL is just events and such. While I am no expert about Q3, the game logic is not part of the engine there either.

My point is all of the above allow you to use Microsoft IDEs to debug whether .NET or C++.
The night is young. How else can I annoy the world before sunsrise? 8) Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..
Spike
Posts: 2914
Joined: Fri Nov 05, 2004 3:12 am
Location: UK
Contact:

Re: What are you working on?

Post by Spike »

Its described it as 'idTech3' because they use q3 toolchains, q3 shaders, etc, but with skeletal models instead of md3. That's the justification for that, anyway, and describes the visuals better than claiming it to be a paletted game.
The Wastes still uses FTE somewhere under all the menuqc+csqc. And besides, FTE can run q3 itself well enough, they're just using the Q1-derived API instead.

Baker, that's why I debug QC in fteqccgui. Single-stepping etc rocks (feel free to implement compat into your engines - it uses stdin/stdout to communicate with the gui, and a commandline arg to let the engine to know that it should listen for it).
Side note: compile with -DVM_LUA if you want to write your ssqc in lua instead. hifi wrote a qc2lua thing if you want to get a quick start with the gamecode. The 'q1qvm' stuff allows you to use C (or c++ or etc etc, anything that can be compiled/wrapped as a dll, and thus debugged with msvc/whatever) instead, but engine interaction is more limited, and the menu+csqc is still exclusively qc.
scripting languages are useful for per-map scripts, so that you don't need to depend on insane stuff like killtarget to try to get some semblance of turing-completeness. There's a few things you can do with QC to try to achieve sanity, but its nowhere near as nice as lua's dynamically compiled stuff - require("maps/" .. mapname .. ".lua"), voila, you can now create custom entities on a per-map basis. FTE's qc has an addprogs("foo.dat"); but there's still all sorts of gotchas. :(
Baker
Posts: 3666
Joined: Tue Mar 14, 2006 5:15 am

Re: What are you working on?

Post by Baker »

Spike wrote:Single-stepping etc rocks (feel free to implement compat into your engines - it uses stdin/stdout to communicate with the gui, and a commandline arg to let the engine to know that it should listen for it).
/Snort :biggrin:

Why am I not surprised :lol:

In a perfect world, Spike's infrastructural ideas would propagate across the Earth.
The night is young. How else can I annoy the world before sunsrise? 8) Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..
frag.machine
Posts: 2126
Joined: Sat Nov 25, 2006 1:49 pm

Re: What are you working on?

Post by frag.machine »

Baker wrote:
toneddu2000 wrote:lus, dealing with Quake3 means dealing with pure C instead of quakec. I wonder why they switched..
Probably so they could use pure C instead of QuakeC. :razz: :razz:

Q2, Half-Life went from QuakeC to C/C++. If Carmack thought qc was the way to go, Q3 would have used QuakeC. :lol:

I'm not knocking QuakeC. But debugging in Visual Studio is surreal bliss.
Actually, I remember Carmack saying he regretted going to native C DLL for game code, thus Quake 3 used interpreted C.
I know FrikaC made a cgi-bin version of the quakec interpreter once and wrote part of his website in QuakeC :) (LordHavoc)
frag.machine
Posts: 2126
Joined: Sat Nov 25, 2006 1:49 pm

Re: What are you working on?

Post by frag.machine »

mh wrote:idTech3 is Quake 3, not 2.

idTech2 is Quake 2; idTech 1 is Doom. The Quake engine doesn't have an idTech number but can be considered an earlier version of 2.

So in 2016 it was based on FTE; in 2018 it's based on Quake 3; simple explanation: the team switched engine.
Interesting, first time I heard this definition for idtech2 not being Quake.
And now I got a sad because poor Quake engine is demoted to a second class citizen position in the gaming history... :cry:
I know FrikaC made a cgi-bin version of the quakec interpreter once and wrote part of his website in QuakeC :) (LordHavoc)
toneddu2000
Posts: 1395
Joined: Tue Feb 24, 2009 4:39 pm
Location: Italy

Re: What are you working on?

Post by toneddu2000 »

Spike wrote:Baker, that's why I debug QC in fteqccgui.
Ehm..few little words about this nice feature? I clicked debug, choose the .exe, and it created a fteqcc.ini file with lots of configs in it. Now what? :biggrin: Could you please make a 2 minutes explanation about debugging in quakec to a person who never debugged in his entire life? :biggrin: I know that you could set break points in your editor but I don't know how you can go step-by-step in fteqccgui
Baker wrote:In a perfect world, Spike's infrastructural ideas would propagate across the Earth.
Same :biggrin:
frag.machine wrote:And now I got a sad because poor Quake engine is demoted to a second class citizen position in the gaming history... :cry:
Lol..actually, now that you said that, I recall that I never understood well the idtechX engine family! :lol:
Meadow Fun!! - my first commercial game, made with FTEQW game engine
Spike
Posts: 2914
Joined: Fri Nov 05, 2004 3:12 am
Location: UK
Contact:

Re: What are you working on?

Post by Spike »

debugging in fteqcc.
double-click a .src file (select fteqccgui to open it with, if you've not already set up your file associations).
hit f7 to compile it.
hit f5 to start running it (first time it'll likely prompt for engine (pick some version of fte), and then the base directory, it'll guess the gamedir from the .src location and add -window to the commandline, because that's more sane).

in the gui:
hit f5 to resume normal running after hitting a breakpoint.
hit f7 to recompile - note that this will also restart the map in order to apply changes, assuming you didn't quit the engine first.
hit f8 while its stopped to change which statement gets executed next.
hit f9 to set a breakpoint. breakpoints set inside the gui will be re-applied on map restarts, and for all 3 modules.
hit f10 to single step (step over - treating child functions as if they were a single statement).
hit f11 to single step (step into - entering child functions).
hit shift+f11 to continue execution until it returns to the parent function (step out).
(these keyboard shortcuts should all be documented in fteqccgui's menus.)
you can mouse-over expressions to see their values, assuming execution is paused - otherwise it'll just try to display their types/descriptions.
or you can use the watch window thing to type in stuff that you want to re-evaluate each time the program stops.
(expression evaluation is fairly basic, and basically limited to globals and ent.field expressions, including basic assignments, locals are kinda messy. evaluating an ent will give a long list of its fields, integers on the lhs of an expression are interpreted as entity indexes, so '1.netname' will show the first player's name)

at the console:
watchpoint_[csqc|ssqc|menu] can be used to break your program when the watched expression changes (the memory address that stores the expression will be tested).
poke_[csqc|ssqc|menu] can be used to evaluate expressions.
a stack trace will be shown whenever the engine is waiting for the debugger to allow it to resume execution. you can read locals etc here.

while debugging:
any bounds checks, errors from builtins, etc, should trigger an exception. focus will be given to the gui (which will display the relevant error dialog), you can then use f8 to change where its executing, or change variables by evaluating some expression with an assignment in it (or just change the code and hit f7 to restart the thing).

use #pragma sourcefile "foo.src" in order to instruct fteqcc to compile additional modules. This will allow you to gracefully debug all three of ssqc+csqc+menuqc with a single debugging session. commonly you'll have a .src that just includes three such lines (if its called preprogs.src then it'll be favoured by default over progs.src).
not really sure if there's anything else worth mentioning.




fteqccgui debug protocol (for baker)
-qcdebug will be on the commandline if the engine is started via fteqccgui. If so, interpret the stdin/stdout as a debug session, otherwise as an alternative console. debug commands are all \n separated.
g2e debuggerwnd $hwnd - gui tells the engine which window to set focus to on exceptions (windows doesn't let programs grab focus from others, only for programs to voluntarily give focus to another).
g2e qcresume - tells the engine that it should start running now, and not stop until the next breakpoint or exception. silently ignored if not debugging.
g2e qcstep over - tells the engine that it should run until the line number changes (unless it hits a child function, in which case it runs until return as if it were a single instruction).
g2e qcstep into - tells the engine that it should run until the line number changes (first statement of a child function counts as a new line number).
g2e qcstep out - tells the engine that it should run until it returns to its current parent.
g2e qcbreakpoint $mode "$file" line - tells the engine to clear|set|toggle a breakpoint (mode is 0|1|2)
g2e qcjump "$file" line - tells the engine to change where its currently executing.
g2e qcinspect "$expression" "$scopename" - asks the engine to evaluate the given expression. Scopename is provided to allow the engine fail gracefully if the function isn't current or whatever. The result is returned via a qcvalue response.
g2e qcreloaded - lets the engine know that something has been recompiled, and that it should restart everything.
e2g status $status_text - engine tells the gui what its status is. This doesn't necessarily display anywhere, but is useful for the gui to know that its talking to an engine that knows whats going on. you might want to just use refocuswindow instead though, both remove any warning messages about the engine not supporting -qcdebug.
e2g qcstep "$file" $line - engine tells the gui that it has stopped, at the specified line.
e2g qcfault "$file" $line "reason" - engine tells the gui that it has stopped, at the specified line. the reason text will be messageboxed.
e2g qcvalue "$variableformula" "$value" - engine reports the value of a requested expression back to the gui
e2g qcreloaded "$vmname" "$progsname" - engine lets the gui know that it has loaded a 'new' progs, and is now waiting until told to qcresume (this allows the gui to resend breakpoints).
e2g refocuswindow $hwnd - engine reports its hwnd to the gui, so that the gui can give it focus any time execution is resumed.
so yeah, if the engine breaks then it needs to give focus to the gui and wait until qcstep/qcresume. qcreloaded should abort current execution and reload everything.
the engine will need to read the .lno files and figure out line numbers itself, filenames come from a statement<-functable->file lookup.
the engine will need its own expression evaluation logic, which can be as simple as global[.field[.field[.field]]], but future versions might expect more :(
If -qcdebug is used then Sys_Printf should not dump anything other than the above to the stdout, other stuff is kinda undefined. Be careful with input if you wish to respond to window events while broken, and limit any drawing to just the console or whatever. Remember to release any cursor grabs too, and that dedicated servers don't have any of that stuff. While you could potentially handle the qc* commands via the console, if the engine actually supports breaking then those commands will of course get lost, so these will HAVE to be handled early, and not just while broken. You'll get broken pipe errors if the gui quits before the engine - generally the engine should quit too, but whatever.
I'd be nice to switch this stuff to a named pipe, so that it can attach without needing to restart/select the engine or whatever, but mneh.

Me documenting this stuff means that Baker now has to cause it to propagate across the Earth, right? Good. Mwahaha...
toneddu2000
Posts: 1395
Joined: Tue Feb 24, 2009 4:39 pm
Location: Italy

Re: What are you working on?

Post by toneddu2000 »

thanks A LOT man! :biggrin:
Meadow Fun!! - my first commercial game, made with FTEQW game engine
mh
Posts: 2292
Joined: Sat Jan 12, 2008 1:38 am

Re: What are you working on?

Post by mh »

frag.machine wrote:Actually, I remember Carmack saying he regretted going to native C DLL for game code, thus Quake 3 used interpreted C.
That was for security & portability reasons.

It's also notable that Q3 does have the ability to load native DLLs in addition to QVMs. The idea is that you develop using DLLs and get to use a proper toolchain and debugger. Then you compile to QVM and ship that.
We had the power, we had the space, we had a sense of time and place
We knew the words, we knew the score, we knew what we were fighting for
toneddu2000
Posts: 1395
Joined: Tue Feb 24, 2009 4:39 pm
Location: Italy

Re: What are you working on?

Post by toneddu2000 »

Banging my head against dynamic parallel shadows in FTE so hard that I asked help on Freelancer site. I post link here so maybe some Quake engine dev could be tempted..

I know it's a very low budget project and someone could be considered insulted, but (as I stated in the post):
- I don't care if devs copy/paste the shadow part from another engine (like Tesseract from example)
- it's an open source project so the entire community would benefit from it
Meadow Fun!! - my first commercial game, made with FTEQW game engine
Post Reply