InsideQC Forums

Been planning on making a standalone version of Hellsmash for a while now, and have a little time to work on it.

Upon looking around, it seems that qfusion is probably the best suited for my needs with this, unfortunately I have almost no idea what I'm gonna need in the way of tools / pointers for it.

Hence I figure I might as well ask here, and see if anybody might be able to steer me in the right directions for info.

What I figure I'm gonna need:
code::blocks + mingw (engine and gamex86.dll)
blender (modeling)
GtkRadiant + q3map2 (mapping tools, project obviously uses lightstyles)
Q3A Shader Manual

What info I need:
location of QuakeC interpreter code (what files I look in) and or a plug-in module for it
???

I assume I'm going in the right direction with this right?

qfusion cannot run qc. you'd likely find it easier to just rewrite your mod in C instead.
if you want to port a qc interpreter to qfusion, you'd need to port all the pr_*.c files over, and somehow integrate the two sv_phys.c, sv_move.c, world.c, files with whatever already exists in qfusion.
don't expect to run generic qc mods with it (hence why you might as well just convert your mod to c instead).

Spike wrote:qfusion cannot run qc.

I already knew that much.

Spike wrote: if you want to port a qc interpreter to qfusion, you'd need to port all the pr_*.c files over, and somehow integrate the two sv_phys.c, sv_move.c, world.c, files with whatever already exists in qfusion.

That was exactly what I needed to know, thank you!

Spike wrote: don't expect to run generic qc mods with it (hence why you might as well just convert your mod to c instead).

Not the objective with this project. I intend to break all compatibility with quake for this project (standalone game, using mostly q3 data formats), but wanted to at least make an attempt to keep some low level accessibility for n00b modders. (I still remember the horrific experience of reading through quake 2's gamex86.dll code years ago...I really couldn't decipher it back then )

Good going Dr. Shadowborg, and good luck.

Adding a qc interpreter to qfusion seems like a lot of extra work though considering support for Warsow formats already exists in FTE. I'm curious - why do it?

Yeah, you will need Radiant and q3map2 to make maps using FBSP. And Blender is fine for creating IQMs (Warsow ditched the SKM format a while back).

You will need the shader manual, but you'll also need all Quake 3 mapping tutorials you can get your hands on and you'll want to read and compare shaders from eg Warsow and other sources. You will also want to read the q3map2 wiki.

http://en.wikibooks.org/wiki/Q3Map2

goldenboy wrote:Good going Dr. Shadowborg, and good luck.

Thanks, hopefully I'll be able to get up to speed on this newer tech. Then we'll all be able to see a merry band of unemployed programmers, ex-military specialists, cyborgs and gogo girls do battle with chainsaw and rippergun toting illithids, zombies, and other assorted exotic horrors within equally exotic (and hazardous) locations.

goldenboy wrote: Adding a qc interpreter to qfusion seems like a lot of extra work though considering support for Warsow formats already exists in FTE. I'm curious - why do it?

I wasn't actually aware that FTE could handle the FBSP format. (I knew about .md3 and Q3BSP support) I guess I should download a more recent version of FTE and see how it performs on the laptop I'm gonna be developing on.

Another reason is I've always seen FTE as being the same as DP. (lots of features, not a lot of documentation on said features, features that may never be used, etc.) In some ways, I feel it's better to start from a basic, barebones "just what you need to run it" plain codebase and just add what you need when you need it. CSQC also adds another level of complexity to the picture.

goldenboy wrote: Yeah, you will need Radiant and q3map2 to make maps using FBSP. And Blender is fine for creating IQMs (Warsow ditched the SKM format a while back).

You will need the shader manual, but you'll also need all Quake 3 mapping tutorials you can get your hands on and you'll want to read and compare shaders from eg Warsow and other sources. You will also want to read the q3map2 wiki.

http://en.wikibooks.org/wiki/Q3Map2

Thanks for the link, I'll check that out as well. (upon googling FBSP, I see I'm not the only one who's been looking at it for one of their projects, hehe )

Does QFusion even support md3 anymore? Warsow has switched to IQM afaik.

Yeah, I use FBSP and IQM combined with QC for my project. My reason for using FTE is that I don't want to throw away 5 years of work on my QC, and I want to use some hud code by gnounc that needs CSQC.

Warsow uses Angelscript for its game modes and GUI, I think.

Anyway, if you use qfusion with QC keep us updated I'd be curious to see such a combination, even though I'm unlikely to switch because I use other FTE features.

Are you moving to QFusion because of the shader syntax support?

Don't forget Darkplaces has support for that as well, although limited for the sake of the complex lighting model.

If wide support is intended, try sticking to a February 2011 build.

I should also remind that Darkplaces still "works" on certain ancient hardware (ok, it works a lot better on a Voodoo2 than this, and the main culprit of the slow is the carelessly high polygon count of the player models)

Also another option is FTEQW, which also has q3 shader support. FTEQW also has a LOT of defines you can disable for stuff you don't want if you want a cleaner build than a fully merged fully featured one, and you probably don't want that silly colorful comic sans splash screen (is that still in there spike?).


Also q3bsp and lightstyles don't really mix - q3map2's take on it is faked up shader generation to emulate lightstyles - the actual lighting doesn't change.

For editing Q3 shaders, the old tool q3ase may come in handy.


Also Blender, there's no working MD3 exporter for the later 2.6X versions. You'll have to stick to 2.49 if you want to export directly to MD3 from Blender using these scripts. You can however, have an annoying-as-hell pipeline to MD3 with 2.6x by exporting to IQM then converting that with Noesis. While IQM is a good format, I don't crusade on pushing it to be used for everything modeled for every engine under the sun, though it does make a very nice "exchange" model format to others only because the Blender exporter is so well written (as opposed to everything else it can export). I use IQM to produce PSKs for UnrealEngine2 and MDRs for OA3, because the included PSK exporter with blender is just plain crap and a MDR exporter (Raven's MD4 fixup for Elite Force) for Blender does not yet exist.

goldenboy wrote:Does QFusion even support md3 anymore? Warsow has switched to IQM afaik.

Dunno about the latest builds, currently messing around with qfusion version 10.

goldenboy wrote: Anyway, if you use qfusion with QC keep us updated I'd be curious to see such a combination, even though I'm unlikely to switch because I use other FTE features.

Will do!

leileilol wrote: Are you moving to QFusion because of the shader syntax support?

Alot of reasons actually.

Reasons:
1. I got tired of only three hull sizes
2. vertex swimming on models
3. no tag support (model based muzzleflashes are good for software, but otherwise ehhh.)
4. no shader support (I'll admit I've never used a shader before)
5. playing q3ta's big CTF map
6. playing EF and EF2
7. ability to do portals you can see through among other things
8. CSQC or engine mod ONLY for HUD modifications

leileilol wrote: Don't forget Darkplaces has support for that as well, although limited for the sake of the complex lighting model.

If wide support is intended, try sticking to a February 2011 build.

I should also remind that Darkplaces still "works" on certain ancient hardware (ok, it works a lot better on a Voodoo2 than this, and the main culprit of the slow is the carelessly high polygon count of the player models)

I've never been able to get DP to actually work very well on any of my equipment. It's either not worked, worked with messed up vertexes all over my screen, or worked slowly.

leileilol wrote: Also another option is FTEQW, which also has q3 shader support

I'll give it a try, though it will have to perform as fast and smooth as qfusion does.

leileilol wrote: Also q3bsp and lightstyles don't really mix - q3map2's take on it is faked up shader generation to emulate lightstyles - the actual lighting doesn't change.

Didn't look too bad to me on ravendelux. Besides, what else is there in mapping formats that support the goodies that Q3BSP / FBSP do?

leileilol wrote: For editing Q3 shaders, the old tool q3ase may come in handy.

Noted, I'll grab that too.

leileilol wrote: Also Blender, there's no working MD3 exporter for the later 2.6X versions. You'll have to stick to 2.49 if you want to export directly to MD3 from Blender using these scripts. You can however, have an annoying-as-hell pipeline to MD3 with 2.6x by exporting to IQM then converting that with Noesis. While IQM is a good format, I don't crusade on pushing it to be used for everything modeled for every engine, though it does make a very nice "exchange" model format to others. I use IQM to produce PSKs for UnrealEngine2 and MDRs for OA3.

Also noted. Worse comes to worst I can always try to add support for IQM from later builds of Warsow if FTE doesn't fit the bill.

Anyway, thanks for the pointers / tips. I'll try to keep you all updated as I progress.

Hm, just downloaded and tried to run the latest stable release with fteqw-v100-win32.zip. Said that it wasn't a valid win32 executable. :/ Doesn't work on win2k? I'm downloading fteglqw-v100-win32.zip now, I'll give that a try.

Edit: no go on fteglqw either. I'll just stick with trying to get qfusion up and running. Should if nothing else provide a good learning experience.

QFusion is based on Quake 2. At one point it was fairly easy to add monster game code back for single player. I don't know if that is still feasible in the final version released 3 years ago. The engine for Warsow has diverged since then.

Dr. Shadowborg wrote:Reasons:
1. I got tired of only three hull sizes
2. vertex swimming on models
3. no tag support (model based muzzleflashes are good for software, but otherwise ehhh.)
4. no shader support (I'll admit I've never used a shader before)
5. playing q3ta's big CTF map
6. playing EF and EF2
7. ability to do portals you can see through among other things
8. CSQC or engine mod ONLY for HUD modifications

1. Darkplaces can force new hulls even on q1bsp, iirc. there's some cvar that can do it
2. SPOILER: MD3 still has vertex swimming
3. dpextensions.qc, look for QUAKE3MODELTAGS for more info. should also be fte compatible
4. The novelty of having lots of stages will eventually die down, when you're serious you'll most likely stick to 1 or 2 stage shaders.
5. that's unfortunately a big hack with lots of complex vertex alpha shader trickery for terrain blending
6. EF has a whole "Icarus" scripting enigne for the single player; EF2 used the Ubertools framework for alot of the advanced stuff
7. div0 hacked in portals into Darkplaces once
8. Just a new hud in CSQC is one of the easiest things you could do in CSQC. if c0's still around, ask for his hud base.

leileilol wrote:

Dr. Shadowborg wrote:Reasons:
7. ability to do portals you can see through among other things

7. div0 hacked in portals into Darkplaces once

Nahuel has used div0´s code and got it working (even can shoot through them !):
http://www.youtube.com/watch?v=aN7McP2AB1c&feature=plcp

I cannot contribute much, but I want at least link 2 pages I know with Q3shader manuals, because you asked for it in your opening post:
http://toolz.nexuizninjaz.com/shader/
http://www.robotrenegade.com/q3map2/docs/shader_manual/

I hope they are of some use for you.
Best wishes for your project.

qbism wrote: QFusion is based on Quake 2. At one point it was fairly easy to add monster game code back for single player. I don't know if that is still feasible in the final version released 3 years ago. The engine for Warsow has diverged since then.

I don't suppose you've got an archived copy of that discussion left anywhere do you?

leileilol wrote: 1. Darkplaces can force new hulls even on q1bsp, iirc. there's some cvar that can do it

I'd heard that was buggy and didn't work very well, hence why it's not used more often.

leileilol wrote: 2. SPOILER: MD3 still has vertex swimming

Perhaps so, but it can't possibly be as bad as .mdl and .md2 can be.

leileilol wrote: 3. dpextensions.qc, look for QUAKE3MODELTAGS for more info. should also be fte compatible
4. The novelty of having lots of stages will eventually die down, when you're serious you'll most likely stick to 1 or 2 stage shaders.
5. that's unfortunately a big hack with lots of complex vertex alpha shader trickery for terrain blending
6. EF has a whole "Icarus" scripting enigne for the single player; EF2 used the Ubertools framework for alot of the advanced stuff
7. div0 hacked in portals into Darkplaces once
8. Just a new hud in CSQC is one of the easiest things you could do in CSQC. if c0's still around, ask for his hud base.

None of which does me much good. I tried a February 2011 release of DP and while it runs okay, for some reason when dlights are on FPS goes down to 1-2 fps and none of the architecture gets lit up either. I've tried all the settings too, none of which seem to help outside of actually turning the dlights off.

seven wrote: ...

I cannot contribute much, but I want at least link 2 pages I know with Q3shader manuals, because you asked for it in your opening post:
http://toolz.nexuizninjaz.com/shader/
http://www.robotrenegade.com/q3map2/docs/shader_manual/

I hope they are of some use for you.
Best wishes for your project.

Thanks, those will help alot too!

Dr. Shadowborg wrote: for some reason when dlights are on FPS goes down to 1-2 fps and none of the architecture gets lit up either.

Darkplaces by default has realtime lights from dlights. Turn it off

r_shadows_realtime_dlight 0 should do the trick, iirc. By the way the realtime shadows stuff is much more slower in 16-bit color than it is in 32-bit due to the required high precision stencil buffer, iirc


Also recent more Darkplaces builds add Direct3D9 support as well as a software renderer (for SSE2-supporting cpus). vid_d3d9 and vid_soft should be the cvars for them, IIRC, AFAIK,

leileilol wrote: Darkplaces by default has realtime lights from dlights. Turn it off

r_shadows_realtime_dlight 0 should do the trick, iirc. By the way the realtime shadows stuff is much more slower in 16-bit color than it is in 32-bit due to the required high precision stencil buffer, iirc

Also recent more Darkplaces builds add Direct3D9 support as well as a software renderer (for SSE2-supporting cpus). vid_d3d9 and vid_soft should be the cvars for them, IIRC, AFAIK,

That's what I was talking about. Turning them off fixes that issue, but doesn't fix the issue where projectiles that should be emitting light don't appear to be doing so. (EF_MUZZLEFLASH isn't working either)

How recent do I have to go to get a D3D9 supporting build?