• Content count

  • Joined

  • Last visited

Everything posted by S1CA

  1. As above, there is no OpenGL implementation for the PS4...   Direct3D 9 gets you WinXP+. Direct3D 11 gets you WinVista+. Direct3D 11.1 gets you Win8+. OpenGL 2.x/3.x/4.x gets you Linux/Mac/Windows. GNM gets you PS4. GCM and/or PSGL gets you PS3. GXM gets you PSVita. DirectX 11.x gets you Xbone. DirectX 9.x gets you Xbox360. GLES 1.x/2.x gets you Android/iOS. WebGL gets you HTML5. GX gets you Wii. GX2 gets you WiiU.   If you want a cross platform graphics API, you've got to make your own wrapper around most of the above... or you can use an existing game engine that's already done this work    And Mantle gets you AMD. Yep. On PC. Similarly (only slightly tongue in cheek) Glide gets you 3Dfx. PVR SGL gets you PowerVR PCX. On PC ;)
  2.   I haven't made any games of my own, but I have been thinking of some ideas. ... Yeah I guess I need to make more games of my own. Definitely! Most ideas sound good. Most look good on paper too. In reality most have major flaws. Whenever I tell people (outside the industry) that I make games they tell me their 'great' games ideas (that are usually "it's just like XYZ but birds instead of planes") or how the film script they have in their head would make a great game. Sometimes (rarely) people even have ideas about actual gameplay mechanics. Everyone who plays games has some ideas and things they'd do differently. Talk is cheap, ideas are cheaper - but how do you know an idea is going to work or be fun to play? Turning those ideas into a reality by actually making something is how you prove your designs work. It's ok if your ideas fail - it's actually good if they fail - that's good experience, and if you get used to failing early it saves you time (and money once it's a job). An incredibly important skill for a games designer is to work within constraints (time, hardware power, etc). You only fully realise the constraints inherent in your ideas by putting them into practice. You might do some of that stuff on a degree course, but it's really not enough - your peers are coming in with completed games, mods for existing games and lots of little side prototypes that they've done across multiple genres simply because they love doing it not because they were required to do that as part of a course. This isn't an industry that does apprenticeships - you have to do that part on your own! BTW to prove things like core gameplay mechanics ideas shouldn't need too much technical or art skill. 2D prototypes or simple boxy 3D are sufficient to prove most. On a related note, when something's actually playable, that itself generates new ideas and improvements.     Yep, I work at Reflections The universities we work with change from year to year, and the level of connection varies and involve more than just placements (e.g. guest lectures), so "all of the local ones" is the most accurate answer.
  3. I agree with what Tom and ambershee said.    At the studio I work at: We DO take on a very small number of interns each year. NOTE this is for university placement years, not for short term school "work experience". It's done in partnership with universities close to our office. The best N students are chosen from CS or games courses. AFAIK we don't take on design interns, only programming and art. The most successful candidates have a real passion about games and making games; they do a lot of stuff in their own time. As Tom says, expect to apply to a lot of companies to get an internship (all of them if you have the time!:)). Expect to apply to even more to get a placement as a designer - there is no shortage of good ideas (and more people queuing up with good ideas) in the games industry - what is needed is people who can make those ideas a reality - that's why people who get the pure design jobs tend to have experience. You may find intern roles as a "level builder", but quite often that's considered a branch of environment art so unless you have a qualification in say architecture or town planning, or are good at art, that might be out.   The competition for intern and entry level games positions is fierce - think about it, everyone in the world currently doing a games course at university or college wants those positions, so do a large number of the people on this board and similar. So as well as a lot of luck, you need to stand out from the 1000s of people you're in competition with.   How many games have you made yourself? Do you enter competitions like Ludum Dare? (etc etc) How many mods/levels have you made for existing games? Have you learnt to do any programming and/or art? Have you showcased your games (and other creations) much on forums such as this one? Have you covered a broad range of game genres in the stuff you've made (when it's a real 'job' you have to produce good work even for genres and IPs you hate)?   The people who are getting those intern roles are doing all of those things and more, if you aren't you should be! Those things are also major points in your favour for when you apply for non-intern entry level roles.   If you have stuff to show, then include links when you're contacting companies. Local games industry networking events can be a mixed bag - they're a good place to meet student, indie and hobbyist developers who you can collaborate with on more games. They can be a good place to get advice of people in the industry. If you have a good portfolio of games (and related things) you've made, it can be a good place to show people (to get feedback, and to ask if companies have any intern places available).   Game development conferences are good for similar reasons if you can afford to go and have a higher proportion of companies and professional developers.   As a group, the company I work for now also has a graduate scheme that might be of interest to you: https://www.ubisoftgroup.com/en-us/careers/graduateprogram/
  4. Dreamcast 'supports' DirectX too :) http://msdn.microsoft.com/en-us/library/ms834190.aspx   Thing is, because console hardware is fixed, some of the abstractions in the Direct3D you find on PC are unnecessary, so even on the Xboxen (and Dreamcast) there's D3D and another API that lets you get at some of the lower level aspects of the hardware directly - people tend to use a mixture of both.   Regarding PS4, this article: http://www.eurogamer.net/articles/digitalfoundry-how-the-crew-was-ported-to-playstation-4 covers a talk I co-presented at the Develop conference last year and has the few details that Sony allowed us to talk about publicly - as frob says, everything else is still covered by NDAs so isn't open for discussion.
  5. How is the Game Development field?

    Regarding the job availability question - most of of the available games jobs are not entry level and require some amount of industry experience in a real production environment (ideally with shipped product).   However, there are still some junior positions out there, particularly at indie studios who don't have the budget to pay for senior people. That's one way to get some industry experience (on top of your degree and portfolio of personal projects mentioned above).   The other common route into the entry level jobs is internships, usually at the larger companies but sometimes at smaller ones too (budget reasons as above and external funding is sometimes available to studios for taking on interns). The best performing interns are often offered permanent junior jobs. As an extension of the traditional intern intake, the company I work for has also started a graduate programme which may be of interest to you in a few years: https://www.ubisoftgroup.com/en-us/careers/graduateprogram/index.aspx
  6. How is the Game Development field?

    I've been reviewing a lot of CVs and interviewing people recently (for senior engine programming posts) but if I were reviewing for entry level jobs my order of preference would also be 100% with what Hodgman said. 
  7. Anybody left from the 2003 crowd?

    "hello world"   /relurk
  8. Premature optimisation of CODE is bad, but optimisation of code is only a small part of achieving good performance. Ideally:   0. At the start: Ensure the scope of the design fits with the reality of the hardware. 1. Very early on: Ensure the architecture of the engine + game will give the expected level of performance. Comes from understanding of the hardware and experience. 2. Early on: Set some rough budgets. "We're aiming for 60Hz so that's 16ms of GPU time to play with, world rendering must happen in around 8ms, post process in 2ms, etc". Same for CPU and memory. Have in-engine profiling for each system that shows how well each system is doing. 3. Throughout: Design and implement systems with performance in mind ("Cool, so algorithmically this O(blah) but what effect is that having on the cache?") 4. Throughout: Profile systems and check how close they are to the budgets you set. Adjust budgets if necessary. Analyse any systems that are wildly over to see why.  5. Later (alpha-ish onward): Profile systems against the budgets. Analyse all that are over. Optimise the ones that are over or borrow budget from a different system if you can't optimise any further.   Mindset is hugely important. Performance is a whole team thing not just a programmer thing, that's important to get across to everyone - have budgets for design ("you can have N cars on screen"), art ("main character models must fit within X MB, use no more than Y textures and have no more than Z bones"), audio ("must fit within N MB and use no more than M DSP effects at any one time"), etc.   [That's from my experience of shipping console, PC and handheld games, including a few that ran at 60Hz]
  9. If you could hire only one....

    1) What frob and Tom said : work out your requirements first! You need to do some proper project planning... 2) From your planning you should realise that most projects naturally break into phases (e.g. concept, pre-production, production, marketing, debug, ship, post-launch). 3) You'll probably need both artists, but not for the entire project - so work out what phases you need each for and contract accordingly. It's likely you'll need each multiple times - for example the concept artist can help prepare your marketing materials. 4) If you have a genuine tie-break situation (e.g. two 3D artists who are equally as strong on paper and at interview), go for the one who's personality will best fit with the personality of the team (the whole team - even a team of remote workers),
  10. How soon to start being proactive?

    I agree with Tom about networking and when to start applying. There are a couple of other things to bear in mind:   1) Internships are in sync with semesters, permanent jobs are not. Games companies may offer promising interns permanent positions but generally they hire all year round based on project demands. If you have a particular company in mind, keep an eye on what they're up to for clues: if they've just shipped a game it's likely a new project will start ramping up a month or two after. If they've just announced a game, there's a chance they're moving from pre-production into production which can need new staff.   2) Most universities have a computing or games course. Even discounting the people who didn't take it seriously, that's a hell of a lot of new graduates for very few junior jobs and on paper at least most of them look the same - no real job experience and a bunch of education grades. You need to stand out from the crowd - develop some polished portfolio demos that show off your programming abilities - it also makes the interview process a lot easier for both you and for the interviewer because they can ask you questions about technical choices you made and you get to talk about something you know (and get to prove you've not just rote learnt the very basics).
  11. graphics specialization

    #1, what frob said. In particular, do as much and learn as much as you can about graphics programming before you try to make the jump. For junior roles and for people with no proven graphics or engine programming experience in the games industry, a good demo that shows you have a good understanding* of the core algorithms and techniques is the only way you can differentiate yourself from all the other people who want to transfer from other industries to games. [* When I say understanding, I mean it - if I'm interviewing you for my team I'll want to discuss the details of the techniques you chose and what the alternatives might be - from the interviewer's side it's easy to spot the difference between "copied from a book but doesn't understand how it works" and "understands"].     #2, AAA teams and projects are big enough these days that graphics programming and renderer programming are increasingly two separate (but of course closely related) specialist areas. Many big games use graphics engine middleware or already have their own proprietary engines, so there will be more demand for graphics programmers in the future than there will be for graphics engine programmers. Entry level low-level engine programming jobs are also very very rare. I've worked on a few games now that have had people who spent the majority of their time writing shaders...     #3, what to learn? I think writing a game or graphics engine you'd spend as much time bogged down with software design issues and platform APIs as you would learning actual transferrable techniques. Use an off the shelf engine and skip the low-level stuff unless that's really really what you want to be doing.   Writing a software rasterizer is a good one for understanding a lot of underlying principles. Be careful not to get carried away with 1990's optimisation techniques and methods though, I'd advise Fabian Giesen's series of articles for an up to date look at the pipeline and rasterizers: http://fgiesen.wordpress.com/category/graphics-pipeline/   I'd learn the common basics such as lighting (the illumination/reflectance part and the implementation part), shadows (it's a start having an idea what a shadow map is, but do you know how to fix the aliasing issues?), skinning/animation, particle and other effects (a common entry level task), HDR (fake vs real).   Have a rough understanding of common visibility algorithms (PVS vs Portal, etc) can be useful.   A good book to read for ideas for topics to learn? Realtime Rendering.   Look at some of your favourite games - can you explain how everything is rendered? If not, start learning, start guessing, start experimenting.   Given the higher than average volume of data in graphics, good choice of data structures and algorithms can matter. Good choice means understanding some underlying CPU concepts (Big-O isn't everything!).    Knowledge of how GPUs work and where the performance bottlenecks are in the pipeline is quite an engine-y thing but frame rate is the whole team's concern.   Maths, maths and more maths. It's useful for a graphics programmer. SIGGRAPH papers tend to be much easier to read when you understand at least some of the Greek bits ;)
  12. HLSL Mipmapping on XBox360

    'MIN_MAG_MIP_LINEAR' is a DirectX 10/11 style sampler state (part of the D3D10_FILTER and D3D11_FILTER enums). Xbox 360 is Direct3D 9* so doesn't support those things. Look at the filter names in the D3D9 enum and you'll be safe. "LINEAR" for a mip filter (tri-linear) is supported right back to D3D7. [* The hardware, the native D3D9 API, and the HLSL support on 360 do have a few D3D10 features, but it's expressed as extensions to the D3D9 API].
  13. Quitting programming as a job!

    Comments rather than an answer to your specific question. I've been programming as a full time job for 16 years, and a hobby for 25, I can empathise (also in my mid 30s). Som of this comes about when your hobby is the same as your job, I go through similar down periods. Some of the issues you list are just the realities of the commercial world, if what you made at home had to be commercially successful there would be equally annoying (but maybe different) problems. Quote:1) No control over what I make Like the person working in a factory or a bank. Your home programming is more fun, there are no constraints, so is more fulfilling - and that makes what you do at work feel too restrictive. At work you have to program whatever your immediate boss wants. You get more seniority in the company and you have to program whatever the directors want. You become a director (or more commonly, start your own company) and have to program whatever the customer who's paying the bills wants. More seniority gives you more control over how but not what. Quote:2) Finding bugs More preparation == fewer bugs Testing after every change == bugs much quicker to find More experience == less pain; it's just another form of problem solving, it can actually be fun! Quote:3) The continual process of trial and error involved in fixing bugs There shouldn't be any trial and error TBH! I think this is again an experience thing. Most bugs are easy to find. A small handful of bugs are tricky to find, but experience gives you tools, techniques and intuition to track them down more quickly. Fixing bugs should be easy too, in my experience if a bug is difficult to fix it's usually because of bad design or bad implementation based on an incorrect assumption. Quote:4) Trying to work out what someone else's code is supposed to be doing Yep. Been there. If the comments are crap, what's written doesn't conform to any of the coding standards and the person who wrote the code left years ago. Don't try to read the code, just put test functions and breakpoints in and see what comes out the other end in the debugger. NIH Syndrome is a demon in most programmers though, it's difficult to resist at times (sometimes what's there works and is algorithmically correct, just different to the way I'd have done something - in those cases it's better to grin and bear it - maybe adding a few comments to the code to clarify it and keeping a few notes on how it works). Quote:5) Making things that are of no interest to me Same as #1 really. Even things that once were interesting lose their interest and fun. Quote:6) Feeling like a replaceable cog in a machine True for most jobs where you're not at director level really. I've found less of this feeling at smaller companies (I've worked at 3 and 8 person startups as well as multinationals), but that's replaced with more uncertainty because smaller companies usually have a single big customer/job that's keeping them going. Quote:7) Getting no thanks for completing a project. (All the praise goes to the producers and sometimes the artists). Your salary is your thanks. Anything more is a bonus. Just be proud of what you did. Plenty of people don't get credited for hard or even creative work (how many buildings have the names of the builders or even the architects on them?) Quote:It seems there are two kinds of people. People who work as programmers, the ones who love bugs and the ones who swear at their computers. I have worked in web programming, game programming and flash programming and hated them all! Yep, does sound like while you can program, it might not be something for you. I've hated some of the corporate and political aspects of most of the programming jobs I've had, but not hated the actual programming itself. Quote:What I do like is talking to the artists. That's quite fun. I like writing too. And am average at drawing. Now I'm in my 30s and I feel like I don't have any transferable skills to do a different kind of job. Plus I've got loads of gaps in my CV since I keep quitting jobs because they drive me stir-crazy. I think I would like a job organising and helping people in some way. But I don't know what. Producer? (or similar project management). You could capitalise on your existing experience (maybe there are jobs at your own company - talk to your boss, maybe there's an intermediate role without changing company) and make sideways moves. Being a producer (or something like a lead programmer) will have more paperwork, more meetings, more politics, etc, but none of the code woes you hate. Even less creativity, certainly, and still equally stressful, but that's work... If you can improve the separation between work and home, you can be more creative at home. Sideways moves are less risky (but ultimately less fulfilling) than radical ones. Quote:Maybe a conference organiser or something to do with the environment. Your description might also be a sign of being burnt out and/or depressed. Alternative idea: grin and bear it (the job market is too difficult/competetive to be looking at the moment), save up some money, go travelling in some far flung place and work as a volunteer - come back recharged and with a better idea of what/were you want to be in life. Quote:My question is: Has anyone here quit the IT industry and found that they are happier in another job. If so what was it? Not personally (yet? ;)), but a number of friends who have. One qualified as a personal trainer and runs a gym. Another makes giant robotic sculptures and makes money from performance art at festivals and other events. Others got into different fields within IT (i.e. out of making products and into stuff like support and consultancy).
  14. Alternative to gamedev forums?

    Quote:Original post by Moe I haven't hung out here in a while because I'm finding my interests are shifting and I don't have nearly as much free time as what I used to have. Perhaps that is true for more than just myself? Yep. Developing games is my full time job; other aspects of 'real' life and other hobbies/interests have grown and absorbed what little free time I spent participating on sites like this.
  15. Untitled

    you woulda loved copperlists :-) (video hardware programs with a wait for scanline instruction and a register poke instruction, and due to the timing you could set a video hardware register to different value multiple times across one scanline - palette register poking, bitmap start position poking, and even blitter transfers running asynchronously to the cpu - with the CPU left to do fun things like re-write the copperlist on the fly. Jay Miner deserves a sainthood for services to the demo scene! </nostalgia>
  16. Digital Test Cards For Games

    - "safe area" markers. The area which text or important icons will be safely readable on a CRT TV. Useful for console game development. - Make sure the colour/gamma space of the file is made clear. sRGB?, Gamma 2.2?, linear? - Colours & greyscale gradients in each of the above colour spaces (useful for determining where gamma and de-gamma bugs are in your engine/pipeline as well as demonstrating the difference between linear and perceptual luminance). - Maybe take a leaf out of the MPEG test card book and make part of it useful for testing the quality of different DXT/BC compressors.
  17. 360 programming in C++?

    Learn D3D9 and the latest version of any C++ API or function you find that starts with the letter X (XInput, XAudio2, ..) on a Windows PC. Quote:Because if it just sends a file over, one would think you could make a skeleton EXE and replace it at the last second, fooling it to use a C++ exe? Not a chance. PC x86 instructions will not run on the Power PC cores in the Xbox 360. Xbox executables are also signed and protected in a few ways that you aren't going to break. It works for C# because there's a CLR running on the XBox side so no platform specific machine code gets sent. I'd advise making your game (forget engines for anything other than learning or personal use, the commercial and open source engines already have such a head start that it's not worth it for commercial gain unless you have something *really* different) for PC but engineering and designing the code well so that you can easily port to another platform later on (e.g. if someone at MS loves your game and agrees to you publishing it on XBLA). My day job is as an engine programmer specialising in Xbox360 stuff, trust me, there isn't that much difference to progrmming for a PC. When we first got devkits, we ported the basics of a PC DirectX 9 engine to 360 in about a week! So what's significantly different from Windows PC? (and tips) * The CPU cores are PowerPC based. These don't run ANY of your x86 specific code (including MMX, SSE, etc). They have some different performance characteristics (cf. in-order execution vs out-of-order execution). They're big-endian (x86 is little endian). Your binary file access, bitfields, tricks with casting types into things they're not, etc - they all break when you port unless you're very careful. Older Apple Macs use big endian CPUs (PowerPC and 68k) * One application runs at a time and it always occupies all of the screen and machine resources. So window handling, message pumps, etc all dissappear. A lot of Win32 APIs go away too, if it's not in Win32 base (memory, files, etc), be wary. * All older Direct* interfaces are gone. No DirectDraw, no DirectPlay. This includes down-level COM interfaces, so no D3D8, etc. Only D3D9, the X* APIs, and a handful of Win32 core APIs. There are of course a bunch of new APIs :) * D3D: No fixed function pipeline. Shaders only! Shader model 3 only. [There are a few 360 specific additions to SM3]. Use HLSL. The shader assembly you know from PC isn't what the hardware uses (it isn't on PC either, but that's a different story). * D3D: Don't get too reliant on D3DX. It has some D3DX but there are better APIs out there. Some of them are cross platform and available on PC (e.g. XNA Math). * D3D: If you use the D3DX Effect system, don't use the more advanced things like scripting too much. * D3D: Render targets are a very different beast on 360. Your 360 implementation will end up completely different to your PC implementation. When designing your engine, think VERY carefully about the scope of when render targets are rendered to and when their contents are required as textures. * D3D: It's a fixed platform so there are new APIs that let you get a bit closer to the metal and expose some things you won't see on PC - but you really only need to worry about those kinds of things when you're optimising and adapting for the platform specific stuff. * Any executable that's released on Xbox360 has to go through a quality control procedure at MS. They check your game against all sorts of things on a big checklist, stuff like "does the game crash if we leave it running for more than 8 hours", "does this button on the controller do the same thing in this game as it does in every other game and does the picture of the controller on sceen look like the real one", etc. Study a few Xbox games and you'll get the idea - it's to make the gamers experience as consistent and smooth as possible. Follow the Games For Windows guidelines and you'll have covered a few points. Merry Christmas.
  18. 2 FPS - Vertex shader bound?

    needle.in.haystack But what I will say is: in the 9 or so years I've programmed shaders I've never seen a PC be so seriously vertex bound except in cases of extreme wrongness (hey, we all know shipping games can be bugged to hell too) or deliberate test behaviour. Cap for Hardware Vertex Processing only means "card can do fixed function T&L in hardware" not "can do shaders". Could it be CPU bound...? It doesn't necessarily have to mean the game code itself is running slow, it could be (for example) kmixer.sys software mixing too many concurrent sound channels. Run a CPU profiler over the whole system (profiling the GW process alone doesn't tell you if the driver is spinlocked most of the time). If the Intel driver is doing VP on the CPU as well (even if the driver pretends to be doing it in H/W, some Intels do that..) expect a ton more CPU load. Remember there's a vertex buffer creation flag for hardware VP vs software VP. If device is MIXED VP, be wary of more than 2 switches between the two per frame. Force it to fixed function with the same number of draw calls and only the POSITION in the FVF (you can find out where it lives from the vertex declaration) and the stride set to skip the rest. Debug runtimes? ;-)
  19. Screen Coordinate Types

    Quote:Original post by Tom Backton In 2D there isn't much sense in specifying non-integer numbers for positions on the screen. A lot of people use normalised 2D coordinates stored in non-integer types (e.g. top left of the screen is x=0.0, y=0.0 and the bottom right of the screen is x=1.0, y=1.0). One reason is it makes resolution independence easy to deal with. e.g. if I want to draw a rectangle which occupies the top left quarter of the screen, the coordinates of it's two extremities are x=0.0, y=0.0 and x=0.5, y=0.5. To translate that to real pixel coordinates I just multiply all coordinates by the pixel dimensions of the screen inside the graphics library. To change the resolution of a game using the library I then only need to change the screen size multiplier values rather than changing all the 2D coordinates in my game. If your 2D graphics is ultimately going to end up going through a 3D pipeline then normalised coordinates are also closer to what you'd feed into a homogenous projection matrix. Another resolution independent alternative that some people prefer (that also fits with using integers for coordinates) is virtual coordinates where you pick a maximum resolution you're going to support (e.g. 4096x4096) then all 2D coordinates are passed to your library assuming they're going to be displayed at that resolution. Your library then does the conversion to the real resolution in one place in the same way as you would with normalised coordinates. Caveats with either form of resolution independence: 1) a coordinate the user passes to your library might not be exactly representable in the final resolution, e.g. x = 0.0137 on a 1280 pixel wide resolution ends up at pixel location 17.536. The visual result of this if your library is being used for something like a UI is slighty mis-aligned pixels on some things. 2) you need to define what the aspect ratio is for your normalised or virtualised coordinate system and also adjust for that when converting to pixel coordinates (or in your projection matrix for a 3d pipeline). Asides: 1) fixed point. You can have values which are stored in integer types but represent non-integer values. If your library is used on low end platforms like mobile phones you might want to look into it. 2) 2D becomes something more than 2D when viewed on a 3D TV or with 3D glasses. It looks like 3D viewing technologies might have a chance of taking off this time around. You might want to consider exposing a depth value for your 2D because mis-placed 2D on a 3D display can look/feel very weird (but if you do that you may as well consider your 2D as just another type of 3D [smile]).
  20. Quote:Original post by DrEvil Also, the Ps3 msvc integration tools are pretty poor. Unless there is something somewhere I'm not aware of, the 'integration' is as basic as MSVC being able to launch the ps3 compiler, and msvc being able to launch sonys crappy debugger. Effectively the 'integration' leaves msvc as simply an editor and a means to maintain a project. Useful but still not as ideal as if they had it use the entire debugging pipeline in msvc. Yep. There are a few other things like the breakpoint support, the project wizard, SN-DBS integration, etc. In terms of functionality rather than niceness of UI and ease of use, there are a few things the Pro-DG debugger can do that I wish were possible in the MSVS debugger. As an aside I've always wondered whether the default ProDG key mappings were deliberate [smile]
  21. Quote:Original post by stupid_programmer Quote:Original post by phantom Also, the SDKs from MS and Sony intergrate directly with the ide which makes life easier. That seems odd to me that Sony would write tools that plug right in to Visual Studio with MS being their competition and all. Not really, it'd be a bit childish and odd of them not to, kinda like if Xbox 360 didn't work or wasn't tested on Sony TV's because they're competitors in a different space. Sony care about developers making games for PS3 and will do what they can to make that easier (...more games or higher quality). A small part of that includes supplying development tools that integrate with the IDE and run on the OS that most of their [external] registered developers use. People aren't making PC or Xbox games with those tools, they're making PS3 games with them, no loss for Sony... There is also a historical reason for the support, Sony bought SN-Systems (http://www.snsys.com). SN made development tools (notably ProDG) for many console platforms over the years, including PS1, PS2, PSP & PS3 (, N64, GameCube,...). ProDG VSI (Visual Studio Integration) existed long before Sony bought the company. The compiler and other parts of the integration are only a small part of the PS3 tool set provided by SN, the rest of the tools (target manager, debugger, profiler, etc) exist as standalone tools.
  22. Multisampling + shaders in D3D9

    As well as the AA render target, create a plain texture of the same dimensions & format. When you need to use the contents of the AA render target as a texture, StretchRect() from the render target surface to the surface representing one of the mip map levels of your destination texture (obtained with IDirect3DTexture9::GetSurfaceLevel()). This destination texture is what you set on the device for your pixel shaders to use. [aside: resolving from AA to non-AA is very close to what you'll have to do on console platforms]
  23. Decisions, decisions... 1. For a specific monitor in a multi-monitor system: a) MonitorFromRect() to get the handle of a monitor you're interested in. b) EnumDisplayMonitors() to get handles for all monitors. c) GetMonitorInfo() to get ino about that monitor. d) The rcWork member of the MONITORINFO takes the taskbar into account. Bear in mind that: - Each monitor might be at different resolution to the others. - If you're using the GPU there can be a significant performance penalty if your window straddles two monitors (Windows needs to copy pixels using the CPU in this case). - Monitors don't necessarily need to be in order, monitor 1 might be to the right of monitor 2. 2. GetSystemMetrics() with SM_CXVIRTUALSCREEN, SM_CYVIRTUALSCREEN, SM_XVIRTUALSCREEN, SM_YVIRTUALSCREEN. 3. SystemParametersInfo() with SPI_GETWORKAREA. 4. GetSystemMetrics() with SM_CXMAXIMIZED, SM_CYMAXIMIZED.
  24. This shiny old wheel from those nice chaps at Intel might be of interest: ftp://download.intel.com/ids/mmx/MMX_App_Alpha_Blending.pdf
  25. I'd say anywhere from £25000 (junior) to £60000 (senior/lead specialist with lots of experience). There of course exceptions, but that's the general range. For a senior console engine/renderer programmer the average is somewhere between £35000 - £45000 Of course "it depends". Depends on the specific experience of the candidate. Depends on the level of specialist knowledge required for the role. Depends on the company. Depends on how desperate the company are to fill the role. Salaries in the South of England are usually higher than those in the North.