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

greenvertex

Members
  • Content count

    79
  • Joined

  • Last visited

Community Reputation

510 Good

About greenvertex

  • Rank
    Member
  1. If you're looking to do games in C# I say just jump in. If you have even a marginal background in C++ (which it seems like you do) you'll have no problem understanding C#. Start [url="http://xbox.create.msdn.com"]here[/url], there's a lot of tutorials and code samples to look through. Get a few of those working and if you're not satisfied with your understanding of the language I've never had any complaints about the [url="http://shop.oreilly.com/product/0636920024064.do"]O'Reilly[/url] series of books.
  2. I'd really like some opinions on the following idea: [CODE] struct DXBundle { ID3D11Device* device; ID3D11DeviceContext* context; D3D_FEATURE_LEVEL* featureLevel; DXBundle() { UINT createFlags = 0; #if _DEBUG createFlags |= D3D11_CREATE_DEVICE_DEBUG; #endif return D3D11CreateDevice( 0, D3D_DRIVER_TYPE_HARDWARE, 0, createFlags, 0, 0, D3D11_SDK_VERSION, device, featureLevel, context); } ~DXBundle() { if(context) { context->ClearState(); context->Flush(); context->Release(); } if(device) { device->Release(); } } }; [/CODE] There's a couple places I could see using this, the above example is a simple one that appears fairly convenient. Automatic construction and release at the cost of a dot operator seems like a fair trade. Anyone know of any reasons to avoid creating little "construction wrappers" like this? Note: I've left out copy and copy assign intentionally for readability, that and the jury's still out on how I want to handle them in this particular instance...
  3. Then don't. If you have some complex operation to perform on each node's buffer that is generic enough to reside in an external library, have that operation take as an argument the address and length of the buffer. No serialization required.
  4. Not necessarily, you can write an algorithm that traverses the object tree in client code, applying some algorithm from your shared library to each node. Again, it's not a "fix all" function call, but it's still beneficial to assume as little as you can about client code from a library.
  5. [CODE] extern "C" __declspec(dllexport) void pluginEntryFunction(void* _theObject) { // Following is wrong and dangerous: myClass* theObject=(myClass*)_theObject; } [/CODE] That seems incredibly generic to me. Maybe that's why you're running into issues? Instead maybe prefer something long the lines of: [CODE] extern "C" __declspec(dllexport) void pluginParseBuffer(char* theBuffer) { //Do something... } [/CODE] It's not a good idea to define the same type in and out of your library for exactly the reasons you described. While breaking up a generic function into more specific operations is certainly more verbose on the client's end, they can always be wrapped in a function to perform the appropriate calls in order there.
  6. [quote]But would I be better off learning how to make my own engine, or using one like unity? and would it be easier to do it 2-d?[/quote] You would be better off using an engine, commercial or otherwise. You're going to find yourself not making any real progress for a long time if you decide to roll your own. Most times this leads to dead projects, those that don't die don't end up having what's generally considered an engine running them... It would be easier to do something in 2D. The math is easier, there are plenty of environments to work in, and there are a lot fewer problems to deal with. If 2D is where you what you want to do, don't use Unity, it's very much ill suited for 2D games.
  7. Not really sure how much of a hint you want here but there's an abstract data type very suited to this type of search. I won't name it, but the next paragraph contains problem spoilers (if that's such a thing...): Each number has a pair of factors that are, themselves, numbers that are either primes or smaller numbers with pairs of factors. If you keep splitting your number this way, eventually you'll have a particular type of data structure containing a bunch of numbers at the very "bottom" (my word, not the actual term typically used) that are all prime. All you have to do at that point is pick the right one... You don't necessarily need to store factors in a file, though there's no reason not too if you really want to do it.
  8. Yea disregard what I said, Olof is correct. You're not accessing the majority of pages so your memory allocation is indeed not causing the problem. I still disagree with the magnitude of the allocation though...
  9. Yea that's going to be extremely slow for large numbers. You're reserving memory for num integers when really you only need memory proportional to the number of prime factors of num at the end of the day. So if you entered 1,000,000 you're looking at almost 4 megs of RAM reserved, roughly 797 [url="http://en.wikipedia.org/wiki/Page_(computer_memory)"]pages[/url]. As you iterate through all that, your swapping pages constantly from CPU cache to memory and visa versa. That's generally a slow(ish) operation. While your solution certainly works, it's not terribly efficient overall in terms of memory (as you've seen). My suggestion is to go back to the drawing board and see if you can figure out how to calculate the primes without requiring so much memory. You're almost there, you're just being a little overzealous with calloc...
  10. Some sort of [url="http://en.wikipedia.org/wiki/Graph_(mathematics)"]graph[/url] (with weighted edges) might be a good choice. Each city is a node that contains a list of edges to other nodes (cities) that give possible routes as well as distance. This could even be a [url="http://en.wikipedia.org/wiki/Directed_acyclic_graph"]DAG[/url] with weighted edges so long as you view all routes uniformly (a route from A to B is the same as the route from B to A).
  11. [url="http://www.cprogramming.com/tutorial/3d/quaternions.html"]This [/url]is probably one of the better resources I've found on the subject. [quote]1. How do you visualize a quaternion? It's simple to imagine a vector and rotation around a vector. But how do you visualize a + bj + ck + dl? What does each component represent (visually)? For example, I'm having a hard time imagining what adjusting the scalar component or any of the complex parts does to my rotation.[/quote] In short? You don't. Our 3D experience doesn't lend itself readily to considering hyperspheres and such. Work on understanding the operations you need instead. [quote]2. I have found several equations for converting a quaternion to a 4x4 matrix. I was therefore considering using a single quaternion to represent my camera instead of the code above. However, I'm not sure I understand how. For example, how are pitch, yaw, roll, and a vector all contained within 4 values? I'm definitely missing something here.[/quote] [url="http://content.gpwiki.org/index.php/OpenGL:Tutorials:Using_Quaternions_to_represent_rotation"]This[/url] seems like a good set of implementations for common quaternion uses. [quote]3. Does an implementation using quaternions come with an implicit performance hit? It seems translating provided angles into a quaternion, then into a matrix, and finally multiplying that matrix with the MODELVIEW is expensive.[/quote] Yes, there is overhead, but you're saving in other places by eliminating some vector-matrix multiplication.
  12. You're only assigning the first value in each of your lists to tablero[...][y]. Each of those values just happens to be an 'H' so you're filling your entire set of vectors with 'H' and ignoring all the other values. You might want to look at putting all that information in a text file like: HHHHHHHHHHHHHHHHHHH HPHHHHH OHHHHHH H H HHHHHHHHHHH H H HHHE HHH B M H E HHH HHHH HHHHHH HHHHHHH HHHH HHHHHH HHHHHHH HHHH HHHHHH HHHHHHH E HHHHHH HHHHHHHHHHHHHHHHHHH And using [url="http://www.cplusplus.com/doc/tutorial/files/"]file i/o[/url] to read them into a vector of chars (not ints as you were doing - though they'd work, it's wasted space). This will solve two problems: First, you can't initialize with, or assign to, a std::vector an initializer list (which is what you sort of appear to be trying to do). Second, you can have multiple maps without defining a new function for each map and these maps will be easier to read while you're making them.
  13. [quote]So, do you think it was naive of me to suppose I could determine the complexity bounds before discovering the actual algorithm? Or should I keep defending this as a possibility in my project?[/quote] Not necessarily naive, if you can determine the class of some undetermined algorithm you could prove some asymptotic lower bound to that class as in the sorting example above. But, barring that, I don't believe it's generally possible beyond the most generic assumption of big-omega(1).
  14. Take a look at xmemory and xmemory0 if you want to see how std containers manage it in VS2012. They will throw bad_alloc if there is one (note the absence of a "throw()" on push_back), there is no error handling within the container itself.
  15. Even with your sorting example, you already partially knew the algorithm: you must iterate though all elements at least once, leading to an asymptotic lower bound of big-omega(n). Presupposing absolutely nothing about an algorithm would lead to big-omega(1) I suppose, but that's not terribly meaningful or accurate in most cases. You could make somewhat general statements about classes of algorithms given you know at least the data it operates on (as in sort above): Vector-based algorithms will be big-omega(n). Matrix-based algorithms will be big-omega(n[sup]2[/sup]) etc. Note, these are all asymptotic lower bounds. Generally the least interesting of the bounds family. You wouldn't really be able to say anything about theta or O as far as I know, as determining an upper bound on an unknown is seemingly impossible.