Jump to content
The Dark Mod Forums

Nyarlathotep

Member
  • Posts

    1196
  • Joined

  • Last visited

Posts posted by Nyarlathotep

  1. Because lockpicking minigames are so last year.

     

    Since your cock doubles as a lockpick, the masturbation minigame is going to replace it. I think it'll add some much-needed life into what has become a tired gameplay mechanic. The TDM guys have some really great ideas.

  2. Don't forget about the rape simulator and the 'spontaneous' ejaculation feature...by pressing CTRL-J, the player will have a spontaneous orgasm to relieve stress.

    CTRL-J only enters the masturbation mode. You have to use the mouse to achieve orgasm, replete with sound effects. :blush:

  3. There's also a lot of work (programming work especially) that doesn't need to have a Thief flavour - in fact it can't have a "flavour". From the player's perspective, it either works or it doesn't!

    Well, you could have global variables with particularly "thiefy" names... :P

     

    I think our Laser Hammerite would disagree!

    Don't you frighten me like that! :(

  4. Well honestly, the only thing you can do is answer what questions I have, such as this one:

     

    Finally, I'm making a trip by the bookstore for textbooks on Friday; can anyone recommend a good C++ and/or OpenGL book I could use?

    ...and whether or not you want to look at some Java school projects I've done. Although--word of warning--I'm not overly proud of these projects.

  5. This thread has languished for two weeks now. What did I do wrong? :blink: Looking back through the thread, I noticed that Crispy stated that I didn't have any sample code (how did I miss THAT?), which simply isn't true. I have plenty of code from school projects--it's simply that I'm not much proud of them (I'd like to clean them up, minimally).

     

    As for the Doom 3 SDK, I haven't been able to find my copy of D3 anywhere. A hallmate of mine has a copy on his external hard drive I could borrow, at least until I find mine or get a new one. As his hard drive is ext2, are there any problems with using Linux for TDM (especially since I don't have a Windows C++ compiler)?

     

    Finally, I'm making a trip by the bookstore for textbooks on Friday; can anyone recommend a good C++ and/or OpenGL book I could use?

  6. (Seriously, somebody has to do the right thing and stop this or the thread will be 20 pages long and there still won't be any new arguments in it. :P )

    I was hoping my post would at least take the thread in a slightly new direction, but so far it appears to have been entirely ignored... :rolleyes:

  7. How do you imagine players communicating their desire to form a truce? If you see somebody from the other team, wouldn't you be likely to kill them before they have a chance to kill you? Keep in mind that unlike a guard, they're as weak as you are, and it would give your team a significantly better chance of winning if the other team is understaffed or injured. And couldn't it be hard to fill a server with enough players to get past the obstacle? I guess you might be able to scale the obstacle based on the number of players, but I have trouble thinking of interesting obstacles that are scalable.

     

    @Nyarlathotep: I'm not sure about this, so don't take my word for it, but... I thought I heard somewhere that it's possible to increase the maximum number of players in a D3 game. Also, it seems like D3 gives you flexibility about what to send or not to send over the network. (for example, I'm under the impression that brittle-fracture physics aren't propagated since they're purely aesthetic)

    That may be true. Unfortunately, I don't know. I only know the reasons why D3 was limited to 4 players. As for brittle-fracture physics (glass-breaking), I had forgotten that it was deemed as special effect--although, it would be interesting if glass actually caused damage. B)

  8. On the issue of alliances/treacheries... I have a hard time imagining it working in an MP FPS game. I suspect players would stick with their teams, and punish any treacheries by repeatedly killing the perpetrator. I suspect anybody who helped the other team would be considered no different from TKers in CS. Sooner or later, most servers would probably end up with automated options for teams to punish any of their members that work against them. In order for alliances and treacheries to have much meaning, you need a much longer lasting game with larger consequences, such as a MUD.

    Anyways, Doom 3 only allows for 4 players at a time. That's fine for co-op, but anything else might be slightly tricky. Doom 3 sends pretty much everything that happens on a client's system, including phys-props. It's great for co-op, but anything slightly more epic than a four-player game requires slightly smarter netcode.

  9. Actually, wouldn't it be fairly simple to add no-save-zones and then add a player-option to forcibly ignore them? A mapper could put them in place, but if a player, like Zylon-Blade, hates the concept of not being able to save in the middle of a poker game, for example, he could turn it off. More importantly, if a mapper decides to abuse their power, such as putting the entire map in one big no-save-zone, the player can tun it off. Give the mapper power, but give the player the right to a veto.

     

    Either way, add a bookmark save (one that doesn't get turned off in a no-save-zone). If a player decides to quit in the middle of a no-save-zone, then he won't be punished by not being able to save.

  10. @Andrey: Nice models, but shouldn't they be lower poly for ingame?

     

    You have to "cap the shadow volume", apparently. I'm not familiar enough with the algorithm to know exactly what that means.

    I thought that had to with eliminating the errors that occur at infinity. :blink:

     

    There is an interesting NVIDIA paper on how it can be done here:

     

    Depth peeling.

     

    Given the complexity and the number of extra rendering passes required, it is not difficult to see why id didn't bother to implement it for Doom 3.

    And that's pretty much the only way to actually use the depth buffer to depth-sort triangles--that is, without somehow modifying how the depth buffer behaves (one vague idea I have concerns using the depth buffer like a hash map). What concerns me is that apparently the only way to have order-independent transparency without dedicated hardware is to use an O(n) algorithm. (Carmack's next engine gets around it by not using hardware transparency at all.) Carmack was right when he demanded that video card manufacturers come up with a hardware solution for order-independent transparency.

     

    BTW, thanks for the article. An O(n) algorithm is almost entirely useless in real-time graphics, but the article did a great job of explaining why OpenGL doesn't make the task any easier.

  11. Z-ordering--damn, I forget these terms too easily! Z-ordering would mostly become useful when there are a lot of polys that Doom 3 wouldn't cull, like if you had a bunch of monsters in one room. However, that's dependent on how effective graphics cards are at culling unordered polygons. Anyways, I know for a fact that graphics cards are capable of doing some basic z-ordering (the depth buffer determines which poly is in front, doesn't it?), otherwise you'd be seeing z-fighting of distant objects and other such fun errors.

     

    Edit: Huh, I always thought that the stencil was used to generate the shadow volume, rather than to emulate raycasting. Wouldn't having the camera in shadow cause the lighting to be screwed up?

  12. It doesn't seem that hard to add a step that tags triangles as transparent--to specifically be ordered from back to front. For the most part, modern engines order polygons front-to-back for culling purposes, although a lot (and I am beginning to suspect D3E) just throw the whole mess at the graphics card for it to work out.

     

    By the ways, that picture is fugly--c'mon, ordering isn't that hard, nor is it that resource/time consuming! Every damn frame has to be ordered one way or the other before it can be rendered! Graphics cards order everything front-to-back for culling purposes, and they reorder everything back-to-front (or rather, that which remains) for texturing! It can't be that fucking hard! <_<

     

    Edit: As for shadows, probably the best performing way to get a reasonable facsimile of shadowing would be to use a projected texture of the surface, with the alpha map acting as a measure of intensity (transparent for full light, and opaque for none). Well implemented, I don't think that it would look any worse, that is, less realistic, than Doom 3's lighting.

     

    I'm a bit fuzzy on how stencil shadows are any different than projected shadows (with the notable exception of the stencil itself), so I don't know how compatible projected textures are with volumetric shadows. Anyways, you can turn off shadowing on the triangles that have that have alpha. Either I'm missing something important, or Carmack is bitching over something that would take a week at most to implement and makes for so much better usability. :unsure:

  13. Didn't read the above because I don't want to see spoilers, but wanted to mention I finally picked up "Baldur's Gate 2, the Collection" a while back, per oDDity's recommendation. Found it at a half price bookstore for $10. Has Shadows of Amn and Throne of Baal. One of these days I'll make time to play it.

     

    Huh, I also found Thief 2 there. They had a bunch of copies, so I snatched one up. I already had T2, of course -- but it's always good to have a spare; especially since my copy has gotten pretty scratched up over the years. Or I might give the new one to a friend who wanted to try it out. Think it was only $8 or so.

    Where is this store, perchance? I've never been able to find a copy of Thief 2, and for that matter, Planescape: Torment. I'd love to pick up Thief: Gold while I'm at it--every time I have to reinstall it I have to recover disc 1, it's scratched up so badly.

  14. Alpha-testing

     

    One of Doom 3's biggest weaknesses is its handling of translucent textures... Doom 3 does no depth-sorting of translucent triangles, and it's not possible to efficiently render shadows on them either. So allowing regular materials to have a full range of transparencies is out of the question and would lead to graphical errors or horrific performance. But it is possible for D3 to efficiently and correctly draw a triangle that consists only of fully opaque and fully translucent areas. This is the purpose of "alpha-testing"... You specify a threshold level of alpha above which a pixel is considered fully opaque, and anything under that level of alpha is considered fully transparent. (it's called alpha-testing, because the alpha channel is tested before deciding whether or not to draw a pixel)

     

    To construct an alpha-tested material, you first construct a diffusemap image with an alpha channel, then you create material in which the alphatest keyword is specified in the diffusemap stage. For example:

    textures/mymap/leafs
    {
    bumpmap textures/mymap/leafs_local
    {
    	blend diffusemap
    	map textures/mymap/leafs
    	// parts of the image with an alpha of more than 0.5 are opaque
    	alphatest 0.5
    }
    specularmap textures/mymap/leafs_s
    }

    I think it may be possible to use the alphatest keyword in other stages as well, but I haven't done much experimenting with it, so I don't know for sure.

    Question. Aren't (partially) transparent triangles correctly depth-sorted? As alpha'd triangles aren't rendered as alternately opaque and invisible, it's safe to assume that transparent textures are being correctly blended. Ignoring shadowing, why would it cause errors to correctly render it?

  15. Seeing as this clip is from the 80's (1986) and came with the first zelda release for the NES, they wouldn't be 15 any more ... so lets ask that again ... you reckon they're hot? :D

    Now? Quite probably, but in that video? *Shudder* Then again, they're probably both at least 35 now, so who knows?

  16. When I think about the culture of grads concentrating in video game technology, it's a far cry from this.

    Care to elaborate? I think I know why you're saying this, but I'd like to hear (read) them for myself.

  17. Before the interviewing process begins, perhaps it is best for people to get some small idea of me...

     

    My only experience in coding is in Java and Python (unless you are willing to count fucking around with StarLogo). I don't have much that I would consider to be in a presentable format right now, unfortunately (most of what I have are school projects--not very interesting).

     

    As for my willingness to learn, I am a college student (CS major). If I am unwilling or can't learn, then I belong neither here nor at my (rather prestigious) school. Being a second-year, I don't have much experience; in fact, I'm applying to get more experience.

     

    I have 2 cats, enjoy romantic dinners for two and long walks down the beach.

     

    Looking for (TDM) love,

    Nyarlathotep

  18. Awesome. I already have a decent idea of the major differences between Java and C--although I don't yet know how to put them to good use. I was more worried that you wouldn't want to put up with someone so ignorant as me (on C++ and D3-scripting). I guess I should send NH a pm, then, eh?

×
×
  • Create New...