Comments on: Bounty hunters be alert http://www.quaddicted.com/quaddictedcom/bounty-hunters-be-alert/ The greatest Quake 1 Singleplayer site on this planet. Tue, 09 Aug 2011 22:15:18 +0000 hourly 1 By: Willem http://www.quaddicted.com/quaddictedcom/bounty-hunters-be-alert/comment-page-1/#comment-2212 Willem Thu, 07 Jan 2010 10:57:02 +0000 http://www.quaddicted.com/?p=1026#comment-2212 LevelEd is being worked on ... slowly. :) LevelEd is being worked on … slowly. :)

]]>
By: rudl http://www.quaddicted.com/quaddictedcom/bounty-hunters-be-alert/comment-page-1/#comment-2211 rudl Wed, 06 Jan 2010 17:45:15 +0000 http://www.quaddicted.com/?p=1026#comment-2211 I would love to see more linux builds of map editors. I would love to see more linux builds of map editors.

]]>
By: ijed http://www.quaddicted.com/quaddictedcom/bounty-hunters-be-alert/comment-page-1/#comment-2210 ijed Wed, 06 Jan 2010 15:02:38 +0000 http://www.quaddicted.com/?p=1026#comment-2210 Quick3D can export to .mdl maintaining UV's (no more back/front projection) but it's a funky POS to use. Kind of like Qme ;) Until the first (awesome) task is completed it works. Try this tutorial: http://qexpo.tastyspleen.net/booth.php?id=153 Quick3D can export to .mdl maintaining UV’s (no more back/front projection) but it’s a funky POS to use. Kind of like Qme ;)

Until the first (awesome) task is completed it works. Try this tutorial:

http://qexpo.tastyspleen.net/booth.php?id=153

]]>
By: drohnwerks http://www.quaddicted.com/quaddictedcom/bounty-hunters-be-alert/comment-page-1/#comment-2209 drohnwerks Wed, 06 Jan 2010 09:14:54 +0000 http://www.quaddicted.com/?p=1026#comment-2209 A couple of things came to mind. I would love to see level ed (http://wantonhubris.com/blog/2009/10/20/leveled-preview/) finished, toetag is the easiest program I have used ;) How about .mdl import into Blender? we can export, but not import... A couple of things came to mind.

I would love to see level ed (http://wantonhubris.com/blog/2009/10/20/leveled-preview/) finished, toetag is the easiest program I have used ;)

How about .mdl import into Blender? we can export, but not import…

]]>
By: RickyT23 http://www.quaddicted.com/quaddictedcom/bounty-hunters-be-alert/comment-page-1/#comment-2206 RickyT23 Sun, 03 Jan 2010 04:27:46 +0000 http://www.quaddicted.com/?p=1026#comment-2206 I would kill for the light tool. Tyrlite is really hindered in what it can do compared to AguirRes'. Would get used by me for sure :DDD I would kill for the light tool. Tyrlite is really hindered in what it can do compared to AguirRes’. Would get used by me for sure :DDD

]]>
By: Willem http://www.quaddicted.com/quaddictedcom/bounty-hunters-be-alert/comment-page-1/#comment-2195 Willem Thu, 31 Dec 2009 10:46:49 +0000 http://www.quaddicted.com/?p=1026#comment-2195 " I don’t remember if Willem actually did do a threading vis for Windows." I did. The source is on Quaketastic as "WVis". "Note that proper multithreading support isn’t as easily added (or enabled) as it seems. In Willem’s version, running a fullvis on multiple threads corrupts the autosave feature, for example." That's an issue that needs be addressed, for sure. I've looked at it in the past but haven't come up with a reliable fix. Multithreading complicates it (obviously). Still, it SHOULD be possible... ” I don’t remember if Willem actually did do a threading vis for Windows.”

I did. The source is on Quaketastic as “WVis”.

“Note that proper multithreading support isn’t as easily added (or enabled) as it seems. In Willem’s version, running a fullvis on multiple threads corrupts the autosave feature, for example.”

That’s an issue that needs be addressed, for sure. I’ve looked at it in the past but haven’t come up with a reliable fix. Multithreading complicates it (obviously). Still, it SHOULD be possible…

]]>
By: negke http://www.quaddicted.com/quaddictedcom/bounty-hunters-be-alert/comment-page-1/#comment-2194 negke Thu, 31 Dec 2009 10:39:04 +0000 http://www.quaddicted.com/?p=1026#comment-2194 Note that proper multithreading support isn't as easily added (or enabled) as it seems. In Willem's version, running a fullvis on multiple threads corrupts the autosave feature, for example. Note that proper multithreading support isn’t as easily added (or enabled) as it seems. In Willem’s version, running a fullvis on multiple threads corrupts the autosave feature, for example.

]]>
By: gb http://www.quaddicted.com/quaddictedcom/bounty-hunters-be-alert/comment-page-1/#comment-2193 gb Thu, 31 Dec 2009 03:02:24 +0000 http://www.quaddicted.com/?p=1026#comment-2193 eh, actually I was confused. Nothing needs to be ported, just neatly merged and made to compile on Win/Lin/Mac, then features added. eh, actually I was confused. Nothing needs to be ported, just neatly merged and made to compile on Win/Lin/Mac, then features added.

]]>
By: gb http://www.quaddicted.com/quaddictedcom/bounty-hunters-be-alert/comment-page-1/#comment-2192 gb Wed, 30 Dec 2009 23:56:07 +0000 http://www.quaddicted.com/?p=1026#comment-2192 "merging gb’s Linux port and Willem’s Mac tools (if they are based on aguirRe’s too) with the Windows original." That should probably be, "merge Willem's changes to the Mac version into gb's intended-as-crossplatform base, make the result (cross-)compile on Win/Lin/Mac, however you do that is up to you, and finally add threading support for vis under Windows, Mac and Linux (I think for Mac it exists already)." Because I'm unsure if AguiRre wishes for our stuff to be merged into his Windows codebase and then marketed as "AguirRe's tools". Hence I choose bjptools as a homage to him, but really, lots of people worked on those tools, they include work from Tyrann, Greg Lewis, and so forth, and id of course. My version basically replaced some Windows-common C functions with more standard ones, like strnicmp to strncasecmp, _inline to inline and so forth. This is all commented though. The other thing was commenting out some stuff that used Windows-specific header files like io.h and including common (for Linux) C header files like string.h to make some things work. It's all commented // gb. Really there aren't too many changes - do a "grep gb **/*" in the bjptools dir. Remember these tools were crossplatform to start with, so the main problem was to remove or substitute Windows- or MS- specific things. Also, only Treeqbsp was ported; Txqbsp was too hard for me to port. Finally, be aware that TreeQBSP uses a mixture of C and C++ files. The way to compile these under Linux is to use the -fpermissive flag to the C compiler if I remember correctly. Wildcard support in wad filenames was not ported because frankly I didn't know how to do that in Linux. It's commented out :) All in all, TreeQBSP, vis and light are pretty easy to port I think. The threading issue is about adding multi-threading support to the Linux version (and the Windows version, too, iirc) of Vis. This feature is already somewhat prepared in the original code, as far as I know, probably commented out. The goal, of course, is to decrease the ridiculous vising times for modern maps. bjptools-090908.zip should be the latest version including source. Ported shall be "TreeQBSP", "Vis" and "Light" (append .exe for Windows version, hehe). Willem's OSX source is also on Quaddicted. I don't remember if Willem actually did do a threading vis for Windows. “merging gb’s Linux port and Willem’s Mac tools (if they are based on aguirRe’s too) with the Windows original.”

That should probably be, “merge Willem’s changes to the Mac version into gb’s intended-as-crossplatform base, make the result (cross-)compile on Win/Lin/Mac, however you do that is up to you, and finally add threading support for vis under Windows, Mac and Linux (I think for Mac it exists already).”

Because I’m unsure if AguiRre wishes for our stuff to be merged into his Windows codebase and then marketed as “AguirRe’s tools”. Hence I choose bjptools as a homage to him, but really, lots of people worked on those tools, they include work from Tyrann, Greg Lewis, and so forth, and id of course.

My version basically replaced some Windows-common C functions with more standard ones, like strnicmp to strncasecmp, _inline to inline and so forth. This is all commented though. The other thing was commenting out some stuff that used Windows-specific header files like io.h and including common (for Linux) C header files like string.h to make some things work. It’s all commented // gb.

Really there aren’t too many changes – do a “grep gb **/*” in the bjptools dir. Remember these tools were crossplatform to start with, so the main problem was to remove or substitute Windows- or MS- specific things.

Also, only Treeqbsp was ported; Txqbsp was too hard for me to port.

Finally, be aware that TreeQBSP uses a mixture of C and C++ files. The way to compile these under Linux is to use the -fpermissive flag to the C compiler if I remember correctly.

Wildcard support in wad filenames was not ported because frankly I didn’t know how to do that in Linux. It’s commented out :)

All in all, TreeQBSP, vis and light are pretty easy to port I think.

The threading issue is about adding multi-threading support to the Linux version (and the Windows version, too, iirc) of Vis. This feature is already somewhat prepared in the original code, as far as I know, probably commented out. The goal, of course, is to decrease the ridiculous vising times for modern maps.

bjptools-090908.zip should be the latest version including source. Ported shall be “TreeQBSP”, “Vis” and “Light” (append .exe for Windows version, hehe). Willem’s OSX source is also on Quaddicted. I don’t remember if Willem actually did do a threading vis for Windows.

]]>
By: metlslime http://www.quaddicted.com/quaddictedcom/bounty-hunters-be-alert/comment-page-1/#comment-2189 metlslime Tue, 29 Dec 2009 22:02:38 +0000 http://www.quaddicted.com/?p=1026#comment-2189 also... Hint brushes could just be a special texture named "hint", but detail brushes would need a special way to define them. (in q2/q3 they are stored in the extra flags for the surface, which q1 map format doesn't have.) Probably you would need to group them into fake entities, such as "func_detail" which the compiler would use to know which brushes are detail. But those entities would not be compiled into the bsp or spawned in the engine of course, they are only there as a mapping convenience. also…

Hint brushes could just be a special texture named “hint”, but detail brushes would need a special way to define them. (in q2/q3 they are stored in the extra flags for the surface, which q1 map format doesn’t have.)

Probably you would need to group them into fake entities, such as “func_detail” which the compiler would use to know which brushes are detail. But those entities would not be compiled into the bsp or spawned in the engine of course, they are only there as a mapping convenience.

]]>
By: metlslime http://www.quaddicted.com/quaddictedcom/bounty-hunters-be-alert/comment-page-1/#comment-2188 metlslime Tue, 29 Dec 2009 21:56:39 +0000 http://www.quaddicted.com/?p=1026#comment-2188 "Is the cd track field in the BSP format limited to 1 byte? Or was the “0-255″ a random thought?" .map and .bsp formats store it as a string. --- Also skip / hint / detail -- 1. skip is supported by standalone tools, i assume that you are looking for the equivalent capability but merged into qbsp so mappers don't need the extra tool? That seems like a good idea, because I think you could actually get some additional benefits from that -- e.g. remove the surfaces entirely from the bsp file, so that they don't eat up lightmap space, or add to the total marksurfaces list, etc. This could actually help borderline maps get under the limits for standard engines. 2. hint probably needs to be defined slightly more (same behavior as Q2? Q3?) Perhaps whoever intends to implement it can talk to you about the options for how to do it, or maybe do some tests on the most beneficial implementation. Generally used to make the bsp cleaner or more optimized, but it was kind of esoteric and i never actually used it in my q2 mapping. 3. detail brushes, as defined in Q2/Q3 (there may be slight differences), are possible (i think) in the q1 bsp format, but would not be compatible with the software renderer. Basically detail surfaces are dumped as a list into the appropriate leafnode, and rendered with the rest of the leaf, rather than causing the leaf to be divided up into even smaller nodes. The problem is software renderer assumes that a leafnode's faces can't ever occlude each other, so it doesn't have to worry about draw order. (It works in opengl because the z-buffer takes care of it.) Someone said recently (on func) that some compiler already supports detail brushes. I haven't investigated the claim yet, but if it works in software mode I am highly suspicious that it is the same definintion of "detail" as used in Q2 and Q3. “Is the cd track field in the BSP format limited to 1 byte? Or was the “0-255″ a random thought?”

.map and .bsp formats store it as a string.

Also skip / hint / detail —

1. skip is supported by standalone tools, i assume that you are looking for the equivalent capability but merged into qbsp so mappers don’t need the extra tool? That seems like a good idea, because I think you could actually get some additional benefits from that — e.g. remove the surfaces entirely from the bsp file, so that they don’t eat up lightmap space, or add to the total marksurfaces list, etc. This could actually help borderline maps get under the limits for standard engines.

2. hint probably needs to be defined slightly more (same behavior as Q2? Q3?) Perhaps whoever intends to implement it can talk to you about the options for how to do it, or maybe do some tests on the most beneficial implementation. Generally used to make the bsp cleaner or more optimized, but it was kind of esoteric and i never actually used it in my q2 mapping.

3. detail brushes, as defined in Q2/Q3 (there may be slight differences), are possible (i think) in the q1 bsp format, but would not be compatible with the software renderer. Basically detail surfaces are dumped as a list into the appropriate leafnode, and rendered with the rest of the leaf, rather than causing the leaf to be divided up into even smaller nodes. The problem is software renderer assumes that a leafnode’s faces can’t ever occlude each other, so it doesn’t have to worry about draw order. (It works in opengl because the z-buffer takes care of it.)

Someone said recently (on func) that some compiler already supports detail brushes. I haven’t investigated the claim yet, but if it works in software mode I am highly suspicious that it is the same definintion of “detail” as used in Q2 and Q3.

]]>
By: Spirit http://www.quaddicted.com/quaddictedcom/bounty-hunters-be-alert/comment-page-1/#comment-2187 Spirit Tue, 29 Dec 2009 14:27:15 +0000 http://www.quaddicted.com/?p=1026#comment-2187 Perfect Ogg Vorbis would be a patch for stock Quake (GL and software). But since I am not sure how to have linux and mac support with this, a patch for SDL Fitzquake would be sufficient. It would be a start for sure. :) I do not have the time right now but those are some good questions. Check how Darkplaces does it. Allowing any tracknames would be best but I am not sure how to decide what to play for "1" then too. Argh! Is the cd track field in the BSP format limited to 1 byte? Or was the "0-255" a random thought? ----- Unless you are dying to work please do not start any map tool stuff yet (and always contact me before starting anything!). I need to add another bounty for merging gb's Linux port and Willem's Mac tools (if they are based on aguirRe's too) with the Windows original. The new features should be added to that code base. Perfect Ogg Vorbis would be a patch for stock Quake (GL and software). But since I am not sure how to have linux and mac support with this, a patch for SDL Fitzquake would be sufficient. It would be a start for sure. :)

I do not have the time right now but those are some good questions. Check how Darkplaces does it.
Allowing any tracknames would be best but I am not sure how to decide what to play for “1″ then too. Argh!

Is the cd track field in the BSP format limited to 1 byte? Or was the “0-255″ a random thought?

—–

Unless you are dying to work please do not start any map tool stuff yet (and always contact me before starting anything!). I need to add another bounty for merging gb’s Linux port and Willem’s Mac tools (if they are based on aguirRe’s too) with the Windows original. The new features should be added to that code base.

]]>
By: Tuna http://www.quaddicted.com/quaddictedcom/bounty-hunters-be-alert/comment-page-1/#comment-2186 Tuna Tue, 29 Dec 2009 13:33:33 +0000 http://www.quaddicted.com/?p=1026#comment-2186 So .ogg files shall be a complete replacemnt for CD audio? That means .ogg will be preferred although I might have inserted a CD? And only if the .ogg file does not exist we will try to load the CD track? Valid track names should remain numerical (0-255) or should any names be allowed? Just questioning as I don't want to apply to the task (just yet?). But I might be looking into the thread issue later today. So .ogg files shall be a complete replacemnt for CD audio? That means .ogg will be preferred although I might have inserted a CD? And only if the .ogg file does not exist we will try to load the CD track?

Valid track names should remain numerical (0-255) or should any names be allowed?

Just questioning as I don’t want to apply to the task (just yet?).

But I might be looking into the thread issue later today.

]]>
By: Baker http://www.quaddicted.com/quaddictedcom/bounty-hunters-be-alert/comment-page-1/#comment-2185 Baker Tue, 29 Dec 2009 11:16:35 +0000 http://www.quaddicted.com/?p=1026#comment-2185 @tuna "That about someone having 1.ogg and hits 'cd play 1' on the console. What will actually be played?" quake/id1/sound/cdtracks/track001.ogg @tuna

“That about someone having 1.ogg and hits ‘cd play 1′ on the console. What will actually be played?”

quake/id1/sound/cdtracks/track001.ogg

]]>
By: Baker http://www.quaddicted.com/quaddictedcom/bounty-hunters-be-alert/comment-page-1/#comment-2184 Baker Tue, 29 Dec 2009 11:13:43 +0000 http://www.quaddicted.com/?p=1026#comment-2184 @ Tuna Multi-Threaded vis tool Spirit is referring to: http://www.celephais.net/board/view_thread.php?id=60365 Source: http://www.quaketastic.com/upload/files/tools/windows/misc/WVis.zip --- Ogg Vorbis: I don't claim to speak for Spirit whatsoever, but my guess is that adding it to FitzQuake 0.85 and FitzQuake 0.80 SDL would probably satisfy Spirit's requirements. FitzQuake 0.85 + source http://www.celephais.net/fitzquake/ FitzQuake 0.80 SDL + source http://www.kristianduske.com/fitzquake/ I don't claim to speak for Spirit, but even adding it to EZQuake (Windows | Linux | OS X) would probably technically qualify provided it did not use weird proprietary libraries (like the MP3 player in FuhQuake that used WinAMP) and just uses libvorbis dlls and any other FOSS libraries needed, because the sample implementation could be ported to FitzQuake. I'm just pointing that out since I know you have worked with the EZQuake source code. DarkPlaces has Ogg Vorbis support. Again, I don't claim to speak for Spirit at all and maybe I'm wrong. @ Tuna

Multi-Threaded vis tool Spirit is referring to:

http://www.celephais.net/board/view_thread.php?id=60365

Source: http://www.quaketastic.com/upload/files/tools/windows/misc/WVis.zip

Ogg Vorbis:

I don’t claim to speak for Spirit whatsoever, but my guess is that adding it to FitzQuake 0.85 and FitzQuake 0.80 SDL would probably satisfy Spirit’s requirements.

FitzQuake 0.85 + source

http://www.celephais.net/fitzquake/

FitzQuake 0.80 SDL + source

http://www.kristianduske.com/fitzquake/

I don’t claim to speak for Spirit, but even adding it to EZQuake (Windows | Linux | OS X) would probably technically qualify provided it did not use weird proprietary libraries (like the MP3 player in FuhQuake that used WinAMP) and just uses libvorbis dlls and any other FOSS libraries needed, because the sample implementation could be ported to FitzQuake. I’m just pointing that out since I know you have worked with the EZQuake source code.

DarkPlaces has Ogg Vorbis support.

Again, I don’t claim to speak for Spirit at all and maybe I’m wrong.

]]>