• 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.

nife87

Members
  • Content count

    231
  • Joined

  • Last visited

Community Reputation

520 Good

About nife87

  • Rank
    Member

Personal Information

  1. A computer is like an air-conditioner; they both stop working properly when you open Windows.
  2. You actually only need an ATmega/tiny (and a few resistors) and an USB-TTL adapter to burn down an Arduino ISP Programmer to make it work. An updated version of this also works with slower SPI speeds, for use with clocks slower than ~400KHz - I have succesfully used it with a 32KHz (WDT-driven) ATmega328P. Note that this ISP programmer works as a general avr-isp, so, once burned onto the controller, you can use the programmer without Arduino. This is what I do to avoid buying a more expensive (and probably not much better) programmer. I just compile with avr-gcc (and set all the bells and whistles I like) and download using avrdude. Also, this option is cross-platform out-of-the-box.
  3. Developers on different levels/stages are probably interested in different topics, and the difficulty of those (basic explanation of AO/SSAO vs. latest performance tweaks to a specific SSAO algorithm), since all have different experience and knowledge. Hence there are many popular blogs :-) One thing everybody loves, however, is an image, whether it contains a screenshot of a game, a colorful model, an IDE or just plain statistical data. And one other thing programmers love is well-documented/-described source.
  4.   Just out of curiosity, what did you not like about it? Maybe you have encountered some of the more buggy builds.   I have used it for quite a few years for cross-platform development and, compared to the alternatives, I find it more flexible/low-level (you can customize about anything, including its build process) and "light-weight" (always responsive and you can trim any fat/plug-ins). For beginners, there are IMHO better alternatives, such as QtCreator, which I find it too bloated (do not get upset - just my opinion). Of course, you have to switch IDE (try out the others) from time to time anyways to form an updated opinion (which I do every few years).   BTW. If you have used CB nightly builds (and you almost have to if you want an updated version), especially those from 4-6 years ago, there are always bound to be some more-or-less buggy builds. If I encounter such buggy build, I just report the bug(s) and step one version down until the next build is released (and usually they have fixed the bug(s) by then).
  5. If you want top-quality reading material with C++ (specifically C++11 and its standard threading library) and threading in mind, I can recommend C++ Concurrency in Action: Practical Multithreading by Anthony Williams (http://www.amazon.co.uk/dp/1933988770) and Herb Sutter's many articles (http://herbsutter.com/).   Pre-C++11 you can use boost::thread (nearly identical to std::thread in C++0x/C++11), so any articles concerning std::thread can also be applied to earlier versions of C++ supported by boost.
  6. They are built on top of each other, yes, but several distros built upon Debian, including Mint and Ubuntu, are way better updated, system-wise, than Debian. This is due to the reputation of stability (or goal, cannot remember for sure, but it sure is stable) that Debian must maintain, which is why the "current", stable release is still dwindling around kernel 2.6 (and how many years old?) instead of the most recent 3.5 (which "stable" versions of Ubuntu and Mint are running).   So I would not exactly mention them by an "is-a" relationship, but more an "originally-a".
  7.   Yes, Debian is great. Unfortunately, to be just in neighbourhood of somewhat updated (kernel-wise, especially), you have to install the "testing" version, which is not for newcomers.   That said, I would also recommend Ubuntu BUT with a different desktop enviroment than Unity (the default). My preferred choice is currently Xubuntu 12.10. For easy transition, Xubuntu (comes with XFCE) is very similar to what regular users call a normal desktop enviroment (elderly Windows) and use fewer resources than Ubuntu or Kubuntu (fancy KDE desktop enviroment, although not my taste).   I started years ago out with a mixture of *buntu/Debian, openSUSE, Fedora (also a good choice) and sometimes Arch, and I have yet to see something as well supported and updated as *buntu, although IMHO I would call the default distro/DE since 12.04 experimental (yes, I am looking at you, Unity). Yes, you have to fiddle a little around in the console from time to time, but mostly things work out of the box. And anyways, once you get used to the console/bash and the  "basic inner workings" of Linux, it is really not that big a deal and makes many things easier than with GUI's. Also, be aware of how well supported your peripheral hardware (anything connected via usb) is, because the cheaper (unsupported) and primarily-Windows-supported stuff can easily take some time and skill (www and the large userbase is good here) to setup.
  8. I am currently writing a URI parser whilst reading the official documentation and noticed that it should be legal to conceal another/multiple schemes within the URI syntax. I would like to be able to specify multiple schemes within a valid URI, like so: vfs:zip///home/user/test.zip vfs:zip:file///home/user/test.zip#data/text.log vfs:zip:file//user:encrypted-password@localhost:127/home/user/test.zip#data/text.log   According to the Generic Syntax (RFC 3986), specifically sections 3 - 3.3 (not all text is listed here):   This means that any characters between the first ':' and the first '/' (specifying either authority or path) should be skipped by parsers and still validate the URI, enabling me to provide zero or more schemes (zip, file, http, etc.) after the primary scheme (vfs, in this case), as far as I can tell.   Any thoughts as to whether or not this is correctly understood?   Otherwise, I think I have to provide the additional schemes via the path part or as a query or fragment, although I would prefer to provide them up-front, like the above, in order to preserve the rest of URI from preliminary preprocessing (other than normalization and percent-decoding).
  9. I found this post helpful: Designing a Robust Input Handling System for Games   EDIT: Sorry. Misread the topic. Thought it was about generic input handling, not mouse-only handling.
  10. This is just an idea, so please inform me if it is totally misplaced   Even though the speed is slowed, time is not, so the client should be able to detect that time gap/leap and drop the connection itself after a fixed time interval without signal. The key is that the server's time interval must be a little larger to accommodate clients clients wanting to resuming (without luck) after an interval close to their time limit. For instance, where X is some time interval (the 1.5 is probably way too much, depending on X itself it may be smaller, but you get the idea): ClientDropTime = X ServerDropTime = X * 1.5
  11. Most, and hereby I mean practically any game I have every played in release, use the in-game GUI to display the console, not an external window API like Windows' own.<br />Thereby they can toggle all aspects of its appearance - but there is much more to it than just pretty graphics, although ones like Source Engine's is both very pretty and functional (listing all cvars related to the chars you have typed so far and easy help/description for any cvars, for instance) IMHO, though I miss an "in-game appearance" (you cannot type while playing - console must be accessed from the menu).<br />You also need a way to bind console input (like "help", "max_fps 100", "quit", etc.) to actual source in order to command the game to do something.<br />Quake, as you mentioned, uses a system of cvars (console variables and commands) - you can read all about both online and in their released source (the newest edition of id's cvar system in actual source, that I know of, lies accessible in their Half Life 2 SDK).<br />Games like FarCry exposes this functionality via a full fledged scripting system (Lua, in this case) and binds commands/variables and the necessary callbacks this way, since they use it for all other scripting purposes anyways.<br />
  12. Sorry, cannot test it right now (Linux), but I would anyhow love to see some screenshots as the game must be quite pretty, judging from those birds =)<br />Note: People are also in general more inclined to review your game if you provide screenshots.
  13. <blockquote class="ipsBlockquote" data-author="Codarki" data-cid="5016113"><p>Sorry I'm in a hurry at the moment, but I think STD allocators should be copyable. You don't have copy constuctor.<br />&nbsp;<br />I think the answer is to have mMemory wrapped in std::shared_ptr.</p></blockquote><br />They are also supposed to be stateless (except for the new scoped ones in C++11), as in they cannot contain instance data members, as in two different instances (with potentially different states, if they are not stateless as specified) of the same type should always be equal:<pre class="_prettyXprint _lang-code _linenums:NaN"> CustomNamedAllocator&lt;T&gt; a1("Mama"); CustomNamedAllocator&lt;T&gt; a2("Papa"); // This should always be true, according to the standard. static_assert(a1 == a2, "Mama is not Papa! Surprise!"); </pre><br />Although I am pretty sure that most STL allocation implementations are made state aware (at least MSVC and GCC are), but since none has mentioned a specific compiler, I thought I would bring this to attention.
  14. FYI, I had multiple USB chargers around 700-1000 mAh (from an HTC Desire, amongst others), several USB Male A - Male Mini A cables and also multiple SD cards lying around, but I reckon that is just me, then :-)<br /><br />I have several/many years of experience with both Linux and programming in general, so it was certainly not hard for me to get started, but I agree that the entire experience of an RPi is more general minded than an Arduino, for instance - and this is great for guys like me who truly wanted a small, capable computer without (software) limitations. You can do pretty much whatever you want with it, especially with those GPIO's (LED Cubes is a great example), and its only limitation is the mediocre hardware (for a "normal" computer, that is). Although I am missing an interface with higher bandwidth than the current (combined SD/USB/Ethernet controller using USB 2.0 bus) for making the perfect DYI NAS :-P<br /><br />TL;DR: I agree. Beginners would probably be more productive with something like an Arduino, but intermediate users have craved this device for a long time.
  15. Before thinking about multi-threading, you should reason about your memory-accessing patterns and if they are optimized enough. One thread with optimized/proper cache usage can often outweigh many threads using sloppy/improper cache usage. Currently, I can think of no less than 4 distinct purposes/methods for multi-threading in games, and I am sure others can think of more. 1) Real-time processing. For faster response to input, Win32 messages, and the like, this processing often takes place in another thread. These threads usually require normal/high priority for fast response, although they are not active very long at a time (they sleep a lot due to inactivity). 2) Background processing. Asynchronous file loading, for instance, requires little processing power since this is an I/O-bound process. Asynchronous resource loading, on the other hand, may require a great deal of processing power when there are resources to load (and loading is not I/O-bound). But none of these tasks have to be carried out right away, so they usually have low/normal priority and will be processed when there are time to spare. 3) Scalable parallel processing. This can be rendering, physics simulation, logic processing, or any other task that can be divided into multiple smaller independent tasks, typically using task schedulers/pools (for queuing and delegation of tasks to worker threads), dependencies (tasks depending on other tasks or frame dependencies) and priorities for choosing the right order of processing. There is typically one global task scheduler and N+C worker threads, where N is the number of available hardware threads and C is some number for balancing the workload of worker threads (I have seen both -2, -1, 0 and 1, depending on the amount of processing the other threads have to perform). For reference, see http://threadingbuildingblocks.org/ 4) Another popular solution for systems with few hardware threads (2-4) is to dedicate each thread to one/more subsystems and is often good enough when developing for a platform with a specific amount of threads (consoles, some mobiles, for instance). So for a 2-thread system you might have input, rendering and networking on one thread and physics and logic on another, but often one or more threads will have finished processing the current frame before the others and will have to wait (maybe not at first because it can process the next frame, but it cannot continue beyond X frames). This method can therefore lead to wasted cycles in waiting threads and is not scalable in itself. Task schedulers, as explained in 3), address this problem by balancing the load amongst the available worker threads in order to avoid stalling any threads = no/less wasted cycles. This requires the work to be split into more-or-less equal-sized and independent tasks for optimal balancing and therefore optimum performance, though, and is therefore easiest to accomplish with something like physics, rendering and (depending on the management) logic. I did not dive into the impact of different synchronization strategies, as others have already mentioned this. Answer: A mix of all 4 methods is probably not a bad idea, but the answer should always be "it depends". You should consider the reason for each thread, its responsibilities, its impact on OS thread scheduling, and if the extra synchronization required, if any, is outweighed by the performance gains, also if any.