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

kilah

Members
  • Content count

    73
  • Joined

  • Last visited

Community Reputation

514 Good

About kilah

  • Rank
    Member
  1. Hi everyone,   Just curious I was reading http://realtimecollisiondetection.net/blog/?p=86 when I decided to think about actually implementing the system as mention, but I faced a dilema. When sorting by key, which includes depth, what depth is that? The centroid of the renderable based on camera position? How do you deal with overlapping objects which centroids are properly sorted? Isn't that a problem? how are you supposed to handle those kind of issues?   In fact I was thinking how does this handles concave objects that wrap other objects within. My first guess was about splitting object into smaller sub meshes and then form the drawcall on the fly by combining those meshes, but seems quite suboptimal.   Any hints would be greatly appreciated, thanks.
  2. ApochPIQ is the best approach from my point of view. Aggresive inlined function may fail to fit the code within instruction cache, compiler is quite clever on this thought.. The best initial approach, if your macro is extensively used within another function, is to create a function near your caller, and use it in a straight manner. Iniline function hint is most likely good to use on small code functions (that generate small amount of ASM code), or functions that are not used extensively within another caller, not a 27 lines behemoth, from my point of view. Of course that would require both profiling and see asm code generated from the macro in each case.
  3. The underneath problem lies on "local variables". You must ensure that your variable lifetime is guaranteed after your function X has returned, so glVertex3fv input is correct. Therefore you must ensure the variable lifetime is bigger than what your local stack funciton offers. The mean and way you ensure that... is your decision. You could instance an array, you can pass a memory address of your data, etc. Cheers.
  4. [quote name='Gnark' timestamp='1323025395' post='4890453'] [quote name='rdragon1' timestamp='1323025131' post='4890449'] No, but you can write a function that does that [/quote] I've tried making a function like this: [code] float* Vec3::get() { float ret[3] = {x,y,z}; return ret; } [/code] but it still counts as one argument. Am I close at all? [/quote] What you are looking for there is: [code] // x,y and z must be contiguous in memory. In short: have them all three together in your class. float* Vec3::get() { return &this->x; } glVertex3fv(vec.get()); [/code] But SirCane solution may be more elegant depending on your point of view.
  5. I guess swiftcoder point was more about "nostalgia from your childhood" is really valuable later on. But what I think he misses is that any memory will do. Personally I have fond memories about me playing basketball in my junior year, aswell as me playing monkey island when I was 10. Anything will do, as long as you enjoy it. The point I think he is completely right about is that fitness at younger ages, specially at puberty, is important for the rest of your life (by no means this means you have to give out on learning whatever you enjoy, but you should balance it). Cheers P.S: You can chase redheads even after high school, no big deal about that!
  6. [quote name='colinhect' timestamp='1322593114' post='4888824'] [quote name='Sepiantum' timestamp='1322526723' post='4888632'] So over the course of the years, one finds it imperative that if he wants to improve performance, he must write his own memory management system. [/quote] Can someone elaborate on this? I understand that for games 10 years ago this could be considered imperative but I don't see how this would make that much of a different for modern games. Memory isn't (or shouldn't be) newed and deleted excessively every frame and it seems like most games these days are GPU bound. I would guess that energy spent on parallelization would have a bigger performance impact. Is there something I'm missing? Are there any benchmarks showing significant performance increase in a game based on a custom memory management system? [/quote] Depends on many things. For instance fragmentation created by uncontrolled heap calls may turn out to be a problem on some platforms, other problems may benefit from memory pools due to their allocating strategy. Therefore a custom allocator to solve those problems may be a solution. I say "it may" because it is problem specific (ie: specific linked list allocator that keeps data contiguous) and platform specific( ie: performance gain from replacing heap allocation on a OS system like Windows to your custom allocator may turn out to be a harder problem to solve than what you think, for a general purpose allocation strategy). General allocators are quite doing their job, that's why it may not be worthy to replace them. And definitely the almighty hint: do not optimize until you profile. Cheers.
  7. The whole object is allocated in the heap, Foo::age too. Think that the size of your object is what the allocation request is about, that includes Foo::age. What it is going to happen is that you have 2 allocations on heap per object in this case. That means first allocation is sizeof( Foo) = sizeof(age) + sizeof(name), and second allocation sizeof(string) for name pointer. (In fact there is going to be even more allocations due to std::string but that's another story)
  8. There are several ways to use enable_if/disable_if in this case, but my way of solving this would be a disable_if on your first func when is_floating returns true for T. This could lead you to another problem: What about double types? You would end up with only func(float.... ), not the generic one, which may, or may not, be a problem for you in this case.
  9. What you are looking for is partial specialization, not all compilers support it, but it is incresingly common on most used ones. Also you must understand that T may be float, so you would endup with 2 definitions of a single method (forbidden). Therefore in order to avoid that problem, check type_traits which will allow you to "use one or the other based on type of class T". Cheers.
  10. My wild guess: as long as you do not link them both at the same time, everything should be fine. Same definition but different translation units. So if only link one of them to the main flow, should be no problem.
  11. What you aim for? That should be your main concern if you are in learning phase. Is it gameplay developer? is it runtime development? Is it tool development? Do you really know? Depending on your aim Unity is the right tool or not. For example, if you want to pitch a position as a Physics programmer, creating your own collision solver will impress a way more a technical recruiter than anything you may do on Unity. On the other hand, If you want gameplay programming of any sort, stick with unity, as you will focus your mind on those problem you worry about, and not bother on lower level systems. If you don't have any specific idea on what you want to do, Using unity will always help you to understand the big picture first, which is always a good approach. My 2 cents.
  12. SQLite is the way to go in general for single user applications from my point of view. In our current framework we use a serialziation mechanism (google protocol buffers) in order to get snapshots of our current state of art. Thus it allow nice network object/states transfers from/to clients. But this requirement is due to the fact that we want our clients to be able to server distributed data without relying on external database servers. For that sole reason, we are not relying on SQLite.
  13. Aren't you trying to declare and initiailize a global variable on a header?
  14. @Cairn VBO store data on whatever the driver decides that is the best option at that moment, generally speaking this means VRAM. So what you are doing, is uploading your data using a DMA petition through your driver, which is one of VBO main advantage. If you are uploading and array of data who is not changing, there is no need to upload again your information, and combined with a plausible VRAM storage + lower drawcalls, means your performance will increase a lot compared to direct draw calls (glBegin/glEnd). If you require to update information, VBO will also be faster than direct draw calls due to the fact that you are asking the driver for a DMA petition, and uploading it before doing the draw call. You are not uploading and drawing for each step, as you would with direct draw calls. Cheers.