Jump to content
The Dark Mod Forums

motorsep

Member
  • Posts

    913
  • Joined

  • Last visited

  • Days Won

    2

Posts posted by motorsep

  1. What I don't get -- and what you haven't explained -- is the connection between FM distribution and the GPL. We're talking about distributing FMs. What have those got to do with the GPL? FMs are separate content saved in a separate folder, that can be put there by any one of a variety of mechanisms that have nothing to do with the GPL game code.

     

    There ya go - to download FMs via Workshop you don't need anything. Just subscribe and get it via web browser or Steam client (if you do it via web, when you launcher Steam client mod/FM will download). However, to upload FM to Steam Workshop you need SDK implementation. You can not implement this part in the engine. That's where GPL conflict is. And I brought it up, yet again, when I saw post #325.

  2. I haven't seen anything that suggests that Workshop is incompatible with GPL, but we probably want to steer clear of it anyway for various reasons that you'll find up there somewhere earlier in the thread.

     

    Seriously, Workshop has C++ code, just like the rest of the Steamworks SDK. I don't know if you guy messing with me or can't wrap your heads around the concept :/

  3. 1. What does the GNU Operating system have to do with Steamworks?

     

    2. What is your source for the claim "Steamworks can't be implemented due to conflict with GPL license."

     

    GNU GPL license is my source. It clearly states that any code merged with GPL code has to be/become GPL. I don't have time to waste on this nonsense. You've been on board with TDM too long and you should know the limitations due to engine's GPL license.

     

    If Steamworks could be implemented with GPL code, then Steel Storm had Steamworks implemented. However, it's impossible due to the GPL license on the engine.

  4. In addition to what jaxa already wrote, the creator of Unreal engine Tim Sweeney confirms on Nvidia's blog that the kite demo runs on TITAN X:

     

    Aye, thanks for digging it out. UE4 doesn't feel too awesome any longer :(

     

    If anyone interested / has time, try Unigine's Valley demo: http://unigine.com/products/valley/

     

    My GPU is 670 GTX (the rest of the hardware is like 9 years old) and yet that demo runs fine on it. That makes me wonder about UE4 optimization.

  5. It says in the description that it's 30 FPS, and it's rendered on Titan X so on average GPU it would probably be 1 frame per second. LOD is noticable in couple of paces but it's not jarring.

     

    Lol, I "love" this kind of comments :/ Thief in the Shadows was rendered on Titan X. Kite description only says 30 fps. No word about hardware.

  6. Regarding outside levels, we have LOD. The issue is that most mappers do not excessively use it. The deal is that idTech 4, the base of our engine wasn't designed for large outdoor levels. In return, other engines (for example those who are suited for large outdoor levels like CryEngine) are in return not that powerful in regards to high-detailed interiours.

     

    You should probably play Crysis 3 to see how detailed interiors are.

     

    As for AI, I am sure any game with a lot of thinking smart AI will bog down performance. So I don't believe it's relevant to the engine.

  7. Well when something is free there is always a catch, first black mark? having to create an account just to download the launcher, second black mark? not very user friendly launcher..

     

    Lol, what's wrong with registering? I am sure you had to create account for games or some other software. Epic needs to track usage and whatnot. Kinda a no-brainer to me - I will require some sort of registration for my games just so I could track people back for feedback and whatnot.

  8. It has half the job done for gpu vertex skinning, but when we tackle that we'll want to aim for more rather than just copy BFG and stop there, but that bit of code from BFG would be useful as a base. Its parallel processing system is a big upgrade (and looks correspondingly hard to digest), but what it's used for in the renderer (constructing shadow vols, cpu skinning, sillhouette detection, light interaction culling) would probably be easier and faster to do on the gpu using OpenGL3 techniques.

     

    What do you mean by "half the job done on GPU vertex skinning" ? What BFG has for GPU skinning is one of the good performance oriented techniques available (coming from another engine author). I'd like to know what would be the other "half" of the skinning :)

     

    I believe it's not possible to do all these things BFG currently does on CPU, on GPU. If that was possible, it would have been done on GPU. Afaik, shadow volumes (in any engine) are CPU bound by design. None managed to move all that to GPU.

  9. Right, but can I add that to the map entity ? I know I can do that for entities in .def file, but this is something that should only pertain to a particular entity that was created as func_static / func_mover, and then then adjusted to work with certain gui_parms.

     

    If I use that on the root func_mover/func_static, all of the entities I make will have the same description / comments for gui_parms, when in reality those gui_parms can serve entirely different purpose.

  10. Is there a way to add a description for entity's spawnargs? (so it's visible in when using entity in DR)

     

    I have an entity (func_mover / func_mover with gui screen) which has 12 gui_parms. I'd like to add some sort of comment / description for each of those so that when someone else will use the prefab with that entity, that person would know what those gui_parms are for.

     

    Thanks.

  11.  

    But there is. It's entirely possible for it to be released as St Lucia and the training mission. Were somebody to verify their game cache, it would install St Lucia and the training mission. The other option is to include every mission and add new ones via free product updates that change the master copy on Steam for all future installs. Again, very, very simple.

     

     

    But, no, there is not a way to store missions as pk4 files (or any files for that matter) on Steam servers and have TDM download it directly from Steam servers. Anything that goes on Steam servers needs to be authored into depots and Steam app will be the one downloading it in the form of DLC or updates.

     

    As I already said, the best way to go about it is to release with all missions, and have new missions downloaded using usual way of TDM from your servers, not from Steam servers. Once critical mass of new missions is accumulated, you can push it as free updated to reduce load on your servers.

     

    I don't see another way of doing it, unless you have the capacity to serve swarm of users who will download missions from your servers upon release.

  12. :huh: Where on Earth did you get login systems from? We're talking about whether or not to use the current mirrors and risk an overload on release, or use Steam servers and post newly released FMs as updates.

     

    I am referring to general attitude some people exposing about unwilling to adjust to what Steam requires. Yes, there are some games that do things non-Steam way, but generally there is a reason behind it and not everyone can do such things on Steam.

     

    I already said there is no way to store missions on Steam servers without resorting to Workshop / DLC format (which means you can't use in-game downloader as is).

×
×
  • Create New...