Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

4 Neutral

About ROGRat

  • Rank

Personal Information

  • Interests

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. ROGRat

    10hz Smoothness

    Thanks for your comments, guys. Much appreciated! 🙂 I just realized that the video I uploaded was of the debug build, so it's choppier than it could have been. Never mind, so long as people get the idea. This is something I should have done years ago. I'm really impressed with the playoff for the small amount of time invested. It's not that I ever doubted it or thought that somehow my own hacks would be better, not at all. I just get distracted with a squillion other things. It's no surprise that the Gaffer implementation is nearly the de facto standard for game loops and if there was an established repertoire of programming patterns for game authorship, I'd reckon it'd be right up there. It's hard to fault and the frame rate gain is nothing to shrug at. After going through the paces of adding a Gafferesque core loop and states, I can see why people either have difficulty putting it in their code or come away unsure as to whether they've done it correctly. Wrapping the whole shebang in a state structure makes for easier repeat visits. I cheated a bit and used the structures and methods in the System.Numerics namespace which are conveniently SIMD/SSE enabled. I've no doubt there are others, but I'm thinking of writing a top-down guide with all the nitty gritty details. Speaking of which -- what's going on with the variable t I have seen in some bare-bone use-cases? :-)
  2. ROGRat

    10hz Smoothness

    The old fixed timestep paradigm. Juicy stuff, and arguably the backbone of many a great gaming title Until recently, I'd not bothered to implement it, instead preferring my own questionable potpourri of odds and ends, with maybe a little vertical blanking here and there. I checked out DeWitter's game loop many moons ago but, in spite of it's virtues, it wasn't what I needed at the time. After being asked by a work-colleage-turned-indy-gamedev guy for a rundown on how it worked, what the point of it is and 'what the hell is this interpolation business?', I cobbled together a little demo. In this video, everything is updated at a fixed timestep (60hz) however, only the colored bar is rendered with interpolated state. At about the halfway mark, after throwing some white boxes onto the screen, I switch down to a 10hz update rate (after a brief pause). Thanks to interpolation,, the colored bar retains most of it's smooth movement, even at `10hz. The white boxes, with all their physics goodness, don't fare well at 10hz without interpolation. I haven't implemented it there because I'm honestly not sure how.. https://www.youtube.com/watch?v=6SptavKHwew&feature=youtu.be
  3. ROGRat


    Blizzard lost their way a few years ago. World of Warcraft has lost most of its appeal and although Diablo 3 was fun for a short while, it’s a huge departure from the near perfection that was Diablo 2. If Blizzard want to retain their existing customer base and see continued growth, all the need to do is go back to their roots. What they’re doing in this day and age just doesn’t work.
  4. It’s not pointless at all. Assigning your main thread to a single core, just to sidestep threading, is not just a code smell, it’s a train wreck. If another process comes along and does the same thing, and uses more CPU time than your application can tolerate, it will either perform poorly or stop responding entirely. Until that other process starts behaving. If ever. If the same thing happened with my implementation, even if two processes came along and specifically targeted the core my main thread was running on and the core my timer was running on, not only would my application continue to run (since it’s free to be scheduled on another, less utilised, core) but my timer almost certainly would too. :+D
  5. I wish it was a problem that was confined to a handful of old processors that you rarely see in the wild anymore. On some systems the problem is in the BIOS and keep in mind that the vast majority of users never update their BIOS. The problem is made worse by the fact that most mainboard and system vendors do not provide an automated update path for it. Implementing a timer using the method I suggested (on Windows) not only ensures an accurate timer across a broad range of systems, it also minimises scalability problems down the track. If your application/game has multiple threads on multiple cores and needs to call QueryPerformance from those threads, the resulting performance hit from doing so compared to calling it from a single dedicated thread is too high to ignore. The so-called cost and complexity of threads, aside from being negligible in this context, is something that needs to be confronted and accepted in the era of many-core processors. In this case, the small investment of time and effort goes a long way. 🙂 Edit/Note: For C#/.Net Framework, call Stopwatch.GetTimestamp. It calls QueryPerformanceCounter internally. Do NOT use DateTime.Now or Environment.TickCount.
  6. On Windows, you should create a timer using QueryPerformanceCounter on a separate thread (not a worker thread) and lock that threads affinity to one processor core (NumberOfCores- 1 is a good choice, but using the same core as the games main thread is fine also). If the timer thread is allowed to transition between cores, QueryPerformanceCounter will return imprecise values on some systems.
  7. ROGRat

    What are the principles of game design?

    Goals are usually accompanied by Reward, something that provides incentive for working toward said goal. That little dopamine hit that we’ve all gone scrambling for!
  8. ROGRat

    (Updated) Struggling With Remembering What I've Learned.

    You’re definitely not alone. I can relate, and I know that there are plenty of others here that can relate too. The fact that you’re still working away at it and haven’t given up in despair shows that you’re making good progress. I’ve never understood how some people can commit all of the gory details to memory but I guess it comes down to how often you work at it. I’ve never had much luck getting things to “stick”, and because of that, I have tonnes of documentation. Every time I master a new concept or solve a problem I’m working on, I stop and document the heck out of it. At first it seemed a bit pointless, but after a while I no longer worried about whether I could remember how to do a certain esoteric thing...chances are I’ve docuented it. Maybe. .NET framework languages are great for this because you can (and should) document your code as you go along. If you get frustrated with something you’re working on, try not to throw the whole thing away. Keep whatever code you can because it’ll help you remember when you suddenly try to do it again, out of the blue, six months from now 🙂 Regardless of which route you take, there are loads of very knowledgeable folk here that will gladly help out if you get stuck.
  9. The WaitableObject can be used in fuscreen “windowed mode” (borderless window covering the whole screen). You also need to call SwapChain.SetMaximumFrameLatency(1) when using the WaitableObject.
  10. I apologise for not reading your OP carefully before replying. Am I right in assuming that your test system is a laptop like the one you described? Some of these laptops will default to the Intel adapter unless otherwise specified in the nVidia driver options, or by starting the application by choosing the adapter at runtime using the context menu option which is available by right clicking the applications icon. To complicate matters further, some newer laptops can only use either the nVidia or the Intel adapter, and switching between them requires a manufacturer-supplied utility followed by a reboot. If you’re writing code that you plan to run on systems other than your own, this is worth keeping in mind. I’m not sure why you’re experiencing a crash in release mode, as your code appears sound. I suggest creating a debug Device (you will need Windows SDK installed). Programmatically, DXGI allows you to query each adapters capabilities to help you decide which one you want to use. Switching to full screen mode is a little more involved than calling SetFullscreenState. Are you calling ResizeTarget/ResizeBuffers as needed?
  11. Unity sounds Iike overkill for what you’re doing. SharpDX is the way to go and Direct2D is very easy to get going and is ideal for what you’re looking at doing. Performance is surprisingly good under ANY .NET language.
  12. Are you enumerating the SharpDX.DXGI.Output objects connected to each DXGI.Adaptor? If you want to render on an Output which is not considered your “Primary Display” by Windows, your application will need to create its main window at the co-orxinates which translate to that Output. Otherwise, it will just be created on your Primary Display and will render using the default Adaptor.
  13. ROGRat

    Direct2D for 2D games

    I’ve implemented a complete engine using DXGI (for access to a SwapChain and Output devices) and Direct2D. If used properly it’s very fast and is easy to work with. Of particular interest to game developers is the SpriteBatch class, which can punch out thousands of sprites, with transforms and effects, per frame on modest hardware
  • 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!