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


  • Content count

  • Joined

  • Last visited

Community Reputation

153 Neutral

About JarkkoL

  • Rank
  1. Oh, you misunderstood what I said. I didn't advocate design where physics code has dependencies to audio code, but that having global access to resources doesn't hide such a dependency any more than explicitly passing the resources to the code. It means that some physics programmer doesn't accidentally write dependencies to audio code because of global resources, but that he needs to also access audio API's anyway thus is well aware of making such a dependency. And you are absolutely right that such a connection between the engine sub-systems should be made at a higher level.   I think global resources have their proper uses, but you need to weigh pros vs cons to see if they are the best solution for given problem. No one is saying you should make everything global ;)
  2. While I agree with your principle in general, there are practical scenarios where global access to resources is much more pragmatic solution. When you find the need to access a resource in the depths of the code, it can be very cumbersome to change all the interfaces & functions to pass the resource all way through the necessary callstack. You may even have some very generic functions in the callstack where it makes no sense to change the interface to pass specific resources through the interfaces.   If you have need to play sound in the depths of physics code, global access to sound resources doesn't endanger modularity any more than explicitly passing the resources. In both cases you need to #include sound code in your physics code, which should be enough of a red flag.
  3. It's perfectly fine to use globals in C++, though instead of accessing them directly you should access them via functions to provide some level of encapsulation. It's just good practice to minimize the number of globals to avoid your code becoming an unmanagable spaghetti mess. For resource management, I personally use globals since passing pointers to resource repositories everywhere where needed would be much worse option.   Cheers, Jarkko
  4. Hey fellow coders, I just released new update of [url="http://sourceforge.net/projects/spinxengine"]Spin-X Platform[/url] source code (changelist [url="http://community.spinxengine.com/sxe_news_announcements/6-spin-x_engine_changes.html#post49"]description[/url]). Cheers, Jarkko [center][url="http://www.spinxplatform.com/screenshots/sxed.jpg"][img]http://www.spinxplatform.com/screenshots/sxed_thumb.jpg[/img][/url][/center] [center][i][color=#808080][size=2]Spin-X Editor Screenshot (click to enlarge)[/size][/color][/i][/center]
  5. [quote name='SteveDeFacto' timestamp='1314618023' post='4855023']How does that even make sense?...[/quote] What do you mean? I assume you know how QuickHull algorithm in 3D works. Cheers, Jarkko
  6. [quote name='SteveDeFacto' timestamp='1314615752' post='4855016'] I have to use QuickHull to create the convex mesh anyway. It's cheaper to just use the tetrahedrons that my QuickHull functions iterates over instead of reiterating over them in a second pass to compute the volume. [/quote] It's faster to calculate the volume of the convex mesh in separate pass than integrate the calculation into the QuickHull algorithm. When you calculate the volume in a separate pass you need to only iterate through polygons of the convex mesh, while when integrated into QuickHull you need to calculate much more volumes. Also a word of warning, implementing robust QuickHull is major pain in the ass because of numerical precision issues. Cheers, Jarkko
  7. That's right, which is why it's a good test case for testing the scalability and overhead of a job queue implementation. People seem to be arguing that the contention is an issue in lock-free implementations, while the test seems to demonstrate that's not the case in practice at least with those tasks sizes and core counts. IIRC, Intel has lock-free job queue implementation in TBB, which uses work stealing technique to address potential issue with contention. Cheers, Jarkko
  8. The level of CPU usage depends on how well the systems are multi-threaded more than anything, and it's difficult to believe that your queue implementation would be the reason for such a poor performance. I don't think you should optimize for queue starvation case since it's not the case that occurs during frame rendering. If it does, then the solution is to do better job parallelizing different systems, not optimizing the starvation case. The jobs that are in the queue will recursively emit more jobs and the job queue wont be empty until main thread waits for all the jobs to complete. The performance of my job queue has been excellent in the stress tests and high contention cases. There isn't really any notable overhead even when the average task size has been even as small as ~0.04ms compared to larger task sizes. I have tested this only up to 16-core systems though, so can't say how well it scales beyond that. I recently wrote a simple ray-tracer for fun and got over 4x boost on Core i7 by multi-threading it with the job queue (0.2ms average task size). Of course this is quite an analytical case but it demonstrates that the lock-free job queue implementation itself doesn't impose much of an overhead for multi-threading tasks around that size at least. Cheers, Jarkko
  9. Right, the behavior of typeid() is compiler specific when you disable RTTI (disabling RTTI isn't part of C++ standard). Regarding your original code, it looks good to me. Thanks for sharing the trick (: Cheers, Jarkko
  10. You can use typeid(T).name() without RTTI. Cheers, Jarkko
  11. [quote name='dummynull' timestamp='1312959563' post='4847059']Money. If the game project is interesting for me (jrpg f.e.), then moral satisfaction is enough. All business is based on idea to be the first one against competitors.[/quote] I can tell you right now that you wont be able to monetize a single algorithm. You should either: 1) Have your implementation as part of some graphics middleware you license to AAA developers. Anyway, you told you got no access to console devkits, and most AAA developers wont be interested if you got no console port. Not many AAA developers develop for open platforms only and saying that "porting is a breeze" will not cut it, comes across as very unprofessional and shows you got no clue. 2) Indirectly monetize the algorithm by gaining reputation and publishing well written article of your algorithm, for example by trying to get it in GPU Pro or such if it's truly something good. Then use the reputation to advertise your consulting services, use it for negotiating better salary, etc. This would probably be your best bet. Cheers, Jarkko
  12. [quote name='Antheus' timestamp='1312825000' post='4846274']Not in traditional sense. If system relies on queue to provide messages before it can do useful work it's prone to live-lock. a->b->c->a. b is waiting for a and never produces any data to c which never provides work to a so b will keep waiting.[/quote] I'm talking about having worker threads enter into the wait state when queue has no tasks in it. You can't have dead-/livelock in that case. [quote name='Antheus' timestamp='1312825000' post='4846274'] 500k per second is still a lot at around 10k per frame. Way too much synchronization. It's similar to graphic state changes. Large batches, few changes. Ideally one should aim at triple digits.[/quote] I agree that 10k tasks per frame would be a lot, but that's not the number of tasks the system enables you to execute. It's the maximum throughput of tasks of the system, when 100% of the time is spent on management of tasks which do nothing. I mentioned in an earlier post that even with 500 tasks / frame you would still spend 1ms of the frame (~6%) just on the scheduling/management, which is pretty high number. [quote name='samoth' timestamp='1312836780' post='4846366']A semaphore is the right thing to do, but it means that for every task you post, you must also release the semaphore.[/quote] In my lock-free job queue implementation I don't have to do this. Workers enter into the wait state only when job queue runs out of tasks, which never happens in practice during the frame. Just to clarify, I don't set/reset the event that workers are waiting in case of the empty queue, except when the last job is popped from the queue or the first job is pushed to the queue, so there's no per job SetEvent/ResetEvent overhead. Cheers, Jarkko
  13. [quote name='Antheus' timestamp='1312822313' post='4846249']They spin in case of contention in worst possible way.[/quote] I was referring to samoth's remark that job queue will spin when there is nothing to do. Workers don't have to spin in that case. I agree that they will spin in the case of contention of course because that's how lock-less lifo/fifo queues work, but as far as I understand using locks instead wouldn't make this any better in high contention cases. So you should rather figure out how to lower the contention if that's an issue by using job stealing for example (it hasn't been an issue when I have stress-tested the queue). Regarding having the busy-wait, when new jobs are pushed to the queue, workers are freed to execute jobs, which as far as I can tell shouldn't cause any deadlock issues. [quote name='Antheus' timestamp='1312822313' post='4846249']500k synchronization tasks (passed between threads or to workers) are abysmal.[/quote] We are talking about 500k per second not per frame, and that's the max throughput the system can process not actual jobs doing something useful. Cheers, Jarkko
  14. Lock-free queue doesn't need to spin in the case there are no jobs in the queue to process. I know exactly what you mean, but you can have the workers enter in to event wait in the case the queue runs out of jobs. That's what I did with my job queue implementation to address the issue. 500k tasks per second isn't terribly bad but is still a bit on the low side. If a game is running at 60fps and spawns 500 jobs / frame, that would mean spending 6% of the CPU time (or 1ms) in a frame just for task management. You could argue about batching more jobs together to lower the overhead, but it's not as trivial as you may think. Important thing is to try to keep the size of jobs below some time threshold (e.g. <1ms) to minimize the time wasted at the end of the frame. However, by batching jobs you increase the potential end-of-frame wait time and depending on the case it's can be very difficult to control that batches don't significantly exceed the time limit. Another thing to consider is that by spreading similar work to be executed simultaneously on multiple threads you put less pressure on shared caches. Cheers, Jarkko
  15. You don't need access to console devkits for the performance figures. For Xbox360 you can use XNA and IIRC, you can also do some development on retail PS3. There are limitations on consoles that makes it non-trivial to get good performance on them, so having your algorithm running on those platforms significantly adds to the credibility of your algorithm in the eyes of AAA developers. Screenshots & videos are an easy way for people to judge the quality of your work, so I would suggest releasing those publicly here for example. If you get good feedback then you could port it for Xbox360 & PS3 for performance figures. Since you mentioned that gamers have proved the quality, what's the game you are referring to? Cheers, Jarkko