Archive for category XNA
This’ll be fun post to write: I’ll outline the things that are ready for the alpha release (ie. bragging), and then I’ll start talking about what needs to be fixed, and then go on to where we’re heading after that. And then… well, we’re now officially in testing-and-bug-fixing mode for the alpha, so I guess it’s time to announce the release date. Ahem.
Where we’re at.
Species 0.4.0 is a functional and apparently stable evolution-from-first-principles simulator. It’s possible to spot natural selection in action with the Species Average statistics, and I’ve seen things like convergent evolution (creatures consistently become more amorous, for example) and punctuated equilibrium (evolution starts off quite rapidly, but slows down after a number of generations). There’s plenty of neutral, beneficial, and harmful mutations, and a variable mutation rate (you can set it when you start a new map).
We’ve also implemented genetic recombination (mating) and the possibility of predator/prey relationships (attacking and eating dead creatures).
We also have a small variety of observational functions. It’s possible to analyse most of the creatures statistics, watch the progress of their energy and health bars over the course of their lifetime, and read their genetic code (which, admittedly, is somewhat indecipherable).
We’ve got a built-in speciation detector, that works out which populations can and cannot interbreed, and allows for the retrieval of stats and averages. We also have a real-time population history, which doubles as a tree of life.
Oh, and we’ve got a variable map generator, that you can use to customise the map before you enter the game, as well as entry-level save/load functionality.
And moddable body parts, too. 🙂
What we’re missing
Playing the game at the moment reveals a few… not so much ‘bugs’ as ‘things that aren’t much fun’. They’re things I’m aware of, but haven’t had time to fix and/or expect to fix with a planned, later feature.
Constant environment. The environment at the moment is a fairly constant variable: tree’s always regrow in the same area’s and the temperature never changes. This means that creatures have a tendency to adapt to their environment and stagnate.
Highly variable survival rate. A less-than-fertile map has a good chance of killing off the starting creatures, while a fertile one will cause a ridiculous population explosion once they adapt to be more efficient.
Lack of carnivorous incentive. Creatures rarely become predators because vegetation is plentiful and easy to find in comparison to meat.
Unmapped Mutations. I still need to add a mutation map for feature, limb-tip and body covering mutations. At the moment they find an ‘ideal’ far too rapidly.
Not enough Homogenizing. Species currently don’t visually distinguish themselves very well: you end up with a large crowd of highly variable creatures. Reducing the mutation rate helps, but I’d like to amplify homogenising forces like mating to make individual species more visually distinct from each other, as well as implement some sort of herding behaviour to make them congregate into discreet area’s.
Stupid creatures. They’re really pretty dumb sometimes. I expect their AI to improve slowly, a little bit with each release.
Incomplete Statistic Mapping. The UI allows you to track which statistics affect which other statistics, but the mapping is incomplete and doesn’t take into account all the effects (it’s a big list, and I’m tweaking it all the time. Nevertheless, I’ve managed to include all the major effects).
Performance. Is absolutely terrible on less-than-modern machines. My development laptop struggles to keep it going at better than 10fps once the simulation reaches more than 500 creatures.
Where we’re heading
Here’s the fun one! (Note that everything I say from here on out is tentative. I can’t make any promises, this is just what I’m planning)
The Big Feature for Species 0.5.0 will be a complete and massive overhaul of the vegetation system. It will use dynamic biomes based on a temperature/humidity map (which will change over time based on the actions of the creatures), instanced models, and a rewritten terrain shader.
It will also separate vegetative energy into two sources: fruit tree’s (point energy-sources, similar to the tree’s in the current system but rarer and more valuable), and grazing (idle, herbivorous creatures will graze, very slowly and inefficiently gaining energy but reducing the local fertility).
This system will solve the first two problems I have with the alpha release (mentioned above), and will have an as yet unknown effect on the third. But it’ll probably make the performance issues worse, so I may have to shrink the default world-size and creature-cap to compensate.
0.5.0 will probably also feature a top-down map view, with coloured icons for creatures and food sources, and another real-time phylogenetic tree of life. Unlike the current population history graph, though, this tree will encompass the entire history of the simulation, and will record morphological data about extinct species. It will form the basis for an extensive ‘fossil record’ in later versions.
One apparently minor inclusion to the vegetation system will be a ‘height’ value for fruit tree’s: creatures will need to hold their head (or hands) at a particular height to eat from particular tree types. While this might not seem like much, it sets the stage for a creatures vertical position to influence their actions and survival. And that sets the stage for another Big Feature: flight and swimming.
And of course, I’ve already mentioned a third Big Feature in a previous post: multithreading to improve performance. Not to mention my extensive plans for player interaction in the Beta… I may or may not be too ambitious for my own good.
But pulling right back from my deranged ramblings about the future, the figure you suffered through that entire post for is here. Without further ado:
Species 0.4.0 (alpha) will be publically released on the 27th May, 2012
(one way or another)
“… assuming the Old Ones don’t return before then and consume us all. You know, the usual disclaimer.”
Yeah, it’s time for another technical post. Sorry guys, I just can’t help myself. If you understand what I’m talking about, you’re probably doing better than I.
CPU Performance in Species is probably the single most restrictive factor of programming the game. It limits the number of creatures, it limits the methods I can use to change their variety, it limits the complexity of their behaviour, it limits everything sooner or later. But with very, very careful programming and optimisation, that ‘later’ can be pushed pretty far back.
Firstly, a little background: Species is ‘CPU Bound’ as opposed to ‘GPU Bound’. A CPU (Central Processing Unit) limited program spends more time computing what it has to draw than it does actually drawing it, meaning the GPU (Graphics Processing Unit) sits idle until the CPU is finished. I could dump a whole load of extra information onto the GPU and it simply wouldn’t care, because it’s hardly working as it is. The GPU is awesome like that.
Shawn Hargreaves can probably explain all this better than I, if you’re looking to read up on it:
I’m loathe to admit it, but I secretly suspect the Terrain LOD system I spent so long programming may be slowing the game down, because it takes work away from the GPU at the cost of a little bit of work on the CPU’s part, and I’m so heavily CPU bound there’s a chance just brute-force-rendering the terrain would be better at this point (I could be wrong, though, and taking it out at this point would be rather silly since there’s so much more yet to implement, on the GPU and CPU)
That’s why some of my systems, like the Billboard Vegetation, are reliant on offloading information from the CPU to the GPU. The GPU can handle it. The GPU can handle anything. (Advertised product may not in fact be able to handle anything)
So that’s fairly simple, right? Drawing takes no time at all, so all our time must be spent updating the simulation.
In reality, I’m only spending maybe a quarter of my CPU time in the update call. The reason for this is the bottleneck between the CPU and the GPU. Before the GPU can draw anything, the CPU need to tell it what to draw, in excruciating detail.
So even though I can’t save time by saving the GPU work, I can save time, lots of it, by stopping the CPU from telling the GPU it has work to do. There are a variety of ways I’m doing this…
I’m sure I’ve mentioned before that creatures are made up of a whole bunch of separate ‘part’ meshes. A high detail creature would have a torso, tail, 6 limbs, 6 limb tips, a neck, a head, and a currently unlimited number of Features attached to the head (open to later revision). Multiply this by whatever our creature cap is and we’re calling the draw routine far too many times for good performance.
But it doesn’t have to be called for every creature. Creatures off-screen don’t need to be drawn at all, and we can get away with drawing less detail on distant creatures.
We can also speed this up with State Batching. (Note for technical readers: Model Instancing would have been my preferred approach, but the parameters for each creature are unique. It’s not easy to instance meshes under those conditions). See, in order to tell the GPU what to draw, the CPU has to feed it with the model, texture, and parameters things like animated bone positions, sizes, colours, etc). The easiest method would be just to feed in these three things for every model, every time, and this is exactly what repeatedly calling Draw() in XNA does.
But you don’t actually have to. The GPU remembers: if you just change the parameters, but leave the model and texture as is, you can draw a second copy of it without resending the model. So by carefully rearranging the order of drawing to (for example) draw all creature torso’s one after the other, you only need to set the torso model on the GPU once. You can do the same thing with textures and parameters too, if you’re changing models all over the place but repeatedly using the same texture.
Obviously there are other, more subtle and game-specific ways to improve general CPU performance as well. Moving calculations out of loops wherever possible is a generic one: more than once I’ve caught myself doing a calculation multiple times when it could be done only once. A more specific example was carefully controlling matrix operators: streamlining the modifications I’d made to the skinning animation system cost me some programming time, but resulted in a noticeable performance increase.
But even with all these ongoing optimisations, I’m still not happy with the games performance. I’ve been treating my 4 year old, dual-core laptop as a baseline minimum (not least because that laptop is my development machine), but it struggles keeping the game running at a decent frame rate once the simulation gets going properly. There’s still room to optimise (there’s always room to optimise), but I don’t think I can get it to
the performance levels I’m hoping for with after-the-fact methods and reprogramming individual methods. This leaves one other option…
… multithreading. *dramatic thunder*
(Note: this rest of this post will likely be one long whine. I hate multithreading even more than I hate render targets. I still plan to tame it one day, because it really is a powerful way to improve CPU performance, but not for the alpha release)
Most machines have more than one CPU these days, and many people assume as a result that that means the computer must be faster. 4 cores? FAST. 8 cores? ULTRAFAST. 128 cores? OMG WHY YOU STEAL NASA SUPERCOMPUTER. In reality though, most programs are not designed to take advantage of this. The vast majority of programs do all their actions on a single core, because Multithreading Is Hard.
Multithreading is the process of taking part of what you have to calculate and giving it to a separate process (thread), which can run in parallel on a separate core: in short, it’s telling the computer to do multiple things at once. So for a game, you might tell the main core to render the screen while the second core works on updating the simulation for the next frame.
Of course, describing the process so clinically doesn’t quite summarize the emotional response I have to multithreading. So for that side of things, here’s an alternative explanation: multithreading is the process of juggling 3 plates, 2 watermelons, a chainsaw and a rabid wolverine while walking a tightrope over a pit of giant acid-spitting ants while cyborg trapeze artists take pot-shots at you with AK-47’s and grenade launchers.
I’ve actually attempted multithreading in the past. The results were unpleasant, unpredictable, and impossible to debug, mainly because I didn’t know what I was doing but also partly because that’s just the way multithreading is.
To give you an idea, suppose the first thread retrieves something from the second before the second thread is finished with it. The program might fail (which is what we want, so we can work out why the first thread is retrieving stuff from the second), but it will usually try to keep going. The simulation will start acting strangely, using false values, but not actually telling you it’s doing so. If it fails, it will fail somewhere else in the code that has nothing to do with the multithreading, and you will then spend hours investigating in the wrong place.
The usual approach to multithreading is to implement a lock, so that one thread waits for the other to finish before using any of the same resources. But the draw call needs to use a lot of the same resources that the update call uses, so it would likely spend much of it’s time waiting, and wouldn’t be much of an improvement over single threading.
(There are, obviously, ways around this, and when I do implement multithreading properly I will have to study them in detail)
In addition, for some reason, Multithreading plays havoc with Visual Studio’s debug mode: a multithreaded game seems to run much slower than an equivalent single threaded game in debug mode: so slow that, during my ill-fated attempt, I had run the game outside of debug mode on in order to test it. Less than ideal, and it makes tracing bugs and errors much, much harder.
For the alpha release, and probably for the second alpha release too, we will have to settle for less-than-optimal performance. When I do implement Multithreading I will have to set aside a lot of time to rework a large amount of the code, and to deal with the inevitable problems. With luck, though, I will be able to significantly improve frame rates, which will allow for bigger worlds and more creatures.
“You know, there’s probably potential for a misogynistic nerd-joke about multithreading in there somewhere.”
As it turns out, modding is pretty hard to do in XNA. So, the first part of this post will serve as a bit of a ‘how to’ for XNA developers building for PC (it might help for XBox, maybe, but I make no promises). After that I’ll skip to the more species-specific discussion: feel free to skip ahead.
The reason XNA has trouble with modding is its content pipeline, which serves to pre-serialize the game content into an easily readable binary format (*.xnb). This is actually a very smart system: rather than spending loads of time compiling models and textures every time you open the game, it compiles them once on the developers end, saves the result as a part of the game data, and can quickly load it again on the players end without having to do anything complex with it.
But it’s a nightmare for modding, because it means modded parts either need to be pre-compiled to be brought into the game, or the game needs to be shown how to compile the modded parts itself.
Of course, the XNA team are awesome, so they provided the WinFormsContentLoading sample. This sample shows us how to make a program that compiles and renders a model, and can easily be extended to work with Textures and other files, too (well, ‘easily assuming you don’t find one of the pitfalls‘). Perfect! Add that to the game and it can compile modded parts, right?
Not right. You see, for a variety of reasons that I’m certain make sense to someone somewhere, Microsoft have decided in their infinite wisdom that the content pipeline assemblies shall not be included in the XNA redistributable, and XNA developers are forbidden from distributing it themselves. This means that, were I to include mod compilation capabilities in the game, it would not run for anyone who had not installed the full version of XNA. The full version of XNA is free, but installing an entire development environment just to run the game is a bit much to ask.
Interestingly though, restricting compilation does not restrict use. Once compiled, modded parts can be distributed all we like. So, with or without XNA, everyone will be able to use modded parts. They’ll only need to install XNA if they want to make modded parts.
This leads to the strategy I have in place for Species, which could be easily applied to any game. Mod users won’t have to do anything more than download modded parts and copy them into the appropriate subfolder. The Load Content routine, rather than loading a hardcoded number of items, reads the number of *.xnb files in the subfolders and loads them in one by one (it’s not necessary to have them in the Content Project, so long as it can read their filename).
Mod making, on the other hand will be a bit more involved. It won’t actually require the mod developer to use XNA: I’ve created a utilitarian (read: ugly) ‘mod maker’ application out of the WinFormsContentLoading sample, that compiles and copies the *.xnb files. But even so, the mod developer will have to install XNA and Visual C# to use the mod maker in the first place.
I hope that this will be acceptable for people making modded parts, as it’s the easiest I can make the process at this stage. Thank goodness Visual C# and XNA are free, or it probably wouldn’t even be worth implementing, which would be a great loss in a game like this. Community modding has huge potential to expand this game beyond what any development team could make it, and I’m incredibly excited to release it into the wild and see what people come up with.
If you’re skipping ahead, start reading here.
So, what will be moddable in Species specifically?
In the Alpha release, just body parts. It will be possible to model your own head types, eyes, ears, horns, feet, etc, or to draw your own new body coverings like scales or fur. Add the required stats, copy the files in, and new body parts will appear in the game. Also, technically, you can replace any texture or model in the game using just the mod maker, but that’s just a side effect.
This is only the start though. It takes time to open up a section of the game to modding (without just handing out the source code, which I’m reluctant to do) which is why I didn’t bother opening the vegetation system up. The billboard vegetation will be replaced in the second alpha release with a much more complex and dynamic vegetation-and-environment system, and that will be open to modding. In the long term, I’d even like to open the statistic map to modding: allow the players to add their own selection pressures and stats. That’s an ambitious one, though. At the moment, just making it visible through the UI has been quite a time consuming job.
Subtly pulling the conversation back to body parts (the ultimate conversational topic!), there’s one aspect of that I’ve not yet discussed. It’s one of the last things I implemented, which is ironic because this subject is one of the very first things I started to sketch out when I began designing this game. I’ve even got proof, one of the very first digital sketches I made, a long long time ago:
Mutation mapping is something I have to be careful with, because I know some people are going to look at these diagrams and say “he’s guiding the evolution”. That is not and never will be the purpose of this system: every mutation goes in both directions, and no mutations are more or less likely to occur than any others.
What the Mutation Map system is doing is not guiding the simulation, it is restricting it. Without this system, if we were to just use a random number generator, it would be entirely possible for a fin to spontaneously become a wing, a duck bill to become a crocodile mouth, a reproductive organ to become a politician, etc. Since such a thing doesn’t happen in real life and is impossible (or at least, extremely unlikely) according to the theory of evolution, this restriction is an important element of the simulation.
It also allows for progressive development amongst otherwise discreet variables. It’s easy to imagine a Species slowly getting larger and larger in the game, because floating point variables work perfectly for evolution, but with discreet variables such as eyes, features will suddenly appear on a mutant creature and then spread through the population. This isn’t gradual at all.
A mutation map doesn’t actually stop this, but it allows it to be a lot less sudden, by including (for example) a light-sensing patch of skin, followed by a better, shaped patch, followed by a very basic lens, followed by a complex eye. It’s also possible to include offshoots at every stage (and recommended: I’m going to try to include as much content as possible in the vanilla game, before we even get to modding). Of course, the light sensing patch will still appear just as suddenly as the eye did earlier (in real life, it’s likely a patch of skin would grow more and more capable of sensing light rather than just appearing), but that’s still a lot more gradual than a fully formed eye appearing out of nowhere.
An interesting point about the mutation mapping in general is a fact I realised some time between realising it was going to be necessary and implementing it: I shouldn’t actually be designing it as a ‘web’. The above diagram shows the problem with the way I was originally designing it: I was using features idea’s I knew existed in real life, and connecting them based on similarities. I was doing it completely backwards: what I should have been doing instead was starting from a simple design and branching out, letting the part design reflect it’s statistics rather than working out the statistics based on the part design.
Here’s a more recent sketch. As you can see, rather than the convoluted web we had in the body covering sketch, designing this way forms a sensible nested heirachy:
It’s also scarily exponential. Four generations with three statistics and I already have 40 different feet types. Not to mention the fact that designing stuff like this is surprisingly easy: it wouldn’t be hard to extend the design to a fifth generation. Modelling and importing 121 feet types, on the other hand… not so easy. As a friend mentioned to me recently, the feature creep potential for Species is rediculous!
Which is part of why modding holds so much appeal for me. Even with the help of a proper graphic artist, there’s no way an indie studio like us can do that much content on our own. Community modding frees us to work on new engine functionality, things like flight and swimming and an improved vegetation system, while a lot of the actual potential for biodiversity can be unlocked and appended by the community themselves.
Don’t worry, though: I’m not going to rely entirely on the modding community The vanilla game will have as much content as I can build and pack into it. Nevertheless, I’m superexcited to see what people do with it once the game hits the public, in a month and a half or so… 🙂
“He’s only excited because he feeds off the wordpress blog stats the way demons feed off of the souls of D&D players.”
aka. Misadventures In Implementing a Real Time Tree of Life Graph. Note: this post is a logical sequel to the previous post, though it also doubles as a what-not-to-do tutorial of sorts when it comes to implementing real time graphs and render targets in XNA. Fair warning: It’ll probably be a bit incomprehensible if you’re not a programmer.
/tangential progress report: we’re about 40% of the way to the alpha release deadline and about 50% of the way through the “list of crap to do”. So we’re ahead of schedule, but not by much.
It’s probably worth noting that part of the reason I’m cutting it so fine is micro-feature-creep. A major advantage of programming on your own is the ability to indulge your inner ADHD-sufferer: getting distracted by something that sounds like fun and wandering off to code it. Some of my favorite features in Species have come about via ooh-shiney moments like this, but it slows down my progress on the stuff I’d planned out in advance.
Okay, back to the topic…
I not-so-briefly touched upon my very first tree of life graphing attempt in the previous post. This image…
… shows the end result.
Frankly, it’s ugly. It’s barely recognisable as what it’s supposed to represent, and it’s a performance hazard. Each one of those bars is a seperate sprite representing the life-time of a creature, which means I’m calling DrawSprite() a couple thousand times every frame. This would be manageable if I stopped drawing the simulation in the background (a tactic I’m may have to adopt when I get around to trying out the life-web I mentioned last post), but because I was rendering it as an overlay this wasn’t something I spent much time considering.
The idea behind this graph was that it would show the culmative effect of population changes by displaying all the creatures lives at an individual level. Admittedly, it manages this to some extent, but it does so extremely poorly. The rapid movement to the right, for example: that’s not natural selection, that’s just the logical result of measuring mutation from the starting location. If you start a value at 1, and your children are 0.9 and 1.1, it doesn’t matter that they are going in opposite directions: they will both appear at 0.1 on the graph.
But as far as first attempts go, it taught me quite a bit about what I was trying to achieve. That’s the whole point of prototyping: try something, learn, then try it again using the information you’ve learned. In this case what I learned was that showing individual creature lives was too microscopic to paint a good long term picture. I was going to have to summarize, and for that I’d need to use the species and speciation tranking system… which, despite post order, I hadn’t implemented at this stage. The above graph was generated entirely from random colour changes and the genetic distance algorithm.
So I went and I implemented species and speciation tracking while researching and considering my next move. Surprisingly, for such a simple concept, there are a whole variety of ways to implement a real-time graph. I’ll get to those in a moment, but first: what I decided I wanted to achieve was a population tracking graph that would show the relative size of each species and the effects of speciation, so you could see whether the splintering population was a single sterile creature, or a large segment. It would also need to be able to dynamically move and re-arrange population lines, to keep them from overlapping and under-representing the total population. This… turned out to be more ambitious than I expected.
I narrowed it down to a number of ways to do this:
1. Brute force sprites: draw a lot of sprites to form the shapes you want. This was the method I’d used for the previous version, and despite my complaints, for that version it was actually feasable: the number of sprites involved aren’t a negligable performance hit by any means, but they’re manageable and they’re easy. But to do this for a graph that shows changing population size on a per-frame/per-pixel basis? On a modern monitor we’re talking about 1080 sprites, multiplied by the number of species shown. Not viable.
2. Vertex List: dynamically changing geometry to represent the shapes you want. I didn’t spend much time looking into this option, but it has a number of things going for it: dynamically re-arranging Species Lines would be easy to do. The biggest problem with it is the bottleneck between the GPU and CPU: dropping that much vertex data on the GPU every frame can’t be a small performance hit.
3. Shader Trickery: sending the raw population data to the GPU and having it do all the work in the pixel shader by, essentially, drawing the graph on a transparent slide right in front of the camera. This is probably one of the best options here: it defers a lot of work to the GPU, is easy to implement, and allows the things I wanted to do, but… older shaders can only handle so many variables as parameters (255 for shader model 3.0), which is nowhere near enough. The CPU-GPU bottleneck issue still exists, but Shader Parameters are designed to be modified on the fly in a way that Vertices aren’t, so it’s not as bad. If I was targetting a later shader model this would probably be my preferred option, but as it stands… no.
4. Colour Arrays: generate an array of Color objects, modify it directly every frame, then save it to a texture and render that texture to the screen. Similar to option 3, except done entirely on the CPU rather than the GPU. I actually tried this one out: turns out that for full-screen textures it leaves a pretty massive footprint on your performance.
5. Render Targets: Oh god.
I hate render targets. I’ve had several dealings with them in the past, and every time they’ve given me a whole new bunch of reasons to hate them. Render targets are evil. /title drop
Don’t get me wrong, Render Targets are a vital and powerful aspect of the XNA framework, and there’s no doubt we’d miss them if they weren’t there. But they’re still evil. I still have nightmares about debugging Render Target issues. (okay I don’t really, that was hyperbole. My nightmares are more only have ordinary everyday things, like giant zombie demon spiders with flamethrowers held in their pincers. Also, the moth. Everybody has nightmares about the moth right?)
The basic concept behind this approach is to render only the ‘front’ pixels of the graph, then move the entire thing 1 pixel along next frame and render the next set of ‘front’ pixels. For a single line graph, this means you only have to draw 2 sprites: 1 for the line and another for the entire graph that was rendered last frame. This is a very efficient way of doing things, with the disadvantage is that what is drawn is drawn. I can’t modify the graph later if I want to move population lines to the left or right in response to population pressure.
But you can’t just do this straight onto the screen: I’m rendering everything else onto the screen, so I don’t want to be moving all that one pixel to the left every frame. Just the graph. And that means render targets, which are basically extra screens that you can activate, draw stuff on (without overwriting anything else) and return to later. Sounds easy, right?
A few points about render targets, for XNA users who are interested in avoiding the same horrible spiky pitfalls I fell into, climbed out of, then tripped and fell into again:
1. A render target has to be removed from the device before you can retrieve the texture from it. Failing to do so causes an exception. To remove it, call GraphicsDevice.SetRenderTarget(0, null);
2. Switching to a render target, then switching back, has an unfortionate tendency to clear your screen to a certain shade of purple. There are reasons for this (mostly because XNA is designed to work with the XBox, which has it’s share of quirks), but I didn’t know them at the time. All I knew was “suddenly purple WTF?”. To avoid this, it’s necessary to render to any Render Targets’s before you draw anything to the backbuffer.
3. A render target cannot render it’s own texture. In order to do what I said before (render a texture, then move it one pixel to the left and render again) you actually need to switch back and forth each frame between two render targets.
4. A render target cannot be used to render to multiple textures. You’d think you’d be able to render an object, then copy the result into a Texture2D and render a new object. This is what I wanted to do with the population lines so I could move them left and right: draw each one seperately and move their parent sprites. Turns out no: copying the result into a Texture2D only copies a reference to the Render Targets texture, so when you render the next thing in the list you overwrite the earlier Texture2D.
5. There is apparently a limit to the number of render targets you can have, so you’re not allowed to render multiple seperate objects that way, either. It’s nothing concrete, but somewhere between 40 and 60 targets the program will start to glitch out. For me, the sky went white, the game briefly lagged, and then it crashed out with an incomprehensible exception. I have no idea why these were the symptoms of too many rendertargets: I choose to believe I’d accidentally imported an identical anti-matter universe into the game and everything except the earth exploded at once. The few seconds of lag were just waiting for the shockwave to hit.
So how can you render an unknown number of seperate objects, like population lines, into seperate textures? There’s only one way: use a single render target, and perform a deep copy of the Texture2D before you move onto the next object so you copy all the information of the object and not just it’s reference. So how do you perform a deep copy? SetData() and GetData(), two of the slowest texture related functions in the framework! As it turns out, this performance hit for an almost-full-screen graph was almost as bad as option 1, way up there earlier in this post. So that’s out too.
(It’s probably worth noting that this method, can be possible for smaller images, like 256×256 thumbnails, where there’s less data to copy. I still don’t recommend doing it more than once per frame, however)
Eventually I gave up and left the population lines alone. The current system lets them stay where they are, overlapping.
I’ll leave the fancy visual stuff to the proper phylogenetic tree, which won’t display population histories and will be implemented later WITHOUT RENDERTARGETS. SCREW RENDER TARGETS. (okay, maybe with one render target).
Apparently he hates rendertargets almost as much as he hates multithreadin-“
NO. YOU DO NOT SPEAK THAT WORD IN THIS HOUSE.
Enthusiastic innocence quickly gave way to confused curiosity as I realised that working with XNA wasn’t really anything like the amateur programming I had been doing before. It had similarities, sure, and it was still many saganhertz more user-friendly than working directly with DirectX, but it didn’t try to hide the skeletons underneath: instead, it encouraged me to dig them up and molest their remains as much and as often as I could.
Err… okay, that analogy got creepy fast. Moving on: what I was trying to say before my twisted subconscious got control of that sentence was that, rather than providing me with pre-built shaders, XNA provided me with one really basic shader and then encouraged me to learn HLSL (High Level Shader Language. Yeah, programmers aren’t paid to be inventive with names), so I could write my own. Rather than giving me an inbuilt animation system, XNA gave me a sample solution in which such a system was implemented, encouraging me to learn how and why it worked. And so on.
So even though it was more difficult and slower than working with my other engines and programs, XNA managed to hold my interest, and still does. And with that interest came the inevitable question “what am I going to make with it?”
It’d need to be something that I wouldn’t be afraid of screwing up: so anything with a complex story was right out. Something small enough it could be done by a team consisting of 1 mundane modeller, 1 poor programmer, 1 worse writer and 1 apathetic anal-retentive alliterative ass, and where I was all of those. Except the last one, ’cause I loathe alliteration with all my shrivelled black heart.
Say, didn’t I have an idea for an evolution simulator around here somewhere?
If “saganhertz” isn’t a real word it should be,
So here’s me, late 2007. University wasn’t going well, and I was beginning to suspect I had chosen the wrong career path. On the other hand, my programming skills had been improving, and I had finally gone looking for a 3D game engine.
I found Blitz3D.
Blitz’s simple interface and use of the BASIC programming language lightened the learning curve going from 2D to 3D graphics, but it also removed from me some area’s of complexity, like collision managment, basic drawing concepts and terrain rendering. In hindsight, I really can’t tell if this was a good thing or a bad thing. On the one hand, it allowed me to build a few projects to near-completion very quickly: on the other, I only had a very shallow understanding of what it was I was actually doing. I remained enthused, but it slowly began to dawn on me that Blitz simply wasn’t powerful enough for my needs.
Losing interest in one project and looking for something else to occupy myself, I decided that I needed a different, more powerful engine. I found something even more powerful than that: the XNA framework.
According to a definition I found on the internet, which means it is absolutely infallible and anyone using any other definition is a blasphemer and a heretic, a game framework is a step above raw DirectX but a step below an actual game engine: it’s used to build the engine, which in turn is used to build the game. I had no idea at the time what this meant, but I saw normal mapping and bloom effects in an XNA project and, eyes shining with innocence, I happily ran after the graphical candy.
Sold his soul for Parallax Mapping,