Jump to content
  • Advertisement

AgentC

Member
  • Content Count

    382
  • Joined

  • Last visited

Community Reputation

2475 Excellent

About AgentC

  • Rank
    Member

Personal Information

Social

  • Github
    cadaver

Recent Profile Visitors

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

  1. AgentC

    What are you working on?

    I've got my next Commodore 64 hobby project, MW ULTRA, in the pipeline. It's actually a reboot of my first C64 game from about 20 years ago. Back then it was a simplistic platformer / shooter, now the plan is to integrate shooting, close combat and stealth mechanics while still keeping it a sidescroller. There should also be a story of conspiracy & intrigue. Here's a work-in-progress video from a few months back with placeholder background & enemy graphics, where hiding behind cover, performing a surprise takedown, and alerting enemy with noise is being tested:
  2. I remember some similar troubles in my toy engine, which does raw Win32 API calls without relying on SDL or such. On window activation (WM_ACTIVATE message), I manually restore the window if it was minimized before, by calling ShowWindow() with SW_RESTORE argument. Also, in case it's supposed to be fullscreen, I change to fullscreen mode again with ChangeDisplaySettings(). In practice, I don't rely on Direct3D11 to do any magic on my behalf, so the window code would be exactly the same on OpenGL, though I've made the window association to the swapchain. You can check the relevant code here: https://github.com/cadaver/turso3d/blob/master/Turso3D/Window/Win32/Win32Window.cpp https://github.com/cadaver/turso3d/blob/master/Turso3D/Graphics/D3D11/D3D11Graphics.cpp
  3. AgentC

    Urho3D Graphics abstraction

    I'm no longer actively involved in the development of this library, but thought I'd chime in.. When a rendertarget is set such that it's still also being bound as a SRV, what should happen is that the runtime cleans up the still bound SRV, and if you have the debug device flag enabled, you see this as output log spam. (D3D11 WARNING: ID3D11DeviceContext::OMSetRenderTargets[AndUnorderedAccessViews]: Forcing VS shader resource slot 0 to NULL) That's why the D3D11 Graphics::PrepareDraw() in Urho3D sets rendertargets first, then textures. The situation also easily happens also in Urho3D's own rendering, when pingponged postprocesses are involved. In case you see an actual rendering bug resulting from this (ie. black screen) please raise it in Urho3D's issue tracker.
  4. AgentC

    What are you working on?

    So many excellent looking projects here! Here's mine: day job - programmer at a medium-small North Finland game studio, mostly HTML5 and Unity projects these days. Current active hobby project - Steel Ranger, a Turrican / Metroid inspired scifi action-adventure for the Commodore 64. Now at the point of designing the game world layout, with an aim to get about 500 screens total. The basic game engine, player movement, player weapons and world tilesets are already done. I also maintain a mostly technical and sparsely updated development diary for it.
  5. Since the topic is so complex, I'll just put some very high-level notes while not even trying to formulate a complete answer to the actual question.   1) For cache-friendliness, try to ensure each operation's required memory is in a continuous memory region, and preferably accessed linearly from start to end. For example updating a particle system or an animated skeleton. Avoid "jumping" from heap object to another through pointers. A well-structured entity-component system is possibly a good match here, at least if the systems don't need accessing each other's data a lot.   2) A typical approach nowadays is to structure the execution of a frame into a task graph, and the tasks are executed on any available cores by worker threads. Data from each task or operation flows to the next, for example physics simulation & animation together produce the final positions of game objects, which go to culling, from which a visible object list goes to render command generation, which is finally submitted to the graphics API. When the culling / render stage for the current frame is running, you can already be calculating the logic for the next frame.   For both points 1 & 2 it's probably best to keep scripting for low-volume, high-level operations (e.g. ask pathfinding to start moving this object toward position x) or configuration (stats of game objects, list of render passes and postprocess effects for the actual rendering code). For such infrequent use even a singlethreaded script VM could be fine.   Here's Naughty Dog talking about their engine's multithreading & memory allocation: http://www.gdcvault.com/play/1022186/Parallelizing-the-Naughty-Dog-Engine   Also old Bitsquid development blog entries may be interesting reading: http://bitsquid.blogspot.com/
  6. To take the window creation and management as an example, SDL implements it separately (using the relevant OS-level API's) for each OS / platform it supports. Same for e.g. audio, joystick etc.
  7. Consider also debugger support. If you program game logic directly in native C / C++, you can debug using your compiler's tools. With a scripting system, you'll have to implement debugging yourself if you want the same level of access. The script VM may help in this by providing hooks for breakpoints, single-stepping etc.   Though, once you have script debugging in place, you can go above and beyond of what gdb or Visual Studio could provide by tying it into your game engine systems (e.g. editing the game object properties while the game is running, selectively suspending or restarting specific scripts..)
  8. hypester nails a lot of points I was thinking of as well. Though the popular YA series still do include physical combat, so I wouldn't see a reason to exclude it entirely. The production cost of choices and branching storylines vs. the expected sales could be a big hurdle, until there's some major evolutionary step in storytelling technology   If a game is heavily focused on interpersonal relationships, and these tie into the game mechanics, they could become somewhat cheapened once players manage to dig up the formulas used to guide the story / relationships (compare to the Mass Effect 2 Suicide Mission flowchart). Though that's just my gut feeling.  
  9. It's possible it's not documented strongly enough that it's a helper only. And it's also extensively used by all the included samples :)   But anyway, there's the Engine class that does that actual work (and which is simply instantiated by Application, which you could also do yourself.) Even that isn't strictly mandatory, if you know what you're doing you can instantiate only the subsystems you need, but then we're deep in "advanced use" territory.
  10. Just a minor Urho-related correction: the Application class is an optional helper, not the "core of the engine". The most useful thing it does, for simple applications which don't need more sophisticated control, is to abstract away how the platform wants the main loop to be run, which differs on iOS and Emscripten ("run one frame when requested" instead of "run in a loop forever until exited"), but you're not forced to use it.
  11. AgentC

    Game Engine Modules/Projects

    Strictly speaking you can also live dangerously and take the approach that the engine DLL and the game simply need to be compiled with the same C++ compiler, and therefore allow working through C++ ABI directly instead of making a proper C API (C4 engine, and some graphics libraries like Ogre work this way.)   But I agree that dynamic libraries are a complication and the OP likely doesn't need them right now.
  12. AgentC

    Modern OpenGL Transforms, HOW?

    AAA engines don't necessarily use the most modern strategies out there, but just something that works well enough for the target platform(s) + the game they're running.   Typically the most amount of geometry comes from static world geometry, which can be batched together (offline, not runtime) into bigger chunks to reduce draw calls.   Something like trees and foliage would just be rendered instanced. When far away, sprite impostors can be used for even lower performance impact.   One particle effect with all its particles is usually one draw call, and its vertex buffer is typically completely rewritten each frame when it's visible and updating. Most of the math can be done in vertex shader so that the CPU-side calculations for the update stay light.   On modern desktops you can get quite high with the draw call count (a few thousand should be no problem) but on high resolutions and less beefy GPU's the shading would easily become the bottleneck instead.   One thing to consider is that AAA games on Windows usually use D3D, which can have better optimized drivers. If you have bad luck with OpenGL drivers (Intel?) and an older card the driver may be doing work on CPU which should really be done on GPU. Using VBO's and a good driver, over a thousand draw calls should not be a problem on either D3D or OpenGL.  
  13. That clears it up.   You can get quite nice results with assuming a very low version like GL1.1 and checking for extensions, with the downside that the more extensions you use, your code can become quite complex and ugly from the supported / not supported codepaths, and you'll be using functionality which is deprecated from the point of view of newer GL (3.0+) versions, so you may learn bad habits.   The old GPUs (except historically Nvidia) can come with poor GL drivers, so you may encounter bugs where the driver tells you that some extension is supported, then you go ahead and use it, and crash. Though if you mostly just render textured triangles to the backbuffer, maybe using (simple) shaders, there's not much extensions needed and not much that can go wrong.   The Second Life open source client code (LGPL) can be quite illuminating in how they only require a low OpenGL base version and then check for supported features to enable e.g. VBOs (if no VBO support, they use vertex arrays instead) and GLSL shaders. There's also quite some driver bug workarounds in there. Or at least it used to be like that, haven't checked in a few years to see if they rewrote everything to be more modern :)
  14. Is the program actually required to run on machines with very old GPU and drivers that only support GL1.x, no shaders etc. or is it just that you want to supply a legacy OpenGL style API for users of the program?
  15. Will echo what many have already said.   The engine runtime is the fun part, and also mostly easy, unless you go for challenging state-of-the-art tech, or try to maximize performance. Creating the scene management, rendering and lighting, physics integration, possible multithreading etc. This can still take a lot of time (easily a man-year) depending on your expertise and how much features you're going to add.   After you've got the runtime done, the rest is to make the system usable for actual game creation. Up to this point you probably haven't needed to make any concrete decisions on how the game projects made with the engine are structured, how assets are imported and cooked into a build, how the game logic or rules are inserted and how they interact with the runtime, how the world data is represented for processes like precalculated lighting or navigation data creation, and how to make all the workflows usable for the creators. Now you're going to have to make a lot of decisions which influence what kind of games you can make with the system, and how usable it turns out in the end.   It helps if you can handle 3D modelling yourself so you can continuously test from a content creator's point. In reality working on the runtime & tools / workflow will very likely intertwine, I just separated them to illustrate the difference.   You can also decide to limit yourself to just creating a coder-oriented runtime library (compare e.g. to Cocos2D or Ogre), rather than a full-blown game engine (like Unity). It will still be a worthwhile learning experience, but probably not something that's directly useful as a game creation tool. Getting to the full-blown stage will certainly take man-years.
  • 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!