Anyone: frikdos.exe isn't compatible with 64-bit. Any suggestions? 

Build a new one from source for your platform. http://www.inside3d.com/frikbot/frikqcc/frikqcc27src.zip

Just delete the "plock=blah;" line in qcc.c (how'd that get in there?) 

i've always wondered, do people who suggest it seriously believe that Build a new one from source is a viable alternative? i've seen that 'solution' thrown around a few times now and it seems absurd to me.

that said, i don't know exactly what's going on, but i use frikqcc.exe without any problems in w7 64bit. 

fteq even a smaller progs.dat bitcount and some errors just overide.
I don't know if that's on 64-bit.

http://www.fteqw.com/ 

There's a simple way to work around this issue without sacrificing the decorative value of torches and flames. Just replace some of them with dummy models and add a few extra point lights. The func_illusionary hack comes in handy here, because it doesn't require messing around with the modelindex, creates a static entity, and preserves the animation.

"classname" "func_illusionary"
"origin" "x y z"
"model" "progs/flame.mdl" // or flame2.mdl

If there's no other real light_flame around, place an additional sound hack entity for the fire ambience. 

I use Gentoo, so "build it from source" is in principle a convincing solution to me. If the guy gives me a makefile, I'm unlikely to complain.

Even Ubuntu comes with GCC. You could say that Linux is a car that comes with a full set of tools to repair it, and the owner is supposed to know how to use them. That's why Linux is cheap.

Windows on the other hand... I guess on Windows, users aren't supposed to know what a compiler is, so telling them to build something from source is outside the rules for that platform, basically. Windows is a car where the user is told to call the customer service when it breaks (and then wait outside in the snow for it to arrive).

Same for Mac. Mac will just drop a new car at your doorstep and charge you money for it, and users will simply pay for that, because they're pretty rich. The old Mac car gets discarded, even if just the radio was broken. Mac users don't compile stuff. Slaves back at the factory do it for them. 

OR WE WILL BEAT DEM! 

i suspected it was something like that. i don't even know what a makefile is. :P

just something to keep in mind for you code monkeys out there. :) 

Hi.

Could somebody point me to a good tutorial that would describe curved surfaces for me? Not the ones in Q3, I mean using angled brushes to round off a corner so it wouldn't be so, 90 degrees.

I just need a little help with the geometry of it all.

Thanks. 

czg wrote this http://www.quaddicted.com/stuff/curv_tut.htm

There was a more recent one by someone else (ijed?) but I don't know where to find it. 

http://web.archive.org/web/20050308151558/http://czg.spawnpoint.org/curv_tut/curv_tut.htm

There is a curve tutorial by CZG, where he shows you how to make pipes and stuff on the grid... in the archive version, the images are missing though. :-/

I guess I could whip something up as well for radiant, maybe I'll do it today, it's easy...

It's hard to explain without pictures. Let's start with an inward corner, like in doorways. Imagine a 90 degree corner of a doorway. To round it off, you basically put more angles in there, for example you can create a 45 degree corner by putting a little triangle shaped brush in there.

This is all that id usually did in the original Quake maps; you'll find lots of doorways that have little wedges in them.

To round it off more than 45 degrees, you'll have to put more brushes in. The next step is putting two little wedges in, and make it so they don't overlap (pull the edges around in Radiant until both little triangles look the same size, and always stay on grid). That will create two additional surfaces in the corner and make it *very* roughly rounded.

For each additional surface in the curve, you'll have to put in an additional little brush. This is the part that is easier to explain with pictures. It will usually look OK if you have three additional surfaces in a corner/curve (this translates to three little brushes), where the middle one is at a 45 degree angle and the outer ones are at a lesser angle.

A 45 degree angle is created in the editor by going one step down, one step sideways on the grid. OK?

Lesser / sharper angles are created by going two steps down, one step sideways. Or four steps down, one step sideways. It's done like this to ensure everything stays on the grid.

http://www.quaketastic.com/upload/files/screen_shots/24sided.jpg

Observe very closely how the angles are done in this 24-sided circle. You don't need so many sides in the beginning - doing the "three angles/brushes per corner" method will yield a 16 sided circle if you do it "all the way around", since 4 X 4 surfaces = 16. It's 16 and not 12 because you have to add the sides that aren't angled. ;-) hard to get without pictures, I know.

This 16-sided method is good enough usually, but sometimes you may want 24 sided to make something look even more smooth. More surfaces in a curve = it looks rounder, smoother.

Now for out facing corners, like the corner of a corridor, it is much the same method, only the curve goes in the other direction... the angles/brushes are on the inside of the curve in this case. The methodology is much the same.

Maybe someone has the pics from the CZG tutorial, but I guess I should put that in my radiant tutorial as well.

You can of course simply use (ex.) Radiant's functions to create cylinders. I'd strongly suggest to stay at a reasonable amount of sides, like a 16 sided cylinder, and be very sure that every corner is on the grid, snapping the thing to the grid (Ctrl-G in radiant) to make damn sure. You can then use the clipper to chop the cylinder into half-and quarter cylinders. This method works best if you set the grid to like 32, and make the cylinder from a relatively large brush like 256x256. For tighter curves, you'll need a smaller grid, or less sides in the curve.

If you look at handrails in games like Quake 4, the corners are often only using two sides. It looks crappy, but for small things in a large/detailed environment, you can get away with it. Also, curves eat performance.

A map full of curves will run slower and slower and take longer and longer to vis. The higher the number of sides in your circles, the slower it will be. Don't go overboard. 

nice, Spirit has the version with pictures. :-) 

Hello all, I'm new on this forum (I am reading it for a long time, but only decided to post now).
I'm working on a Quake 1 map for quite a long time (in Quark) and I got a warning telling me that I have too many marksurfaces in the map (limit seems to be 32k). But the map compiles ok and I can run it in standard glquake.

Questions :
1. What is "marksurfaces" ? I think they are the total polygon number from the map, but I want a confirmation.
2. If the answer to question 1 is "yes", then should I try to keep it under 32k ? What will happen if I go way beyond this ?
...Because my map is not very big, I'd say it's rather small and it's not very detalied either, but I plan to add more details.

Ah, one last note - the map is NOT surrounded by some big box and it doesn't have "leaks" :)

Thanks in advance for your responses and please escuse my bad english. 

Hi RaverX. I'm not sure what marksurfaces are, I only know that you get more of them when your map becomes bigger :) Engine coders will know what they are.

When you exceed the 32 k limit, the map won't run in standard (old) Quake engines. Newer engines, like Fitzquake 0.85, Quakespasm, darkplaces, FTE, and probably DirectQ, have higher marksurfaces limits (and generally higher limits for most things). So with a modern engine, nothing will happen except a warning might be printed to the console.

How a pretty small map could exceed marksurfaces I'm not sure. It might be the editor. Quark is a little infamous among mappers. But if it compiles and runs, then fine.

Remember sending your map to people like negke for playtesting before eventually releasing. It helps. 

View 'all posts' and then do a word search whenever you've got a question - chances are it'll pop up somewhere.

Marksurfaces are produced by complex brushwork, or just lots of brushes intersecting / touching each other. Making simpler structures will reduce marksurfaces, as will just making less map.

But I wouldn't worry about it too much - most people now use a modernised engine so you should be fine.

But!

Make sure to use the compile tools from here:

http://user.tninet.se/~xir870k/

And the documentation there is very good as well - it'll give you a much more concise explanation of marksurfaces and all the other terminology as well.

There are newer versions of the compilers like Willem's WVis which allows for multi-threading - handy, but not necessary if you're just starting.

Any tools you want can be found on http://www.quaddicted.com/ which also has all the maps etc. 

Thank you all for your response, they are greatly appreciated. I really didn't expect anyone to answer so fast.

ijed, I already use those tools, I'll try to read the documentation as well...

You are right, I'm using a lot of small brushes, like small "screws" to hold pillars on the ground, duplicated a lot of times, I guess that might be the problem...

One more question - when the compiler splits the polygons in the map, does it matter how many lights and shadows (lightmaps) are in the map ?

What I'm trying to say :
Let's say I have a face of a cube with a single texture applied there, that's a rectangle. It should be split in 2 triangles, right ? (best case scenario). But what if there's a light nearby casting some shadows there ? Will I still get 2 triangles or a lot more ?

I'm asking this because I alos have a lot of lights in my map (I like playing with shadows). 

with pictures.

http://www.quaketastic.com/upload/files/misc/curvetut.7z

I can make a .zip if you need. 

Try turning the screws into a func_wall (one per room or so), this should help a little. In some cases you can also move brushes 1 unit away from adjacent ones (walls or floor) so the faces behind them don't get split multiple times. This two techniques can be used to lower marksurfaces quite a bit, but their effectiveness also depends on the situation - what helps in one area might be counterproductive in another. Walk around the map with r_showtris 1 (Fitzquake, DP) to see how the faces are split and where optimization makes most sense.

Lights have no influence on the geometry and how it's compiled. 

Reducing Marksurfaces can be done by making some of those small detail-brushes into func_illusionaries. You can make a group of seperate detail brushes into one func_illusionary entity. This will heavily reduce the marksurfaces count and it will also stop the player from clipping agains the brush. If they are small then you wont notice any difference whatsoever.

func_illusionaries, walls, doors, trains etc dont cast shadows though. But this is OK - if you have a large structure like a detailed tank for example, the you can make the whole thing into a func_illusionary or whatever, and then put a solid brush inside this so that you can quite see it, but it creates a shadow and also stops the player from being able to move through it.

If you want to see the marksurfaces and how the world model fits together then in Fitzquake anyway, you can use the console command "r_showtris 1". This will draw the lines of the world model (BSP). Someone said that you can reduce marksurfaces buy seperating touching brushes. This can work very well. Imagine a square face with a cuboid light fitting stuck in the middle of it.
The square face would be made up of two triangles ideally, but the touching brush means that it needs to be a lot more than two triangles, connecting points at each corner of the touching brush to the four outside corners of the square face :)

Confusing eh?

In short, my advice:

Make each of the clusters of "screws" into a func_illusionary (this is exactly what I would do), re-compile, and watch your marksurface count go down :D 

full of missing letters and typos.

"theN you can make the whole thing"

"canT quite see it" 

I started a radiant curve tutorial at kneedeepinthedoomed.wordpress.com, for now only pics, will fill in words in a while. Not everything will work in other editors, but the basics are the same. Radiant has very easy ways to make cylinders, circular holes, and rings with a lot of sides and perfectly snap them to the grid. I'll also do pipes, connecting pipes, circles out of pipes, and finally terrain etc.

I've stuck to 16 sided circles, maybe you want to do something about 24 sided ones, and correct all my mistakes, ijed. 

Are completely separate. All that the light tool does is draw the lightmap - a big texture made of shadows that gets painted over your world geometry.

Any func_ brushes aren't part of world geometry so don't affect Vis times, marksurfaces etc. although they can have other problems like flickering in and out of visibility if within different Vis leafs - usually only for big brush entities though.

They don't make shadows either, but if you have something big and intricate you can turn it into a func_wall and stick a simple rectangular world brush inside it to make a shadow.

Curve tutorial... I will add to it, but in a month or so. If I have an attack of boredom (sweet, sweet boredom) maybe I'll get back from holiday with something ready. 

The hint with r_showtris really helped. I turned on r_showtris and ... HOLLY SH*T ! The screen was full of lines and I notices something - I can see the entire map. First it was like WTF, then (in 2-3 seconds) it hits me : the map is not fully VISED, I compiled it with novis, because I always add stuff and I need to compile it quickly to see if my "new things" really look like I want to...

Could that be my problem ? 

As long as your map runs OK in a modern engine I don't think you *have* a problem.

It needs to be fullvised before you release it, though.

Fullvis it and load it into an engine that supports r_lockpvs. This allows you to freeze your current field of view, so to speak, and then noclip around to see how much of the map gets actually drawn. This is often quite enlightening, too.

Those lines should get less once you apply the func_illusionary or func_wall trick. In a detailed map it's normal to have a lot of polies, though. 

you can also use r_showtris instead of r_lockpvs to see how much is being drawn. This can break down in polygon-dense areas, if you can't clearly see what you're looking at, though.