Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

  • Days Won


Hodgman last won the day on February 13

Hodgman had the most liked content!

Community Reputation

52489 Excellent

About Hodgman

  • Rank
    Moderator - APIs & Tools

Personal Information

  • Website
  • Role
    Game Designer
    Technical Artist
    Technical Director
  • Interests


  • Twitter
  • Github

Recent Profile Visitors

96019 profile views
  1. There was a discussion recently on making TCP-websockets behave a little more UDP-like. If you're doing a networking model that works well with unreliable streams (e.g. shooters), then this might be worth a look: People have developed fast paced shooters on Websockets, despite TCP not being ideal. RTS games often use lock-step networking models that work well on TCP.
  2. Hodgman

    Space Hockey - Pirate Dawn Universe

    I'm not attacking you. I'm honestly trying to help. I don't believe that there should be a stigma around mental health discussions and it definitely shouldn't ever be used as a slur. To be clear, I'm not attacking you with: "You're mentally unstable, therefore your claims are false". I'm stating the opposite of that: "You repeatedly make false claims, have baseless delusions of grandeur, express paranoid conspiracies against yourself which are false... which are all warning signs of disordered thinking". I'm honestly very worried about you and want to help. I also think that your inability to succeed with your game projects is down to self-sabotaging acts that stem from this disordered thinking... and that if you want to actually succeed as a game designer, you need to address those issues first. We've all watched you talk about these wlid kook posts for years, and the only sensible conclusion is that you're experiencing disordered thinking. You need to get someone who's qualified in this stuff to diagnose it. I am not a doctor, just a concerned colleague. Going along with your stories of you-vs-the-games-industry, or you the genius-inventor-being-sabotaged is not helping you, it's just enabling harm. So I'm not going to indulge you any more. Enough is enough. We've tried playing along with you and it hasn't helped. So, here's the plain truth: it's not true. It's simply not true. This is delusional. I'm literally quoting you... No, you didn't. This is a fantasy. There's no real work in those areas, by you, that's accessible to the public. Just ideas in your head. This is not true. This is a paranoid conspiracy delusion.
  3. Hodgman

    Space Hockey - Pirate Dawn Universe

    No you're not. You're neither famous or infamous. You are suffering from delusional thinking and need to seek medical advice immediately. There's no conspiracy against you. It's psychosis. This is not an insult. As someone with my own mental health concerns, this is honestly the most helpful thing I can think to tell you. The sad truth is you're in an episode right now. Talk to your doctor about this. We've all watched you post incoherently for YEARS about conspiracies to suppress you and your achievements, about your achievements and association with projects (many of which have shown to be wild exaggerations or fabrications), and your game ideas that don't gain traction due to your own personal shortcomings, or by their own incomplete nature (no conspiracy required). When's it going to stop? It's really not healthy. The only way you can help yourself is to get these symptoms diagnosed professionally and find a treatment plan that can stop you from sabotaging yourself with this disordered thinking. Good luck. We're here for you if there's anything we can actually do to help you. If you want to keep insisting that you're a suppressed genius and that the world is out to get you though, I'll keep reminding you that none of us know who you are and there is no worldwide conspiracy. The world simply doesn't even notice Marc Michalik.
  4. Hodgman

    Space Hockey - Pirate Dawn Universe

    Sorry, who are you?
  5. is a helper / utility function (not part of D3D itself) that loads images that have been saved in the DDS image format. Are your images in that format? If not, then you don't want to be using that function. You can, however, look at the source code to CreateDDSTextureFromMemory to see which actual D3D functions it's using to create a texture resource, copy compressed image data into that resource, and then make an SRV for the resource so it can be bound to shaders.
  6. Assuming 60fps, then that's around 20GBps of PCIe traffic. That's near the limit for a lot of PC's! I'd probably aim for below 100MB per frame... The minimum cbuffer size is 256B, so yeah, one per object, times a million objects, times 3 frames = 0.72GB... But... If you're drawing a million objects, you probably really want to be using instancing or indirect drawing or some kind of batching system where you don't need to make a million draw calls each using its own cbuffer. Possibly also using a system where most of the per-object data is stored and calculated on GPU, so that you don't need to triple buffer it.
  7. Hodgman

    Mathematically ideal field of view

    That's the mathematically ideal answer. Everything else is a lie IMHO, setting the vertical FOV and calculating the horizontal produces better results in these days of wide-screen monitors. Most recent games I've looked into let you choose between 60 to 80 degrees vertical, which ends up as around 90 to 115 degrees horizontal on a standard wide-screen (or 145 to 155 degrees horizontal on a triple wide).
  8. If memory serves... The GeForce 9/FX series introduced half-precision processing instructions, and was about twice as fast if you used them (or alternatively - it was twice as slow if you needed 32bit precision....). Also, a lot of SM3.0 level GPU's didn't run 32bit computation by default a lot of the time -- they'd do things in 24 bit precision where possible, and most weren't IEEE 754 compliant. Not sure on the timing, but the idea of half-precision computation was phased out pretty soon afterwards, and is only just being introduced now in Dx12 level GPUs!
  9. I think https://www.khronos.org/registry/OpenGL/extensions/EXT/EXT_texture_sRGB.txt adds the compressed sRGB formats
  10. They already don't match up before this (we use PhysX which is non-deterministic, and also sometimes user inputs from clients will arrive slightly too late to be applied at the exact frame that they wanted to apply them on) so the visual position of each player's vehicle is smoothed out to hide the corrections, while the physics state is constantly snapping with corrections from the server. If I end up using a larger tick size for high ping players, they'll end up with more physics snapping = more weird visual smoothing... but the severity of these issues will depend on how bad their ping is. I think gamers kind of expect to have a worse network experience in fast paced when their ping is high, so it might be acceptable..? Using the client-side reprediction model, the current behavior is that high-ping players end up with higher and higher CPU loads / their framerate drops lower as their ping increases!! That's pretty awful, so I think having horrible physics quality at high ping is a better outcome than horrible framerate
  11. If you want to add a line once (not once per frame) then you only call AddLine once (not once per frame)?
  12. I don't know if it's the "correct" way to do things, I'm just making up game/engine architecture as I go along. I'll let you know after I successfully launch a game using this model For what it's worth though, Doom 3 used this model of client-side rewind and reprediction. There's a very in depth write up here: http://mrelusive.com/publications/papers/The-DOOM-III-Network-Architecture.pdf As for the punishing ping thing... Yeah that's my main objection to this model at the moment. I'd love to support fairly high pings, as my racing game doesn't have collisions, so high ping shouldn't be as much of an issue. I haven't implemented these yet, but my plans are to automatically tweak some settings on the client when their ping is too high: * increase the physics tick size during reprediction - e.g. Instead of doing 10x 60Hz ticks, run 5x 30Hz ticks to repredict. * spread reprediction cost over multiple frames. e.g. When the client gets a state update that's 10 frames old, they currently save their game state, load the servers state snapshot, run 10 ticks, then compare the new state against their saved one and add differences into the visual smoothing buffer. Instead, when getting that 10 frame old server snapshot, then could save their game state,load the servers state snapshot, run 5 ticks, save this as a new fake "server snapshot", load own their saved game state from before this prediction and advance to the next frame as if nothing happened. Next frame they take that half repredicted gamestate from the previous frame (which is now only 6 ticks out of date instead of 10) and pretend that it just arrived from the server.
  13. If you're drawing a new line every frame (e.g. a line that shows which enemy your missile launcher is locked on to) then set the duration to 0. If you're drawing a one-off line that you want to linger for a second so that you can see it (e.g. a line that shows the path by a a bullet which exists for a single frame) then you use a large lifetime value like 1000ms.
  14. The Jitter Buffer section implies that state updates from the server arrive at the clients slightly before the client is due to present that frame. This means that he's running the server in the future / clients in the past (like counter strike) and not how I've described in my last post. The downside here is, in order for Sever updates packets for frame F to arrive just before frame F occurs for a client, the client clock has to be synced to at least ping/2 ms in the past relative to the server clock. This means that when the client sends user input to the server for frame G, the server will receive it at time G+ping. This will be fine for completely predictable actions, like moving a single FPS character -- there is latency, but the client can hide it by applying the inputs on their end at frame G -- this is incorrect / divergent from the server's version of events (because the server will apply the change at G+ping), but if no other interactions occur, the end result / final position of the character will be the same on both ends. You only run into issues when your predictions are wrong because there's other things going on in the world, e.g. When two different FPS characters walk into each other, or you walk into a door/moving object being controlled on the server, or if two people throw physics objects at each other, there's some kind of timing/rhythm puzzle, etc, you'll notice ping ms of input latency. AFAIK, counter strike doesn't address that at all / it's just a tolerated downside. However, they do address the special case of weapon ray-tracing, by having the server rewind all player skeletons when receiving a shooting input, so that input lag of shooting is corrected for. The mostly correct predictions plus rewinding of weapon hit boxes means that it seems rock solid.
  15. Hodgman

    Triggering 3D mode on TV's

    Same way they negotiate about resolution, refresh rate, etc -- they use the HDMI protocol to talk to each other over the HDMI cable (or replace HDMI with any of the other protocols). You just start sending stereoscopic images to your display system: In D3D: https://docs.microsoft.com/en-us/windows/desktop/direct3ddxgi/stereo-rendering-stereo-status-notifying In GL: https://www.nvidia.com/content/GTC-2010/pdfs/2010_GTC2010.pdf Or you can talk to your GPU drivers directly, e.g. https://docs.nvidia.com/gameworks/content/gameworkslibrary/coresdk/nvapi/group__stereoapi.html
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!