Jump to content
The Dark Mod Forums

Revelator's TDM Branch


nbohr1more

Recommended Posts

No, that is not what I meant. How do I update the repository on my maschine?

 

~/src/tdm_experimental/The-Darkmod-Experimental$ git pull
Already up-to-date.

 

But that cannot be the latest revision, as I haven't updated it for at least 1 or 2 weeks, and you said you fixed stuff in the meantime.

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

Argh!

 

So I thought I had a pretty good plan... Nope getting idstr to GLuint conversion errors. Somehow, it works in feedback but he made

two sets of data for it which is something I didn't want to do. I can't understand how vertexProgram (etc) can be type "int" in Material.h

...how the hell do you pack an ARB program into an integer? Bah! :angry: Close to the point of conceding to hard-coding these. The dream

of defining the ARB shader in the material def is fading...

Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

Link to comment
Share on other sites

I can't understand how vertexProgram (etc) can be type "int" in Material.h ...how the hell do you pack an ARB program into an integer? Bah! :angry: Close to the point of conceding to hard-coding these. The dream of defining the ARB shader in the material def is fading...

 

It's just an index number for a pre-loaded program. The indexes are defined inplicitly in tr_local.h near the bottom of the file, in an enum at approx line 1330. Those indexes are mapped to actual text programs in draw_arb2.cpp, in a table around line 350. There are 20 or so "set" programs that always get loaded, then remaining slots are used for progs named in material files. You could reserve yourself a slot in the enum at the end for "custom_light_program", then when you want to change it dynamically, you'd update the table entry to give it the new program name and call the same load proc that R_ReloadARBPrograms uses.

 

Hope that works. I can't actually test it because I'm at work and browsing the code on my phone :)

Link to comment
Share on other sites

That's true. You could load one dynamically from a text string using the same method though. Just harvest a couple of lines of code from R_LoadARBProgram(). You'd still reserve yourself a slot in the enum so you;re always using the same index number. Then bind that program and call qglProgramStringARB to compile your text like happens at the end of R_LoadARBProgram.

Link to comment
Share on other sites

one could probably yank something together from this part of R_LoadARBProgram

 

// vertex and fragment programs can both be present in a single file, so
// scan for the proper header to be the start point, and stamp a 0 in after the end
start = NULL;
if (progs[progIndex].target == GL_VERTEX_PROGRAM_ARB) {
 if (!glConfig.ARBVertexProgramAvailable) {
  common->Printf(S_COLOR_RED ": GL_VERTEX_PROGRAM_ARB not available\n" S_COLOR_DEFAULT);
  return;
 }
 start = strstr((char *)buffer, "!!ARBvp");
}
if (progs[progIndex].target == GL_FRAGMENT_PROGRAM_ARB) {
 if (!glConfig.ARBFragmentProgramAvailable) {
  common->Printf(S_COLOR_RED ": GL_FRAGMENT_PROGRAM_ARB not available\n" S_COLOR_DEFAULT);
  return;
 }
 start = strstr((char *)buffer, "!!ARBfp");
}
if (!start) {
 common->Printf(S_COLOR_RED ": !!ARB not found\n"  S_COLOR_DEFAULT);
 return;
}
end = strstr(start, "END");
if (!end) {
 common->Printf(S_COLOR_RED ": END not found\n"  S_COLOR_DEFAULT);
 return;
}

 

These defines are allways a part of ASM shaders so they should be exactly what you need :)

Link to comment
Share on other sites

Hmm, I wonder if the data capture order would allow something like:

 


static progDef_t progs[MAX_GLPROGS] = {

{ GL_VERTEX_PROGRAM_ARB, VPROG_CUSTOM_LIGHT, backEnd.vLight->lightShader->GetInteractionVS() },
{ GL_FRAGMENT_PROGRAM_ARB, FPROG_CUSTOM_LIGHT, backEnd.vLight->lightShader->GetInteractionFS() }

 

...

 

I hope I have enough time to test this tonight...

Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

Link to comment
Share on other sites

Ok fixed crash and removed all backends besides ARB2 :) Reformatted sources.

Nice one!

 

Hmm, I wonder if the data capture order would allow something like:
 static progDef_t progs[MAX_GLPROGS] = { { GL_VERTEX_PROGRAM_ARB, CUSTOM_LIGHT, backEnd.vLight->lightShader->GetInteractionVS() }, { GL_FRAGMENT_PROGRAM_ARB, CUSTOM_LIGHT, backEnd.vLight->lightShader->GetInteractionFS() } 

... I hope I have enough time to test this tonight...

 

You'll run into a problem there, that the GetInteractionVS() will be evaluated only at program startup, not when you later try to load a shader dynamically. It'll probably crash because vLight will be null at that point.

 

If I were you I'd give it a dummy or NULL arb program to start with, any old one will do, just so you've reserved a constant-numbered slot for your custom program. Then swap it out when you need to later.

Link to comment
Share on other sites

Or use the old code for light as a fallback ? :)

 

Removing the old backends is easy compared ;) but you will learn something from it.

Else id go with something like steve said.

 

Ugh im wasted :S internet went down at work and spent most day trying fixing what turned out to be a broken router (facepalm).

Link to comment
Share on other sites

Well, I'm pre-populating GetInteractionFS() in material.cpp so hopefully that string will access the current vLight relationship to the lightDef...

 

Yes, I will also add the initialization for the underlying "interactionVS and FS" values at the top of Material.cpp...

Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

Link to comment
Share on other sites

latest revision does not compile here:

 

scons: Cannot explain why `build/release/core/renderer/draw_nv20.o' is being rebuilt: No previous build information found
scons: *** [build/release/core/renderer/draw_nv20.o] Source `renderer/draw_nv20.cpp' not found, needed by target `build/release/core/renderer/draw_nv20.o'.
scons: building terminated because of errors.

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

Looking to get away with scons completely by replacing it with a project generator named MPC http://www.dre.vanderbilt.edu/~schmidt/DOC_ROOT/ACE/MPC/docs/html/MakeProjectCreator.html

 

I discovered this tool when i looked for a high performance socket library that would be usable with games such as Doom 3.

 

MPC can create make files / autotool based build scripts / msvc project files / borland projects / mac projects, and many more :).

 

Could Ofc also use cmake as it also supports multiple IDE's / Compilers but cmake cannot create autotools based build scripts which would probably fly better with linux.

 

MPC is perl based btw.

  • Like 1
Link to comment
Share on other sites

Hmm i wonder if i should upload my Revelation branch to github for people to hack at.

Its probably the cleanest port i made so far of Doom 3 but i removed all editors and build systems for anything but windows (plan was to use the dhewm3 changes and then create a CodeBlocks workspace for Windows and One for linux) but first i needed to update my Compiler suite which is done now. Since it uses Glew i would keep off the SDL changes from dhewm3 since its not needed, glew is useable on linux to.

One could probably make the changes for darkmod to run on it pretty easily by keeping darkmods gamecode and do the nessesary changes needed on my port.

Link to comment
Share on other sites

As is no, but the changes nessesary to the main executable code should be easy. That said my port does not rely on boost so i need to check out what parts of the darkmod executable code needs boost.

The game code needs no change if i just copy in the game code from darkmod so that part is easy, what i need to know are the changes to the rest of the code -> renderer / framework etc.

Ill do a diff by the weekend to see what changes are nessesary, and then ill start porting it over.

 

The benefit would be native IDE support on linux as well as windows and the port would be able to use mingw64 on windows instead of msvc :).

A 64 bit port might also be possible with the dhewm3 changes though i have to check darkmods gamecode and see if the dhewm3 changes can apply without to much work for a 64 bit port.

Link to comment
Share on other sites

eeh, why not to follow some decent standard and use cmake ? I never understood when people find some obscure tool and present it as the ultimate solution.

 

Cmake is de facto standard for cross platform development. Works like a charm on Linux, Windows and OSX. RBDoom 3 BFG uses it, dhewm3 uses it afaik, Blender is switching from scons to cmake.

Edited by motorsep
Link to comment
Share on other sites

cmake is fine :) and i might use it, setting up my own workspaces saves me having to tell cmake where the nessesary libraries are every time though (atleast on windows) but maybe something can be thrown together for autodetecting those on windows as well. atm dhewm3 cannot find the system libraries if i use mingw64 because some of the headers are in subfolders of the include dir (autotool builds do that unfortunatly). Maybe i can use pkg-config to pick up the correct paths somehow .

Link to comment
Share on other sites

Uploaded my Revelation Engine here https://github.com/revelator/Revelation-Engine

 

This is windows only and all editors have been removed as well as all the old backends + support code.

It also uses defered interactions and uses a somewhat modified stencil shadow code based on the omp patch from linux.

Besides that i added the light depthbounds code from RBDoom3 and the work me and steve done with depthbuffer access.

Also removed the unused glasswarp code from this one, as well as a ton of fixes for bugs pointed out by dhewm3 and fabian sanglard.

The matrices are reset to a default value every pass which fixes bugs in the gui in case you use Sikkpins parallax shaders.

 

Included are game code for mods that work with it (SikkMod Grimm Quest Classic Doom) with the same fixes to the game code as the vanilla code.

It works quite well as is for Doom3 :)

 

While not darkmod compatible there might be a few interresting things devs can have a look at for use with darkmod, or even use it as a base if you like.

Link to comment
Share on other sites

cmake is fine :) and i might use it, setting up my own workspaces saves me having to tell cmake where the nessesary libraries are every time though (atleast on windows) but maybe something can be thrown together for autodetecting those on windows as well. atm dhewm3 cannot find the system libraries if i use mingw64 because some of the headers are in subfolders of the include dir (autotool builds do that unfortunatly). Maybe i can use pkg-config to pick up the correct paths somehow .

 

Use MSVC 2013 Community Edition on Windows, and gcc on Linux. It only makes sense to use native tools for each platform, especially that they are free! o.O

 

P.S. MSVC 2013 Community Edition is almost exactly the same as MSVC 2013 Pro, but free.

Edited by motorsep
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recent Status Updates

    • Petike the Taffer  »  DeTeEff

      I've updated the articles for your FMs and your author category at the wiki. Your newer nickname (DeTeEff) now comes first, and the one in parentheses is your older nickname (Fieldmedic). Just to avoid confusing people who played your FMs years ago and remember your older nickname. I've added a wiki article for your latest FM, Who Watches the Watcher?, as part of my current updating efforts. Unless I overlooked something, you have five different FMs so far.
      · 0 replies
    • Petike the Taffer

      I've finally managed to log in to The Dark Mod Wiki. I'm back in the saddle and before the holidays start in full, I'll be adding a few new FM articles and doing other updates. Written in Stone is already done.
      · 4 replies
    • nbohr1more

      TDM 15th Anniversary Contest is now active! Please declare your participation: https://forums.thedarkmod.com/index.php?/topic/22413-the-dark-mod-15th-anniversary-contest-entry-thread/
       
      · 0 replies
    • JackFarmer

      @TheUnbeholden
      You cannot receive PMs. Could you please be so kind and check your mailbox if it is full (or maybe you switched off the function)?
      · 1 reply
    • OrbWeaver

      I like the new frob highlight but it would nice if it was less "flickery" while moving over objects (especially barred metal doors).
      · 4 replies
×
×
  • Create New...