Month: April 2014

Yeah you read that right, I’m reading back from the card. yes, I feel kinda dirty. What am I talking about? (skip this is you are gfx coders…)

***generally speaking games create ‘textures’ in memory on the graphics card, so the data is actually stored there. We write data *to* the card, and then we forget about it. We tell the card to draw chunks of that data to the screen, and it does so. What you never do, is read back *from* that same data. In other words, you draw stuff to the screen, but have no way of actually looking *at* the screen from back where you generally are in CPU / RAM land. The reason for this is everyone understands this to be slow, and there are very few reasons to do it***

I have some technique, the details of which I won’t bore you with, which requires me to draw the scene in a certain way, then blur that scene, and then check the color value of specific pixels. I cannot find any way to do this without reading back from the video card. I should say this is for Gratuitous Space Battles 2.

Theoretically, I could maintain an system-memory only version of the scene, render to it there, blur it, and read from it without ever touching the card GPU or card RAM. This would mean no sneaky using that video card bus to do any data transfer. The problem is, I suspect this would be slower. The GPU is good at blurring, and rendering, and in fact, all of the data I draw to the scene is in gfx loaded in the cards RAM. Make no bones about it, I have to compose this scene on the card, in card RAM. And if I want to access specific pixel colors, I need to get that data back.

So what I’m doing now is a call to GetRenderTargetData to grab the data and stick it into a system memory texture I created earlier specifically for this purpose. BTW did I mention I have to do this every frame? Once there I call LockRect() on the whole texture, and then quickly zip through my list of points, then UnLock() as soon as I can. So what happens?

Well if I look at the contention analysis in Visual Studio, it shows me that this calls a lot of thread blocking. It’s pretty much all of the thread blocking. This is clearly sub-optimal. But if I look at the actual game running in 1920×1200 res in FRAPS, the whole thing runs at a consistent 59-60 FPS. My video card is an Nvidia Geforce GTX 670. In other words, it really isn’t a problem. Am I over-reacting to what was once a taboo, and now is not? Are people calling LockRect() on textures just for giggles these days? Is my engine sufficiently meek that it leaves plenty of spare room in each frame to put up with this clunky technique?

I’ve also considered that I may be screwing up by doing this close to the end of a frame (sadly this is a requirement of my engine, unless I let a certain effect *lag* a frame). If it happened mid-frame I suspect the thread-blocking that prevents the end frame Present() wouldn’t be so bad. Sadly I can’t move it.

I’ve also wondered if a series of smaller LockRects() that don’t fill the screen might be quicker, but I doubt it, I think it’s the mere lockiness, not the area of memory that matters. I can easily allow the effect to be toggled under options BTW, so if it is a frame-rate killer for some people, they can just turn it off.

I recently got far enough in GSB2 to start fiddling with the particle effects for various things, and various low-level engine changes mean all of the particle configs for the original game are kind of screwed up and don’t really work right with this engine, so they all need re-doing, which is fine, as CPU/GPU horsepower has risen enormously since then, and it would be good to up the detail count on them anyway.

This reminds me that I never really had a decent particle editor when I started making Gratuitous Space Battles. it was all pretty poor. I had a MUCH better one for Gratuitous Tank Battles, (Which actually used two entirely separate rendering systems for different particle effects…) but ideally I wanted something I could have integrated into the game as an easy to use tool, maybe not for public consumption, but who knows?

Anyway it took me a day to knock this up: (click to enlarge)

Which isn’t too bad given I use my own GUI code, and it gives me a very easy way to stay within one project and one app, and have the source code for the editor readily available, and using the same functions as the actual game, so if I update the particle engine, it’s updated everywhere. I now need to go and create some cool particle effects with it, but obviously that’s the fun part!

My approach to particle effects is pretty simple. I have discrete LODs for some of the more expensive effects, where if you zoom in, a more detailed effect with a lot more particles will appear. That certainly isn’t as smooth as it could be, and of course ideally it would all be procedural and algorithmic, but that sounds like a bit of a nightmare. Expect a smorgasbord of screenshots and videos eventually when I get the hang of using it properly :D

This has taken me all today and part of yesterday to get working. And no it isn’t final, and no, it isn’t optimized yet. And yes, it probably should have been easier. That little asteroid is occluding the bloom flare from that engine. You can see the non-occluded one above. Took me ages, and about a million lines of code. Arrrghhh. Click to enlarge…

I’ve spent the last day or three experimenting with various visual effects for GSB 2. This is kinda fun, but I also think its quite productive. If i was making the game using Unity or some other engine, I’d just pop along to the asset store and browse the effects other people have written and bung them in. Job done, ship the game.

I can see why a lot of people are attracted to doing that, but personally I’ve found rolling my own solutions to be much more rewarding, not just as a coding geek, but from a game design and visuals POV. The lighting effects in GSB 2 will not be the standard Unity effects, or the same effects used in any other engine, ever. they are unique to the game. They may not be ‘radically different’, but I think the distinctiveness helps. Sometimes i end up coming up with pretty wacky solutions to problems which allow me to include features in an unusual way. I think it’s a really good thing for different coders to be approaching each problem in a different way, after all we are supposed to be creating original, and distinct works of ‘art’.

When big movies add special effects, they don’t often copy and paste effects from other films. Arguably Star Wars has already done ‘lasers’ so you could theoretically just copy them. The problem is, you never get innovation that way.

I just watched ‘The Forbidden Planet’, a classic 1950s sci fi movie. it was the first sci-fi movie to have an all electronic soundtrack, which was amazing at the time. It’s cheesy as hell now. I bet one of the reasons for it’s success is how different it sounded as a result. they had to work out how to do that from scratch. Then sci fi movies all tended to sound the same and become tedious until Star Wars, when George Lucas decided classical music could work with a futuristic movie. Now, ALL movies copy that idea.

It would have been easier, simpler, and cheaper, and much more in line with what the audience expected if those innovations had not happened. But when they get it right, they get it right big time. I doubt that GSB 2 will change the future of gaming, but I like to think that by occasionally approaching things from first principles and hacking my own way to make things happen, I’m at least ensuring there is some variety in the way stuff looks.

BTW… On the topic of Robby the robot, what a flipping layabout! He is , if you read-between-the-lines a nightmare to work with. First he does this whole ‘Sorry I was giving myself an oil-job’ excuse (yeah whatever), when he can’t be found when called, then he mocks and sounds incredibly put-out because he is asked to make a new dress. then later, he tells the crew ‘if you need anything, use the beamer’ without ever explaining where or what that is. Plus he moves at about the pace of a snail. if I didn’t know better I’d think he did that deliberately so everyone got sick of asking robby to do something and did it themselves.

‘if you need anything in about 6 hours, use the beamer, otherwise you might as well do it yourself’.

Bah.