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

snk_kid

Members
  • Content count

    3318
  • Joined

  • Last visited

Community Reputation

1312 Excellent

About snk_kid

  • Rank
    Contributor
  1. Quote:Original post by YogurtEmperor One such example of a specialized container would be a “PoD” vector. If the vector knows it will handle only plain data, reallocation and moving of data can be magnitudes faster, as the old objects can simply be copied with an optimized copy routine, rather than one-by-one, which is required of objects that need to have copy constructors called individually, followed by destructors at each item’s previous address. L. Spiro Engine has both CVector<> and CVectorPoD<> templates, but so far there has been no need for CVector<> inside the engine itself (it is used only in some tools that link against some of the sub-libraries in the engine). Which basically means this type of specialization is not a rare gem that only helps in some special cases. It is the bulk of the cases you will find and definitely worth rolling out. Even if your implementation is a bit shoddy you will still be faster than std::vector<> at resizing the array of data. Virtually all modern compiler vendor implementations of std::vector already take advantage of this case all with the same class template using type traits.
  2. http://github.com/snkkid/LazyFooHaskell
  3. Quote:Original post by Tom Backton Last question: When using TBB, is there a reason to use OpenMP too (in the application itself - other than prototyping)? If not, I'll start with boost::thread and then TBB... TBB can be used with other threading/parallel APIs (including OpenMP) but you have to make sure you call one special init function from TBB in each non-TBB thread. TBB subsumes OpenMP so there isn't much point in using it. The only time you'll have a project using both is just purely because of some other library is already using OpenMP. TBB is meant for throughput and scalability and for most things TBB is all you need but if you're dealing with a kind of concurrency with a lot of blocking threads then TBB probably isn't ideal for this. Read the The Pillars of Concurrency. If you're reading this, TBB is in pillars 2 and 3. [Edited by - snk_kid on January 20, 2010 7:09:39 AM]
  4. Actually TBB probably has a lot more companies using than we realize (yeah it has been integrated with UE3 recently). Where I work we are using it for PC game dev (not console dev). What TBB gives you is really difficult for you to do yourself efficiently with a low-level thread APIs like boost/0x threads. It gives more than just (data) parallel algorithms and there is a lot going on underneath than people probably don't realize (for which you can tap into also). [Edited by - snk_kid on January 19, 2010 8:18:07 AM]
  5. Quote:Original post by Daerax Did I slip? I never I studied category theory so I'm probably wrong but I read it some where can't remember now. Sorry for making your write all of that, all I know is the generalization of a fold has this fancy name ;)
  6. I have not read the entire thread but I read your first post a number of times and one thing is clear to me you have conflicting & contradictory goals. On the one hand you want to learn functional programming, on the other hand you want to write nontrivial programs and you're concerned about libraries even though you said you are worried about libraries being a "crutch" to you. You are also coming off as you are trying to run before learning how to walk. I'm going to give you a virtual wake up slap and say to you get your priorities straight and focus. Your original goal is to learn functional programming and FP is not about libraries. It seems like you haven't quite grasped what (purely**) functional programming actually is about because it has nothing to do with imperative loops. In purely functional programming there are no imperative loops (no for, while, etc), no mutable variables, there are no (implicit) side-effects. All you have is values & bindings, (anonymous) functions & abstract functions (which are values too but are not procedures/commands/actions), function application & composition, and most importantly recursion and patterns of recursion (or the recursive operators). Every function input always has the same output for every application of the function, this important property of FP here is known as referential transparency, no hidden side-effects when you're looking at an expression and it is much easier to reason about correctness and to apply equational reasoning. Anyways if you do not know what or how to write or the important properties of the abstract function called fold (and the generalization of a fold called catamorphism (meaning a natural transformation)) then you probably do not understand what FP is really about. Scheme is more biased towards functional programming than (common) lisp, Scheme is based off of the computational theory of all functional programming languages "lambda calculus" (more specifically the untyped simple lambda calculus). So if you're going to stick with Scheme/Lisp but your goal is to learn FP then I'd suggest sticking with Scheme, this will not hinder your goal of using common lisp in the future. I've read quite a bit of HDTP (ages ago now) and it does cover FP concepts later on. Paul Graham stopped working on Arc a while ago and the community got fed up of waiting so they decided to take over the last I heard. I would probably just avoid it. What ever you choose don't worry about what libraries it has now, you're going to need to write these functions yourself to learn about FP. ** note the correct terminology is "purely functional" not "pure functional" as someone mentioned. [Edited by - snk_kid on January 16, 2010 7:25:08 AM]
  7. It's worth pointing out there are various kind of iterators, std::vector's iterator is random access iterator so binary - operator is defined but if you want to keep your code generic then use visitor's solution, std::distance, this function is specialized for different kinds of iterator and will pick the most optimal method (like with random access iteartors it can use binary - operator).
  8. Quote:Original post by BitMaster Quote:Original post by snk_kid Furthermore if you're dealing with software license(s) you probably want to play it safe and not link statically in your app. Actually, Boost will be linked statically anyway unless you configure the automatic linking differently. Nevertheless I still suggest compiling the library properly as it simplifies things greatly in the long run. Typically you define BOOST_ALL_DYN_LINK globally when you want to use shared library/DLLs version of boost. I'm pretty sure there are defines for specifying specific components to use shared library versions also.
  9. Quote:Original post by maya18222 Thanks for the reply. I shall take a look at the books you recommended. Do you recommend a book on TBB too? How does TBB differ to Boost.Threads? Thanks TBB is good, it's based on modern C++ design and it is used by a number of games companies (including where I work). Very much like the standard library generic container & algorithms. The difference with Boost.Thread is boost.thread is low-level API (does not mean it is bad). TBB provides concurrent containers, generic algorithms and these are built on top a of a task scheduler based on one of the best algorithms for load balancing, the work stealing algorithm. You do not need to be concerned with things like how much work to distribute over each core/processor you have, TBB deals with that. You would have to implement these things yourself with boost.thread and you don't get concurrent containers, boost currently lacks a thread pool (a officially). There is an official book for TBB. One downside of TBB is the lack of lambda expressions currently until C++0x is finalized and published next year (hopefully). This is not the fault of TBB of course. [Edited by - snk_kid on December 27, 2009 11:07:38 AM]
  10. Quote:Original post by owl boost is just a bunch of headers and source files thrown all togheter. Some utilities just need you to include the .h files, some others needs you to include some .cpp files into your project. Just add the files you need. You don't need to compile the entire thing in order to use some stuff. The compiler will tell you what you need. This isn't good advice, you should still use the build system because it will configure code for the compiler(s) and environment, even if you know the correct define you should still use the build system. Furthermore if you're dealing with software license(s) you probably want to play it safe and not link statically in your app. I'm sure boost's license is quite lenient however you may be using a license (either your own code or a library) which doesn't play nice with other licenses. [Edited by - snk_kid on December 27, 2009 3:54:37 AM]
  11. Did you read the getting started page? basically get yourself the latest pre-built binary of bjam put it in the root directory of your extracted boost files, navigate to that directory in command prompt (probably best to use MSYS-ified command prompt (not rxvt)) and then write: bjam toolset=gcc --build-type=complete stage This will build all types of libraries, static libraries (.a files for GCC (.lib for vc++)) both static and dynamic linking to CRT (C runtime libraries) and shared libraries/DLLs (there should also be export libraries for these shared libraries and they are also .a files). Caution you gonna need a lot of hard-drive space but this is the probably the easiest method for you. One thing to note is when you are ready to build your source which uses boost since your boost directory is most likely not in the default directories and default search paths where GCC/MinGW looks for include and library files you will need to explicitly state where the header include and library files for boost are. GCC options for these are -I for include directories and -L for library directories. You will also need to state which libraries you want to link to, this is the -l (yes it is case senstive) option. GCC follows the convention of library files (.a) to be liblibname.a but when you specify the library to link to you just say libname instead of liblibname.a e.g. file called libfoo.a is specified to GCC as -lfoo. If you don't want to deal with some of this kind of stuff yet then I recommend a good IDE like Code::Blocks but you still need to say where libraries (include/lib directories) are if they are not in the default directories and default search paths and you still need to state which libraries to link but it will save you some pain. [Edited by - snk_kid on December 26, 2009 7:10:03 PM]
  12. Quote:Original post by implicit Quote:Original post by snk_kid ...Okay, I'll buy that. I got the impression that you thought that scanf with compile-time checking in GCC or extended with type-safety as-is to C++ was a useful way of doing parsing, but perhaps there is a library or language out there which has managed to do parsing with vaguely scanf-like templates in a reasonable way. For C++ Boost.Format gets you some way there but as far as I know it only works with output streams and I would probably get into trouble using it at work on a large project. Got to write & use lowest common denominator C++ code at work on large projects with lots of coders.
  13. Quote:Original post by implicit What are you talking about? Printf certainly has a nice little domain language going, and though I occasionally wish for positional arguments and user-defined types as standard features I must admit that it covers my day-to-day needs admirably. I'm talking about something that doesn't currently exist in C/C++ in an ideal form (yes I already know about GCC doing some form of compile-time type checking and there is boost.format, don't even go there). In OCaml/F# format strings are analyzed by the compiler at compile-time and gives you a function type from the given format, this is given to a parametric type typically called format/Format. This is used with their standard library IO functions and if you apply these functions with arguments with the wrong type(s) and/or the wrong number of arguments you will get a compile-time error. You can use this special format type in your own functions. As I've already stated in C++0x a "variadic template constexpr user-defined literal" (effectively a operator overload templated over an infinite sequence of characters (variadic template with non-type parameters) for which you can use a string literal to implicitly instantiate the template. This is the only ideal way to analyze string(s) (literals) at compile-time in C++0x. It's stupid to limit this functionality to only user-defined literals, this should be applicable to any constexpr function. The ability to analyze strings at compile-time is not just nice for format strings so why not give us the ability to achieve it in a more flexible way instead of the restricted way in the current working draft of C++0x. My point is that while format strings kind of suck in C/C++, this does not mean the idea sucks in general in fact they are done very well in more type-safe languages. Quote:Original post by implicit Scanf, on the other hand, is virtually useless for anything but the most rudimentary and sloppy type of parsing. Something similar can be said for C++ I/O streams. If you're going to parse something complicated then you should be using regular expressions library and if they are not suitable then you should be using a lexer/parser framework. Quote:Original post by implicit As soon as you need any sort of error handling or try to read anything more complicated than space-separated set of integers you end up with convoluted formats with silent arguments, bizarre %[...] catchalls, and length limit parameters (naturally sent as integers rather than size_t just trip up unwary users) for every string. Also, someone needs to be shot for making %f a float type rather than a double. That is an issue specifically with C/C++ (something that could easily be rectified in C++0x with variadic templates and constexpr functions or an alternate method). This is not a problem with the idea of format strings in general. [Edited by - snk_kid on December 26, 2009 7:38:53 AM]
  14. Quote:Original post by fcoelho Use std::istringstream. You can check an example here. I'll take type safe, type checked (at compile-time) format strings over current C++ streams any day. Lets just hope that C++0x generalizes the ability to analyze string literals at compile-time with constexpr functions (only currently possible with constexpr user-defined literals) and variadic templates.
  15. Quote:Original post by cache_hit The only real problem with F# in terms of its garbage collector is that it's still in its infancy. As the .NET Framework becomes more advanced, and as the language itself goes through a few iterations, you will see substantial performance improvements. I used F# extensively during the CTP but haven't used it much since. I like it a lot, but performance was always a concern. It was usually at least twice as slow as optimized C# code. It's great for expressing difficult algorithms, but I'd use C# for anything performance critical. Well, really I'd use C++ for anything performance critical, but I assume you want a single platform. Which CTP are you talking about? there are few of them from quite a while back and one released quite recently. It will also depend on the problem and how you write your solution compared to the C# version, compiler flags, etc. I've also seen benchmarks that show F# programs to be virtually the same performance as C# programs like this recent blog.