can RBDOOM-3-BFG handle external game libraries?

[BielBdeLuna]

I've seen that there is code for handling game libraries (in the sys folder in the "main" files) how can we compile game libraries external to the engine? if we could, would the engine use them?

[motorsep]

Do you mean like game.dll ? No, it doesn't support it. The code you see is leftover code from idTech 4.

[JanSimek]

It shouldn't be too hard to separate the engine and game logic again to make modding easier, right?

[BielBdeLuna]

it would be quite useful, where is the external library handled besides de "main" file?

[motorsep]

It's not useful. It's much harder to debug and it introduces poor memory management. I don't get what stops modders from distributing .exe now, instead of dll ?

Back in old days you still couldn't run mods all together. Same thing here, whether it's exe or dll, you still can only run one mod at a time.

[BielBdeLuna]

it might not be useful to you but having the engine up-datable besides whatever one is coding in the game would be quite useful, and running more than one mod together it's not the point of this. with this we could share improvements in the gamecode independent one from another and new content while maintaining the engine unchanged, and viceversa.

game coding and engine coding are two separate things, some inexperienced coders like me might only change things in the gamecode rather than the engine, I only changed the engine once when I coded the portal-sky stuff, and it was only a single line of code. The other stuff I've coded was game stuff. and I make a lot of branches for several different things, it's quite useful changing the gamelib and keeping the engine.

[motorsep]

That's what github is for.. You can merge engine's upgrades without affecting your code for mod.

I noticed that a lot of Doom 3 modders have no clue what version control systems are :) (not you, but many others don't)

[DanielGibson]

I noticed that a lot of Doom 3 modders have no clue what version control systems are :) (not you, but many others don't)

Yeah, like those guys writing code for you :P

[BielBdeLuna]

but Motorsep, maybe we can have both, while you're doing the game, you could even split the "coding" team in two, one team for the engine and one team for the game code, and once you're about to release you could compile it all in a single file and then you can check those moemory issues if you have any. Maybe even you could have a single executable that already includes the game but if it finds a game llibrary it could make the external game library precede in importance the game that it's already hard-coded in? so you would end up allowing the two possibilities.

[motorsep]

what's what I have now, @BielBdeLuna. Save repository, several people working on several different things, no DLL support and no issues.

And BFG engine is not designed with DLL in mind. Just read the tech docs. IT was specifically engineered to be monolith.

[RobertBeckebans]

I recommend to work on a mod like a git branch and simply rename the .exe. My CMakeLists.txt makes this task very easy and I think that it is better than telling the people to start your mod with +set fs_game .

The network system was designed to be almost optional in D3 however it is completely different in the BFG edition and it would quite some effort to have the gamecode running in a dll. I think id Software designed this edition to be monolith because the entire gamecode runs inside a native operating system thread (which is btw a very cool design). It is a debugging hell to run the game in a separate thread and DLL.

2014-06-05 1:07 GMT+02:00 motorsep notifications@github.com:

what's what I have now, @BielBdeLuna https://github.com/BielBdeLuna. Save repository, several people working on several different things, no DLL support and no issues.

And BFG engine is not designed with DLL in mind. Just read the tech docs. IT was specifically engineered to be monolith.

— Reply to this email directly or view it on GitHub https://github.com/RobertBeckebans/RBDOOM-3-BFG/issues/130#issuecomment-45163554 .

[motorsep]

Note that one still can make fs_game mods if it's just assets / scripts

[nbohr1more]

So I guess there's this one nagging unspoken question here. Portability? How close does the old Doom 3 SDK match the game logic in BFG and how much work to merge in changes (enough to need to start the DLL project from scratch in BFG form)?

Since you've compared the two code-bases, do you have any insight on how feasible porting vanilla DLL mods to BFG engine code is?

Any pointers for anyone attempting such a feat?

[RobertBeckebans]

Porting DLL D3 mods is pointless if they aren't released under the GPLv3 license.

However porting individual changes into this fork is more or less easy. You can do a 3-way merge in KDiff3 with A = vanilla Doom 3 GPL neo/game, B = BFG neo/game-d3xp, C = D3 GPL + game specific changes and merge the results back to C. If you want to merge the code with this fork then customize my AStyle script and format A and C before you merge anything. I especially use AStyle as a tool to merge big code bases manually ( >= 500k LOC ). The biggest changes in the gamecode are the integration of the flash menu code and lobby based network system. The rest is almost standard D3 XP gamecode + bugfixes.

[nbohr1more]

Thanks for the info. I almost forgot about the use of Flash for menus. That might not be too much of a hurdle for other projects but The Dark Mod has too much infrastructure dedicated to the vanilla GUI code (Readables, Mission Briefings, etc). We'll have to look at porting vanilla's GUI system to BFG before attempting any merge. (That and reconciling our resource loader and mission installer setup.)

Do you still plan on releasing your fixes to the vanilla renderer once your commercial project is released (therefore making this much easier)?

[RobertBeckebans]

The development is on hold because I'm still evaluating UE4. id Tech 4 is a dead end for commercial projects with such a few active developers. I make my living from freelance game development so any unpaid work on D3 based projects has absolutley no priority.

2014-06-24 15:53 GMT+02:00 nbohr1more notifications@github.com:

Thanks for the info. I almost forgot about the use of Flash for menus. That might not be too much of a hurdle for other projects but The Dark Mod has too much infrastructure dedicated to the vanilla GUI code (Readables, Mission Briefings, etc). We'll have to look at porting vanilla's GUI system to BFG before attempting any merge. (That and reconciling our resource loader and mission installer setup.)

Do you still plan on releasing your fixes to the vanilla renderer once your commercial project is released (therefore making this much easier)?

— Reply to this email directly or view it on GitHub https://github.com/RobertBeckebans/RBDOOM-3-BFG/issues/130#issuecomment-46973242 .

[nbohr1more]

Thanks again. If you abandon Id Tech 4, we would gladly review any your old unfinished work excluding anything that is considered proprietary. It's a shame that no other large projects seem to have ventured to take advantage of either the standard BFG source dump or your work here. Perhaps either Hexen EOC or Arx EOS will look into this eventually. Right now it seems to be pearls before swine I'm afraid.

Yeah, UE4 definitely is the path of least resistance. The only reason to entertain Id Tech 4 is for the possibility of tighter Blender integration or more GPL tool contributions. The pace of which is obviously going to be pretty darn slow without some sort of commercial backing. (Or as an act of philanthropy...)

[motorsep]

@nbohr1more While UE4 has better tools, it still lack game code (and I mean entire framework). A project would still need skilled programmers to make something beyond provided templates. You also need Maya or Max for content creation since Blender's FBX still sucks. So it's at this moment it's still arguable whether UE4 is more beneficial for a small unfunded indie team, considering they have a programmer.

Btw, the only way indies will look into using any of idTech engines is if there are games out commercially using it and there are tools made to accompany these engine (standalone tools that aid development; improved built-in tools). It's true for all idTech engines, not just idTech 4 / BFG.

[BielBdeLuna]

or an open source and libre replacement of the game ala Freedoom, which is not commercial.

[motorsep]

@BielBdeLuna That's not going to help bringing developers and improvements to the engine. There is well known TheDarkMod, free all the way. And yet, no one has gotten motivated by it into using idTech 4. There is also Hexen mod, which hasn't been active for quite some time.

Making a good free-to-play game, that is free, but with in-game purchases that fund future development, could help. But making full blown GPL game - not going to.

The are a few established free games using idTech 1 and idTech 2 (Xonotic and Warsow) I know about. One of the reasons they are able to attract devs is due to simplicity of assets creation - it takes way less effort to make an asset for those games than for TDM or Hexen or even plain Doom 3. Anyhow, going to offtopic..

[BielBdeLuna]

while you're true in all your statements there is something to be said on TDM, the intent of TDM was not on creating a replaceable asset library for modmakers an indie developers, but to create a community, in fact the focus from the developer to the mission authors is to give a thief like experience to the point of easing out the making missions with the Darkradiant which clearly informs on the intentions of the developers behind TDM. It wasn't the intent of the TDM developers to help bring developers to idtech4. of course if as a by-product if they come they will welcome them though.

on the easiness of asset creation, nothing in idtech4 stops you in creating idtech2 level of assets. is up to the developer, take a look on the games of blendo games in that regard.

[motorsep]

I am not saying TDM was created for a purpose other than being a spiritual successor for Thief. What I am saying is idTech 4 is "dead" because no one wants to get it to the level of modern indie game dev. It's not about novel graphics features. It's about community, tutorials, tools and assets.

idTech 4 engine is much harder to work with than with Darkplaces. Especially because it's made only for one purpose - power Doom 3. When you start going beyond that, you have to solve a lot of issues. It has a lot of unfinished features that you start using and stop half way because it's not finished.

It's plain and simple - the more complex the engine, the more complex it becomes working with it. So it's not just about making assets. It's about everything else, including writing decls, writing scripts (scratch scripts, not extending Doom 3's), wiring all that into game code, expanding game code, etc. etc.

So no, working with idTech 1 and idTech 2 is easier than with idTech 4. They don't even stand close.