Jump to content

Highest Reputation Content


#5215019 What are your opinions on DX12/Vulkan/Mantle?

Posted by Promit on 06 March 2015 - 02:56 PM

Many years ago, I briefly worked at NVIDIA on the DirectX driver team (internship). This is Vista era, when a lot of people were busy with the DX10 transition, the hardware transition, and the OS/driver model transition. My job was to get games that were broken on Vista, dismantle them from the driver level, and figure out why they were broken. While I am not at all an expert on driver matters (and actually sucked at my job, to be honest), I did learn a lot about what games look like from the perspective of a driver and kernel.

 

The first lesson is: Nearly every game ships broken. We're talking major AAA titles from vendors who are everyday names in the industry. In some cases, we're talking about blatant violations of API rules - one D3D9 game never even called BeginFrame/EndFrame. Some are mistakes or oversights - one shipped bad shaders that heavily impacted performance on NV drivers. These things were day to day occurrences that went into a bug tracker. Then somebody would go in, find out what the game screwed up, and patch the driver to deal with it. There are lots of optional patches already in the driver that are simply toggled on or off as per-game settings, and then hacks that are more specific to games - up to and including total replacement of the shipping shaders with custom versions by the driver team. Ever wondered why nearly every major game release is accompanied by a matching driver release from AMD and/or NVIDIA? There you go.

 

The second lesson: The driver is gigantic. Think 1-2 million lines of code dealing with the hardware abstraction layers, plus another million per API supported. The backing function for Clear in D3D 9 was close to a thousand lines of just logic dealing with how exactly to respond to the command. It'd then call out to the correct function to actually modify the buffer in question. The level of complexity internally is enormous and winding, and even inside the driver code it can be tricky to work out how exactly you get to the fast-path behaviors. Additionally the APIs don't do a great job of matching the hardware, which means that even in the best cases the driver is covering up for a LOT of things you don't know about. There are many, many shadow operations and shadow copies of things down there.

 

The third lesson: It's unthreadable. The IHVs sat down starting from maybe circa 2005, and built tons of multithreading into the driver internally. They had some of the best kernel/driver engineers in the world to do it, and literally thousands of full blown real world test cases. They squeezed that system dry, and within the existing drivers and APIs it is impossible to get more than trivial gains out of any application side multithreading. If Futuremark can only get 5% in a trivial test case, the rest of us have no chance.

 

The fourth lesson: Multi GPU (SLI/CrossfireX) is fucking complicated. You cannot begin to conceive of the number of failure cases that are involved until you see them in person. I suspect that more than half of the total software effort within the IHVs is dedicated strictly to making multi-GPU setups work with existing games. (And I don't even know what the hardware side looks like.) If you've ever tried to independently build an app that uses multi GPU - especially if, god help you, you tried to do it in OpenGL - you may have discovered this insane rabbit hole. There is ONE fast path, and it's the narrowest path of all. Take lessons 1 and 2, and magnify them enormously. 

 

Deep breath.

 

Ultimately, the new APIs are designed to cure all four of these problems.

* Why are games broken? Because the APIs are complex, and validation varies from decent (D3D 11) to poor (D3D 9) to catastrophic (OpenGL). There are lots of ways to hit slow paths without knowing anything has gone awry, and often the driver writers already know what mistakes you're going to make and are dynamically patching in workarounds for the common cases.

* Maintaining the drivers with the current wide surface area is tricky. Although AMD and NV have the resources to do it, the smaller IHVs (Intel, PowerVR, Qualcomm, etc) simply cannot keep up with the necessary investment. More importantly, explaining to devs the correct way to write their render pipelines has become borderline impossible. There's too many failure cases. it's been understood for quite a few years now that you cannot max out the performance of any given GPU without having someone from NVIDIA or AMD physically grab your game source code, load it on a dev driver, and do a hands-on analysis. These are the vanishingly few people who have actually seen the source to a game, the driver it's running on, and the Windows kernel it's running on, and the full specs for the hardware. Nobody else has that kind of access or engineering ability.

* Threading is just a catastrophe and is being rethought from the ground up. This requires a lot of the abstractions to be stripped away or retooled, because the old ones required too much driver intervention to be properly threadable in the first place.

* Multi-GPU is becoming explicit. For the last ten years, it has been AMD and NV's goal to make multi-GPU setups completely transparent to everybody, and it's become clear that for some subset of developers, this is just making our jobs harder. The driver has to apply imperfect heuristics to guess what the game is doing, and the game in turn has to do peculiar things in order to trigger the right heuristics. Again, for the big games somebody sits down and matches the two manually. 

 

Part of the goal is simply to stop hiding what's actually going on in the software from game programmers. Debugging drivers has never been possible for us, which meant a lot of poking and prodding and experimenting to figure out exactly what it is that is making the render pipeline of a game slow. The IHVs certainly weren't willing to disclose these things publicly either, as they were considered critical to competitive advantage. (Sure they are guys. Sure they are.) So the game is guessing what the driver is doing, the driver is guessing what the game is doing, and the whole mess could be avoided if the drivers just wouldn't work so hard trying to protect us.

 

So why didn't we do this years ago? Well, there are a lot of politics involved (cough Longs Peak) and some hardware aspects but ultimately what it comes down to is the new models are hard to code for. Microsoft and ARB never wanted to subject us to manually compiling shaders against the correct render states, setting the whole thing invariant, configuring heaps and tables, etc. Segfaulting a GPU isn't a fun experience. You can't trap that in a (user space) debugger. So ... the subtext that a lot of people aren't calling out explicitly is that this round of new APIs has been done in cooperation with the big engines. The Mantle spec is effectively written by Johan Andersson at DICE, and the Khronos Vulkan spec basically pulls Aras P at Unity, Niklas S at Epic, and a couple guys at Valve into the fold.

 

Three out of those four just made their engines public and free with minimal backend financial obligation.

 

Now there's nothing wrong with any of that, obviously, and I don't think it's even the big motivating raison d'etre of the new APIs. But there's a very real message that if these APIs are too challenging to work with directly, well the guys who designed the API also happen to run very full featured engines requiring no financial commitments*. So I think that's served to considerably smooth the politics involved in rolling these difficult to work with APIs out to the market, encouraging organizations that would have been otherwise reticent to do so.

[Edit/update] I'm definitely not suggesting that the APIs have been made artificially difficult, by any means - the engineering work is solid in its own right. It's also become clear, since this post was originally written, that there's a commitment to continuing DX11 and OpenGL support for the near future. That also helped the decision to push these new systems out, I believe.

 

The last piece to the puzzle is that we ran out of new user-facing hardware features many years ago. Ignoring raw speed, what exactly is the user-visible or dev-visible difference between a GTX 480 and a GTX 980? A few limitations have been lifted (notably in compute) but essentially they're the same thing. MS, for all practical purposes, concluded that DX was a mature, stable technology that required only minor work and mostly disbanded the teams involved. Many of the revisions to GL have been little more than API repairs. (A GTX 480 runs full featured OpenGL 4.5, by the way.) So the reason we're seeing new APIs at all stems fundamentally from Andersson hassling the IHVs until AMD woke up, smelled competitive advantage, and started paying attention. That essentially took a three year lag time from when we got hardware to the point that compute could be directly integrated into the core of a render pipeline, which is considered normal today but was bluntly revolutionary at production scale in 2012. It's a lot of small things adding up to a sea change, with key people pushing on the right people for the right things.

 

 

Phew. I'm no longer sure what the point of that rant was, but hopefully it's somehow productive that I wrote it. Ultimately the new APIs are the right step, and they're retroactively useful to old hardware which is great. They will be harder to code. How much harder? Well, that remains to be seen. Personally, my take is that MS and ARB always had the wrong idea. Their idea was to produce a nice, pretty looking front end and deal with all the awful stuff quietly in the background. Yeah it's easy to code against, but it was always a bitch and a half to debug or tune. Nobody ever took that side of the equation into account. What has finally been made clear is that it's okay to have difficult to code APIs, if the end result just works. And that's been my experience so far in retooling: it's a pain in the ass, requires widespread revisions to engine code, forces you to revisit a lot of assumptions, and generally requires a lot of infrastructure before anything works. But once it's up and running, there's no surprises. It works smoothly, you're always on the fast path, anything that IS slow is in your OWN code which can be analyzed by common tools. It's worth it.

 

(*See this post by Unity's Aras P for more thoughts. I have a response comment in there as well.)




#5276232 Vulkan Resources

Posted by L. Spiro on 17 February 2016 - 06:19 PM

Homehttps://www.khronos.org/vulkan/
SDKhttp://lunarg.com/vulkan-sdk/
 
AMD drivershttp://gpuopen.com/gaming-product/vulkan/ (Note that Vulkan support is now part of AMD’s official drivers, so simply getting the latest drivers for your card should give you Vulkan support.)
NVIDIA drivershttps://developer.nvidia.com/vulkan-driver (Note that Vulkan support is now part of NVIDIA’s official drivers, so simply getting the latest drivers for your card should give you Vulkan support.)
Intel drivershttp://blogs.intel.com/evangelists/2016/02/16/intel-open-source-graphics-drivers-now-support-vulkan/
 
Quick referencehttps://www.khronos.org/registry/vulkan/specs/1.0/refguide/Vulkan-1.0-web.pdf
Referencehttps://www.khronos.org/registry/vulkan/specs/1.0/apispec.html
 
GLSL-to-SPIR-Vhttps://github.com/KhronosGroup/glslang

Sample code: https://github.com/LunarG/VulkanSamples
https://github.com/SaschaWillems/Vulkan
https://github.com/nvpro-samples
https://github.com/nvpro-samples/gl_vk_chopper
https://github.com/nvpro-samples/gl_vk_threaded_cadscene
https://github.com/nvpro-samples/gl_vk_bk3dthreaded
https://github.com/nvpro-samples/gl_vk_supersampled
https://github.com/McNopper/Vulkan
https://github.com/GPUOpen-LibrariesAndSDKs/HelloVulkan
 
C++https://github.com/nvpro-pipeline/vkcpp
https://developer.nvidia.com/open-source-vulkan-c-api

Getting startedhttps://vulkan-tutorial.com/
https://renderdoc.org/vulkan-in-30-minutes.html
https://www.khronos.org/news/events/vulkan-webinar
https://developer.nvidia.com/engaging-voyage-vulkan
https://developer.nvidia.com/vulkan-shader-resource-binding
https://developer.nvidia.com/vulkan-memory-management
https://developer.nvidia.com/opengl-vulkan
https://github.com/vinjn/awesome-vulkan

Videoshttps://www.youtube.com/playlist?list=PLYO7XTAX41FPg08uM_bgPE9HLgDAyzDaZ

 
 
L. Spiro




#5027729 Anyone here a self-taught graphics programmer?

Posted by L. Spiro on 31 January 2013 - 10:00 PM

I am.
I started when I was late 13 or early 14 and used DirectX samples and online tutorials, but while struggling at the time with also learning C++ it was too overwhelming and I put it down for a few years, coming back to it at around 16 or 17.
 
I just bought books, read online articles, and worked on it by myself until things clicked and fell into place.
Repeat for many years until today.
 
I do it as a living for tri-Ace, where I work on this engine, primarily on graphics and optimizations.
http://www.youtube.com/watch?v=6cuXgRVMvZ0
[UPDATE]
I now work at Square Enix on this engine:


[/UPDATE]
 
 
The main challenge I faced was at the start when I was overwhelmed by all the things I was trying to learn at once.
After that, things were taken one step at a time and slowly.  It isn’t too hard when you take it at a better pace.
 
 
L. Spiro




#5291078 A Brain Dump of What I Worked on for Uncharted 4

Posted by Allen Chou on 11 May 2016 - 12:36 AM

Uncharted-4-logo-1024x576.jpg
 
 
This post is part of My Career Series.
 
Now that Uncharted 4 is released, I am able to talk about what I worked on for the project. I mostly worked on AI for single-player buddies and multiplayer sidekicks, as well as some gameplay logic. I'm leaving out things that never went in to the final game and some minor things that are too verbose to elaborate on. So here it goes:
 
 
The Post System
 
Before I start, I'd like to mention the post system we used for NPCs. I did not work on the core logic of the system; I wrote client code that makes use of this system.Posts are discrete positions within navigable space, mostly generated from tools and some hand-placed by designers. Based on our needs, we created various post selectors that rate posts differently (e.g. stealth post selector, combat post selector), and we pick the highest-rated post to tell an NPC to go to.
 
posts-1024x576.png
 
 
Buddy Follow
 
The buddy follow system was derived from The Last of Us.The basic idea is that buddies pick positions around the player to follow. These potential positions are fanned out from the player, and must satisfy the following linear path clearance tests: player to position, position to a forward-projected position, forward-projected position to the player.
 
follow-request-1024x576.png
 
Climbing is something present in Uncharted 4 that is not in The Last of Us. To incorporate climbing into the follow system, I added the climb follow post selector that picks climb posts for buddies to move to when the player is climbing.
 
climb-post-1024x576.png
 
It turned out to be trickier than I thought. Simply telling buddies to use regular follow logic when the player is not climbing, and telling them to use climb posts when the player is climbing, is not enough. If the player quickly switch between climbing and non-climbing states, buddies would oscillate pretty badly between the two states. So I added some hysteresis, where the buddies only switch states when the player has switched states and moved far enough while maintaining in that state. In general, hysteresis is a good idea to avoid behavioral flickering.
 
 
Buddy Lead
 
In some scenarios in the game, we wanted buddies to lead the way for the player. I ported over and updated the lead system from The Last of Us, where designers used splines to mark down the general paths we wanted buddies to follow while leading the player.
 
lead-spline-1024x576.png
 
In case of multiple lead paths through a level, designers would place multiple splines and turned them on and off via script.
 
multiple-lead-splines-1024x576.png
 
The player's position is projected onto the spline, and a lead reference point is placed ahead by a distance adjustable by designers. When this lead reference point passes a spline control point marked as a wait point, the buddy would go to the next wait point. If the player backtracks, the buddy would only backtrack when the lead reference point gets too far away from the furthest wait point passed during last advancement. This, again, is hysteresis added to avoid behavioral flickering.
 
I also incorporated dynamic movement speed into the lead system. "Speed planes" are placed along the spline, based on the distance between the buddy and the player along the spline. There are three motion types NPCs can move in: walk, run, and sprint. Depending on which speed plane the player hits, the buddy picks an appropriate motion type to maintain distance away from the player. Designers can turn on and off speed planes as they see fit. Also, the buddy's locomotion animation speed is slightly scaled up or down based on the player's distance to minimize abrupt movement speed change when switching motion types.
 
speed-planes-1024x576.png
 
 
Buddy Cover Share
 
In The Last of Us, the player is able to move past a buddy while both remain in cover. This is called cover share.
 
tlou-cover-share-1024x576.png
 
In The Last of Us, it makes sense for Joel to reach out to the cover wall over Ellie and Tess, who have smaller profile than Joel. But we thought that it wouldn't look as good for Nate, Sam, Sully, and Elena, as they all have similar profiles. Plus, Uncharted 4 is much faster-paced, and having Nate reach out his arms while moving in cover would break the fluidity of the movement. So instead, we decided to simply make buddies hunker against the cover wall and have Nate steer slightly around them.
 
cover-share-1024x576.png
 
The logic I used is very simple. If the projected player position based on velocity lands within a rectangular boundary around the buddy's cover post, the buddy aborts current in-cover behavior and quickly hunkers against the cover wall.
 
cover-share-debug-1024x576.png
 
 
Medic Sidekicks
 
 
I was in charge of multiplayer sidekicks, and I'd say medics are the most special among all. Medic sidekicks in multiplayer require a whole new behavior that is not present in single-player: reviving downed allies and mirroring the player's cover behaviors.
 
medic-revive-1024x576.png
 
Medics try to mimic the player's cover behavior, and stay as close to the player as possible, so when the player is downed, they are close by to revive the player. If a nearby ally is downed, they would also revive the ally, given that the player is not already downed. If the player is equipped with the RevivePak mod for medics, they would try to throw RevivePaks at revive targets before running to the targets for revival; throwing RevivePaks reuses the grenade logic for trajectory clearance test and animation playback, except that I swapped out the grenades with RevivePaks.
 
medic-revivepak-1024x576.png
 
 
Stealth Grass
 
 
Crouch-moving in stealth grass is also something new in Uncharted 4. For it to work, we need to somehow mark the environment, so that the player gameplay logic knows whether the player is in stealth grass. Originally, we thought about making the background artists responsible of marking collision surfaces as stealth grass in Maya, but found out that necessary communication between artists and designers made iteration time too long. So we arrived at a different approach to mark down stealth grass regions. I added an extra stealth grass tag for designers in the editor, so they could mark the nav polys that they'd like the player to treat as stealth grass, with high precision. With this extra information, we can also rate stealth posts based on whether they are in stealth grass or not. This is useful for buddies moving with the player in stealth.
 
stealth-grass-1024x576.png
 
 
Perception
 
 
Since we don't have listen mode in Uncharted 4 like The Last of Us, we needed to do something to make the player aware of imminent threats, so the player doesn't feel overwhelmed by unknown enemy locations. Using the enemy perception data, I added the colored threat indicators that inform the player when an enemy is about to notice him/her as a distraction (white), to perceive a distraction (yellow), and to acquire full awareness (orange). I also made the threat indicator raise a buzzing background noise to build up tension and set off a loud stinger when an enemy becomes fully aware of the player, similar to The Last of Us.
 
threat-colors-1024x601.png
 
 
Investigation
 
This is the last major gameplay feature I worked on before going gold. I don't usually go to formal meetings at Naughty Dog, but for the last few months before gold, we had a at least one meeting per week driven by Bruce Straley or Neil Druckmann, focusing on the AI aspect of the game. Almost after every one of these meetings, there was something to be changed and iterated for the investigation system. I went through many iterations before arriving at what we shipped with the final game.
 
There are two things that create distractions and would cause enemies to investigate: player presence and dead bodies. When an enemy registers a distraction (distraction spotter), he would try to get a nearby ally to investigate with him as a pair. The closer one to the distraction becomes the investigator, and the other becomes the watcher. The distraction spotter can become an investigator or a watcher, and we set up different dialog sets for both scenarios ("There's something over there. I'll check it out." versus "There's something over there. You go check it out.").
 
In order to make the start and end of investigation look more natural, I staggered the timing of enemy movement and the fading of threat indicators, so the investigation pair don't perform the exact same action at the same time in a mechanical fashion.
 
staggered-investigation-1024x576.png
 
If the distraction is a dead body, the investigator would be alerted of player presence and tell everyone else to start searching for the player, irreversibly leaving ambient/unaware state. The dead body discovered would also be highlighted, so the player gets a chance to know what gave him/her away.
 
dead-body-highlight-1024x576.png
 
Under certain difficulties, consecutive investigations would make enemies investigate more aggressively, having a better chance of spotting the player hidden in stealth grass. In crushing difficulty, enemies always investigate aggressively.
 
 
Dialog Looks
 
This is also among the last few things I worked on for this project.Dialog looks refers to the logic that makes characters react to conversations, such as looking at the other people and hand gestures. Previously in The Last of Us, people spent months annotating all in-game scripted dialogs with looks and gestures by hand. This was something we didn't want to do again. We had some scripted dialogs that are already annotated by hand, but we needed a default system that handles dialogs that are not annotated, which I put together. The animators are given parameters to adjust the head turn speed, max head turn angle, look duration, cool down time, etc.
 
dialog-look-1024x576.png
 
 
Jeep Momentum Maintenance
 
One of the problems we had early on regarding the jeep driving section in the Madagascar city level, is that the player's jeep can easily spin out and lose momentum after hitting a wall or an enemy vehicle, throwing the player far behind the convoy and failing the level.
 
My solution was to temporarily cap the angular velocity and change of linear velocity direction upon impact against walls and enemy vehicles. This easy solution turns out pretty effective, making it much harder for players to fail the level due to spin-outs.
 
jeep-momentum-maintenance-1024x576.png
 
 
Vehicle Deaths
 
Driveable vehicles are first introduced in Uncharted 4. Previously, only NPCs can drive vehicles, and those vehicles are constrained to spline rails. I was in charge of handling vehicle deaths.There are multiple ways to kill enemy vehicles: kill the driver, shoot the vehicle enough times, bump into an enemy bike with your jeep, and ram your jeep into an enemy jeep to cause a spin-out. Based on various causes of death, a death animation is picked to play for the dead vehicle and all its passengers. The animation blends into physics-controlled ragdolls, so the death animation smoothly transitions into physically simulated wreckage.
 
bike-ragdoll-1024x576.png
 
For bumped deaths of enemy bikes, I used the bike's bounding box on the XZ plane and the contact position to determine which one of the four directional bump death animations to play.
 
bike-obb-1024x576.png
 
As for jeep spin-outs, I test the jeep's rotational deviation from desired driving direction against a spin-out threshold.
 
jeep-spin-out-1024x576.png
 
When playing death animations, there's a chance that the dead vehicle can penetrate walls. I used a sphere cast, from the vehicle's ideal position along the rail if it weren't dead, to where the vehicle's body actually is. If a contact is generated from the sphere cast, I shifted the vehicle in the direction of the contact normal by a fraction of penetration amount, so the de-penetratiton happens gradually across multiple frames, avoiding positional pops.
 
bike-sphere-cast-1024x576.png
 
I did a special type of vehicle death, called vehicle death hint. They are context-sensitive death animations that interact with environments. Animators and designers place these hints along the spline rail, and specify entry windows on the splines. If a vehicle is killed within an entry window, it starts playing the corresponding special death animation. This feature started off as a tool to implement the specific epic jeep kill in the 2015 E3 demo.
 
 
Bayer Matrix for Dithering
 
We wanted to eliminate geometry clipping the camera when the camera gets too close to environmental objects, mostly foliage. So we decided to fade out pixels in pixel shaders based on how close the pixels are to the camera. Using transparency was not an option, because transparency is not cheap, and there's just too much foliage. Instead, we went with dithering, combining a pixel's distance from the camera and a patterned Bayer matrix, some portion of the pixels are fully discarded, creating an illusion of transparency.
 
dithering-1-1024x576.png
 
Our original Bayer matrix was an 8x8 matrix shown on this Wikipedia page. I thought it was too small and resulted in banding artifacts. I wanted to use a 16x16 Bayer matrix, but it was no where to be found on the internet. So I tried to reverse engineer the pattern of the 8x8 Bayer matrix and noticed a recursive pattern. I would have been able to just use pure inspection to write out a 16x16 matrix by hand, but I wanted to have more fun and wrote a tool that can generate Bayer matrices sized any powers of 2.
 
bayer-matrix.gif
 
After switching to the 16x16 Bayer matrix, there was a noticeable improvement on banding artifacts.
 
dithering-1024x295.png
 
 
Explosion Sound Delay
 
This is a really minor contribution, but I'd still like to mention it. A couple weeks before the 2015 E3 demo, I pointed out that the tower explosion was seen and heard simultaneously and that didn't make sense. Nate and Sully are very far away from the tower, they should have seen and explosion first and then heard it shortly after. The art team added a slight delay to the explosion sound into the final demo.
 
 
Traditional Chinese Localization
 
I didn't switch to Traditional Chinese text and subtitles until two weeks before we were locking down for gold, and I found some translation errors. Most of the errors were literal translations from English to Traditional Chinese and just did't work in the contexts. I did not think I would have time to play through the entire game myself and look out for translation errors simultaneously. So I asked multiple people from QA to play through different chapters of the game in Traditional Chinese, and I went over the recorded gameplay videos as they became available. This proved pretty efficient; I managed to log all the translation errors I found, and the localization team was able to correct them before the deadline.
 
 
That's It
 
These are pretty much the things I worked on for Uncharted 4 that are worth mentioning. I hope you enjoyed reading it. :)



#5219237 Direct3D 12 documentation is now public

Posted by Promit on 26 March 2015 - 12:11 AM

Have fun!

https://msdn.microsoft.com/en-us/library/windows/desktop/dn899121(v=vs.85).aspx

 

P.S. Yes, SlimDX will be supporting D3D 12. We're going to build a modern version of the library that is streamlined to 12 + utilities/math only, and supporting all Win10/D3D 12 hardware platforms. It will be slick.




#4983074 What programmers want from a designer

Posted by jbadams on 23 September 2012 - 07:52 PM

Disclaimer: I'm probably going to write as if I'm speaking on behalf of many (or all) programmers, because I feel it is the style in which I am best able to express these ideas, but the following is all based upon my own personal opinions and experiences.  Other programmers may disagree with some or all of my points of view.

I know you wanted to look beyond them, but before putting them aside I'd like to expand a little bit on money and on the idea.


Money

Obviously, it can really help your recruiting efforts if you're able to pay your programmer.  We put hundreds (even thousands) of hours into learning our skill, and we have limited time available in which to use that skill.  If you're able to pay for that time it's more likely a programmer will be interested in spending time to work on your project.  However, not all projects can afford to spend much -- if anything -- and programmers are sometimes willing to work for discounted rates or even for free.

For a project to be considered without pay, it still needs to satisfy a couple of other money-related conditions:

  • It needs to be fair.  If you're not paying us then you shouldn't be getting paid either, or if there is pay involved you shouldn't be offering your programmer some small amount whilst others -- especially yourself -- get much more.
  • Even if you're not paying for it, it needs to be obvious that you understand and respect that our time is valuable.  You might be able to find a programmer who would be willing to work for free or at a discount, but they would be unlikely to do so for a project where people think programming isn't worth paying for.
  • Beyond compensating people for their time, money also goes towards showing commitment to and belief in the project.  If you're not paying your team -- programmers and otherwise -- then you damn well better show your commitment and belief in the project in other ways.
  • You need to show that you're sensible and -- even if you're not an expert -- have a bit of basic business sense.  If you're aiming for a commercial product then profit sharing is a nice thing to do, but you should be realistic about the fact that this doesn't count as paying your staff; they might not get anything out of such a deal for a variety of reasons including not completing the project, poor sales/conversions, or even running into legal problems either before or after release.
  • By not paying your team members you're asking them to volunteer their valuable time to the project.  You should be making a similar -- if not greater -- contribution of your own time.  Skilled programmers will not work for the dreaded "idea guy", and as essential as an idea is, you should not expect us to attach more than a small amount of value to your idea; you need to be contributing some value beyond that.

You might also show both your commitment, belief in the project, and good business sense by saving up your own money in order to pay other costs such as licencing fees for tools and engines, website or repository hosting, etc.


The idea

In addition to grabbing the programmer's interest, the idea needs to be specific, detailed, and well thought-out.  If you just have a general, high-level concept then you're probably going to have difficulty finding a programmer -- they have general, high-level concepts (and probably even more detailed ideas) of their own.

However, you shouldn't be expecting to simply hand over a design document and have it treated as The Word of God™ to be followed exactly to the letter so that the One True Game™ will result; that's code-monkey work, and you have no choice but to pay for it to be done.  Any experienced programmer will be expecting that a successful game will be the result of an iterative process.

You need to be willing to share the idea.  No skilled programmer is going to waste time privately contacting you on the chance that your idea might be good, you need to provide the idea -- or at least a substantial part thereof -- up-front to be assessed and hopefully gain interest.  Don't suffer from "stupid paranoia", and don't be one of those foolish people who thinks every facet of their latest idea is truly unique.



So... what else are we looking for...


Clear communication (and good presentation)

For both designers and project leaders, one of the most important skills is communication, and our first impression of this is your recruiting advert and any documentation you choose to attach.  You need to put your best foot forward:

  • Take the time to use proper spelling, grammar, and punctuation.  Don't use "1337" or "txt" speak, or unnecessary abbreviations.
  • Don't just ramble.  Take the time to properly structure both your advert and any responses.  Use formatting options, and white-space including paragraphs, indentation, etc.
  • Test any links you include to make sure they work correctly and take the time to fix them if they're broken.

Your contribution (you need to be useful!)

I covered this to an extent in the section on money, but your idea is not enough.  If you're just providing an idea that you want made you're going to have to pay someone.

Otherwise you need to provide useful skills, and you need to be contributing as much time and effort to the project yourself as you expect from others.  It does not count to say you've already finished your contribution by writing up the idea.

You might also be contributing to marketing, sales, etc., and that's a great skill to have that will really help a final product, but again it isn't enough:  you need to be contributing something during the project whilst the programmer is also working on it.

Ideally, you might produce some or all of the art and/or audio for the game, or might be doing an equal share of the programming yourself.  If you're claiming to have design skills that will be used throughout the project -- and again, having created the idea up-front does not count -- you'll need to be able to clearly explain what those skills are, and you'll need something (previous projects, demo games made with Game Maker, board games, card games, etc.) that demonstrates you're actually capable with those skills.


Understanding of the industry/market/processes

Programmers want to be confident that you understand the realities of the industry and market, and that you have some idea of the process that goes into creating a game.  

Gaps in your knowledge are fine if you're both up front and honest about them and are willing to learn -- even better if you're obviously pro-active about it -- from others, but no one wants to work with someone who is completely ignorant or misinformed about how things really work.  This is especially true if you stubbornly stick to your guns when provided with evidence to the contrary; it's fine to want to try an unusual approach, but you need to at least acknowledge it as such, and should never simply stick your head in the sand and refuse to change an incorrect belief.

You don't need to be an expert at everything -- you wouldn't need us if you were! -- but you should have at least a general idea of the entire process.


Reasonable expectations

If you're not paying your programmers, you can't expect us to treat your project like a proper job.  It's probably going to take longer than you might have liked, and you'll have to gracefully accept the occasional interruptions due to real-life issues or the opportunity for paying work.

You should also not be expecting to make a super smash hit game of AAA quality with hour upon hour of intricate storyline.

You should expect to face difficulties and to have to work really hard to see your project through to completion.


Honesty and integrity

We're more comfortable working with someone who is open and honest.  Don't misrepresent yourself or the project, and don't try to rip people off, or no programmer will want to work with you, and you almost certainly will be caught out eventually.


A sensibly sized (i.e. small) team

AAA games are made by huge teams with massive budgets, and they have a lot of management and official policy -- as well as the incentive of proper pay -- to make that happen properly.

Successful indie and hobbyist games are usually the product of much smaller teams, often ranging from only two people up to a handful.  Larger long-term open-sourced projects might have more contributors over time, but even then usually have a smaller active "core" team working at any one time; they also begin with either an individual or a much smaller team, and only end up with those larger numbers of contributors once substantial progress has been made.

If you're looking to recruit large numbers of people to an unpaid project, most skilled programmers will expect you to fail like many projects before and won't consider you.  Trying to do this probably indicates unreasonable goals and expectations, and is in most cases indicative of an overly ambitious project.



Art, documentation, pre-recorded audio, etc?

Good presentation of whatever you do have is very important, and it should be obvious that you are capable and committed to the project.

The working demo or video of a semi-functional game is great to see.

Concept art that was specifically created for your project is good.  Completed (or nearly complete work-in-progress) art is much better.  Concept art that you simply collected from existing sources might help to explain your project to artists, but often isn't ideal and can sometimes be indicative of a lack of commitment; why not simply delay and save up to get your own?

Audio usually seems premature unless your project is to the stage of having a working demo or game-play video.

Detailed documentation is good, bearing in mind the notes above about iterative design and the understanding that your idea (and any design documents containing it) are not the be-all and end-all, and will not be acceptable as your only contribution.


Oh, and don't bother with "I'll have next week", where x is concept art, a video, a website, or whatever.  Wait till next week and post with x included.

...wow, that ended up quite long, I hope it's helpful!  Perhaps I should clean this up into an article at some point...
Posted Image Posted Image

 




#5233140 Why don't game engines run in kernel mode?

Posted by Bacterius on 06 June 2015 - 08:48 AM

No. Ignoring for a moment that the virtual to physical address space mapping is done in hardware through the MMU, which has a built-in cache, so the address space translation is pretty much free, the main bottleneck in games these days is either CPU/memory/IO (which kernel mode can't really help much with) or graphics API overhead (which kernel mode would make worse, since there is no usable graphics API in kernel mode, so you'd have to basically reimplement a D3D or OpenGL runtime in kernel mode for every version of every display driver you intend to support, which is not realistic). Add to that the fact that switching from user to kernel mode is not free, and that kernel mode development is harder (and more difficult for cross-platform development), that all code has bugs and that in kernel mode any bug has the potential to, say, silently corrupt your physical memory, and that since Vista any Windows drivers you use must be signed or just won't be loaded, and that the driver would be sitting there idling for no reason even when the game is not running, that you'd be unable to run the game on a system you don't have administrative privileges on... just, no. User mode exists for a reason, and there really isn't much performance to be gained in kernel mode anyway compared to the work you'd need to put in to make it work to begin with.




#5285767 Should getters and setters be avoided?

Posted by samoth on 08 April 2016 - 05:10 AM

As usual, you should not take everything too seriously.

 

There is a common behavioural pattern of someone doing something, then someone else noticing that it's actually a clever idea and calling it "best practice". Then someone calls it a "pattern", and soon a witch hunt starts against anyone not applying the pattern. A year later, someone says "considered evil" and the word "antipattern" comes up, and the same witch hunt starts in the opposite direction. And then, another year later, someone says "no longer considered evil".

 

Yes, there are people who use getters and setters in a way that makes you facepalm and moan. But there are also legitimate, sensible applications of getters and setters.

 

Just like with every feature/technique/pattern there are people who recommend it, sometimes for good reasons, sometimes for strawman reasons, and sometimes for religious reasons, and an equal number of people who say the exact opposite. And there are people who use it sensibly, when it's applicable. Try to be among the latter group, and you're good.

 

Whenever it comes to "philosophy" or "religion", it is often hard or impossible to tell what's true and what is not. There is usually no absolute either (neither absolute right nor wrong). Consequently, the examples given to justify one's religion may make perfect sense or may be utter bullshit, depending on which angle you're coming from.

 

For example, take the dog example on Yegor's site. You must think of a dog as a living object. You cannot change its weight, and the dog is immutable. OK, alright... but as anyone who has ever had a pet animal knows, an animal is nowhere near immutable. They grow, they grow fat, they get sick, and they die. Surely, the notion of having to euthanize the animal and replace it with a similar looking one whenever it gains weight or whenever it gets ill is not very "natural", is it?

Thinking about the dog as an object, the dog cannot return NULL, and that is a good thing. Why not, exactly? Real dogs do return NULL when they feel like it. Returning NULL, or figuratively telling "I don't want" or "I don't have any" in another way is a legitimate thing to do. Should a dog be allowed to throw exceptions? You tell me.

 

A bank account should be immutable? So each time you WithdrawMoney(), the bank reopens a new, identical account for you, and deducts the amount from only the original account? Well, that looks like a pattern that should be universally applied! Please tell my bank. Also tell them that I should be able to modify my account balance directly, it's so annoying that WithdrawMoney(-100000) fails with an error message. SetBalance(100000000) doesn't seem to work either.

 

Another scenario where getters/setters are legitimate (in the same sense of doing plausability/validity checks) that immediately comes to mind is placing things in a GUI. Let's say a widget or window has the SetSize setter, which will... duh... set its size. How useless! Except... you want things to be visible on screen, and SetSize will make sure that's the case, even if you call it with invalid values.

 

Another thing is, obviously, hiding implementation details. Rather than assigning true to a boolean, you might call SetEnabled or Enable (which is really the same thing). Why SetSize anyway? I can just change that integer after making sure my values are sane, right?

 

SetEnabled might acquire a mutex because... surprise... the implementation is multi-threaded, which you didn't know of course, and just changing the value whenever you feel like it might have desastrous consequences. Maybe you don't need a mutex, but you need an atomic operation to set a pointer to an object in order to avoid having a worker pick up an intermediate garble value. Or something, whatever it is. The Setter makes sure that whatever it is, it's what happens, and you need not know.

 

It also makes sure that if, for whatever reason, you decide to change your internal representation from a 32-bit integer to a 64-bit integer 10 years in the future, the existing accessors remain valid. GetTickCount under Windows (not object oriented, but same thing really) is a real-life example, which is nothing but an "accessor" that used to simply read the 32-bit integer at 0x7FFE0008. It so happens that now there also exists GetTickCount64 which does the same, only with a bigger integer, but software using the old function still works. And it works under 64-bit Windows as well where the address is a different one. Under the hood, pretty much everything has changed, but 15-year old software still works the same and doesn't need to know. And not only is it "doesn't need to know", but indeed "doesn't want to know".

 

SetSize in your vector-like class might just change an integer or might have to reallocate. In your database object, a function with the same name might change a number, or might cause a file's logical size or a mapping to be altered, optionally dealing with OS errors.




#5016969 Good habits for game development

Posted by Servant of the Lord on 02 January 2013 - 10:28 PM

My personal and non-professional opinion:
  • Write clean code the first time through. Don't write messy code and promise yourself that you'll "clean it up later".
  • Recognize that clean code is better than fast code. It's easy for clean code to be made fast, but hard for fast code to be made clean.
  • Counter tip: Don't be so obsessed with clean code that your project's progress stalls.
  • Avoid macroes, except when they make your code easier, safer, and cleaner.
  • Avoid globals, except when they make your code easier, safer, and cleaner.
  • Avoid gotos, except when they make your code easier, safer, and cleaner.
  • Avoid people that say macroes, globals, and gotos are perfectly fine.
  • Avoid people that say macroes, globals, and gotos are never allowed.
  • Listen to people that say macroes, globals, and gotos should be rarely* used, but who recognize exceptions. smile.png
  • Use RAII, Single Responsibility Principle, and other similar concepts.
  • Don't embed content into code - load content from file or something similar.
  • Create and use a consistent coding style for your code.
  • Use the C++11 smart pointers and std::make_shared(). (use Boost's versions if you can't use C++11)
  • Avoid calling 'new' and 'delete' yourself, except in the rare situations** where they are required.
  • Don't re-invent the wheel, unless it's a small wheel, isn't in the standard library, and won't take you long.
  • Make your code as self-documenting as possible, so it can be easily understood without comments.
  • Comment the code it anyway.
  • Finish the projects and features you start.
  • After you learn to finish the projects or you start, then learn to shoot the projects or features that need to die.
  • Worry about writing poor code. Aim for high quality code, or at least good code.
  • Don't worry about writing perfect code.
  • Really. Don't worry about writing perfect code.

*90% of the time, a global shouldn't be a global, 95% of the time, a macro should be a template or a regular function, 99.9% of the time, a goto is being misused. 100% of these percentages are made up, but illustrate a point anyway. =)

 

**I find that it's rare, but not extremely rare. For performance reasons, probably 19 out of 20 of my dynamic allocations should be smart pointers - but I suppose that would vary from project to project. The vast majority allocations should be on the stack, and neither smart pointers nor raw allocations.




#5287082 Is inheritance evil?

Posted by Aardvajk on 15 April 2016 - 01:21 PM

Of course it isn't. It's s tool that can be used or abused.

Even deep inheritance trees can be appropriate in certain domains. Look at something like Qt for example.

There is, though, a huge amount of very bad OOP out there and a great deal of confusion about the is-a and has-a relationships.

But inheritance itself is not the cause of this. Personally I blame Java :).


#5170701 Protect Against Speed hack

Posted by L. Spiro on 31 July 2014 - 03:34 PM

Once upon a time a man named Bob walked out into a patch of dirt and heard a voice say, “If you build it, they will come.”

So he got to work building a baseball stadium because that’s what you always build when you hear those words.

 

About 7 years later he sat atop his stadium, proud as could be, and waited for them to come.

And he waited.  And waited.

A year later he wondered why no one had come, and then he looked around and realized he had just built his stadium in the middle of the Sahara desert.

As he realized he should have instead spent his time building water-extraction devices, solar panels, and other useful things, a loud, “*$&! ME” shattered the desert silence.

 

 

Lesson: Make sure you actually need what you make.

 

 

What makes you think you need speed-hack protection?

Because you know that they exist and people use them and they could theoretically be used on your game?

Bob knew that baseball exists and people like to play and that they could theoretically play in the Sahara desert.

 

That doesn’t mean they will.

That doesn’t mean he needed to build a stadium there, and his time would be better spent doing almost anything else.

 

Before you spend time on this, make sure you actually have a reason.  Not that people exist who do it, but that a large number of people will actually do it specifically to your game and that that causes headaches for other players.  If it is entirely single-player (and I can tell by your UpdateFrame() that it is (why is that part of a timer??)) then why do you care if the player cheats?

 

 

 

If you want some actual practical take-home advice other than the most-obvious, “You don’t need it,” try making a game where people are having so much fun the thought of speed-hacking (or perhaps cheating in general) never crosses their minds.

In almost all games I play it never crosses my mind to speed-hack, because I am either having too much fun or in the case of SimCity (and friends) there is already a time-hack built in.

 

 

L. Spiro




#5305711 Is it pathetic to never get actually helpful answers here?

Posted by Alberth on 14 August 2016 - 03:30 AM

I briefly browsed through some of your topics, and what I notice is

 

- You seem to ask very high-level questions ("In the industry, how does one do ....", or "How I do <something complicated>").

- You don't seem to give feedback in the topic to the information that you're given.

 

Normally, there are as many answers to a question, as there are persons on this forum. This holds even more for high-level questions. Such question never have a single answer. The answer changes, depending on lots of details that we don't know. The generality of the question doesn't give many clues for us, so we just try to give the best answer with the small amount of detail information that you provide. It is indeed likely that those answers are not what you look for, but we need more information for a better answer.

 

 

The second point is more important, I think. If an answer does not work for you, tell us why, or clarify what you aim for. We cannot read your mind. I think most answers are honest attempts to answer your question. If it answers the wrong thing for you, it's a sign there is a mis-communication somewhere. You didn't provide some information that is needed to steer the answers in your direction, or the person answering missed some clues that you wrote in your post.

 

Writing about a problem that you have is hard. I used to work together with someone that studied CS, just like me. When we discussed something, I always needed at least 2 long emails sent back and forth, just to explain the problem, and to get an understanding that we both were at the same page. Only then, we could start discussing details of the problem itself, and directions of solving it. While we talked in details, I did need those 2 emails back and forth, while we did the same study, and both work in the same field!

 

Here, there is a lot more diversity in persons and experience. The problems being discussed are also much more varying. It's amazing we solve anything at all.

Capturing a problem in a few lines of text is extremely difficult. Getting the other side to understand what you write is even harder.

 

For this reason, it is useful to reply on new information that you get. Assume the other side is seriously trying to help you, but there is a problem in communicating. try to understand what you get as response (you may want to think about the answer for a day or 2 even), and if it doesn't work out, try to explain what exactly fails for you. The more details you provide, the better we can answer your problem.

 

 

On the other hand, this forum is not a "we solve your problem for you" forum. You should not expect copy/paste-ready answers here. Th aim of this forum is to learn you programming, and that means finding your own way out of your problems. We can steer you in the generally right direction, give alternative solutions, find stupid simple errors, and review your code, but we can't tell you how to solve your problem in the literal sense, as that defeats the goal of learning to program. Also, that service would cost too much time, you would need to give money in exchange if you want a solution without having to solve it yourself.

 

 

Please reply.




#5044042 The games that everybody writes.

Posted by Haps on 17 March 2013 - 03:26 PM

Crash to Desktop is wildly popular amongst beginners and experts alike.




#5027737 Anyone here a self-taught graphics programmer?

Posted by Hodgman on 31 January 2013 - 10:29 PM

I have pretty much the same story as L. Spiro. I'd started learning C++ as a teenager, and played around with OpenGL tutorials from time to time. The easiest way that I could make cool games was by modding existing ones, so I learned most of my 3D math by accident, as a result of playing around with other people's game code. When it came to high-school physics class, I realised I already knew about concepts like vectors and forces etc, except sometimes with the wrong terminology.

 

I then did "IT" at university, but kept playing around with D3D and GL in my spare time, and tried to use it in university programming assignments whenever I could. I did manage to take one elective class which actually taught us basic fixed-function D3D, but I aced that class because I'd already taught myself the subject matter! Unfortunately I wasn't able to take the theoretical computer graphics classes at all.

I just bought books, read online articles, and worked on it by myself until things clicked and fell into place.

Repeat for many years until today.

^^ this... except I couldn't afford to buy books at all until I started working as a programmer wink.png

 

In one of my early jobs, there was an opening in the engine department, for someone who knew shaders and graphics programming. I put my hand up based on my hobby work, and was more qualified than anyone else that went for it, so I got transferred into that department and got to start doing it professionally. At my next job I applied to be a graphics/special-effects specialist, and got the job (with the title of "junior effects programmer" to begin with dry.png) and I was paired up with a guy who'd been doing it for years, whom I learned a lot from, just by sitting next to him. I also learned a lot by being exposed to the low level APIs on the consoles, and their spec documents. After that, I got a job as the main graphics programmer at a different company in their engine team, and was thrown in the deep end along with the specifications for all the consoles and the responsibility of making a new renderer from scratch biggrin.png




#4967975 "Must-Learn" Languages

Posted by Hodgman on 09 August 2012 - 10:14 PM

Instead of 7 specific languages, I'd give you 7 categories:

A systems language, like C, C++.
A managed language, like Java, C#.
A weakly typed language, like Python, Lua.
A web-server centric language, like PHP, Ruby.
An automation language, like Bash, Batch.
A functional language, like Erlang, Haskell.
A domain-specific language, like SQL, Mathematica.

[edit]This is a good 8th category:

In my opinion add an Assembler Language and the list is complete

And if you want a 9th, try a logic language, like Prolog.


#5159205 Best comment ever

Posted by alkisbkn on 09 June 2014 - 02:29 AM

/*

      .o.       ooooooooo.   ooooo      ooo   .oooooo.   ooooo        oooooooooo.   o8o  .oooooo..o      oooooooooooo       .o.       ooooo     ooo ooooo        ooooooooooooo 
     .888.      `888   `Y88. `888b.     `8'  d8P'  `Y8b  `888'        `888'   `Y8b  `YP d8P'    `Y8      `888'     `8      .888.      `888'     `8' `888'        8'   888   `8 
    .8"888.      888   .d88'  8 `88b.    8  888      888  888          888      888  '  Y88bo.            888             .8"888.      888       8   888              888      
   .8' `888.     888ooo88P'   8   `88b.  8  888      888  888          888      888      `"Y8888o.        888oooo8       .8' `888.     888       8   888              888      
  .88ooo8888.    888`88b.     8     `88b.8  888      888  888          888      888          `"Y88b       888    "      .88ooo8888.    888       8   888              888      
 .8'     `888.   888  `88b.   8       `888  `88b    d88'  888       o  888     d88'     oo     .d8P       888          .8'     `888.   `88.    .8'   888       o      888      
o88o     o8888o o888o  o888o o8o        `8   `Y8bood8P'  o888ooooood8 o888bood8P'       8""88888P'       o888o        o88o     o8888o    `YbodP'    o888ooooood8     o888o     
                                                                                                                                                                               





*/