Tuesday, 29 April 2014

Software Occlusion Now Integrated

Lots of tweaks happened today, including Dave's completion of the CPU software occluder which is now working inside the main engine and culling objects left, right and everywhere. Added an extra control to SETUP.INI to control how many polygons are selected for the occlusion geometry which will help lower end systems use occlusion to suit their performance limitations. Also saw some good improvements to the weapons, making them feel a little better. My own work involved solving the issue of why the latest build did not run on some systems which turned out to be a stray debug DLL dependence, new code to control entity speed for non character entities so that the speed you see in the editor is the same as that in the game and perhaps my favorite completed item was the alpha slice in the editor which will remove the roof from buildings, and disable them from selection when the TAB is pressed to engage the mode which allows you to place tables and objects inside the entity building rooms. You will wonder how you managed before this extra little feature. Just zoom in, press TAB, select some furniture and start decorating!

Fixes from yesterday include enemy flinching and extra spurting blood when enemies shot, entity editing mode back into the F9 mode, strange 'grey screen' issue reproduced and fixed, muzzle flashes now line up with the gun no matter the FOV, improved fogging technique above (and below) the water line, reduced accuracy when shooting from the hip for default weapons and a few other minor tweaks to bring things closer to completion.

Due to a very insistent Ravey, I also added (actually re-instated HEADLIMBS field in the FPE) the head shot feature which will provide a X4 multiplier for any bullet that hits the head of any character.  Combined with the new feature which recovers from iron-sight the moment you release the Right Mouse Button, you get a much better sense of combat. We also removed the ability to sprint and shoot at the same time, and when you put all these things together you get a much cooler game play experience.  Obviously lots more to follow, but it's starting to take the shape of a serious FPS mechanism. Finally, we also fixed the annoying issue of running through the edge of the gate entity, so that now the physics shape lines up perfectly with the visible object geometry.  A small but vital fix for this version.

We all have a myriad of tasks assigned for Wednesday, but my main task assigned will be the start of character ragdoll physics. I have budgeted a day but with the usual distractions it will probably leak into Thursday too, but the time has come when it becomes my sole task. The good news is that I have done ragdoll twice before for FPSC projects so third time should be a charm! I am not aiming for the full Monty ragdoll on this occasion, I will be looking to create a convincing 'fall over dead' simulation for situations when the enemy expires and falls up/down/off a hill, or over a crate or entity wall, or from a very high tower, or down some spiral stairs, or into the water, or in the middle of the sky. It's a lot to handle, but it should be fun to code and even more fun to test!  If anyone wants to post some inspiring ragdoll YouTube footage to get my brain in the mood for some good ragdoll coding, post here and fuel the old fire.

19 comments:

  1. At your request here is an inspiring YouTube video of Bullet Physics Ragdoll working in DBPro.

    http://www.youtube.com/watch?v=ROI51PKuuAQ

    ReplyDelete
  2. me personally don't care for ragdoll effect. I think is a waste of time to work on it know when we can get better effects in fpscr like explosion effects or particle effect like when you shoot a brick wall. I would want some AI scripts over ragdoll any day. one of the most important effects is missing from characters animation is hit effect when you shoot them.

    ReplyDelete
    Replies
    1. Lee just finished saying that the hit effect was added, both greater blood spurts and moving limbs.

      And if you've shot one of the enemies on a slope, or near a wall, you'll know that ragdolls are very important.

      Delete
  3. Agreed ragdoll is important and other things such as explosion effects will happen eventually its just patience is needed on our end and trust these guys, we all knew this was a long term project but hey they still have my full support

    ReplyDelete
    Replies
    1. Indeed Nathan. It seems as though Dave Ravey knows what a good modern FPS game needs and is pushing Lee to get it right. Lee may be a good programmer, but he lacks knowledge of modern games, and not only that, but what makes a bad game.

      Delete
  4. Lol, Clonkex are you saying Lee doesn't know what makes a bad game? Surely that is impossible?!

    ReplyDelete
    Replies
    1. Haha :P I guess I sort of am. I suppose what I'm saying is that he hasn't played many modern games, and those few that he HAS played are all the highly-rated AAA games. No one has recommended a bad, "what-not-to-do" game as yet. Basically, by Lee's own admission, he hasn't kept up with modern games, and Dave has, making it likely that Dave knows more about what makes a game bad.

      Does that make sense? :P

      Delete
  5. "We also removed the ability to sprint and shoot at the same time"

    Not sure why that would be seen as a good thing as its a very useful thing people with a weapon can do.

    Does that refer to removing sprint and shoot from the Player, Enemies or Both?

    I would have though that both should be able to do that and that enemies should be able to shoot in almost any possible movement scenario unless prevented from doing so by some scenario restriction or other which would make it impossible for them to do so. e.g. a location or other action they may be involved in which prevents the possibility.

    I would have thought that any modern game with decent AI should allow enemies to shoot for example when stepping, walking or running (forwards, backwards, sideways, upwards, downwards), when kneeling, prone and flat on floor etc;

    Will Reloaded enemies then have to stop at idle at a standing position only before they can shoot or reload a weapon, much akin to Classic when they were sitting ducks? I hope not? Perhaps I have misread the implications here?

    Hopefully this will also apply to the player and that shooting from various positions and or during movement whether walking or running and so on will be possible?

    A Boot Hill style shoot out where the Main Character and an Enemy opponent have to stand still on the spot facing one another before drawing their weapon and shoot in the fastest gun in the West style is not really what a modern Game would be restricted too.

    Not what Reloaded as a modern up to date FPS should be reduced to at all I would have thought. Player and Enemies should be somewhat more inventive than that in my personal opinion anyway.

    Perhaps I have completely misunderstood or misinterpreted something that would otherwise be of considerable concern which I sometimes do so forgive me if that's the case.

    :-)

    ReplyDelete
    Replies
    1. I do agree somewhat, in that this varies between games and I think the ability to shoot whilst sprinting should be an option, but I also don't mind terribly.

      I do believe you have somewhat misunderstood, Pete. The fact that you can't shoot while you're sprinting doesn't prevent you from shooting while you're moving, only while you're holding down the shift key. This is pretty common in modern FPS games; normally, while the shift key is not held but the player is moving, the gun is animated to be held about chest-height and bounces slightly from side to side, but still aims forward. While the shift key is being held and the player is sprinting, the gun is normally pulled back against the chest so that the elbows are at the sides of the body and is animated to swing violently back and forth as the player character puts all his effort into running quickly. In the case of a pistol, sprinting often causes it be raised to a vertical position (which looks good but isn't very realistic when you think about running like that), or in some games the player character lets go with their left hand and simply swings both arms, one with a pistol held in it.

      That's my not-so-quick and mostly pointless run-down of FPS sprinting animations. I hope it somehow answers any questions you may have.

      Or maybe, to summarise, I'll say this: Normally (shift key not held), the character is jogging along, still able to aim and shoot. When the shift key is held, however, the player begins sprinting, where all his energy is put into moving as quickly as possible, which disallows shooting his gun. The same would apply for NPCs, where instead of having a shift key to hold they have an internal state which is changed by the AI code.

      Maybe THAT will answer any questions :P

      Delete
    2. An alternative to disabling shooting while sprinting is to greatly reduce the accuracy. In real life, when a person is running like hell, they tend to bob up and down and all over the place (most people at least). Or best yet, let the game maker decide with some accuracy settings based on speed for different weapons (some may have guidance/tracking, some may be more primitive, etc).

      Having certain customizable physics options will allow the user to create more unique gaming experiences. That's what the original FPSC games lacked. All the games made with that were pretty much identical. A game created by FPSC always gave itself away by the famous HUD of health, ammo - always the same. I never created a full game with FPSC so for all I know the ability for greater customization is there and people just didn't use it? (and most people probably won't anyway).

      Speaking in general, I always prefer a piece of software that doesn't force the original programmer's assumptions and tastes onto me - but that allows me to drill down into modular options and change what I wish if I want to, but has solid defaults so that is not required for those who don't wish it. That's the best of all worlds. And it keeps the learning curve very simple, and the interface intuitive.

      Delete
    3. You know WHY they were all identical, don't you? It's because Lee has a nasty habit of hardcoding everything ;)

      I agree with what you've said; having the options available in the player start marker is a good idea, even I kind of feel like the marker is a slightly "hidden" place to put settings. The last thing you want is to be searching high and low to find a setting you forgot the location of.

      Delete
    4. "It's because Lee has a nasty habit of hardcoding everything ;)"

      Has? Or Had? The original FPSC was written several years ago. All the more years of programming experience (and user feedback) since then. I've been noticing and quite impressed with what he's leaned since then, too. As a programmer myself, learning and improvement takes a lot of time and experience, results, feedback, rewrites, etc.

      And to answer your other comment below - hehe yeah you're right, I get carried away a bit there sometimes. Let's just say I have a very unique point of view ;)

      Delete
    5. Oops. Your other comment above (the above post). :D

      Delete
    6. Has, definitely. We as the community have kind of forced him to learn to do otherwise, but all too often he writes about how he put in a new feature, hardcoded and not changeable.

      Maybe it's just me. Any time I write something, I always end up spending more time than absolutely necessary making sure the end user has every option available to them. So any time I see something that as an end user I might want to change, I can't help but make sure they have the choice to do so, however obscure and unintuitive the option may be.

      Delete
    7. I guess you kinda have a point there.

      As for my programming, I might not go quite that far ("no matter how obscure"), but I'm otherwise the same way. It's always frustrated me when I'm using someone else's software and I need to change an option, and then it's not there. So I'm always sure not to inflict that on others (or my future self). I always like to make things compatible with visions beyond my own current one, whenever possible.

      Delete
  6. Reloaded allows the Player to Run (Sprint) and Shoot now so I see no need to change that except that the exaggerated swinging of weapons when running which is overly so. Its that - that needs changing not the weapon shooting capability which has nothing wrong with it in and of itself.

    Humans can run and shoot but their weapons don't normally sway back and forth that wildly.

    :-)

    ReplyDelete
    Replies
    1. The solution as I see it, is to give the option inside Reloaded as to whether or not fire-while-sprint is enabled. If it is, the gun bobs (not sways) more quickly than when just running, but doesn't bob any more widely than running. If it is disabled, the gun uses a separate animation (pulling the rifle back against you chest and holding it sideways, etc.) to give a reason for not being able to shoot.

      Delete
  7. Software occlusion is nice and glad to hear that it'll be in the next beta. Any plans for hardware occlusion? I know OpenGL had some sort of extension for occlusion so I would guess DirectX probably has an equivalent way to handle it as well.

    ReplyDelete