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

njpaul

Members
  • Content count

    477
  • Joined

  • Last visited

Community Reputation

367 Neutral

About njpaul

  • Rank
    Member

Personal Information

  • Location
    Milwaukee, WI
  1.   Okay, I'll take it out of the realm of abstract as much as possible. This API is to report system faults to a fault reporting application. The 16-bit number represents a fault code. Why not an enum? Well as we've learned in the past when developing similar systems, it's common to not know the complete set of codes you will have up-front, and more codes are created as the system evolves. We'd have to distribute a new header file every time we need other applications to be able to use the code, and in my industry that involves a lot of configuration management overhead - it's not cheap. The rejection would happen by having the application receiving the fault code log the rejection to a file and drop the fault, with no indication to the caller. Why? We've found that faults tend to manifest themselves in interesting ways in the field, as opposed to the relatively clean environment of the lab. Sometimes this leads to an excess of spurious, uninteresting or maybe even incorrect faults. It's beneficial to be able to disable the fault quickly through configuration why a more permanent solution is developed, tested, and released. So what should a calling application do if the fault is rejected? We certainly don't want them to stop running. The rejected is fault is already in a log file, so there's no point in logging it further. Instead, the caller never needs to know if it was rejected or not.   I agree that if the type doesn't exist on the architecture, we probably have bigger problems. We do work with some architectures like that, but it's not likely we'd ever be asked to port this set of software to one of those systems. In practice we generally work only on POSIX-compliant systems, which does define those types. So is it common these days for new C or C++ programs to always use exact-width integer types, with the exception of perhaps size_t for loop indexing or counting, or some of the "fast" types for performance (after profiling, of course)?
  2.  In that case I would probably just read into whatever type is expected by the multimedia API.   You give an example where you don't care as long as the number you pass has at least 16 bits, as the others can be masked off. But which ones should be used? Without additional context, there are arguments for using the most significant bits, and there are arguments for using the least significant bits. Which is correct? Better not to guess; specify that the interface requires 16 bits exactly, and everyone knows how things will work. I do see your point, but to clarify, the documentation in this case would say something like "The number must be defined in the configuration file for the application.", whereas the policy is really an XML file that gets validated against a schema. The schema limits the allowed numbers to a 16-bit unsigned integer, and if the number isn't in the configuration file, it's rejected as nonsense. So no one gets the wrong impression, I'm not against using exact-width types in APIs. I'm just looking for tradeoffs between exact-width and inexact-width types in an API. One possible reason to not use, for example again, uint16_t, is that if this code gets ported to a system without that type, the API would have to change. Not a likely scenario, I know, considering that those kinds of platforms probably wouldn't support other parts of the application anyways. That's why this is driven mainly out of curiosity, and does not stem from a real-world problem.  
  3.   Yes, for reading or writing binary data I agree. However, what it is best stored as isn't necessarily the best type for the operations you have to perform on it. With some hypothetical binary format and calculation to perform on that data, it may make sense for the serialized data to be a 16-bit unsigned integer, but it may also be that the calculation performed on that data is more performant when the type is uint_fast16_t or some other larger size. You also don't have to use exact-width types to read or write binary data. Casting to a pointer to one of these types from a char buffer breaks strict aliasing rules anyways. One alternative is to memcpy the data into a type of at least the necessary size, and swap just those bytes for endian if required. A quick test shows my compiler inlines the memcpy call and performs about the same as the casting version.
  4. Hi everyone. It's been a really long time since I've been part of this community, but I can think of no forums I've liked better than this. Fair warning - I posted this on Stack Overflow and, frustratingly, people said it was too broad of a topic, and won't explain how I can improve the question. So I'm posting this here with the hopes that I can have a reasonable discussion, and maybe come to an answer. Anywho... It seems fairly common for highly-portable APIs, such as OpenGL, Vulkan, or glib,to define types and parameters in terms of exact-width integer sizes. Those APIs often cite "portability reasons", without really providing detailed rationale. Many languages these days seem to have their numeric types defined as exact-width types as well (ex: Rust). I have an API function, for example, where an input must be restricted to a 16-bit unsigned integer. However, I don't really care if the type of parameter allows values greater than 65535. There are additional validation checks, as well as policy and documentation, in place that ensure the value is in the correct range, or the input is rejected. So I could get away with defining the type as unsigned int, uint_least16_t, or uint_fast16_t. As another example, in code that does bit manipulation, I don't really care if the type has more than 16 bits, as long as it has at least that many. So I would use one of the aforementioned types and mask off just the bits I'm interested in. So what are the benefits and drawbacks of the exact-width types in these cases? I'm particularly interested in the API case. Do exact-width types make it easier for bindings for other languages? Are there other reasons? I feel like I'm missing a piece of the portability puzzle. I'm just looking for why some APIs use exact-width types, when possibly inexact types would be fine, citing portability. But I'm not just going to blindly trust and follow their example for my own code without some rationale. At work I've never really had to focus much on different architectures. Pretty much everything we do is either x86, x86_64, or PPC64, or is code that is not designed to be portable anyways, like device drivers or embedded software. Over the lifetime of a typical project, the architecture does not change - we just pick something and run with it. So this question is mainly out of curiosity.
  5. I tend to rarely use smart pointers. When I first was introduced to them, I overused shared_ptr, and I would often end up with some interesting crashes in destructors on program exit. Then I started thinking more about why I actually needed them for my situation, and it turns out I didn't. I often have manager classes that are the sole place for creation and destruction of whatever resource they're managing. When I need a pointer to a resource, I ask the manager for it. Not that there aren't any reasons to use smart pointers, but I tend to structure code in a way where I don't need them. Sometimes this can't be done, and sometimes it'd just be too much work to refactor the code. I know of a multi-million line program that is littered with shared pointers, and occasionally those developers will run into a problem with them.
  6. [quote name='njpaul' timestamp='1339676254' post='4949128'] Does XI2.2 support force feedback? [/quote] From what I can tell, XI2 does not support force feedback. Additionally, I haven't even been able to get XI2 to recognize the joystick as an input device. evtest and fftest work fine though. I found a [url="https://bugs.freedesktop.org/show_bug.cgi?id=42399"]bug report[/url] describing a similar problem, although that person was able to get the device to be recognized by modifying a configuration file. However, I did discover that joysticks (in /dev/input/eventX) can be used in user space, even though the mouse and keyboard cannot. I think my solution will be to have X handle the mouse/keyboard input, and use the eventX file for joysticks. I don't have any touch devices lying around, so I can't test those. I guess I'll cross that hurdle when I get to it.
  7. Thanks for the input everyone. I guess I will use X, as least as far as it will take me, and if I do hit any limitations I may rethink the decision. Does XI2.2 support force feedback? That's the only limitation I'm really worried about at the moment. [quote name='Bregma' timestamp='1339617689' post='4948911'] If your game needs to run as root, you're definitely doing something wrong. [/quote] Well it wouldn't have to run as root if I create an input group and a udev rule, but that might be asking too much out of users.
  8. I'm about to begin work on the Linux portion of my input system. For keyboard/mouse input, I'm undecided if I should use XCB/Xlib or if I should use the kernel input directly (/dev/input/...). Does anyone have any experience as to which method is preferred? I would like to support joysticks and gamepads in the future as well. From what I've been reading, it seems I'll need to use the kernel input directly for those, so would it make sense to just use it for everything? The only thing I don't really like is the lack of permissions by default to open files in /dev/input, but that's easily solvable using groups. Thanks
  9. I wouldn't consider myself a hardcore programmer, but I would consider myself a hardcore software engineer. I spend the majority of my time at work working on documents describing the software. I've been working where I'm at for about 16 months now, and I've only spent about a month of that time writing production code. Things move slowly with us because we have to follow DO-178B standards. I work with some guys who have been there over a year and have yet to write a line of production code. I don't count the test applications we write as production code, since the customer will never run them, but we get to write those too. In total, I've probably spent about 4 months of my time working on code of some sort. At home I spend maybe 2 hours during the work week on hobby projects, and maybe 10 hours over the weekend.
  10. When I graduated in May 2007 I started looking for game programming jobs. I had a couple interviews that didn't work out, and I didn't really want to move halfway across the country, so I decided to look for work locally. Within a month I found my current job as a programmer for Astronautics Corperation of America, where I work on Airbus A400M software. After taking many programming tests for the game jobs, I expected a difficult interview, but the phone interview lasted about all of 15 minutes without needing a programming test, I got a call a few hours later with a job offer, and I started the following Monday. Funny how things work out sometimes. I had only a mild interest in airplane software when I applied, but the longer I work there, the less interested I am in games. The pay is definately better anyways. It's a cool feeling knowing that your softare has a liftetime of 30 years, instead of a shelf life of about a year. I still keep my eye on the occasional game dev jobs that open up in the area though.
  11. You may want to look into the Decorator Pattern.
  12. I like to listen to http://www.alifeelided.net when I'm working, but I may be a little biased.
  13. Quote:Original post by BeanDog Utah liquor laws don't really affect me (I don't drink), but they're really bizarre. You can't buy beer over 3.2% except in imported bottles (never on tap). Some kinds/strengths of liquor can only be sold in "private clubs for members." So if you're ever in a bar in Utah and they ask you, "Are you a member?" JUST SAY YES. They're trying to save you some retarded $10 or $20 membership fee that they never charge to anyone who's a "member." That would really suck for me. All the beer I drink is over 3.2%. In fact I had a mighty tasty Russian Imperial Stout the other day that came in at over 12%.
  14. In Wisconsin it is very common to have all you can eat fish frys on Fridays, and they're very popular. When I lived in Michigan it wasn't very common, and probably isn't very common elsewhere. Also, you can get a 12oz. bottle of Miller Lite or a 16oz. glass of Miller Lite for the same price, but people usually go with the bottle. Now why people drink Miller Lite when we have a variety of fantastic micro brews around just baffles me.
  15. I find boost's multi_index hashed_unique to be quite good. A couple other people and myself wrote up a quick test a little while ago comparing std::map with stdext::hash_map and boost's multi_index. The test is at http://rafb.net/p/14CHPC26.html. Pardon the misnomers, this code underwent several revisions and was just thrown together. I'm sure someone could rip into this test and tell me how bad it is, but oh well. PWToolBox is a library my team wrote. The results of this, running on Windows XP 2.4GHz with 1GB of RAM is http://rafb.net/p/1pbx1P57.html. All times are in seconds.