Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

  • Days Won


Ravyne last won the day on April 22

Ravyne had the most liked content!

Community Reputation

14305 Excellent

About Ravyne

  • Rank

Personal Information

  • Interests

Recent Profile Visitors

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

  1. Ravyne

    Large Tilemap Storage

    There are different ways to store it, but in a 3D array, the extra dimension would be the map sections. If you have a large map, and you cut that up into, say, 64x64 tile squares (which is your first two dimensions), then you can think of the 3rd dimension as if you picked up all those sections stacked them up, each section has a place in that stack, which is your third dimension. Up to this point, you just have all the sections themselves defined, but not how each section makes up the larger map. What you need is a way of relating those sections in the larger 2D space of the map. One way is another 2D map -- think of it like a tilemap within a tilemap, only the outer tilemap contains map sections. When you draw, the sections might be 1024 pixels apart, and tiles might be 16 pixels apart. You'd find which few sections are on screen, where their corner is, and draw the tiles within it relative to it's corner, then you move over 1024 pixels where the next section is, and then draw it's tiles. Your drawing loop is now nested four levels deep, rather than two. You can have a single 4D array, or a 2D array (the section map) and many smaller 2D arrays (the section tilemaps) -- and you might collect the section tilemaps together as a single (now 3D) array, or not. Now, really, if you want to think about streaming a very large map, is that you don't have to have all the sections in memory. Just the ones that are on-screen and a few nearby so that the player never sees them loading. In that arrangement, you'd not have a 4D array, or even a 3D array of map segments. You'd have a 2D array that's the map of sections, and each of those would be a pointer (or reference) to the small tilemap for that section. You load only the tilemaps for sections nearby, on demand, and you can free the tilemaps of far away sections as needed. If that's not clear, feel free to ask again. But do keep in mind that all this complication might be unnecessary. This streaming sort of set up really only benefits you if tilemap memory use is high, or if loading the entire large map all at once is noticably slow.
  2. Ravyne

    Large Tilemap Storage

    A 2D array is usually more than sufficient for 2D map storage and iterating through it. As long as you're not falling into any performance anti-patterns (e.g. drawing the entire map instead of just the screen, not walking the layers/cols/rows in memory-order, failing to batch draw calls, etc.) Draw efficiently, iteration is not going to be your bottleneck. Back in the day we were drawing 320x240 screens with ~450 tiles (1 dense layer + 2 sparse layers) using software blitters at 60fps on 66mhz 486s, albeit at 8-bit color. What's often more useful is chunking the whole map into regular sections, either so that you can stream them from disk or just to keep memory use down if it's a concern on your platform -- but that approach ultimately only amounts to a 2D array of map sections, which themselves are 2D arrays of tiles. Even something like a quad-tree is likely over-thinking a 2D game. There's an article floating around about optimizing minecraft-like cube storage, where they looked at various more-complicated storage schemes like RLE arrays and compressed octrees -- the conclusion was that plain old 3D arrays were the winner anyway, and I think Minecraft world sections are (or were) something like 32x32x256. Drawing performance comes from how they generate and optimize draw calls from this simple storage, not coming up with any sort of clever storage.
  3. I--and most people, I think--view GDDs as a living document that's anything but sacrosanct; they're not meant to set things in stone and then be followed verbatim, or for what's written in them to go forever unchallenged and unchanged. I think the answer to what should be recorded is to record what seems important, when it's important, to the level of detail that's necessary to keep the team operating together -- not what's inconsequential, not sooner, and not in more detail than is useful and--more importantly--can be clearly seem. Over-planning carries risks just like underplanning -- working in perfect lock-step towards the wrong goal can waste just as much time, energy, and morale as working haphazardly at unclear ones. Resist the urge to codify your speculations as anything but that -- "We don't know the answer yet, but we think this is an important question." Is a perfectly fine thing to write down, and in fact far better than pretending to know.
  4. Ravyne

    Compile time "polymorphism"

    It's a useful trick to use template specialization to unify the identifiers so that you can hand unrelated types to another template. It's especially useful when you don't control the types yourself, or can't change the types to unify the names directly. If you do own the types and have the freedom to alter the signatures, it's usually better to do it directly. The C++ STL does that, more or less. Strings are a distinct type, but they're also a container in a sense like std::vector -- you can use them with std::algorithms, for instance. Surprisingly few people seem to know that.
  5. Ravyne

    C++ Magazine

    Dobbs' print run ended in 2009, but the articles are available on the website. IIRC, I believe I stumbled upon a zip file of the entire archive once, but I might be confusing it with something else. I'm not aware of any print magazines for C++ specifically, the few print magazines that are around are broader or have a specific industry focus. isocpp.org is a pretty good aggregator for C++ goings-on, though.
  6. They're 64 bit CPUs, though some of the least expensive devices might only have 2GB of non-upgradable RAM and come with a 32-bit OS (Microsoft basically gives Windows away for some kinds of low-spec devices). Performance-wise, you-re looking at a CPU core that's probably less than half the speed of an i-series CPU between lower clocks and IPC, probably doesn't support AVX, and has a lot less cache. You're looking at single-channel memory. You're looking at an integrated GPU that's only 12 or 18 shader lanes wide (compared to 24, 48, or 72 on the i-series) that are clocked about half as fast, have no EDRAM, and have to share that single memory channel with running programs. It might work for you, but it's not going to be a premium -- maybe not even comfortable -- experience. You might be better off saving for a lower-end, non-atom machine -- even one that's last-years model or a gently-used/refurbished machine might be a better value if cost is a factor.
  7. Keep in mind that a big part of the reason that C++ can seem old-hat is that the majority of resources are pre-C++11 -- there's just a lot of material, resources, and code out there that reflects an earlier state of the language. Things are getting much better though, and if you know where to look, you can find current-day and even forward-looking resources. C++14 made significant strides in language ergonomics, and C++17 and surrounding technical specifications are bringing some long-overdue libraries into the standard ecosystem. I do like Rust a lot as well. I've been meaning to play with it more myself. It's got possibly the most amazing community, especially considering its modest size. The tooling is great, the error messages are awesome, there's really a lot to like. The challenge with Rust, I think, is that it demands quite a lot from people as they approach it -- more understanding and possibly more patience than a lot of other languages.
  8. Ravyne

    Display resolution matters?

    You can do some low-level bit-fiddling/shift-arithmetic more readily if your width* is a power of two -- it doesn't matter so much what your height is. Whether you gain a measurable advantage can depend on other things. For example, if you don't have a proper display controller or useful DMA and you're blasting pixels to the display in real-time, then your CPU probably doesn't have enough downtime to do what we'd think of as traditional software rasterization--the hard-real-time constraint becomes the limiting factor, along with any memory/device access latencies in the pixel-loop. It can also be hard to make blanket statements about embedded devices. Some displays might have embedded buffers, some might have serial addressing, some might have planar video memory, some might have a line-stride that's different than the number of pixels wide it is, or you might be attempting to use an 8-bit microcontroller with a display that's wider than 256 pixels, or the display wants 9-bit color, or... You get the idea. In general, powers of two are nice in some modestly useful ways, but opportunity and meaningful ability to leverage those nice things are pretty situational. For a computer a power-of-two number is kind of like a prime or square number is for a mathematician--its an ordinary number with an extra property that might sometimes give way to a helpful observation or shortcut, but more often than not, doesn't. If the inner kernel of what you're doing can exploit one such trick well you can see considerable speedups, or none at all.
  9. Ravyne

    Simplicity vs. Complexity

    Complexity is sometimes necessary to achieve a design, it's unnecessary complexity that's to be avoided. Complexity always carries a kind of psychic weight to it, and if that weight is greater than the payoff, then it's a net negative. You could say that good design trends towards being another facet of the "make it as simple as possible, but no simpler" axiom.
  10. Ravyne

    Also getting the PS4 pro? what to expect

    [quote name="dpadam450" post="5318603" timestamp="1478573756" Yea its not upscaled 1080p. I work on Killing Floor 2 and its 3200x1800 effectively. So its not native 1800p but it looks pretty freaking good for a 400 complete system. I spent 400 on my 1070 alone to do full 4k native, so for console gamers, it is pretty legit. Also, buy Killing Floor 2 please.[/quote] 1080p upscaled on original PS4 is what I said, but yes 4K looks pretty great regardless of checkerboard or upscaling something like 3200x1800.
  11. Ravyne

    getting a new PC for DX development

    I think 6-8 cores will be the norm for gaming builds in 2-4 years -- they're already possible, and not even hideously unaffordable now, and it looks to be shaping up that Zen performs on par to at least Haswell (pessimistically) and more likely to Broadwell/Skylake on a core-for-core, clock-for-clock basis. Assuming AMD delivers on clock-speed (We've already seen 3.0 Ghz demoed on an engineering sample, which would be a bit low, but no telling if they're just holding back) its looking quite likely that they're prepared to deliver competitive 8-core CPUs and will all but certainly take their usual tactic of undercutting Intel, who'll respond by restructuring their current price-sheets immediately, and likely by moving 6 and 8 core designs down to more mainstream segments ASAP. This will happen unless AMD fails to deliver a compelling value, but even if clockspeeds disappoint it only takes the right price to make those 8-core Zens appealing, given the baseline IPC we have evidence for.   If we were a few months further along, I'd have recommended to wait and see what Zen delivers, but at some point you just have to stop looking over the horizon or you'll never buy a computer again.
  12. Ravyne

    Also getting the PS4 pro? what to expect

    IIRC, Sony is mandating that all games continue to support the original PS4, and essentially mandating that all new games support the Pro's extended capabilities in some way, for most games that will mean 1080p upscaled approaching 60fps for original and 4k upscaled approaching 60fps for extra crispy Pro, at minimum, with many games probably also provide a setting for true 1080p at a solid 60 FPS with higher fidelity on the Pro hardware as well -- a lot of the market doesn't have 4K yet so that power might as well be put to good use.   For me, with my very nice, very low-latency 1080p television I'm looking forward to the PS4 Pro and Xbox Scorpio giving me a really good 1080p experience and that's worth the cost of upgrading. Neither machine is really capable of 4K/60 without rendering tricks anyhow, it'll be another proper generation before that happens. 
  13. Ravyne

    getting a new PC for DX development

    On threading, most modern games typically expect about 6 threads on 6 modestly-speedy cores, or to 4 or 8 threads on 4 significantly-speedy cores. The current crop of consoles is the former, with the console giving developers about 6 or 7 full cores out of the 8 in the machine -- these are Jaguar architecture in both Microsoft and Sony's boxes, and run at around 1.6Ghz (2.1Ghz in the PS4 Pro). A modern gaming PC typically has 4 cores and 4 or 8 threads, with much higher clock-rates and better IPC in general.   That being said, modern games typically employ some sort of job-queue to leverage all those resources, and don't really lock particular workload-threads to particular cores, aside from maybe a few well-known, long-lived ones -- e.g. rendering, UI/input, networking, might be statically-allocated threads. Most times what they do is structure some piece of work as an independent unit (say, computing collisions for a particular body) and stick it into a priority que where a job-manager with find it and assign it to an available thread -- the main thread of the engine gets the result asynchronously at a later time, going about its business (usually, making more jobs) until results are in. This scales really well in general, but was a really crucial abstraction during the PS3/Xbox 360 generation where the architectures were so different (3c/6t extended AVX + GPU compute on 360, 1c/2t + 7 DSP (Cell) on PS3).
  14. Ravyne

    Changes to GDNet+ and More

    These seem like great tiers to me, and the included add impressions make it a steal if you're going to use them. The yearly prices are quite fair regardless, and the ad-lite/ad-free stand-alone subs are nice for people who want to support the site directly but wouldn't use the Pro features -- Maybe they too should get some other forum badge in recognition of that.   Speaking of badges -- will crossbones go away entirely, or just no longer confer the benefits of the old Plus membership? I'd be cool to keep it around just as a marker of people who make regular contributions in the form of articles, journals or making significant reputation gains during some window of time.
  15. Ravyne

    getting a new PC for DX development

    When I moved from quadcore (8 thread) to hexcore (12 thread) i7s, my build times improved completely linearly. For day to day productivity as a professional developer, the difference was absolutely worth the two hundred bucks or so it cost to go to hexcore and X99. The Ks have allowed me, more than once, to hit target framerates when running demos of our work that had not reached proper optimization stages. It's up to you whether these things matter for a personal machine, but it would be absurd to cut these corners in a professional environment.       I do NOT recommend going to SLI/Crossfire configurations except in extreme configurations requiring multiple top of the line GPUs. They are much more trouble than they're worth.     On X99/Hexacore, also consider Xeon v4 -- most of the x99 motherboards are compatible (but check your manufacturer's page and note the BIOS version required), and there are a couple benefits -- ECC, support for server/workstation/enterprise features, and a full compliment of 40 PCIe lanes all the way down the range (even the quad-cores), and you give up 200Mhz on the base clockspeed (comparing Broadwell i7 hexacore vs same-priced Broadwell Xeon v4 hexacore) but *gain* 200Mhz on boost clocks -- which is probably a more beneficial arrangement. You're looking at a ~620 USD processor in any case, but if money is tight you can go quad-core Xeon v4 for under 300 USD and get all those benefits I mentioned for about the same price as a consumer i7 -- you give up some clockspeed (~400Mhz), but gain quad-channel memory and a couple megs of cache against the consumer part.   This strategy of x99/socket 2011 has another potential side-benefit, which is that in 3 years or so a *ton* of server equipment is going to start going off-lease and being retired, and you'll be able to pick up a high core-count Xeon (and probably tons of RAM) for relatively cheap and maybe extend the life of the machine another few years. There's 8-core, 2.6Ghz dual-socket-capable Xeon V2s going for about $65 each right now all over Ebay. People are using these to build out 16-core, dual-socket machines with 64GB ECC for ~600 USD, lots of YouTuber's are using them to do their video capture, rendering, and transcoding. I considered building one myself, but my workloads don't really scale out that wide.     On video cards, definitely prefer a faster single card -- AMD actually does a really good job scaling traditional Crossfire workloads, but the future of traditional SLI/Crossfire is a bit murky since both D3D12 and Vulkan move that functionality out of the driver and put it into the hands of Devs to figure out. Don't feel like you have to chase the top-end though -- the diminished returns are really pronounced. Think about what resolution and settings you want to play with, and then chose a card that can deliver 60FPS under those conditions. 1060s and 480s are good to about 2560x1600 or (stretching a bit) 3440x1440 ultrawide -- though I'd probably go 1070 for 3440x1440 -- If you wanted to go all the way to 4k, only the newest Titan/1080ti really hits 60FPS consistently, the vanilla 1080 falls just short unless you start dropping settings a bit back.   As a developer, I'd only go multi-GPU in my system if I planned to support it, but you really should make sure you test for it if you're using D3D11 or OpenGL that provides it in the driver in any case. Also keep in mind that the new APIs allow you to mix GPUs of different capabilities and vendors now -- For example, you could have the integrated GPU do simple tasks like rendering the skybox, UI, and running full-screen effect shaders; it doesn't sound like much, but these low-utilization tasks can sometimes stall the next frame on a single GPU (or at least, occupy GPU hardware while not utilizing it as much as game rendering would) -- done well, end result is picking up a handful of frames/second, with generally-better frame-rate consistency.
  • 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!