Jump to content
The Dark Mod Forums

motorsep

Member
  • Posts

    913
  • Joined

  • Last visited

  • Days Won

    2

Posts posted by motorsep

  1. Will you have to do this often? If you are only going to search the list of entities in response to something happening in game, for example, you probably don't need to worry about the time taken. If it's going to happen every frame, then yes it's worth doing it in the sdk.

     

    Yeah, probably every tick. Or every so often, but often enough that performance is important.

     

    I'm not at home so can't check the exact method names, but look for the idEntity::GetSpawnArg() method, or something very similarly named. You can GetSpawnArg("classname") to find out an entity's game class.

     

    Me neither :) so, no rush.. I appreciate your help.

  2. Now that I am thinking about it, script would be slow. So keeping it within SDK code would be the best thing.

     

    I was looking into the code last night, and it seems that what's already there is a functionality to pull entity's index. So there is no out of the box function that only polls entities of a certain class, correct?

     

    If so, how would I determine what is the class of the polled entity? (entity index 0 is always a worldspawn class, but the rest?)

  3. I deleted the script and it didn't work, afaik the script is only creating at map start a fog light so if i delete it then it should not matter if the script is present or not. I will try making a simple test level but until now this has not give me any hope. Does materials in BFG also need to be different? I have a bunch of custom materials on this map.

     

    No, materials are the same, unless you use some custom shaders. What error do you get in the console?

  4. I'd be interested to know if anyone can answer this one. Do FS keep their separate CMs, or do they get absorbed into the world CM during dmapping? I guess they might have to keep separate ones since you can toggle them hidden.

     

    If you inline func_static, the entire thing, including collisions, gets embedded into .proc/.cm and not counted as an entity.

     

    "inline" parameter is broken in Doom 3 engine (although that was fixed in Quake 4). I would like to know if func_statics with "inline" can have skins and all that.

  5. We bumped the entity limit from 4096 to 8192 a long time ago, and I don't recall there being any large rewrites that needed to accompany that.

     

    That I know how to do changing GENTITYNUM_BITS 12 to GENTITYNUM_BITS 13 :)

     

    We bumped the collision limit from 2048 to 4096 as well w/o needing to do anything other than change the limit.

     

    How do I do that?

     

    I'm not familiar with Doom3 BFG, but your devs should just change the limits and see what happens. If they run into problems, then debug those problems and make the necessary changes.

     

    It's the same when it comes to entity limits. My devs only know so much about the engine. They wouldn't know where to start digging about all the entity limitations. Currently entire focus was around fixing renderer to work with AMD as well as with NVidia, porting tools back, fixing Linux port, making Blender tools, etc. Haven't really gotten to expanding engine with new capacity and new feature for gameplay.

  6. That's right, I should have said all active entities. Func statics do contribute to physics calculations with their collision models, but they don't need to think independently. And whatever processing time they do take will no doubt scale proportionately. My main point was that having some limit, any limit, is in itself a performance optimization because it means the game can use faster memory. If you do try higher limits I'm sure we'll be interested to know what the effects are!

     

    Try this: https://www.unigine.com/products/valley/

     

    Then let me know if you can accuse those devs of being sloppy and putting too many entities on that map ;)

     

    So, sure, there is a limit when engine isn't designed for such things. Thus my questions is why ents are capped at 4096 and how to quadruple entities count without breaking everything else (clearly certain things need to be adjusted to cope with increased entity count, but what exactly)

  7. I was me back at d3w who was insistent on it, because I had added the "wheel of pain" of modern shooters in d3 :laugh:

    tell me, what do you use to author your flash for the HUD and PDA that you already showed in one of your videos in alpha stage?

     

    with Actionscript can you create objects and repeat it "n" times? this can't be achieved with d3 GUIs.

     

    Flash for interactive surfaces shouldn't be that difficult to include in the game code also.

     

    I use Flash MX2004. It's kinda crappy (crashes a lot) but does the job. I might upgrade to CS5.5 if they still sell it on Amazon (or might just go with subscription for CS6, once I have menu art ready).

     

    Action script is fully fledged programming language, so to speak. You can do Matrix-like screen of falling letters :D I am not sure what you mean about repeating object. If you create it by coding it, then yes perhaps.

     

    Oh, and you can make wheel of pain in Flash too.

  8. I'm no programmer.

    Who is "we" ? are you talking about Robert Beckebans?

     

    No, not RB. My team and I is who I refer as "we".

     

    Fullscreen GUI is flawed. Someone (I forgot his nick on d3w) talked about it before d3w went down. It was taxing performance (hud in particular as menus/PDA didn't matter) like crazy. Flash has no such issue afaik. Also, Flash is a standardized tool that far more people know how to work with (graphically and Actionscript 2) than with GUI scripts. Not to mention superb animation support.

     

    I wish we had Flash for interactive surfaces already, to keep it consistent with fullscreen interface, and flexible.

  9. I care about FS GUI because modding is the first step to creating one's game. hence why I care about menu.

     

    Use Flash ;)

     

    explain how pk4 is old packaging? do you intend to sell your game in a console, if not, why is it then old packaging? also, what about sharing assets amongst other members of the community? pk4 is a neat way of sharing small mods that are useful for other members of the community, as a resource for mod making, in my case the portalsky stuff. I could pack all the resources in the pk4 quite easily, how do I use the *.resource file? and what is the benefit of having all the content from a level all packed up in a single file, other than quickly loading a map assets on consoles.

     

    pk4 is slower vfs than .resources for all I know, without getting into too much details. while on PC difference in read/search speed in .resources isn't not huge over pk4, on Android devices you will literally feel/see the difference (and eventually I am hopping to bring Storm Engine 2 to Android / iOS). Again, if pk4 is so easy to bring back, why hasn't it been done so far? ;)

     

    In BFG, you can't use .resources for mods, even for main game packaging because it's designed for DVD distribution for consoles. We modified it to act as pk4, where you don't have packaging per map, and you can author .resources for a mod, and run it with +set fs_game <modFolder> where mode folder contains single .resources file with content of your mod.

  10. on the GUI vs Flash.

    why do you say it's not easy to have both working at the same time? you only check if you have the flash resource and if you do you load it, if not then load the *.gui asset, or error.

     

    Because we looked into it. Fullscreen old gui rendering is not entirely in the BFG's code. You would need to port some stuff over from idTech 4. And 2 systems can not co-exist. I was explained by the programmer who was looking into it, but forgot the details. Either way, if you think it's easy, then by all means implement it and show it to us :D

     

    on the Shadow Mapping.

    instead of wasting the entities on lights for the effect and waste cycles with several lights you just use a single light entity and light the whole area correctly.

     

    You can have 8192 entities per level. That's plenty. You can even extend it more (requires deeper changes, but doable). You still waste computation power to shadow mapping. It's not free by any means. It's more about CPU/GPU vs VRAM bandwidth, and bandwidth is not cheap. That's why 256bit GPUs cost arm and a leg, and 64bit GPUs are dirt cheap.

     

    ...

    GUI

    pk4

     

    If you are modding Doom 3, why do you care for menu? People aren't gonna play menu, they will be playing the game ;)

    Pk4 is obsolete packaging. New .resources have all tools in the engine to author it for distribution.

     

    c++ code wise all is mixed in the d3xp code.

     

    Not quite. It's a bit different for certain things (which I don't know how to explain, since I am not a programmer). Some code, such as vehicles for example, was not directly portable and we had to rewrite code to accommodate for new code base.

  11. modular architecture can reside besides specially crafted meshes/brushes, so it shouldn't be considered as a step back (specially when instancing could be used for other things than map's architecture) architecture wise can help to render huge cities as modular architecture can be used in conjunction to form several variations easily.

     

    Or you can make entire buildings as unique models and performance will be the same, except that you don't need OpenGL 4.x (needs that for instancing) and you don't need to engineer more code.

     

    on shadow maps, really? do you really see using small lights to recreate the shadows casted for every alpha-masked grass bush on the map viable?

     

    Sure, why not? Alternatively you can make grates as geometry, and since shadows cast from those will be precomputed, performance drop won't be significant. For a field of grass, if you really need grass to cast shadows, then use 1 projected light per grass patch.

     

    Another important thing to mention is that if you have shadow mapping shadows from alpha tested surfaces, and majority of your users will run it with shadow volumes, they won't see those shadows. So if you don't care for people with decent, but less powerful GPUs, go for shadow mapping.

     

    My reasons to use shadow maps vs shadow volumes, considering performance differences are minimal (or shadow mapping is much faster, like in Darkplaces/Tesseract engines for example), are following:

     

    - Use of complex geometry (the more polys models have, then more polys shadows will have, the more cost at calculating silhouette; not the case with shadow maps)

    - Implementation of Forward+ rendering (can't implement that with shadow volumes; although it will require OpenGL 4.x)

     

    Since RbDoom3 shadow maps perform horribly, and forward+ rendering requires OpenGL 4.x, I temporarily gave up on shadow maps.

     

    but shadow maps implementations shouldn't be regarded for the "benefits" of the mapping aspect of the technique, but because it also incorporates the possibility to alter those shadows via GLSL, so even if the jittered shadows currently kill the computer performance if you have a lower end card (in my case are completely off because I'm using mesa, but my laptop is not going to last forever ) the potential for the future improvement outweighs whatever one can do with stencil buffer shadows.

     

    All features require practical approach. You gotta ask yourself what is the benefit of adding these features. How is shadow mapping, for example, going to help your game succeed? In this particular case it only will make Phoronix drool over it and remains of Doom 3 community say "cool". That's all there is for this particular implementation.

     

    A rule of thumb is to implement features you need today. When tomorrow comes, and you still need new features, implement those tomorrow. That's what efficient development is about. Not making perfect engine suitable for all game types and all features, forever (unless you are in the business of making and selling game engines).

     

    So when you are making a game, you want to make a _game_. Shadow mapping won't make Doom 3 any better game than it is now. But slow shadow mapping will make people, who otherwise enjoyed the game, cringe. With this sluggish world economy, chances are high for the current hardware distribution to stay at about the same level in the next 2 years. So you will still have about the same ratio of people with 256bit GPUs to 64bit GPUs (referring to VRAM here).

     

    To summarize, I am not saying "throw away shadow mapping". I am saying: "Make fast and scalable shadow mapping". Fast shadow mapping should look decent and be as fast as shadow volumes. Pretty shadow mapping should look much better than shadow volumes, but not drop performance to the ground.

  12. mod creation wise, BFG is regular d3 sans pk4 and full-screen GUI (although the game still uses GUIs for in-game in-surfaces GUIs).

     

    Not only. Fonts are different, the way you write scripts is slightly different, game code is slightly different, shaders are different.

     

    I've looked into the GUIs issue and the code for the full-screen GUIS seems to be not that complex, and the references to full-screen GUIS are the same as in regular D3 except they have replaced with the flash calls, One thing I want to reintroduce is full-screen GUIs by adding them besides the flash calls, so if you have a flash file for that GUI you're served with flash (so you can retain BFG functionality, and I know Motorsep has done some flash GUIs for his own game )but if you miss the Flash content you can use *.gui files. (which is the idea here)

     

    On the contrary, I wanted to add Flash to interactive surfaces, so that designer can use either :) However it's not easy, especially to have both working at the same time.

  13. @HMart: Shadow maps, the way they are implemented now, are good for Doom 3 BFG vanilla, and for GPUs with 256bit VRAM.

     

    People who can play BFG with their 64bit VRAM crappy GPUs, can't really play it with shadow maps. It's irrelevant for RBDoom 3 BFG really, because you can switch back and forth between types of shadows. But if you are planning on using engine for an indie game, I'd think twice using shadow maps.

     

    Neither Doom 3 BFG GPL, nor RBDoom 3 BFG can't be easily used for modding. There is a lot of stuff not working right or broken. We are at the point where engine is fixed up to the point of being usable to build games from scratch. Dmap is in, all tools are in (all working except GUI Editor, but that's in progress), a lot of rendering issues/bugs fixed, some renderer's enhancement have been made, etc.

     

    That being said - patience - once alpha of my game is out, the engine will be out too, along with dev portal. Then you can either use it for TDM, or any other game, or mod my game ;)

×
×
  • Create New...