Hi, First, I want to say : Good work Christophe!
See other comments inline ;) > just to sum up what has happened with my changes during the past weeks: > - reduce memory usage due to unnecessary copies > - do progressive loading of map ground image (avoid a 8-30MB duplicate image > sitting in memory) > - try to have all Surface in display format (leads to more optimized SDL > software functions being called, > or some memory savings) > - more touchscreen-friendly widgets/controls > Changes in the menu are good. Running with "-d widget.border" may help you for future changes. It draws red border around the widgets. About the "kinetic scrolling", I've noticed you had commited it, but I had to look at code to understand why it didn't work! (Need to disable "scrolling on border" for those who wants to try too). It's easy to use :) There is only one issue, it's quite annoying to use with weapon that needs a target such as the automatic bazooka. I'll have a look. Once the issue will be fixed, we should remove some scrolling options... currently you can move camera with middle-click/ctrl+click (not very different from kinetic scrolling), scroll on border, ctrl + arrow and kinetic scrolling). From my point of view, in the future, we can keep only kinetic scrolling and ctrl+arrow. > - have special code for the Tile/TileItem objects in 16bits mode: use of > colorkey instead of alphablending leads to both less memory used and improved > framerates (6/10 -> 12/18 on my android target) > That's good! > Note: it seems I have broken the big endian support in 24bits; I suspect it > has to do with my loading code for the image ground. I'd like to fix that, > but my only big endian device available is not debugging-friendly, so this > will take time. > If at least you can reproduce it, this is already good ;) It let you test some fixes. > Future work is about the Double class. It is killing performance on ARM > targets: by changing code to use only floats (thus breaking network games of > course), I bumped speed from said 12/18 fps to 16/24fps, and noticeable > reduce lag (I suspect IA to freeze game up to 1-3s sometimes). Therefore, I > will modify the parts that only need float: so far, linked to display, such > as member/movement/surface/widget, or are only on one side (some part of IA). > The parts that should not be modified: physics, network related code. There > are some parameters stored as Double in for instance the Character class. As > they can be safely cast to Double, I think they can be stored as float. > I'm more anxious about those changes. Let me explain why. First, with the changes you have already done, it was breaking build on my computer (using gcc 4.4.3) with the following errors : http://pastebin.com/SAnykkHN I have fixed it in r7756 but the changes I have done are really silly, so feel free to modify the code to fix it in another way. Secondly, it's not so easy to say that this part of the code is not important for network. In the past, with iFlo, we noticed that synchronization in the code that displays character members is highly important. A very small difference in the member position means a different trajectory for the weapon projectile. *From my point of view*, we want network on ARM, it may be the future of Wormux. That means that if the Double class causes too much performance problems, we should remove it. Code that causes network unsynchronization must be identified and fixed if possible (for instance by using integer if floating points numbers are useless), or leads to some information sent in network game to ensure a proper behavior. Such network synchronization should be checked/disabled in debug mode, to be sure that it does not hide some other bugs. Network synchronization must only fix problems to floating points computation. I hope this message will not afraid you too much :P Regards, Matt (gentildemon) _______________________________________________ Wormux-dev mailing list Wormux-dev@gna.org https://mail.gna.org/listinfo/wormux-dev
