Jump to content
The Dark Mod Forums

Tels

Member
  • Posts

    14984
  • Joined

  • Last visited

  • Days Won

    23

Posts posted by Tels

  1. This will work with UDF too (but not with ExFAT, which has limited support outside of Windows). Compatibility between different cameras might be an issue, but how often do you need to copy data from one camera to another? I suspect most people just format the card in the device it's in, since this is a very quick and easy way to delete all its contents prior to a shoot.

     

    Anything that can play DVDs or Blu-rays will be able to read UDF, and if it can burn DVDs and Blu-rays it should be able to write to UDF media too, which I'm pretty sure applies to Windows XP and newer although I haven't specifically tested.

     

    EDIT: This table suggests that only Windows Vista and newer can write UDF, so maybe that is the issue.

     

    There's nothing specifically "optical" about UDF; it's just a filesystem. Not as full-featured as NTFS or ext2/3/4, but certainly better than FAT and its derivatives.

     

    Maybe there are no special software libraries or chips that can be used in cameras, or the manufacturers simply don't know about them?

     

    And there is:

    Max. volume size

    2 TB (hard disk), 8 TB (optical disc)[1][2]

     

     

    Still plenty of room for for SD cards and USB sticks,

     

    But the manufacturers work and think in strange ways, anyway. My LG TV set formats the HD with JFS (https://en.wikipedia.org/wiki/JFS_%28file_system%29) - so it must have some sort of Linux/UNix/BSD inside (The menus are written in Java. Yes, that means even changing the channel invokes a Java app..).

     

    But the recorded content is encrypted, and while you can read the disk in a computer, you can't use the contents. Likewise, with LG, you cannot reformat the disk (or create a second partition) to have your own content on the same disk.

     

    That works with Samsung (at least some models), but not LG. And since my TV has only one usable-for-HD-USB port (the second USB port only takes peripherals like mouse), you can either record to the HD, OR play your own content from the other HD. But never both at the same time.

     

    Even more stranger is that the TV detects when you plug in a USB hub, and have the HD on that hub - and then complains and won't take it. It's understandable, because there could be power issues, but even with external power to the hub the disk is not taken. So, the OS on the TV makes an extra effort to detect an USB hub...

     

    Propritary shitty stuff that breaks, is incompatible, and cannot be upgraded, either....

  2. Ah, I see says the blind man. The closest equivalent would be the falloffimage and that is defined by a texture.

     

    The cubemap light proposal I discussed earlier would add a spherical falloff so we would have a value there but

    we'd need it earlier in the chain... I guess we would need a new keyword or parm... no breaking existing maps

    but no easy way to make everything soft either... (unless we just assume a defined value).

     

    Hm, I think encoding it as a constant might do for a first try, so that is is sortof between a candle and a campfire, and ignoring edge cases like a pin hole light and a burning house on the other end of the spectrum. :)

     

    Just had a look at the shadows of a neon tube in my kitchen, the shadows it casts are assymetrical, and quite more soften in one direction. But I guess for a first try we could ignore that either and assume spherical light areas - the difference is quite small (unless the light is really really long and slender) and probably nobody will notice it - afterall, the entire shadows are just an first-order approximation and we miss any effects like walls reflecting lights.

  3. The shader uses the light_center and the silhouette verts as input and projects the results to the casting surface.

    The penumbra calcs would just modify the angle of the projection depending on the distance to the light_center.

     

    Yes, this could cause some problems for existing maps if we use the natural function instead of a clamped function that

    defines the maximum penumbra size. And, again, we could do a cheap version where the pixel offset is fixed for all shadows

    so you don't get realistic penumbra fading but just a smooth shadow edge.

     

    No, I think you misunderstood me. I meant the _size of the area of the light_.

     

    Not the size of the penumbra per se, but the size of the penumbra based on distance and size of the light.

     

    If you have a small, point light, then the shadow in distance X will have a very small, hard edge. If you have a 5m diameter light, then the shadow in the same distance X will be very soft. And this is a "per light" parameter. Think fi. of the size difference between a candle flame and a lighting bulb and then a camp fire. They all three will throw different shadows of the same object in the same distance. For instance:

     

    http://wrice.blogspot.de/2010_04_01_archive.html

     

    Scroll down a bit and you see a diagram, and you see that the size of the penumbra wedge depends of the area (size) of the light.

     

    Of course, you might first get it working at all, and then care about that detail later, I was just wondering :)

  4. One question: The penumbra assumes a certain size of area for the light. Leaving asside non-symmetrical sizes (like long, slenderli ghts) and treating the light as a circle with a specific size - how the shader know the size?

     

    Since most of our lights are point sources... would it assume the same size for all lights? A larger light would cast softer shadows, a smaller light harder shadows.

     

    How would the light definition (and hence the mapper) define that size?

  5. Hey guys,

     

    So I'm still working on the second wing of the manor. There's a long way to go (need to put in gameplay, loot, etc), but it's shaping up pretty nicely so I thought I'd share. Crits/places where I can improve are always welcome!

     

    Lush, rich, filthy-rich, luxorious in-door scenes, that's what TDM is good at, and what you show to almost perfection here. Congrats! Looking forward to this mission!

  6. Hopefully the new soft particles will be the default and we can get rid of the old, ugly ones. I guess even if you are strapped for performance, you don't want the ugly transitions, and would rather dial another setting down instead.

     

    As for the smoke vs. halo, would it be possible to make this a parameter in the material files instead of hard-coding it? Or is this unnec.?

     

    Good work, btw! :wub:

  7. And if we could get a privacy centric, google-free version of android to go on there as well, happy days!

     

    I fear this will be impossible - almost all important apps from the major manufacturers are published only in the google store - and w/o a google account, you can't even install software (let alone install older versions of an app). Truly a few steps backwards for the general computing platforms - and it starts to infect everything from TV sets to central heating control panels :(

  8. Work on the editor continues. Instead of taking shortcuts I'm doing it "right", which means it goes a bit slower than I want, but it has the benefit that the code is much more cleaner and re-usable.

     

    Anyway, the latest additions are:

    • a dialog that shows the current keybindings (note: They are dynamically generated, and updated automatically, f.i. when the menus get changed, or the language switches)
    • Selection tracking. You can use LMB (left mouse) to select one block, Shift LMB to select multiple, and Ctrl to deselect blocks.
    • Started some basics fror the renderer, prefab, map, block and location storage

    Screenie:

     

    post-144-0-72101700-1414677819_thumb.jpg

     

    Please try it, and tell me what you think. (And no, it is not yet possible to actually edit or generate a map - I'm working on it ;)

    • Like 1
  9. I would like get these out for the weekend, and since there should'nt be any bugs it should be a simple play through of each.

     

    Whhops, that might be tight with the I18N then - couldn't you have asked earlier? :(

     

    It's easy to run the script on the misison (if I can get it, tho),but then it needs to be tested again which I don't think will work for "the weekend" which is in 2 days *sigh* Once again I18n gets dropped..

  10. Don't believe me for a second, but there ya go, from Carmack himself: http://fabiensanglar...adowVolumes.txt and he stated that shadow volumes are slower, costly and complex, compare to shadow maps.

     

    Note, that was a year 2000. We are getting into 2015 pretty soon, and quality issues with shadow mapping have been resolved on a certain level.

     

    That's all nice and dandy, but who is going to rewrite the TDM engine? I don't think we have the resources in one way or another.

  11. I too think that penumbra rendering would be simpler to implement (its more an addition that a a complete architecture change) and it would also not bring down the performance much compared to what we got now.

     

    Either you got a modern system (where everything either runs at 60 FPS,anyway,or is bogged down by the single CPU thread not getting enough power), or you got an old system where shadow maps won't help that much – they need GPU memory like there is no tomorrow - which is esp not that good because our textures are quite big and use a lot of memory already.

    • Like 1
  12. The technical hurdles in implementing such a system aside, I have no idea what this would achieve, other than forcing the player to become aware of his surroundings in a fashion that is awkwardly unrealistic in an artificial 3d environment. You've walked down a long hallway, slipping from shadow to shadow, when a guard at the end of the hallway turns to look your direction. Are you safe or do you have to move?

     

    Our system: Check your lightgem--oh crap, you're on the edge of detection, better crouch.

    This system: Check your lightgem, then wonder whether somewhere behind you down the hall is a lit area that happens to be directly behind your head. Swing the mouse to turn and look around, but now you can't see where the guard is, so swing the mouse to look the other way again to try and line it up as he walks your direction....will crouching line your head up with a bright spot on the floor behind you? Better turn around and check.....etc.

     

    This could only work if there was a second lightgem (or the lightgem has two sides or takes the silouette into account). Then a quick glance a the lightgem would tell you.

     

    It would still be quite complicated - how do you slip from a dark room into a dark corridor, if behind that one is another one leading to abright room? Not only could you not hide in the dark corridor (breaking a lot of maps Iguess) but also the player would somehow need to know about that and take it into account.

     

    I see no chance for that feature to become useful for gameplay, technical difficulties aside...

  13. Wouldn't it be easier to add the reverb during audio playback while the game is running? There is no real reason to have every sound twice just to add reverb, is there?

     

    Theoretically, EAX or the successor should handle this, its a shame our audio engine never got updated…

  14. Edit: Regarding the topic - a slingshot seems unnecessary. We already have the bow, no need for a second projectile launcher. Also junk items can already be used as a distraction.

     

    I think the point the OP was trying to make is that there is a place for an "unlimited ammo for distraction purposes".

     

    If the slingshot only worked with rocks you pick up, then you'd also need them somewhere lying around and the player to find and collect them. But then, he could just use a noise arrow or a broadhead or throw a pepple, they work all on the same "collect ammo and use it later" principle.

     

    But a slingshot with an unlimited supply would bring something unique to the game. Wether it is something we want, is of course open to debate. I'm inclided to think it would make the game too easy.

  15. Oh wow, has it been so long already? I still remember the first samples of Thief's Den and how it showed us suddenly that if we wanted to release something to the public, we actually would have to start working on silly things like functional menus :D

     

    Happy Anniversary everyone!

    • Like 1
  16. From: http://www.3dfxzone.it/enboard/topic.asp?TOPIC_ID=1462&whichpage=2

     

    Ive tried a number of doom3 beta console commands to enable 16bit colour in the full game but they are not present. As most people here know already, the game is locked to 32bit colour and this is what causes the biggest impact on lower-end graphics cards.

     

    Yeah, those where the times.. eh, 16 bit color in 2004? Excuse me? I'd say good riddance to old systems holding modern game engines hostage :)

  17. So how do you set up AFs without AF editor ?

     

    Almost nobody does that for an FM, right? Plus, we used to edit AF just by editing the AF, or you use some other dedicated AF editor. There is not much reason that the AF editor is tied into the game engine.

     

    Of course, having real-time in-game editing would be super-cool, but then it should be done right, not in a half-assed half-broken-by-engine-updates way :)

×
×
  • Create New...