tools

[kortemik]

CMakeLists.txt specifies the paths for tools which are found in older gpl release from id software but not on the new bfg release, should we include them here? dmap is quite essential, others more or less.

[BielBdeLuna]

could Darkradiant become the new "editor" callable from the engine?

[motorsep]

There is no reason for having embedded level editor, unless it can provide preview with exactly same materials/shaders as engine. DR uses old ARB backend, so it won't render preview native to BFG. Thus, might as well keeping it standalone.

[raynorpat]

See #150 for a pull request for dmap and the aas compiler

[RobertBeckebans]

I have been waiting for such a pull request for a very long time. I checked the code with my private branch and added another fix for the light frustums.

[kortemik]

Awesome contribution @raynorpat thank you!

Also now included in #147, also the Sys_GetSystemMem is now removed. It was still referenced in posix_main.cpp

[BielBdeLuna]

I can't get it to compile, I get the following trouble:

[ 10%] Building CXX object CMakeFiles/RBDoom3BFG.dir/tools/compilers/aas/BrushBSP.cpp.o
/usr/local/share/d3bfg/src/RBDOOM-3-BFG/neo/tools/compilers/aas/BrushBSP.cpp: In member function ‘void idBrushBSP::Build(idBrushList, int, bool (*)(idBrush*, idBrush*), bool (*)(idBrush*, idBrush*))’:
/usr/local/share/d3bfg/src/RBDOOM-3-BFG/neo/tools/compilers/aas/BrushBSP.cpp:1134:61: warning: deprecated conversion from string constant to ‘char*’ [-Wwrite-strings]
   DisplayRealTimeString( "\r%6d", i * 100 / gridCells.Num() );
                                                             ^
/usr/local/share/d3bfg/src/RBDOOM-3-BFG/neo/tools/compilers/aas/BrushBSP.cpp: In member function ‘void idBrushBSP::MakeTreePortals_r(idBrushBSPNode*)’:
/usr/local/share/d3bfg/src/RBDOOM-3-BFG/neo/tools/compilers/aas/BrushBSP.cpp:1436:45: warning: deprecated conversion from string constant to ‘char*’ [-Wwrite-strings]
  DisplayRealTimeString( "\r%6d", numPortals );
                                             ^
/usr/local/share/d3bfg/src/RBDOOM-3-BFG/neo/tools/compilers/aas/BrushBSP.cpp: In member function ‘void idBrushBSP::MeltLeafNodePortals(idBrushBSPNode*, int, idVectorSet<idVec3, 3>&)’:
/usr/local/share/d3bfg/src/RBDOOM-3-BFG/neo/tools/compilers/aas/BrushBSP.cpp:2372:52: warning: deprecated conversion from string constant to ‘char*’ [-Wwrite-strings]
  DisplayRealTimeString( "\r%6d", numInsertedPoints );
                                                    ^
In file included from idlib/../idlib/Lib.h:315:0,
                 from idlib/precompiled.h:48:
idlib/../idlib/containers/VectorSet.h: In instantiation of ‘int idVectorSet<type, dimension>::FindVector(const type&, float) [with type = idVec3; int dimension = 3]’:
/usr/local/share/d3bfg/src/RBDOOM-3-BFG/neo/tools/compilers/aas/BrushBSP.cpp:2297:68:   required from here
idlib/../idlib/containers/VectorSet.h:173:12: error: ‘Append’ was not declared in this scope, and no declarations were found by argument-dependent lookup at the point of instantiation [-fpermissive]
idlib/../idlib/containers/VectorSet.h:173:12: note: declarations in dependent base ‘idList<idVec3, (memTag_t)40u>’ are not found by unqualified lookup
idlib/../idlib/containers/VectorSet.h:173:12: note: use ‘this->Append’ instead
make[2]: *** [CMakeFiles/RBDoom3BFG.dir/tools/compilers/aas/BrushBSP.cpp.o] Error 1
make[1]: *** [CMakeFiles/RBDoom3BFG.dir/all] Error 2
make: *** [all] Error 2

[kortemik]

@BielBdeLuna try my https://github.com/kortemik/RBDOOM-3-BFG i fixed it as compiler suggest. VectorSet.h line 173 replace Append with this->Append.

[BielBdeLuna]

@kortemik I can't post issues in your fork... so I'l post it here:

I got a trouble while compiling /render/cinematic.cpp so i haven't got to /aas/BrushBSP.cpp

!CAUTION! this error is not for RobertBeckebans's fork but for Kortemik's...

[ 40%] Building CXX object CMakeFiles/RBDoom3BFG.dir/renderer/Cinematic.cpp.o
/usr/local/share/d3bfg/kortemik/RBDOOM-3-BFG/neo/renderer/Cinematic.cpp:56:29: fatal error: libavutil/frame.h: El fitxer o directori no existeix
 #include "libavutil/frame.h"
                             ^
compilation terminated.
make[2]: *** [CMakeFiles/RBDoom3BFG.dir/renderer/Cinematic.cpp.o] Error 1
make[1]: *** [CMakeFiles/RBDoom3BFG.dir/all] Error 2
make: *** [all] Error 2

"libavutil/frame.h: the file or directory doesn't exist"

I got this from ./cmake-eclipse-linux-debug.sh

-- The C compiler identification is GNU 4.8.2
-- The CXX compiler identification is GNU 4.8.2
-- Could not determine Eclipse version, assuming at least 3.6 (Helios). Adjust CMAKE_ECLIPSE_VERSION if this is wrong.
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- CMAKE_BUILD_TYPE:Debug
-- Looking for XOpenDisplay in /usr/lib/x86_64-linux-gnu/libX11.so;/usr/lib/x86_64-linux-gnu/libXext.so
-- Looking for XOpenDisplay in /usr/lib/x86_64-linux-gnu/libX11.so;/usr/lib/x86_64-linux-gnu/libXext.so - found
-- Looking for gethostbyname
-- Looking for gethostbyname - found
-- Looking for connect
-- Looking for connect - found
-- Looking for remove
-- Looking for remove - found
-- Looking for shmat
-- Looking for shmat - found
-- Looking for IceConnectionNumber in ICE
-- Looking for IceConnectionNumber in ICE - found
-- Found X11: /usr/lib/x86_64-linux-gnu/libX11.so
-- Found OpenGL: /usr/lib/x86_64-linux-gnu/libGL.so  
-- Found PkgConfig: /usr/bin/pkg-config (found version "0.26") 
-- checking for module 'libavcodec'
--   found libavcodec, version 54.35.0
-- checking for module 'libavformat'
--   found libavformat, version 54.20.4
-- checking for module 'libavutil'
--   found libavutil, version 52.3.0
-- checking for module 'libswscale'
--   found libswscale, version 2.1.1
-- Found FFMPEG or Libav: /usr/lib/x86_64-linux-gnu/libavcodec.so;/usr/lib/x86_64-linux-gnu/libavformat.so;/usr/lib/x86_64-linux-gnu/libavutil.so;/usr/lib/x86_64-linux-gnu/libswscale.so, /usr/include
-- Looking for include file pthread.h
-- Looking for include file pthread.h - found
-- Looking for pthread_create
-- Looking for pthread_create - not found
-- Looking for pthread_create in pthreads
-- Looking for pthread_create in pthreads - not found
-- Looking for pthread_create in pthread
-- Looking for pthread_create in pthread - found
-- Found Threads: TRUE  
-- Found SDL: /usr/lib/x86_64-linux-gnu/libSDLmain.a;/usr/lib/x86_64-linux-gnu/libSDL.so;-lpthread (found version "1.2.15") 
-- Found OpenAL: /usr/lib/x86_64-linux-gnu/libopenal.so  
-- Configuring done
-- Generating done
-- Build files have been written to: /usr/local/share/d3bfg/kortemik/RBDOOM-3-BFG/build

so I have a libavutil... but maybe it's not to correct version?

[kortemik]

could you please show the contents of following directory $ ls /usr/include/ffmpeg/

Also I tend to follow channel #iodoom3 on http://webchat.freenode.net/

Rather post issues here if any https://github.com/RobertBeckebans/RBDOOM-3-BFG/pull/147 or now to my repo, i enabled issues

[BielBdeLuna]

I don't have a ffmpeg directory in /usr/include/ but ./cmake-eclipse-linux-debug.sh found an ffmpeg or Libav in my system in: /usr/lib/x86_64-linux-gnu/libavcodec.so

[kortemik]

Which distro would that be?

[DanielGibson]

Am 05.08.2014 16:31, schrieb Biel Bestué de Luna:

I don't have a ffmpeg directory in /usr/include/ but ./cmake-eclipse-linux-debug.sh found an ffmpeg or Libav in my system in: /usr/lib/x86_64-linux-gnu/libavcodec.so

Maybe it's /usr/include/libav*/ (libavcodec/ libavformat/ etc) instead?

[BielBdeLuna]

I have the last Ubuntu x64 I have the following /usr/include/libav*/ /usr/include/libavcodec/ /usr/include/libavformat/ /usr/include/libavutil/

inside /usr/include/libavutil/ I have the following: adler32.h aes.h attributes.h audioconvert.h audio_fifo.h avassert.h avconfig.h avstring.h avutil.h base64.h blowfish.h bswap.h channel_layout.h common.h cpu.h crc.h dict.h error.h eval.h fifo.h file.h imgutils.h intfloat.h intfloat_readwrite.h intreadwrite.h lfg.h log.h lzo.h mathematics.h md5.h mem.h old_pix_fmts.h opt.h parseutils.h pixdesc.h pixfmt.h random_seed.h rational.h samplefmt.h sha.h time.h version.h xtea.h

and indeed frame.h isn't amongst them.

[BielBdeLuna]

in fact frame.h also isn't in either /usr/include/libavcodec/ nor in /usr/include/libavformat/

[kortemik]

please get latest version, i added fix for system includes :)

[BielBdeLuna]

I've pulled your changes but unfortunately I get the same error:

[ 40%] Building CXX object CMakeFiles/RBDoom3BFG.dir/renderer/Cinematic.cpp.o
/usr/local/share/d3bfg/kortemik/RBDOOM-3-BFG/neo/renderer/Cinematic.cpp:68:29: fatal error: libavutil/frame.h: El fitxer o directori no existeix
 #include <libavutil/frame.h>
                             ^
compilation terminated.
make[2]: *** [CMakeFiles/RBDoom3BFG.dir/renderer/Cinematic.cpp.o] Error 1
make[1]: *** [CMakeFiles/RBDoom3BFG.dir/all] Error 2
make: *** [all] Error 2

[kortemik]

let me install one ubuntu for testing

[kortemik]

and fixed :)

[BielBdeLuna]

pulled and compiled ok! now what changes does it have with the tools pull in rbdoom-3-bfg?

[raynorpat]

Replacing Append with this->Append really needs to be merged.

Earlier gcc versions like 4.6 don't fail but I've tried a build in a vm of linux mint with gcc 4.8.2 and it fails.

[RobertBeckebans]

Linux version should compile again.

[BielBdeLuna]

ha! finally it compiled. but! oh goddamit! when I tried to run it! I went really mad for a moment there. and amidst my fffffffffffffffFFFFFFFFFF I decided to check if SDL2 was ON. it was. so I set it to OFF and now it compiles fine and runs great :-)

now I'll proceed to check dmap and testmap!

[BielBdeLuna]

testmap and dmap work allright.

but I see they don't generate a .cm file that in dhewm3 they used to. .cm were a collision file isn't it?

oh. and another thing. d3xp portal sky works.

I'm obliged to say: "remember that beer I owed you back in Black Mesa?"

[RobertBeckebans]

.cm files should be generated automatically out of the brushes inside the .map file when you load a map. The BFG code goes even further and generates a binary version inside the generated/ path.

[BielBdeLuna]

great now I see them! it also generates a binary proc, do we need the .proc file then? wait, isn't the .proc used by the mapping editor to see if there is a leak?

[BielBdeLuna]

guys do you mind If I try to port my half-life-2-like portalsky code from dhewm3 to d3bfg? would you pull it from my fork?

[kortemik]

Sorry about the SDL2 issue.

I would definitely pull it, could you create your own branch on my repo?

@RobertBeckebans how do you find #147 ? I think for windows we should use something like http://stackoverflow.com/questions/4111899/is-there-an-easy-one-shot-solution-to-the-preprocessor-namespace-pollution-intro this is also very handy link from the comments http://herbsutter.com/gotw/_100/ . It would definitely reduce compile times and would draw a clear boarder between platform code and engine code. Precompiled headers are not the cure for bad compile times, they just hide the problem.

[BielBdeLuna]

@kortemik I have my own fork off of RobertBackebans's, so I'll make my branch there, and once I'm finished if you want you can pull it from mine. just like I'll request Robert when the time comes.

jeez, git talk sound really dirty isn't it? XDD

[BielBdeLuna]

can dmap processes be multi-threaded?

[motorsep]

Of course it can be, if some makes it to be (preferably without OpenMP).

[motorsep]

BTW, what's the difference between current portal sky, portal sky from BielBdeLuna's fork and HL2 portal sky?

[BielBdeLuna]

local and global portal skies that I implemented back at the moment, global is the most similar to half life 2, it follows the player even if it's not active ( at the moment you can only have one of those) local portal sky only follows the player once triggered and if re-triggered it goes back to the initial position even if active. you could do quite an Alice in Wonderland effects with those.

there's still the normal portal sky from d3xp so you don't lose compatibility

and now I intend to implement a new entity that stops normal portal sky and local from keeping following the player (but still preserve global), it would serve the purpose of "killing off the process" when you no longer need those portal skies because you no longer see them in the map. then if you re-trigger again those they go back up if they were "killed" with this new entity... just easy stuff that could come in handy when needed. I'll name this new entity "info_portalsky_killer" mwahhahaha!

[motorsep]

@BielBdeLuna So what you have in your mod, is same thing as doom 3's portal sky + local (triggerable) portal sky? Or is it normal (doom 3) + global + local ?

I am a bit lost with "following" and "not following" player. How does it look like when following? What's the purpose? (trying to grasp it from artistic point of view as I always thought sky should not follow player :) )

[BielBdeLuna]

no, Motorsep yo know me, I'm the same dude that proposed this back in dhewm3 times, and d3w times, also the DarkMod uses this implementation, you already asked me for using this mod in your game, don't you remember?

well, let me re-explain:

in d3xp (and in BFG ) we have a portal sky. it's static. it doesn't follow the player movement. you can have several of them, and trigger them at will (it changes the portal sky point of view if you do so)

mine follows the player movement in two flavours, as well as maintaining the original d3xp implementation for compatibility.

so I have: d3xp original portal sky local portal sky global portal sky

the local portal sky when triggered gets the portal sky texture to render the world from the local portal sky entity as the original d3xp, only this time the entity follows the player movement at "n" scale. and every time you re-trigger the local portal sky entity, it moves back to the original position.

the global portal sky acts the same except that when not triggered it keeps following the player, and when re-triggered it doesn't go back to the original position (you can only have one of those in my current implementation) that's basically the same functionality of HL2.

do you understand now?

[motorsep]

Yeah, that was last year on d3w I think.. But I still don't get what "follows" means.

On the test map switching from one portal sky to another was simply switching the look. One portal sky was set to n-scale and another one was set to n*2-scale. So it appeared larger than the original. That's what I understood as a difference between normal and yours (setting scale).

[BielBdeLuna]

no, one thing is scale the other if the portal sky is following you or not. when not following, the portal sky is either static, non-existan (off ) or mal-funcitoning

in the case of "following" there are two flavours. the local ps, starts (or re-starts ) from the same point in space every time you trigger ( or re-trigger ) it, the global ps, keeps following you even if you're using another kind of ps, so you can always return to global and it will stay connected with the player position all the time.

so what does follow do? it gets player position from last position and divides that with the scale. so the movement become "scale" times smaller. then it sets this movement in the current position of the ps entity (in case of one following the player)

this makes the movement of the ps "scale" time smaller than the one form the player, if this scale is consistent with the scaled models in the ps space, then it will make those scaled models seem "scale" times bigger to the user looking at them, because the change in parallax when he moves in the game will be consistent.

do you remember that you asked what was better, to have big vistas modelled in the map or a ps effect. modelling in the map is an option only when the vistas doesn't move, but in other cases you're best with portal skies like this case: http://youtu.be/ostyEA5qHyA?t=4m49s

[motorsep]

I see.. So do you think this https://www.youtube.com/watch?v=9xUXVO8XMDw can be made using global ps or normal ps ?

[BielBdeLuna]

this is the most difficult case. inside a vehicle, and the difficulty spikes when the vehicle starts to change direction, in that last case it might require something I cannot do with the current implementation.

if the train is just going linearly then this is fine and dandy you do the train inside a room with all the floor, the ceiling and walls with ps texture, and you set up a scaled room with the terrain, the player advances into a static train scenery, while the terrain is moving inverse to the train in the scaled room, you can loop the terrain movement, you can script it, and you should script something for the case the player jumps out of the vehicle in linear motion.

but it's simple, it's a global ps or a local ps. both of them do serve the purpose.

---

now if the vehicle starts to go up and down and turn left to right. or spin for the matter, you're in a world of pain. there are two solutions, both difficult, you either model a static terrain that moves inverse tot he train movement (remember turning and moving up and down inverted) which might be crazy to animate. or the best solution (and not in my implementation) a portal sky within a portal sky, yes Inception like:

you set up the train scenery, which is semi-static. it changes directions, rotates an all this but doesn't move on any track. all of this inside a room with walls, ceiling, and floor covered in ps texture.

then you set up a empty room scaled "scale1" times that would contain the semi static train scaled down "scale1" times" and you set your global/local ps there. all of this also inside a room with walls, ceiling, and floor covered in ps texture.

then you set a new empty room scaled "scale2" times which has a scaled model ( scaled "scale2" times) with all the track. and you set a func_mover that follows the track. on that mover you bind to it a d3xp ps (the static portal sky) and you're set

the player in the train room sees what the ps in scaler 1 room sees,which in times sees what ps in scale2 room sees.

if you're not mind-blown yet. to sum up: the scale1 room controls the parallax change within the train, and the scale2 room controls the parallax change in between the train and the track, since I can't do a ps within a ps that's impossible right now.

if you're understood that last case then "YOU ARE thinking with portals!" :D

[motorsep]

sounds like Inception indeed :)

[BielBdeLuna]

I did the pull request on both Robert's and Kortemik's. tell me guys what do you think? there you have a test map and some dev textures, just pull out the console and type testmap testmaps/paortalsky

you can preview my testing branch before pulling the request here:

https://github.com/BielBdeLuna/RBDOOM-3-BFG/tree/portal_sky

[kortemik]

@BielBdeLuna I tested and merged, looks way too awesome to be true!

[BielBdeLuna]

hope it's useful