• 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

132 Neutral

About herc

  • Rank
  1. @all: thanks for your interesting insights why one shouldnt make the default stack size too big. very interesting indeed.
  2. i think one interesting question keeps open (for me at least): assume that some programmer - probably me - loves stack based allocation, because it perfectly suits his needs (speed and such), what would be the problem with increasing the stack size to lets say 256 mbyte ? is there any technical problem associated with that? where would be the difference if i would do the same with the heap and dynamic memory allocation, besides the obvious things like memory management ?
  3. thanks, this is great news! most of my small strings are never longer than 16 chars.
  4. Quote:Original post by Zahlman 1) Many implementations of std::string are optimized for the case of short strings, by adding a small char[] buffer to the data struct and using that when the string will fit. interesting! i will check that with my debugger. ir do you know if it is the case for visual studio 8 ?
  5. for std::string, you people are completely right. that string class is so much more complex regarding the interface than the simple vector class. i would say that my stack based vector implementation is simpler than a custom memory allocator. by the way - do you have any comments on how i did my stack vector class? any obvious pitfalls visible by just inspecting the code? here it is again, in syntax highlighted html: vector_stack_allocated_hpp.html but one can only really tell by trying. thanks for the links, i will try to fight my way through that "write my own mem alloc" stuff.
  6. i am aware of ALL your points, i know that it MIGHT be that lists and strings use a pool-allocator, depending on implementation. in fact, at least for lists, i somewhere have read that microsoft stl implementation does use pool allocation. i also know that you might supply a stack based allocator, but i know/suspect too that it is utterly difficult to write an allocator, instead of a rather simple, tiny stack based string / vector (that of course is then only partially compatible to STL). but then - do you know any stack based allocator, ready to use ? that could be passed to std::string ?
  7. my post should be rather added to this thread Memory Allocator for string class but its retired. (admin: maybe reopen it and add my following as a reply) ------- if you have many small string, that serve just the purpose to deliver some short messages and stuff, and do NOT need to be concatenated till whatever length, i would suggest to just use the stack. why must all stuff be on the heap? so i propose to supply a stack based "clone" of std::string. with a fixed size, simple c-array of some char type. would this work? or is there any issues then with thread and whatever else safety one could run into? i have , for example, implemented my own small stack based vector class. vector_stack_allocated.hpp it is based on the fine boost::array ( http://www.josuttis.com/cppcode, http://www.boost.org/doc/html/boost/array.html ). and i am using it without any troubles in my small game project ( www.gravytris.de ). so, would this be possible with strings too? and if so, is there eventually already such a stack based, STL compatible string class implemented somewhere?
  8. dear game devs, i got a tip from a person i met on a gamedev conference to read a very cool article that appeared some years ago that talks about the brutal truth of beeing a game developer. i forgot the correct article name and the location ( i think he mentioned gamasutra, but not sure) so anyone knows such an article that comments with dark humor about game programming/ beeing a game programmer ?
  9. a very fast and mature library is blitz++ also, you might check www.boost.org . they have ublas.
  10. Quote:Original post by lonesock Well, neither of these 2 links are exactly what you want, but: Hamed's small JPEG Library implements the (supposedly) most commonly used subset of the JFIF. This Image-SCZ code shows a simple (lossy) processing step to run on an image, to then have it compress well with standard lossless compression algorithms. wow! thanks for the links! that scz-compression lib is exactly what i want. low code complexity, just 6 files!
  11. @s1ca: fine. but: i want cross-platform portability. i do not want to code for every possible platform interfaces to the native libs. so far, i plan to port my game to win32, linux and osx. that means: 3 different interfaces... so i would rather like to have a nice, plain ansi c(++) code that has not a single platform dependency (just decompressing memory buffers) @s1ca, smit: thanks for pointing out, i will look at this prefilter. but: i'm rather fine with my compress tga with bzip2. it compresses ( i have run some tests) for abstract line drawings even better than png. png is better on real world images, though, but only slightly ( 5-10%) @doctorsixstring & dabono: you are right, 80kbyte is not that much. sorry for the - besides embedded systems - rather vain argument. but what still counts: i need to link another additional library. that means: * porting hassles (need to compile / install lib on target platform) * static linkage ? dynamic dll ? different code generation modes? i spent countless hours to remove unresolved externals error messages just because of libraries not matching together (because they were compiled against different runtimes etc..) * some libs just wont compile into a static library. for example openAL - i had to alter the source code manually to make a static linking one. so much hassle. and here kicks in my wanted "single header - single c(pp) file principle": just add that to your makefile & project and you are done. whatever mode you compile your code, it will just work. thats what i love about most boost libs: they are just header files. i do not have to link against anything.
  12. i know... there is this rock solid libjpeg from the independent jpeg group. but: it is fairly huge, a complete overkill for my smaller game projects. the code size is not ignorable, this adds some 80 kbytes or so to my app. what i am searching for is either a small, TINY jpeg reading implementation or a custom lossy compresssion lib. i have no problem converting my data beforehand. optimally it would come with a single header and a single c(++) file. so one just needs to add these two to one's project and thats it. (besides, i call such very usefull, small libs "single header libraries") i want something similiar like TARGA in terms of simplicity and code complexity. (by the way: if you compress a TARGA file with bzip2, you get nearly png - compression rates. so no need for libpng, if you store your lossless images in an data-archive compressed with bzip2) i know - lossy image compression is much more complex than just lossless TARGA, but maybe someone here knows any library that can do lossy image compression with low code complexity? it must not compress better or equal than jpeg, just something in the same range. so someone here has a tiny, small wavelet / tinyjpeg or something code?
  13. std::vector uses the heap when creating its internal array - storage. if you have small vectors, you should use the stack instead to gain some extra speed. to use stack based allocation, try vector - libraries like tinyvector from http://oonumerics.org/blitz/ or use boost::array "As replacement for ordinary arrays, the STL provides class std::vector. However, std::vector<> provides the semantics of dynamic arrays. Thus, it manages data to be able to change the number of elements. This results in some overhead in case only arrays with static size are needed." http://www.boost.org/doc/html/array.html or tvmet: http://tvmet.sourceforge.net/
  14. I'm very interested too! i especially would like to have a look at your source code as an inspiration on how to build a simple Opengl-GUI. why not supply the code you already have? or please email me your code: post at andre-krause.net are there any other known opengl-gui's suitable for games out there? i got around 80 fps with a nvidia gforce 4 ti 4200.