 News | Forum | People | FAQ | Links | Search | Register |
Log in |
|
|
That would be cool. I want it. Where do I find Win32 exe?
(Is it as stable as AguirRe's?) Yep, the latest version of ToeTag includes a multithreaded version of VIS but it's only going to work on Mac OSX. The code was pretty easy to hook up in all honesty - it was mostly a matter of incorrect function names and a few small changes here and there. If anyone wants my source code for that you can grab it here:
http://www.wantonhubris.com/SrcForJim/ That's the source code for the original id tools that I based mine on, and the multithreaded versions of LIGHT and VIS that I did. I don't know what's involved in making it Win32 happy, but I know that jimbo is working on a Linux version. Sound very exciting!!
Unfortunately, I feel the usual symptoms of a severe programming allergy starting to creep in! There must me someone out there who is interested in making a win32 exe!! If not, Q1 mapping in OSX seems even more attractive. :D Well, I've done what I can. :) There's the source and I assure whoever looks at it that the multithreading in there works on OSX. It shouldn't be a huge hassle for someone to port it to Win32 unless multithreading on Windows is a complete nightmare. In which, you have my condolences.
Hello, been lurking here for a while finally got time in RL to fart around with mapping and Ive started using BSP & that nice WC3.3 conversion. I like BSP better but it doesnt seem to remember what textures you put on prefabs. Ive been using the "Save Brush" feature I figured this was BSP's "Prefab Factory" equivalent. If there is something else or if anyone knows wether or not BSP will actually save tex info on prefabs please, please fill me in. I have been unable to find anything referencing this in the docs or in the cfgs.
Thanks in advance! Fatty The texture information is saved with the
If that helps... OK, I need some pointers here.
I'm working on a turtlemap which is like 80% done (no roofs and no monsters yet.) My central area (a 1024x1024 atrium) shares the same sky with the surrounding corridors and rooms, because the roof construction is only made of a steel skeleton (no "shingles".) I'd like to keep sky visible and use sunlight. So basically this is like a 1600x1600 area divided by some walls, and doors, and eventually probably inhabited by ~ 100 monsters - nothing more. Think Doom map with ceilings ripped open and 4 times the size. How badly will something like this affect r_speeds? Also, what kind of stuff apart from torches counts toward the static entity limit? ^^ I have a bad feeling there, too. This might combine into a gigantic mess. It was my beginning concept though, large atrium surrounded by wide corridors with holding cells. Maybe this was faulty already, most maps have interlocking corridors and only peripheral outdoor areas. It looked good on paper. Sigh. :-/ It's almost finished though, so we'll soon see anyway... maybe it'll serve as an example to others... :-/ Compile it and see if it runs in FitzQuake. Give it a full vis, and then when in FitzQuake type "r_showtris 1", to look at the mesh.
My visblocking is piss-poor at the best of times, but I know enough to know that you can get away with quite a lot when using a good glquake engine! IMHO. As for there being about 100 monsters - this isnt too many for Quake by any means, so I wouldnt worry about that! Try and block as many of the cielings off from eachother, think "If I put a sky-brush here, blocking this other part from view, will the player *really* be able to tell the difference, if they arent noclipping/flying around the map?". 'Vis-blocking' in this way will keep r_speeds down. Try running the map in standard GlQuake or even software WinQuake, the original Quake executables. If it runs in them, I would say that its a reasonable statement that it will be fine in all other engines!! Others will know better than me! ;-P ...100 monsters on the screen at once wont be healthy for Quake. AguirRes engine, yess, other engines, probably not....
Basically what Ricky says - closing off the various sections into rooms that don't look like rooms because their ceilings are sky brushes - the player just assumes its all open space and not completely boxed in.
I mean using 'invisible' sky brushes with a skybox, basically. It works even if you have a pointed roof - put a wedge coming down from the topmost skybrush that meets its top edge. You have to find the best way to fake the visual effect. Static entities are decorative objects - crucified zombies, func_illusionaries, flames, torches, light globes etc. But not lights, there's a few other exceptions as well. The map is outdoor, as in lots of triangular faces? In a way that's easier to solve from a vis point of view (even if it's more work) in that you can just throw a dog-leg into a corridor that'll break up LOS more - in a brick or metal corridor you have to do more thinking, although wall pillars and corners help. If the walls are high enough (while the player always stays down on the floor) and the rest is sufficiently visblocked, having only 'one sky' shouldn't be much of a problem. Vis time will be longer than with smaller sky units though.
Are crucified zombies static objects as well? I don't think so. I managed to killtarget them in Nehahra, which should mean they're not, but I've heard alot of coders saying they are.
Another question would be does this apply to spawned models that don't necessarily have animation - Nehahra misc_objects, Quoth corpses and ID hacked bmodels. I've never managed to decompile the QC and wouldn't know what it meant at first sight anyway. ...but the Quoth corpses, erm, I can tell you one thing: if you noclip outside of a map, you can still see the corpses (certainly in FitzQuake), whereas you cant see monsters/doors etc.
Hope this helps! It's actually a bit more involved than that. The lynched and crucified corpses are static entities in quoth, and the flayed ones are dynamic - although the tutorial says all of them are dynamic. Changing them now would be a bad move for quoth2, as it might break existing maps by leaving them with too many static entities, or too many dynamic ones! So instead we now offer two spawnflags on such mapobjects. Spawnflag 1 will make them static, and spawnflag 2 dynamic. This allows you to balance your load of dynamic and static entities as you need to. It also extends to things like torches and flames.
Sounds really cool!
When can I get it for WIP map, i.e. when is Quoth2 finished? I mean, christ, I dont want it to be rushed, im just curious. would be easier to judge if we saw the map, you can send it to someone on #terrafusion before vising (do you come/go there?)... Or if you can wait, over here...
Yeah I was talking about BspEd, been using the latest build. I am using the same wad I made the prefabs with. Its just taking the first non-animated texture in the wad and applying it to the entire prefab. Ive got everything set up in the worldspawn & whatnot. Drivers maybe? By now I am sure I am a version or two out of date with the nvidia drivers.
Well, I'm not really used with dynamic vs static entities... so first: what are the maximum limit value for both of them ?
And as it sounds Quoth2 is progressing well, do you have an idea when it will be released ? I rely a little bit on Quoth2 for my next map actually... ;) The quoth2 content is basically done, we just keep tweaking things here and there. Although there isn't quite the same monster load in this release as there was for chapters+quoth1, there is a lot of peripheral content like mapobjects, plus a ton of code improvements and other 'under the hood' changes Preach has added to make everyone's life easier.
We could release any day, but I feel the mapping tutorial ought to be updated with all of the new content and features, otherwise there's no point in releasing; no-one will really know what's in the box. But what do you guys think? Would you rather get the content now, and wait for me to incrementally update the tutorial over the next couple of weeks or so? Or just wait until I finally grind through it like last minute exam revision, so you can clear the first hurdles as soon as your downloads are finished? Well, having the pak without any explanations is not really helpfull for people, as nobody but the quoth2 team, knows exactely what's inside..
Well, it's up to you, but I'd rather prefer to read the "manual" before using new stuffs... In anyway: it is a very good news !! Take your time is better - there's always something left that you want to fix, rushing it at the last minute just means you leave in junk you'd normally sort out.
Writing the docs is a good time to take a breather and look at the whole project, rather than a collection of features under a microscope. </shrug>
|
|
| You must be logged in to post in this thread. |
|
| Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors. |