• 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 slow?

    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.