Tears unnumbered ye shall shed

[debo]

If forced descent were a thing, I imagine deep descent would have to go. That would be... awful. Like, "I will delete this from my local copy if you don't change it" awful

[fizzix]

If forced descent were a thing, I imagine deep descent would have to go. That would be... awful. Like, "I will delete this from my local copy if you don't change it" awful

It's not that bad...but it should probably go back to dropping you 2 levels. Considering that you usually ID scrolls on the downstairs, this means you only lose one level, which honestly, is not that big of a deal.

[PowerWyrm]

Unless you play pure ironman, you can still sell unID scrolls to shops to avoid reading an unID scroll of deep descent. Usually you won't lose anything valuable by doing so (though I sold an unID scroll of acquirement once that way in a game not so long ago).

[AnonymousHero]

Unless you play pure ironman, you can still sell unID scrolls to shops to avoid reading an unID scroll of deep descent. Usually you won't lose anything valuable by doing so (though I sold an unID scroll of acquirement once that way in a game not so long ago).

Heh, maybe that's a kind of emergent strategy with the new 3.5-git drops: Never sell any consumable of which you only have 1.

(That's my experience at least: Immediately identify (by selling) one of any consumable of which you have more than one. Keep ?oIdentify for any consumables you have accumulated no more than one of during the past few levels.)

EDIT: Of course you could still miss out on an !Exp (unlikely as that may be), but at least you can just chug another one just after losing it.

[Derakon]

The problem with that technique as a strategy for avoiding accidentally reading Deep Descent is that it can show up in stacks...

I think that if Deep Descent doesn't show up prior to, say, 150', then we're generally fine; if you can survive 150' then you probably have enough ability to avoid being instantly splattered at 400', though I will grant that mages and priests would have a somewhat rough time of things. Going from 50' to 300' is a rather different story.

[AnonymousHero]

The problem with that technique as a strategy for avoiding accidentally reading Deep Descent is that it can show up in stacks...

I think that if Deep Descent doesn't show up prior to, say, 150', then we're generally fine; if you can survive 150' then you probably have enough ability to avoid being instantly splattered at 400', though I will grant that mages and priests would have a somewhat rough time of things. Going from 50' to 300' is a rather different story.

Oh, right. I wasn't actually thinking about Deep Descent, but stuff like accidentally selling !Exp. My bad. Apologies, I'm a bit tipsy

[AnonymousHero]

Sorry for the thread necromancy, but I thought some people who posted in here might find this interesting: ToME 2.x running on Qt 5.x.

Just to clarify this is not quite UI/engine separation, but the engine is running in a thread separate from the GUI, which is something right?

[Nick]

Sorry for the thread necromancy, but I thought some people who posted in here might find this interesting: ToME 2.x running on Qt 5.x.

Just to clarify this is not quite UI/engine separation, but the engine is running in a thread separate from the GUI, which is something right?

OK, yes, this is very interesting. Thanks for posting!

[Derakon]

Congrats, that's excellent news.

How are you handling drawing? Are you drawing individual characters to specific positions on a canvas, or using some kind of text GUI widget? The speed problems most UI attempts run into are probably due to trying to draw 1920 (80*24) individual character glyphs every time things change. Pyrel was able to work around this problem by intelligently caching tile information so that the vast majority of tiles don't need to be redrawn each tick, but full-screen refreshes are still pretty slow.

[AnonymousHero]

Congrats, that's excellent news.

How are you handling drawing? Are you drawing individual characters to specific positions on a canvas, or using some kind of text GUI widget? The speed problems most UI attempts run into are probably due to trying to draw 1920 (80*24) individual character glyphs every time things change. Pyrel was able to work around this problem by intelligently caching tile information so that the vast majority of tiles don't need to be redrawn each tick, but full-screen refreshes are still pretty slow.

The great thing is that it's a really dumb implementation which seems to be performing quite well. The standard QGraphicsScene is (apparently) easily capable of handling thousands of little "items" (as they call them) in a scene(*), so I just create MxN QGraphicsSimpleTextItem-derived instances and (at the window-open event) position them appropriately for the MxN grid. That's all setup, so when I want to write something I just look up the "character" (QGraphicsSimpleTextItem) at the appropriate place and change its "text" and foreground color. After a whole line is "written"/cleared/whatever I just call "invalidate" on the QGraphicsScene on the portion I updated and it takes care of the rest!

Now, there is a caveat which I haven't mentioned and that is that I haven't yet tried the torture-test which is "center on player" and then go running around (mainly due to lack of arrow key handling ), but given that the current implementation is so unbelievably dumb, I'm not expecting much trouble there.

(*) Using all manner of interesting stuff like BSPs for optimizing exactly which items get redrawn on invalidation/re-paint.

[Derakon]

Hunh, I wouldn't have expected that to be efficient. Interesting. Thanks for describing your approach, anyway. It's possible the Qt front-end for Pyrel would want to steal it.

[nppangband]

The great thing is that it's a really dumb implementation which seems to be performing quite well. The standard QGraphicsScene is (apparently) easily capable of handling thousands of little "items" (as they call them) in a scene(*), so I just create MxN QGraphicsSimpleTextItem-derived instances and (at the window-open event) position them appropriately for the MxN grid. That's all setup, so when I want to write something I just look up the "character" (QGraphicsSimpleTextItem) at the appropriate place and change its "text" and foreground color. After a whole line is "written"/cleared/whatever I just call "invalidate" on the QGraphicsScene on the portion I updated and it takes care of the rest!

Now, there is a caveat which I haven't mentioned and that is that I haven't yet tried the torture-test which is "center on player" and then go running around (mainly due to lack of arrow key handling ), but given that the current implementation is so unbelievably dumb, I'm not expecting much trouble there.

(*) Using all manner of interesting stuff like BSPs for optimizing exactly which items get redrawn on invalidation/re-paint.

Hi Anonymoushero,

I was looking through the QT examples, and I found this:

http://harmattan-dev.nokia.com/docs/library/html/qt4/statemachine-rogue.html

It appears to be just moving around an "@" with direction keys, in a roguelike settings. This code will probably be pretty useful to me soon.

I should post my start to a QT port soon. I am focusing on developing a menubar and toolbars for the game. I haven't actually incorporated any angband code yet. My next step will be to get the port to load the edit files, and close them up on exit.

[nppangband]

Hunh, I wouldn't have expected that to be efficient. Interesting. Thanks for describing your approach, anyway. It's possible the Qt front-end for Pyrel would want to steal it.

I am finding QT to be quite well documented. I faced a little learning curve the first couple days, but now that I am getting used to it things are moving along nicely. Plus there are countless examples out there to learn from.

It is amazing that can be done with just a couple lines of code in QT that takes hundreds or thousands of lines in the Angband "game engine".

[Derakon]

If you need them, Pyrel has fairly optimized drawing routines that aren't specific to any given front-end library here. This handles issues like:

* Deciding which subset of the map to display (centering on @ but taking map boundaries into account)
* Drawing text, including pairs of left/right-aligned items (e.g. for inventory display: item name on one side, weight on the other)
* Mapping from pixel space to the map grid

The qtPyrel subclass of that class has Qt-specific code for performing drawing operations. Note that window setup is handled by other files.