Jump to content
  • Advertisement

pcmaster

Member
  • Content Count

    372
  • Joined

  • Last visited

  • Days Won

    2

pcmaster last won the day on October 9

pcmaster had the most liked content!

Community Reputation

1109 Excellent

5 Followers

About pcmaster

  • Rank
    Member

Personal Information

  • Role
    Programmer
  • Interests
    Business
    Education
    Production
    Programming

Recent Profile Visitors

10001 profile views
  1. pcmaster

    Bare bones AAA team

    The way I see it is that even if you have one development team preparing all the tech, pipelines and workflows and then you suddenly start your other team, the A(AA)-team which you're talking about, to make you a game in 2 years, you'll still have to have that first team upgrading the tech, pipelines and workflows in the meantime for the next game. And 10 people will suffice neither of the two teams and also they'll never work well in separation.
  2. pcmaster

    Bare bones AAA team

    Those off-the-shelf 'CGI assets' might not perform well enough and you might not be able to have as many of them (on screen) as you'd like for your specific game You're still implying that everything's ready. It never is, things evolve and what worked 5 years ago isn't often enough today. Your team will have to constantly accommodate for that continuous change. That requires people and time. Even if you throw really a lot of money into it (buy a lot of 3rd party/outsourced solutions and assets), you might need a surprising number of your own people integrating it. I'm not sure if I'm making much sense or just sound too pessimistic, I just see how much man-time things seem to take in a AAA studio...
  3. pcmaster

    Bare bones AAA team

    Don't forget about editor software, content production pipelines. Even if you use an existing 'engine' which supports dragging 'standard' assets 'into the editor' somehow, for an 'AAA' game you'll find yourself in need of building very custom data pipelines. That involves some more engineers, tech artists, and a lot of time, plus a crystal ball so they design and implement it in such a way that ART rework will be minimised. You can't avoid custom technology for a big, original game. Also don't forget about platforms. Even if your 3rd party 'engine' claims to support all the various consoles and whatnot, chances are you'll still need your own engineers doing a lot of platform-specific work and fixes. I don't think it's even remotely possible to create what we all very vaguely understand as an AAA game with 10 people in full-time developer roles in 2 years from scratch. For a second game of the same genre, almost unchanged technology, and well established pipelines, it'd still say that 10 people and 2 years won't cut it, still an order of magnitude below reality.
  4. Why not simply try out? That i7 (Acer) will be immensely faster than Core2 Duo, which is good for compilation. Also the RAM is bigger.
  5. Hi all, is it only me? I can't even copy out the text of your sources correctly in Windows 7 Firefox x64 into Notepad++. E.g. when I copy m_Effect.CurrentTechnique = m_Effect.Techniques["Textured"]; I actually get some weird characters, especially the "r" in "Textured" isn't ASCII 0x72 but the bytes 0x EF BB BF 72 instead, which looks like the UTF-8 BOM. Similarly for the "d" in the same word. Furthermore, when I hit "Ctrl+F" and try to find all occurrences of "Textured" in this website, it doesn't find the one in the C++ code nor in the HLSL. Anyway, do the other calls work correctly, if you comment out the query for TerrainTypeSampler, for example this one works fine? m_Effect.Parameters["GrassSampler"].SetValue(m_Grass); My I suggest you save your all your sources are plain ASCII (not UTF-8) and try to recompile and re-run? EDIT: Copying stopped yielding weird characters after refreshing the web, also my Firefox is fine again, WTF have I just experienced?
  6. Interestingly enough, I haven't found any proof that ID3D12CommandQueue be thread-safe, so I wouldn't count on it (links, anyone?). Put a mutex around it and you're safe - you won't submit that many command lists during a frame for this to block you (that goes for everything I wrote -- if it's only a few dozen a frame, fǜck it and use a mutex; if it's thousands, go lock-less). Optimise only after measuring. Don't optimise where you can't gain almost anything. Also it makes sense only if you don't care about their order. If they depend one on another and form a directed tree graph, you'll have to order them yourself, but you're surely aware. I didn't know you wouldn't call your Initialize every frame. If it's only at the app start, cool
  7. Maybe I'm combining too many things, if still unclear, we can break it down a bit.
  8. Think about it - nicely looping over a few hundred little pointers every frame on the CPU... that's NOTHING compared to synchronising with the GPU. Once a fence after a frame is passed, each and every resource the GPU touched can be recycled safely. Obviously. In the meantime, record commands into an alternate set of buffers and with different resources (ping-pong, double-buffer, round-robin, ...) as discussed, the pseudo-code you posted is fine. You could have a pool of upload buffers. The thread asks the pool and gets a fresh and safe resource to work with. It gets 'marked' with the current frame counter when handed to the caller. Once its frame's fence signal has been seen some time in the future, all resources with that frame's counter (or older) are good to be reused. You don't even have to "return" them back to the pool. The only time the pool would BLOCK the caller is if it ran out of resources - but that should never happen if you inflate it enough. You won't need to iterate anything if you think about it. The pool is more a ring-buffer, really. The same mechanism can be used for constant buffers if you assemble them somehow dynamically.
  9. Does the upload buffer need to be released ASAP? Short on memory? Why not in 1-2 frames with everything else from the past frame(s)? Less sync, better life, do yourself the favour :)
  10. Why would a SubSystem want to wait for a command list? I smell you're going to read something back immediately? :)
  11. Simply don't make yourself synchronise the CPU threads with the GPU at all! Only the one 'main' thread. Instead, as mentioned by MJP, double-(or triple-)buffer your command lists (and allocators). It isn't such a terrible amount of memory that you'd have to "ration" it. Your subsystems will assume that the resources they are handed are safe to CPU-write and GPU isn't touching them. Also, do NOT use the same command allocator (or any allocator for that matter) on two different threads. Recording commands is a pretty 'intense' operation and if several threads do it at once, they compete for the mutex (or at least an atomic) that's making the allocator thread-safe. Just don't do it. Hand each thread its own allocator (from a pool or double-buffer at least). [OT]If you really need one allocator to serve multiple threads, then for your own hand-written allocators, don't enter the critical section every time for every tiny allocation - give threads only bigger chunks which they'll be using for some time and only occasionally contend for the 'mutex' when their chunk is depleted. Heh, now that I read what I wrote, you still end up with a kinda allocator per-thread anyway ID3D12CommandAllocator isn't your hand-written allocator though, it will have a mutex inside. I reckon it's thread-unfriendly. [/OT]
  12. Yours looks flipped on the Y axis (but not on X). Posting source might help :)
  13. Spidi, an independent European developer, provided deep insights into the struggles and decisions he encountered while making his little cute and awesome game. I appreciate the breakdown of his marketing efforts, especially if you don't know anything about marketing games nowadays (as I don't). Although I don't play rouge-like, "I Am Overburdened" caught my eye and I congratulate Spidi for its release. Thank you for writing this inspiring blog-post, it'll surely help small indies!
  • 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!