• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.

izzo

Members
  • Content count

    413
  • Joined

  • Last visited

Community Reputation

437 Neutral

About izzo

  • Rank
    Member
  1. Hdg Remote Debug is a live update and debug tool for Unity that lets you inspect the GameObjects, components, and properties on a build of your software running on your device. This can save you a lot of time when tweaking things like UI layout or game play parameters; you don't have to keep redeploying to your device.   Recently we've added UWP support so it can now be used with Windows 10 devices, including Microsoft HoloLens!   Just add the server prefab to your scene and your GameObjects will appear automatically in the editor tool. You don't have to make any changes to your code at all!   Hdg Remote Debug is available now on the asset store: http://u3d.as/sHr   Thanks! Sam  
  2. I've just released Hdg Remote Debug on the asset store: http://u3d.as/sHr   https://www.youtube.com/watch?v=3Oigkg-8rWQ   Hdg Remote Debug is a live update and debug tool for Unity 3D that lets you inspect the GameObjects, components, and serialized fields in your game after it has been deployed onto a device. It is an alternative to the Unity Remote that actually works! You can tweak fields on the live build while sitting in the Unity editor, and it's great for quickly iterating on settings like UI layout and touch controls. Features Simple to use. Runs on any platform that Unity supports (tested in the Mac and Windows editor, and with Android and iPhone devices, but it should work everywhere). Works with micro mscorlib! Iterate on touch controls on the device. More reliable than the Unity Remote. Works with Unity free or Pro. Workflow Drop the provided prefab into your scene. Build and deploy to your device. Bring up the Hdg Remote Debug window by clicking on "Window > Hdg Remote Debug". Click the "Active Player" button and your device should appear in the list. Select it and profit!       Hdg Remote Debug is available in the Asset Store now for a launch special half-price deal of $25! Get it here http://u3d.as/sHr!   More information is available on our web site here: http://www.horsedrawngames.com/remote-debug-live-update-of-unity-builds-on-device/   And on the Unity forums post here: http://forum.unity3d.com/threads/hdg-remote-debug-live-update-inspector-for-your-phone.399096/  
  3. Last year I forked NShader, the shader syntax highlighting plugin for Visual Studio, and added some new features to it. I also rebuilt it for Visual Studio 2015. I've just made another update to it to allow you to add file extensions via the Visual Studio settings dialog, and associate them with NShader (previously the file extensions were hard-coded).   You can download source and/or releases here:   https://github.com/samizzo/nshader   There's more information on my blog about the plugin here:   http://www.horsedrawngames.com/shader-syntax-highlighting/ http://www.horsedrawngames.com/shader-syntax-highlighting-in-visual-studio-2013/  
  4. You could also use 16- or 8-bit vertex position formats to reduce the amount of data you need to store. I don't know what your units are, but unless you really want centimetre accuracy you might be able to get away with quantised positions. If you have some sort of grid or quadtree system for your world, you could store those quantised positions as offsets from the current cell or node or whatever, and pass the origin in to your shader along with the verts. Also consider generating footprints less often, and only allowing a fixed number. Your footprints buffer would act like a fifo, and you could fade out the old ones before re-using them. Another idea is when you a chunk of your world goes out of frustum, you could throw away, say, every second footprint. When you come back to that area, you aren't likely to notice that a bunch of footprints have disappeared if they are quite dense. It really depends on how persistent you want it to be. You can probably fake it a lot to give the impression of persistence without actually storing all that much data. Cheers Sam
  5. Does anyone remember that guy posting about how Havok and other physics middleware have these timestep bugs? here and here. He was also complaining about Gaffer's article on timesteps. Anyway according to Gaffer he has apparently been posting everywhere about how there's this conspiracy going on with timesteps: http://gafferongames.wordpress.com/2008/10/20/fix-your-timestep-crazy-internet-stalker/ Gaffer also rebuts the guy's arguments. Crazy stuff :D Sam
  6. There was a problem with Photoshop 7 and alpha in TGA files. Adobe changed it to save transparency information as the alpha channel in TGA files instead of using the actual alpha channel. They fixed it in 7.0.1, but you can download the fixed TGA plugin from here: http://www.adobe.com/support/downloads/detail.jsp?ftpID=1544 Cheers Sam
  7. Rendering, physics, AI, sound, asset streaming.. There's at least five things you could put in separate threads. Also, they will have your issues, but they will have come up with solutions. For example, when they unload assets, they may flag the asset as deinitialising, and then wait a frame or two to ensure that it is not being rendered before unloading it. sam
  8. Maybe it's because I have a console development background, but I agree with the suggestion of using a pool of objects allocated once at program initialisation. If you use some sort of a list, spawning a new object becomes a simple matter of popping it off the start (or end) of your list, and destroying it means pushing it back on to your list. This way you have one big allocation at the start of your program and no mid-game allocations that cause memory fragmentation. You will also improve your cache coherency if you allocate a big array of objects. These techniques probably don't often occur to PC-centric programmers where there is plenty of memory and CPU to spare, but in the console space where these are at a premium, it helps a lot. That's not to say that it won't help PC software too though. Cheers Sam
  9. Also, when are you rendering your transparent objects? It looks like they might be blending against your sky or your water or something.. sam
  10. If you want to get more advanced, you could render the scene without water to a texture, then blend that with your original water texture (which might be a partially transparent noisy texture or something), and perturb the texture coordinates in a shader to give a ripple effect. Or do that but tesselate the water surface and use a vertex shader to make the geometry actually act like a water wave too. sam
  11. Quote:Original post by Zahlman There is really no reason to use ZeroMemory AT ALL in C++. It looks like he's trying to use the Win32 API, which does not have a C++ interface. ZeroMemory is a common function call to use for clearing Win32 API structures. VegaObscura, I don't think you've copied/pasted correctly. It's unlikely that any Microsoft example would look like: MSG msg; ZeroMemory(&msg, sizeof(&msg)); As others have pointed out, it should be: MSG msg; ZeroMemory(&msg, sizeof(msg)); which is the same thing as: MSG msg; ZeroMemory(&msg, sizeof(MSG)); Sam
  12. I find goto useful in situations such as this: void somefunc() { char* ptr = new char[100]; FILE* fp = fopen("somefile", "rb"); if (!fp) goto end; // read header if (fread(ptr, 1, 10, fp) != 10) goto end; /* ..process.. */ // read data if (fread(ptr, 1, 50, fp) != 50) goto end; /* ..process.. */ end: fclose(fp); delete[] ptr; } This is slightly contrived; if using C++ and the function is a member of a class, ptr would probably be a class member, and you'd probably have classes on the stack that are automatically destroyed when the method returns. But there are still occasional cases where you have multiple exit points from a function and resources that need to be destroyed/released from each of them. sam
  13. If you want to do this in a cross-platform way, it'll be a bit of work using mode 13h in Linux. You can't just call software interrupts whenever you want like you can in MS-DOS or in a DOS box in Windows. Also what compiler are you using? You won't be able to call these software interrupts from a Windows program (not even from a Windows console application). I'd recommend against mode 13h. What's the reason for only using C? You could use PixelToaster and not use any other C++ features aside from the PixelToaster interface. Or even wrap the interface up into your own C interface and do everything else in C. Otherwise I think SDL is the only real option left, unless you wrote your own wrapper to provide a linear frame buffer around OpenGL. But if you want to write your own software renderer, you should concentrate on that, and just use an API that provides you with what you need rather than rolling your own. :-) sam
  14. Quote:Original post by DrunkenHyena Also, since everything will now go through a vtable lookup, it will be much less efficient. Nothing will be going through a vtable lookup, since he hasn't overridden anything. Mikeske: If you *really* want to do it this way, you should remove the 'virtual' keyword on the destructor. It adds an unnecessary vtable to your class. But really, why are you doing this?! You're using the D3DX functions but they're all so basic that you might as well just implement the entire thing yourself. Or if you simply must use them, get rid of the inheritance and add the x, y, and z floats to your own class. Then use a reinterpret_cast to cast the this pointer to a D3DXVECTOR3 when you pass it in to the D3DX functions (for this to work you can't have any virtuals). As to your link error: check that your project actually is set up as a static library. I've just been setting up a new static library for my own projects in VS 2005 Express and haven't had seen this error. The only thing I can think of is that maybe it's set as a DLL and nothing is marked as exported. Cheers Sam [Edited by - izzo on January 1, 2007 6:54:57 AM]
  15. Argh I wrote up this big reply and then Firefox crashed! I'll try to summarise. Don't use the virtual keyword if you don't need it. For example, you're unlikely to ever derive from a texture manager singleton so don't make any of its methods virtual; it adds an unnecessary vtable. And as your vtable gets longer and longer, you increase the chance of a cache miss. As Promit said though, these things aren't of that much concern on modern hardware. However, even though the X360 and PS3 are powerful machines, it's still worth keeping it in mind. You can always squeeze more power out of a system. Each SPE on the PS3 can only access its own internal 256Kb memory (local store); they have no cache memory. You need to use DMA to access main memory. The main processor however (like the X360) has a 32Kb data cache and a 32Kb instruction cache, and a 512Kb L2 cache (the X360 has a 1Mb L2 cache). In comparison, a typical current desktop CPU may have 1 to 2Mb of L2 cache and 16 to 32Kb L1 cache. We profiled the PS2 version of one of our games at work last year. This game used systems that were originally designed for use on a PC. There were deep inheritance hierarchies and managers that would iterate over many different derived classes per frame. There was no attempt at exploiting locality of reference (e.g. similar derived types grouped together). The PS2 has a 16Kb instruction cache and an 8Kb data cache and NO L2 cache. We had cache misses all over the shop; I'm pretty sure we were CPU bound. We didn't have time to refactor most of the systems, but one of them, the particle system, was re-written. Originally it used a fairly deep inheritance hierarchy with lots of virtuals. The re-written system performed much better and there was a noticeable improvement in framerate. Of course, most people here are writing PC software and so have no need to think about this. :) Although if you're planning on getting into games it's worth knowing about this sort of thing and even reading about embedded programming. I've heard numerous stories of newbies in the industry who come from a PC background and totally bloat projects by over-using some of the fancier features of C plus plus. Cheers Sam