Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!

1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


Member Since 02 Nov 2012
Offline Last Active Today, 12:09 AM

#5149113 Pentagons in geometry shaders

Posted by C0lumbo on 24 April 2014 - 01:27 AM

Just a guess, but it looks like maybe your code is intended to produce a triangle fan, but it's actually outputting a triangle strip (with some of the triangles being back faced culled). .

#5149005 Communicating "scariness" without openly showing the enemy

Posted by C0lumbo on 23 April 2014 - 11:58 AM

Audio, music and shadows were going to be my main suggestion, but you already mention them...

Have a second badass looking monster, that gets to see your monster, and is absolutely terrified of it?

Camera shakes associated with the monsters footsteps? Maybe dust shaken from the roof too.

Have lots of physics objects (barrels, crates) in the corridors you run through, that get smashed into by the unseen monster so that they fly in front of you?

Dolly zoom as the monster gets closer?

#5149003 Your most valuable debugging techniques for Networked games?

Posted by C0lumbo on 23 April 2014 - 11:49 AM

Make sure that your game launching code lets you create multiplayer games with just one player in debug mode, make it so that it uses as much of the regular multiplayer logic as possible.

Put systems in place to allow creation of AI driven clients (ideally running in a console window on the same machine, so you're not wasting time with multiple machines)

#5147408 Scaling in 3D aircraft game, objects look too small!

Posted by C0lumbo on 16 April 2014 - 11:29 AM

Agree with Ashaman73 that you don't need to sweat too much if the measures aren't accurate, but I wonder if the problem might be your field of view. Maybe your field of view is quite wide (which makes things look little) and you've positioned your aeroplane close to the camera to compensate.


If that's the case, then you've effectively done a dolly zoom (google it, watch youtube vids/gifs, they're cool!) on your aeroplane, distorting the background while keeping the aeroplane looking normal. The fix would be to narrow the field of view and move the camera further back from the focus point.


Edit: PS. Wide field of views give more of a sense of speed, so you might want to consider how important that is to you before narrowing the FOV too much.

#5147057 Problem with perspective view

Posted by C0lumbo on 15 April 2014 - 01:42 AM

A screenshot might help. In particular, I wonder if the front cube is really transparent, or whether the front cube and back cube are actually opaque, but the problem is that the back cube is drawn on top of the front cube.


If so, then perhaps the z-write/z-test is not working, which could be because the depth buffer isn't setup correctly, z-testing or z-writing is disabled, or because the perspective matrix is setup incorrectly.

#5143726 Deleting pointers to inherited objects

Posted by C0lumbo on 01 April 2014 - 10:24 AM

You are aware of the fact that you should have virtual destructors in order to avoid memory leaks, but I think you are misunderstanding the reason why.


The presence of a virtual destructor helps make sure that the destructor of your derived class is called. This is very important if your derived class has allocated some memory or other resources. If the virtual destructor is missing, the derived class's destructor isn't called and resources that the derived class has allocated are not released.


It sounds like you think that the virtual destructor is involved in the process of telling delete the size of the class it's going to delete. It's not involved in that process at all. Instead, typically, when you ask for a block of memory with new, a memory manager will also allocate a small header (say 16 bytes) which is located directly before the pointer that it returns to you. The size of the object that was allocated will be encoded within that header. When you call delete on your pointer, the memory manager can subtract 16 bytes and read the size from the header block.


So, this question "Is there, e.g., a minimum ("new") allocation block which gets deleted whether the entire allocation is used or not?" is kind of irrelevant to explaining the behaviour you're seeing, but probably yes, there is often a minimum allocation size or alignment. So allocating 100 bytes with 100 calls to new, will likely use a couple of KB at least due to the header overhead and alignment/minimum sizes.

#5140999 Why does my game restart when I minimize and reopen it?

Posted by C0lumbo on 21 March 2014 - 10:47 AM

A long time ago, before iOS's 'multitasking', games would often save the entire game state on a suspend event, so that when the app is reopened you can restore the player to the exact position, be it mid-level, deep in the front end menus, or whatever.


These days, for most titles, it's not worth the effort. Just save any user progress as soon as it occurs, if the user suspends your app and tries to return to it, usually the OS will restore your app to the foreground as if nothing has happened. In the event that the OS decided to kill your app to reclaim the RAM, or the user manually killed your app, it doesn't matter much because you will have saved the progress fairly recently.


The only thing I would normally bother doing is to pause the game. One exception is that if your game is pushing the device's memory usage to the limit, then you should make an effort to free a decent chunk of memory on suspend (textures are quite easy to remove/reload), otherwise, the OS is very likely to close your app (particularly bad if your app has links to safari or the app store or something, the user follows the link from within your game, returns to the game only to find it has crashed!).


Here's the relevant doc from Apple: https://developer.apple.com/library/ios/documentation/iphone/conceptual/iphoneosprogrammingguide/ManagingYourApplicationsFlow/ManagingYourApplicationsFlow.html

#5139926 Getting a direction constant from normalized vector

Posted by C0lumbo on 18 March 2014 - 02:32 AM

People are probably correct suggesting that you shouldn't end up needing this function, but to implement it I would perhaps do something like:


float fThreshold = cos(PI / 8);


If (x > fThreshold)

    return East;

else if (x < -fThreshold)

    return West; 

else if (y > fThreshold)

    return North;

else if (y < -fThreshold)

    return South;

else if (x > 0 && y > 0)

    return NorthEast

else if (x > 0 && y < 0)

    return SouthEast

else if (x < 0 && y > 0)

    return NorthWest

else if (x < 0 && y < 0)

    return SouthWest


(this is assuming positive x is east and positivie y is north)

#5139643 [TEXTURE] BC7

Posted by C0lumbo on 17 March 2014 - 12:31 AM

BC7 is pretty great and is incredibly versatile, and is probably the best choice in a wide variety of situations (Chris_F points out the exceptions well, but I'd just emphasize that when Chris_F says that "For some textures BC7 will be too large, so for that you will want BC1", he's not just talking about the amount of memory available, there's a very real performance benefit from reducing the amount of texture data that has to be thrown around, so I don't think BC1 will disappear too quick).


However, you touched upon it's main disadvantage in your original question, BC7s versatility is largely down to the fact you can choose from 8 different encoding schemes at a per block level, and many of these encoding schemes have many different partition tables and other options. This means an exhaustive BC7 encoder has to do similar work to a BC1 encoder but do it many hundreds of times. The result is that the time required to generate a decent quality BC7 compressed version of a texture is huge, it's very slow even with a compute shader to do the heavy lifting.


That said, I have no doubt though that those developing exclusively for hardware that supports BC7 (not very many people on PC yet!), will end up with the majority of their textures as BC7, especially if someone can put together a faster encoder with some clever heuristics to reduce the search space.

#5136346 Optimization in Games

Posted by C0lumbo on 04 March 2014 - 12:02 PM

Most important thing when doing optimisation is to take the time to measure accurately. Makes me so annoyed when people optimise without measuring first, so they have no idea if the optimisation has a real world effect.


I'm coming from an engineering perspective, but the same would apply to any other form of optimisation. Harder perhaps with game design, and although analytics help, you have to be particularly careful when interpreting your measurements.

#5136252 Large textures are really slow...

Posted by C0lumbo on 04 March 2014 - 12:24 AM

I think that tanzanite7 is getting frustrated because he's essentially asking the question:


"In a situation where HSR and early-z are not an option, is discard still bad?"


And he's getting a lot of answers about HSR and early-z.


TBH, I'd have to measure, but one possible reason that discard might be worse than the alpha blend in this scenario is that discard is adding a dynamic branch to the shader (by dynamic, I mean that some fragments within a 2x2 quad might take the discard path and others may not). However, I'd imagine that the relative costs are very hardware and shader dependent, I wouldn't be surprised if you could create a shader where discard clearly improves performance (e.g. if the shader was doing complex per pixel deferred lighting operations). However, I think that where you're just blending a simple texture onto the screen, then the cost of the discard probably outweighs the cost of the alpha blend.

#5134340 How to get good fast?

Posted by C0lumbo on 25 February 2014 - 12:00 AM

Here is a how-to guide to learn programming in just 21 days: http://abstrusegoose.com/249

#5133884 Legal risk in editors, and giving players freedom to edit

Posted by C0lumbo on 23 February 2014 - 10:34 AM

I am not a lawyer, but I think that as long as you are not hosting the content, then there is no problem. e.g. Adobe can hardly be held responsible for what people make in photoshop, be it copyright infringement or even a criminal act (although interestingly Photoshop supposedly includes code that attempts to catch currency forgers)


As an example, there are plenty of sports games without licenses that let you modify the names of teams and players. I believe this is perfectly legal, even though it's obvious the feature is there to let the player base use licensed names. Such games often allow methods for players to save and share their modified team rosters, this is perfectly legal. However, if the method of sharing the rosters involved the developers website/servers in any way, then most likely the developer would get sued. i.e. Let your users save the data as a file and share it through their own website and your fine, provide the service that lets the users share the data and you're in trouble.


Here is my opinion on your specific questions:


-I guess allowing them to change 3D models and changing textures is not a good idea. AFAIK, Im responsible for whatever content they create. Right? You are not responsible

-What about smaller things like names, color templates, etc. You are not responsible

-What about a map editor? Edit the heightmap/tiles, place the built-in objects etc. You would only be responsible if you run some infrastructure that allows players to share the maps

-Is it any different when the game is single-player/online multiplayer? If you are hosting multiplayer servers then you would be responsible for making sure user created content is appropriate. If you're not hosting the user created content then you must still make an effort to warn players that they may (i.e. will definitely) be exposed to obscene content in multiplayer play.

-What if they create a mod for your game? Are you still responsible for its content? You are not responsible unless you host the mods on your website or something

-What if I dont explicitly allow them to change things like textures, sounds etc, but they can change the files in the game`s data folder? You are not responsible

-What if I do protect the files with checksums or something, but someone hacks it? You are not responsible, but if you ship something inappropriate which can be accessed through hacking then you are responsible (e.g. Hot Coffee, or that guy that padded a console DVD with South Park episodes instead of with zeroes, it was inaccessible except by hacking, but they still had to recall all the DVDs)


Again I am not a lawyer, I may be wrong about any of this.


Edit: I suppose the City of Heroes vs Marvel case is relevant: http://en.wikipedia.org/wiki/City_of_Heroes

#5133769 Handling Post Processing after Deferred Shading

Posted by C0lumbo on 23 February 2014 - 02:21 AM

Usually the approach is to have 2 render targets and 'ping pong' between them. Let's say the result of your deferred rendering scene ends up in RT1.


Post Effect A renders to RT2 using RT1 as a texture.

Post Effect B renders to RT1 using RT2 as a texture

Post Effect C renders to RT2 using RT1 as a texture




That's the basic approach, although the details can get a bit messy. e.g. You might want to reuse some of your G-buffer render targets rather than allocating new ones. You might want to do some of your post effects at reduced resolution. You might want to combine some post effects into single passes to better balance ALU and bandwidth usage in your shaders.

#5133020 Checkerboard algorithm?

Posted by C0lumbo on 20 February 2014 - 01:16 PM

Try this:


checkerboardColour(Vec point, float fScale)
return ((int)(p.x/fScale) + (int)(p.y/fScale)) % 2 == 0 ? white : black;