motorsep

Yeah, probably every tick. Or every so often, but often enough that performance is important. Me neither so, no rush.. I appreciate your help.

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?)

No no, I am looking for any entity of a certain class. For example, I need to find any func_door entity on the level and print its name in the console.

How do I find an entity of a given class in the game's world using SDK code (C++) or/and script ? For example Quake has something like find(e); a built-in that returns entity when it finds it. Does Doom 3 SDK have something similar ?

What were the reasons not to improve DOOMedit ? (besides going crossplatform)

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

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.

That I know how to do changing GENTITYNUM_BITS 12 to GENTITYNUM_BITS 13 How do I do that? 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.

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)

Decorative entities don't need to think. I am mostly interested in adding a lot of debris, rocks, etc. Static, non-interactive stuff. It's not for TDM, it's the game engine we are working on (based on Doom 3 BFG).

I am wondering why can't entities limit to be expanded beyond 8192 entities ? (I am sure it's plenty, but still)

Aye, this issue is engine related, so the "bug" report can be closed/suspended. I thought engine supports such functionality already (non-TDM engine).

Please fix it, if possible: http://bugs.thedarkm...iew.php?id=3735

@HMart: Why don't you run a map without script first. Take baby steps to get bare map running, before dumping scripts on it.

The whole charm of Doom/Doom 2 is in sprites.. I don't get why add 3D models into 2.5D engine.. It sucks.

https://github.com/RobertBeckebans/RBDOOM-3-BFG/blob/master/README.txt

Why is this +set fs_basegame mymod there? No need for that.

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 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.

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.

Use Flash 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.

Thanks, but I am not a programmer 7318 is.

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 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. 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. 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.

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. 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. 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.

Not only. Fonts are different, the way you write scripts is slightly different, game code is slightly different, shaders are different. 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.

@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