id Tech Forums

After a long hiatus I came back to mess with the engine. Found another bug - when running, engine crashes when stamina falls down to some level. Not sure if this is related to HUD or stamina code, or something unrelated. Using RMB or LMB also leads to crashes, but I blame it on my makeshift, crude scripts that were made only to run the engine.

I'm busy with University stuff as well. There weren't any performance problems with BFG as far as I know. It was less accepted due to being harder to mod.

Changes in BFG (it's also Carmack's code, I think he was still with id at the time):

• Updated OpenGL core profile
• GLSL shaders instead of antiquated ARB
• Tech 5-like multithreading
• Tech 5 file system
• Flash main menus and hud

There might be more changes, but they weren't that big and affecting performance. BFG forks can currently run on any platform, BFG was even released for consoles, and with right amount of coding it also supports VR.

Most of the stuff won't work when you simply change directory name, it'd take file path adjusting to get it loading properly. Which directory you've renamed?

I guess that you can get those ideas done in any of the engine forks, even stock GPL ones. But if you plan to have large open maps, then you'll have to make a lot of optimisations to get it running. Renderer is not suited for that. I'm still yet to check VkDoom's performance, but I'll do it next week due to schedule changes.

It should be possible, you'll have to change materials those levels use to make them compatible with stock Doom 3, as BFG uses GLSL instead of ARB shaders. If Lost Mission brought new entities like monsters, items or weapons, those should be obviously ported as well (I haven't played it).

The only problem that comes into my head with BFG maps working on stock Doom 3 (and vice versa) is the shader incompatibility.

Welcome to the forums Blogutan!

Before starting development, it'd be good to decide which fork of the engine you'll use. You could go with stock Doom 3 or BFG GPL engines, but their forks brought numerous fixes and improvements, so it's not really practial to use them. You may consider:

• dhewm3 - several fixes, 64bit port, OpenAL audio, better widescreen support, cross compatible
• Raynor Pat's fork - replaced ARB shaders with GLSL, parts of BFG renderer ported as well
• fhDOOM - OpenGL 3.3, GLSL shaders, many graphical improvements, fixed tools
• RBDOOM-3-BFG - improved Doom 3 BFG engine, soft shadows, 64bit and Linux support, several fixes
• OpenTech Engine - based on RBDOOM-3-BFG, suited for creation of standalone games, Flash menu replaced with CEGUI
• Storm Engine 2 - like above, but better performance fixes, improved shaders, YCoCg texture compression, fixed and enhanced tools, reverse-engineered Flash menu, many other improvements
• VkDoom3 - Doom 3 BFG with Vulkan renderer

Check each of those pages and try to choose a best development base for your project. I could help you get up and running with minimal base assets. It'd be easiest for Storm Engine 2 though, as I could simply send you my base directory and write where I made small tweaks in the code to make it run. If you're not into compiling the engine yourself, I could send you a binary as well, but I made a few small changes in dialogues of some tools.

For general development tips, check these sites:

• Doom 3 and Quake 4 sdk websites, you'll find a lot of useful stuff there
• id Tech4 mod wiki

It won't necessarily take a few years to develop a simple game like this on id Tech4. You have AI with area awareness system and dynamic obstacle avoidance, physics code and game logic from get go, it'd only need some scripting. Hardest part is actually starting up with minimal base assets. Once you've got this done, it's all about asset creation and scripting. Since you did a lot of 3D modelling, you could simply make your levels in modelling software. Then you'll have to use func_static to bring the model to your level and seal them with brushes (build brushes with caulk or nodraw textures all around them). The other way would be modelling your level in Blender and exporting it as .map file.

Using vertex painting is necessary to get texture blending, an advantage of using models over world brushes.

I'm a noob as well. I know basics of C++, I can make models, simple textures, levels, edit sounds, use trackers to make simple soundtracks, write (I practise this one on an almost daily basis), but I started working with this engine just recently. I may help you from time to time if I'll be able to.

Guess that he meant this whole no-dll improvement in BFG (or .resource files) since he mentioned modding.

---

Got BFG edition, I'll compile VkNeo to see how it runs soon.

Also, is SE2 compatible with BFG? Guess that there may be some differences in shaders and which scripts and defs engine calls (like se2_main and doom_main) and some other trivial stuff like that.

I prefer to do things alone and only ask for help if I don't understand something.

Not being productive is more of a developer's thing than an engine related problem. Blendo Games developed Quadrilateral Cowboy on stock Doom 3 GPL engine, The Dark Mod also runs on their own fork of it. There's also Icarus Starship Command Simulator game in development. A pity that Hexen: Edge of Chaos died out (or devs decided to work secretely). I'm not a professional developer and I'll most probably never will be, it's just my hobby. I don't really care about great graphics, just something that runs well.

I'm more after making a prototype than full game (but if I'll make a good prototype, I may push it further), and on Doom 3 engine I've got full game logic and AI. Bringing DarkMod's AI improvements to SE2 would make it even better. On UE4 or Unity I'll have to make whole game logic and AI, whether through blueprints or coding. Right now on SE2 all I need is to make assets and scripts, but there is just a lot of other stuff I have to take care of that it makes things slow, and like anyone I have my lazy days.

Agreed on the VR. While I don't see PC gaming suddenly disappearing in a long time, VR support is a great thing to have.

---

But let's keep this on-topic. Anyone already tried compiling VkNeo? I don't even have Doom 3 BFG (got the non-BFG release), so I won't be able to check if it runs better until I'll get a copy...

Only problem is that I'm not a graphics programmer and I'm not that much experienced with renderers and Doom 3 engine codebase. I'll have to learn the code first then try porting it. If the stock BFG with Vulkan code was more similar to RBDoom3 then it could be easier to port (there are noticeable differences, like in ObjectBuffer.cpp).

SE2 is a better development base than stock BFG engine wih Vulkan renderer (and it's only advantage over OpenGL is less CPU overhead), so porting it's assets to VkNeo is not giving me that much.

Vulkan rendering seems neat, I'll try merging it into SE2 when I'll be able to do so (most probably next week). It'd be even better if we could alternate between OpenGl and Vulkan (like r_OpenGl and r_Vulkan cvars), but that'd take much more than my hacky coding.

I think that I'll wait to see RBDoom3BFG implementation first.

I guess those are collision size and type, but I don't have too much time to check references now. Try looking it up on iddevnet or modwiki.

Viewmesh and worldmesh are separate models, guess that they use the same material for both of them?

Check the material if there is noShadows or noSelfShadow. Maybe plasma gun material doesn't have those?

I downsized the image, it's half the actual resolution. Can't go higher without uncapping it in display settings. Found out that the dialogue is defined in resource file, but changing border to resizeable has issues as well. I could plug my laptop to tv with hdmi cable though...

EDIT: I changed the editor layout and recompiled binary, solving the issue. It's not as pretty as it was before, but it'd work.

Checked the commandline method by argoon and still got a crash, so I promptly compiled a 32bit binary and gui editor loaded flawlessly. The issue with particles editor was still there though, and I haven't modified code for it in any way.



The editor window is not resizeable, does not scroll down and it's not possible to drag the window upwards beyond the edge as far as I know. Guess I'll have to dig in it's code.