arena 0.7 has slightly improved and easier gameplay : * more player feedback (you can see if a creature is stunned without looking at its conditions) * increased difference between weapon classes through special effects (swords make bleed, hammer stun, masses stun and weaken, axes stun, weaken and make bleed) * a new adrenaline bar allowing you to use a powerful weapon-specific special attack * a new "custom fight" game mode making it possible to fight any opponent panel * new weather lightning effect
I think you should cap the new list size to say 64 entries growth each time rather than count * 2, it will reduce a lot of empty entries when the array starts to grow.
also, you should have a call back for destroying the list to help with memory management.
Implementing as an array makes insertion/removal of anything but the tail a long process, which as implemented by a for loop is much longer than a straight up memmove.
The only time a List implemented as an Array as you have pays off is if you know the arbitrary index of an item you want to access.
On Jul 14, 9:15 am, stu <yakumo9...@gmail.com> wrote:
> On Jul 14, 5:31 am, jice <jice.nos...@gmail.com> wrote:
> > libtcod 1.3.2 is a bugfix release. It also adds documentation for the > > fast generic container TCODList.
> neat you re-invented a basic data structure.. The Array! > Why call it a list when its really an array and not a list at all?
While I empathize (cf my flamewar on the converse notation error in Python: calling an array a list), I would not have mentioned that here.
> ....
> Implementing as an array makes insertion/removal of anything > but the tail a long process, which as implemented by a for loop > is much longer than a straight up memmove.
IMO, the C version should be rewritten to use memmove and realloc. (However, I don't actually use libtcod, I just archive it locally for reference.)
The C++ version is trickier (but then again, std::vector is a moderate- weight TCODList). algorithm is one of the moderate-weight headers on GCC, so std::copy isn't a real option for a lightweight class. (A competent implementation of std::copy will reduce to memmove when appropriate).
> The only time a List implemented as an Array as you have pays > off is if you know the arbitrary index of an item you want to > access.
I wish. An array is also useful for avoiding dynamic memory manager overhead, by minimizing the total number of pointers allocated. However, I'm not sure this is actually a concern for libtcod.
(Yes, a properly implemented non-robust general C/C++ memory manager can be sublinear in the number of already existing pointers for both allocation and deallocation.)
On 14 juil, 16:15, stu <yakumo9...@gmail.com> wrote:
> neat you re-invented a basic data structure.. The Array! > Why call it a list when its really an array and not a list at all?
Hey put down the big guns ! The list is already used internally by the library, so I just thought it would be cool for it to be documented, so that developers that are looking for a simple container don't bother creating it from scratch in C or use STL in C++. Of course it could be a little faster, but everybody knows a container can't be faster for all operations. Either you have fast push operations, or fast insertions, or fast index access... This implementation is "fast enough" for most common operations and very simple to use. That's the whole philosophy behing libtcod. Nobody is forced to use it.
I think it's neat you put in the list, simply because if this is also meant to be a good RL starter kit (covering all aspects of building a RL, not just for experienced programmers, but also for beginners), many could start with a giant mess of arrays and/or pointers (home- made linked lists) as I did a while back, and while that's good as a learning experience, it can break an otherwise decent RL. Not to mention the morale buster of dealing with such "complex" issues, in the mind of a wannabe programmer.
I'd like to be able to introduce people to coding a RL and not go "oh, then there's this thing with lists... arghh.. use an array.. here's now to insert and delete elements.. index minus one... etc". It's much better to just say "here's a simple list you can use, call these functions, then when you're comfortable with programming you can take up other stuff".
> I think it's neat you put in the list, simply because if this is also > meant to be a good RL starter kit (covering all aspects of building a > RL, not just for experienced programmers, but also for beginners), > many could start with a giant mess of arrays and/or pointers (home- > made linked lists) as I did a while back, and while that's good as a > learning experience, it can break an otherwise decent RL. Not to > mention the morale buster of dealing with such "complex" issues, in > the mind of a wannabe programmer.
> I'd like to be able to introduce people to coding a RL and not go "oh, > then there's this thing with lists... arghh.. use an array.. here's > now to insert and delete elements.. index minus one... etc". It's much > better to just say "here's a simple list you can use, call these > functions, then when you're comfortable with programming you can take > up other stuff".
> Yes I tutor a lot. > :)
> Jotaf
True. I believe a pretty important part of the developers using libtcod are C/C++ beginners. Having a container out of the box will probably save them a lot of pain. But that doesn't mean it's low quality stuff. This is the only container I use in Arena and TCOD and I don't think they are beginner programs...
On Jul 14, 2:29 pm, jice <jice.nos...@gmail.com> wrote:
> True. I believe a pretty important part of the developers using > libtcod are C/C++ beginners. Having a container out of the box will > probably save them a lot of pain. But that doesn't mean it's low > quality stuff. This is the only container I use in Arena and TCOD and > I don't think they are beginner programs...
Well, I didnt say the rest of the lib was bad, I think its quite cool. I'd be using it if it came out before I started writing cnc and rolled my own sdl interface. I'd rather see people use it over curses, its time we all moved from curses to SDL! :)
I think the list code is low quality compared to the rest of TCOD, your using for loops to move large chunks of contiguous memory around, thats plain lazy when you can just memmove and be done.
if it works, it works right, its just one of those things I happened to look at and go aaargh during my teabreak at work :), and I'd rather look at TCOD than SAP....
On 14 Jul, 19:29, jice <jice.nos...@gmail.com> wrote:
> True. I believe a pretty important part of the developers using > libtcod are C/C++ beginners. Having a container out of the box will > probably save them a lot of pain. But that doesn't mean it's low > quality stuff. This is the only container I use in Arena and TCOD and > I don't think they are beginner programs...
> -- > jice
I didn't say anything about its quality, it seems pretty good; my main point is that it's beginner-friendly. A programmer will eventually learn linked lists and array operations, etc. Not to "code something better", but (most importantly) because they need to know how these things work, and (least importantly) to be able to design a library that fits a demanding system better than a generic list. But IMO this knowledge isn't needed when starting out; that's like starting to build a house from the top.
On 15 juil, 03:22, stu <yakumo9...@gmail.com> wrote:
> its time we all moved from curses to SDL! :)
(warning, troll inside...) Honestly, I can't understand how one can use a library as user-unfriendly as curses... Some like their code being plagued with mvaddchnstr and mvwadd_wchnstr... This sounds like mordor's black speech for me... :P
> I think the list code is low quality compared to the rest of TCOD, > your using for loops to move large chunks of contiguous memory > around, thats plain lazy when you can just memmove and be done.
I don't think it matters : * memmove is nothing else than a for loop moving large chunks of contiguous memory. Ok, it will be faster than an optimized C loop, but not that faster, so the gain will be noticeable only if you intend do do billions of insertions. * TCODList has blazing fast push/pop operations, iterators and index access. It will never have fast insertions. So if I had to do billions of insertions, I would certainly not use it because it will be slow, even with memmove. If you definitely need those billions of insertions, then you'll have to write your own container, specifically designed for this use because a general all-purposes container can't be used in every performance-intensive scenario.
Now I'll replace the loop with a memmove call just to keep you from aaarghing, but there won't be any noticeable change in the programs using TCODList :P
Concerning the list reallocation, I think adding a constant amount of entries, like 64 is bad. Try to allocate a list with 10 000 elements and you need 156 reallocations... This is slow and will have noticeable impact on the game performances. And you will lose lots of memory too if you have a lot of small lists with only a few elements. On the other hand, by doubling the size each time, you can allocate in the worst case twice the amount of memory actually needed. This is bad, but it can be an issue only if you allocate a 256Mb container. I'll add a constructor allowing you to preallocate the right size.
Finally, for the memory callback, you can free the memory by destroying the TCODList object. If you mean freeing memory when you remove elements from the list, I think it's bad too. If your list contains 1000 elements at some point, then only 50, there's a good chance it will grow up to 1000 again
