3.2 release candidate is upon us!

Collapse
X
 
  • Time
  • Show
Clear All
new posts

  • Magnate
    replied
    Originally posted by Jungle_Boy
    I noticed a couple issues with the most recently nightly.

    1. I play with the gervais tiles and bigtile mode, (tile width 16x32) it looks like spell effects and shooting are not being displayed correctly. This only happens with bigtile, doubletile, and triple tile. With those options unchecked it displays correctly. Status effects suffer from the same issue in that they do not display in bigtile mode.

    2. It looks like there are some highlighted tiles being left near the health bars that are not being redrawn correctly.

    3. This may be an intended change but when you have a list up such as inventory and press 'e' to go to equipment the first press escapes out of the current list and the second press brings up the equipment window. Perhaps this is related to the macro issue in that some keypresses are being used to escape lists rather than pull up the correct one.

    Also I'm excited to see fractional blows implemented since warriors are one of my favorite classes, it does make it a little difficult to calculate damage since the numbers aren't nice and round anymore. Perhaps we could add a damage/round number to the 'I'nspect screen?

    *edit* I also forgot, with the show unique monsters in a special color option on they do not display correctly in tile mode but I think that is basically an ASCII option since they still display as purple in the monster list, which I like.
    It is indeed an ASCII option - I thought uniques had special tiles anyway? (You can tell I don't play with tiles.) If they don't, I wouldn't know how to go about colouring tiles, so someone else would have to implement that.

    Yes, during the O-combat discussion I realised that damage per round is a whole lot more useful than damage per blow - that's why S displays it on the char screen. I'll make a ticket for that.

    I think you may be right that the double-keypress thing is related to the macro problem. We'll see if they go away together ...

    With 4 tilesets (each of which can be stretched in 2 directions) on 5 platforms there are so many issues with the display of various things in tile modes that there is no way we can fix them all. We will try and make sure that macros and inscriptions still work, but little visual glitches will probably have to wait.

    Leave a comment:


  • ewert
    replied
    Having finished my mage, I think I will start coding stuff (for me ) again. Will try to do it more coordinated in git, so any major changelines are their own forks etc. so if any are liked it is easier to pick them one by one.

    I peeked at the current gits, and it seems there are different stuff in taks and angbands gits. Is the angband/master currently (and in the future) considered to be the vanilla proper? So that is the git/branch that I will want to grab to start reapplying previous changes and coding new ones?

    Leave a comment:


  • Mimu
    replied
    Originally posted by Timo Pietilä
    1. Game is slow for some reason when you use "overhead" term window and there is unseen monster activity nearby. That's noticeable at a degree that you know there is a monster nearby by the fact that game slows down at very early levels, not so much deeper in dungeon when there is always lots of monsters around.
    Hmm. From a programmer's point of view: if you have a constant delay between frames, but during some frames have to process AI for 200 monsters instead of 20, the former is obviously going to be theoretically slower.

    This could be partially mitigated by a very simple fix that there's no reason not to throw in: add one extra variable to track how many milliseconds have passed since the last update, and subtract that from the delay per frame (capping at 0 or 1 milliseconds). It would smooth out things somewhat.

    Leave a comment:


  • PowerDiver
    replied
    Originally posted by Magnate
    This is quite important - could you confirm whether there is any slowdown if the "flickering monsters" option is off?
    animate_flicker was no when I noticed the slowdown.

    To me, it is no big deal, noticeable but not annoying. I would not categorize it as a bug that should block a release.

    Leave a comment:


  • Jungle_Boy
    replied
    I noticed a couple issues with the most recently nightly.

    1. I play with the gervais tiles and bigtile mode, (tile width 16x32) it looks like spell effects and shooting are not being displayed correctly. This only happens with bigtile, doubletile, and triple tile. With those options unchecked it displays correctly. Status effects suffer from the same issue in that they do not display in bigtile mode.

    2. It looks like there are some highlighted tiles being left near the health bars that are not being redrawn correctly.

    3. This may be an intended change but when you have a list up such as inventory and press 'e' to go to equipment the first press escapes out of the current list and the second press brings up the equipment window. Perhaps this is related to the macro issue in that some keypresses are being used to escape lists rather than pull up the correct one.

    Also I'm excited to see fractional blows implemented since warriors are one of my favorite classes, it does make it a little difficult to calculate damage since the numbers aren't nice and round anymore. Perhaps we could add a damage/round number to the 'I'nspect screen?

    *edit* I also forgot, with the show unique monsters in a special color option on they do not display correctly in tile mode but I think that is basically an ASCII option since they still display as purple in the monster list, which I like.

    Leave a comment:


  • Magnate
    replied
    Originally posted by Timo Pietilä
    It gets a lot worse if there is a flickering monster nearby. Actually it might require turning real-time flicker on, because I don't recall seeing that slowdown without it. Also switching to map term window instead of overhead window almost (but not completely) eliminates the slowdown.
    This is quite important - could you confirm whether there is any slowdown if the "flickering monsters" option is off?

    I mostly play on a 5-year-old Compaq Evo N610c (1.8GHz P4), and I never see slowdown with SDL or x11 or gcu (despite *always* playing with the overhead view in a subwindow), but I never use flicker because it gives me a headache. I see horrible slowdowns with -mgtk, but that has nothing to do with nearby monsters, it's just the port.
    Last edited by Magnate; December 20, 2010, 22:54.

    Leave a comment:


  • PowerDiver
    replied
    Originally posted by d_m
    I do most coding/playing on a netbook (1GHz atom processor, 1GB RAM) which is not huge but is certainly not an old 486.
    I was playing on an athlon64 when I thought I noticed the slowing. A step up from a 486. I don't know how it compares to an atom.

    Leave a comment:


  • d_m
    replied
    Originally posted by Timo Pietilä
    To get that start a new char, open a overhead term window, find a breeder and wake it up, then retreat to place where you can be safely while they move at the other side of the wall. Look how much time you use resting.

    It isn't bad slowdown, not in modern computers, but it is slowdown that can actually be noticed, which is quite odd, considering how old this game is. It should run in modern computers so fast that no slowdown could possibly be perceivable.

    It gets a lot worse if there is a flickering monster nearby. Actually it might require turning real-time flicker on, because I don't recall seeing that slowdown without it. Also switching to map term window instead of overhead window almost (but not completely) eliminates the slowdown.
    The breeder suggestion is good, I will summon one in a big room in debug mode and see what happens.

    Leave a comment:


  • Timo Pietilä
    replied
    Originally posted by d_m
    Does anyone else notice these slowdowns? If so, on which platform(s)?
    To get that start a new char, open a overhead term window, find a breeder and wake it up, then retreat to place where you can be safely while they move at the other side of the wall. Look how much time you use resting.

    It isn't bad slowdown, not in modern computers, but it is slowdown that can actually be noticed, which is quite odd, considering how old this game is. It should run in modern computers so fast that no slowdown could possibly be perceivable.

    It gets a lot worse if there is a flickering monster nearby. Actually it might require turning real-time flicker on, because I don't recall seeing that slowdown without it. Also switching to map term window instead of overhead window almost (but not completely) eliminates the slowdown.

    Leave a comment:


  • d_m
    replied
    Originally posted by PowerDiver
    Maybe the current big coders are playing on machines less than 5 years old and cannot notice slowdowns as easily.
    I do most coding/playing on a netbook (1GHz atom processor, 1GB RAM) which is not huge but is certainly not an old 486.

    I have been looking at the flicker code (although I think it may be platform-specific because it performed well in some tests I ran) but I should do more testing under WINE (it may relate to how main-win does refreshes, I'm not sure). I wasn't able to get serious slow-downs under SDL or GCU.

    Does anyone else notice these slowdowns? If so, on which platform(s)?

    I am not sure these issues will be able to be closed before 3.2 is out, but I will try to make sure they are in trac.

    Leave a comment:


  • Timo Pietilä
    replied
    Originally posted by PowerDiver
    I don't know what you mean by "overhead".
    Term window with entire map visible. Names of those two are IMO wrong way around. Map shows you only part of the dungeon, and overhead shows entire dungeon.

    Leave a comment:


  • PowerDiver
    replied
    Originally posted by Timo Pietilä
    1. Game is slow for some reason when you use "overhead" term window and there is unseen monster activity nearby.
    I don't know what you mean by "overhead", but I could tell the difference running once and I think it was because there was a pit nearby. I was playing a warrior without any source of monster detection, so I cannot be sure. Might there be some call to refresh when a nearby non-visible monster gets a turn?

    Maybe the current big coders are playing on machines less than 5 years old and cannot notice slowdowns as easily.

    Leave a comment:


  • Timo Pietilä
    replied
    Originally posted by Magnate
    Excellent, thank you for the update. We have only two known bugs left and then 3.2 can be released.
    I have three which I thought I had made a track ticket but apparently I didn't. I'll make them now.

    1. Game is slow for some reason when you use "overhead" term window and there is unseen monster activity nearby. That's noticeable at a degree that you know there is a monster nearby by the fact that game slows down at very early levels, not so much deeper in dungeon when there is always lots of monsters around.

    2. Entire "overhead" -term window flickers when there is a visible monster with flicker on.

    3. Stretched "Map" term window doesn't get properly updated, it leaves behind traces of areas that should not be there. To reproduce you need to "Look around" with look command, when you change sector in look-command same happens in map term window, and also when char passes sector border so that map moves to next position same happens.

    1 and 2 might be related in that overhead view probably uses a lot of CPU to track monsters (even unseen ones) and refresh screen.

    Leave a comment:


  • Nick
    replied
    Originally posted by Magnate
    The double-tile-breaks-macros thing we have diagnosed: the redraw mega-hack in screen_load().
    It's a little sad that I made so many mega-hacks they need separate names.

    Leave a comment:


  • Magnate
    replied
    Originally posted by PowerDiver
    I have been unable to reproduce this.
    Excellent, thank you for the update. We have only two known bugs left and then 3.2 can be released.

    The double-tile-breaks-macros thing we have diagnosed: the redraw mega-hack in screen_load(). It's just a case of thinking up a solution that doesn't break big tiles.

    The p-not-recognising-inscriptions thing is easily fixable, but we've decided to unify the p and m commands to sort it properly. Priests and paladins have no fear: the class pref files will automatically map p to m, so your muscle memory (and inscriptions) will work fine.

    So hopefully we'll be releasing some time in the next couple of days, unless any more major bugs arise.

    Leave a comment:

Working...
😀
😂
🥰
😘
🤢
😎
😞
😡
👍
👎