Angband.oook.cz
Angband.oook.cz
AboutVariantsLadderForumCompetitionComicScreenshotsFunniesLinks

Go Back   Angband Forums > Angband > Development

Reply
 
Thread Tools Display Modes
Old March 1, 2012, 11:50   #1
PowerWyrm
Veteran
 
PowerWyrm's Avatar
 
Join Date: Apr 2008
Posts: 2,400
PowerWyrm is on a distinguished road
[3.4-dev] Problems with tiles in alphablend/overdraw mode

Found the following problems while experimenting with tiles using alphablend/overdraw:
- the Win32 client doesn't display those tiles properly: this comes from the fact that Term_pict_win_alpha() should be used for the "pict_hook" hook, but it is still defined as Term_pict_win() in term_data_link()
- all clients don't refresh the cursor properly when using the "look" command on a double-height tile
__________________
PWMAngband variant maintainer - check http://powerwyrm.monsite-orange.fr (or http://www.mangband.org/forum/viewforum.php?f=9) to learn more about this new variant!
PowerWyrm is offline   Reply With Quote
Old March 5, 2012, 10:55   #2
Blue Baron
Adept
 
Join Date: Apr 2011
Posts: 103
Blue Baron is on a distinguished road
Quote:
Originally Posted by PowerWyrm View Post
Found the following problems while experimenting with tiles using alphablend/overdraw:
- the Win32 client doesn't display those tiles properly: this comes from the fact that Term_pict_win_alpha() should be used for the "pict_hook" hook, but it is still defined as Term_pict_win() in term_data_link()
- all clients don't refresh the cursor properly when using the "look" command on a double-height tile
Term_pict_win_alpha is supposed to be set in Term_xtra_win_react (around line 1751), after the graphics are initialized. Is this not happening? the alpha function hook is not set in term_data_link because the alpha function is slower than the blitting function and should only be used when needed. (It should not be used for the 8x8 - 32x32 tile sets.)

for the cursor not refreshing properly, I thought it had always been there. However it may be that the first tile of the tile sheet is fully transparent/masked, when it should be opaque black. I guess that the first tile is used for blank spots as well as hidden stuff like lurkers (in the past).

Edit: actually the above is not correct. it relates to the larger tile sizes. with 1x1 tiles the cursor refreshes properly.

Edit2: it turns out the problem was in the pref file. it was just that the coordinates of the nothing tile were off the tile sheet. The fix for Shockbolt's tileset and the UT32 tileset will be in a pull request shortly. (as long as this computer holds out.) It still shows up with text and tile multipliers, but I don't know what to do about that.

Last edited by Blue Baron; March 5, 2012 at 12:14.
Blue Baron is offline   Reply With Quote
Old March 5, 2012, 13:04   #3
PowerWyrm
Veteran
 
PowerWyrm's Avatar
 
Join Date: Apr 2008
Posts: 2,400
PowerWyrm is on a distinguished road
One problem comes from the fact that the cursor is drawn with Term_pict and erased with Term_text. A second problem comes from the fact that double-height tiles use "Term_mark" which sets the attr/char to "Term_blank" on both top and bottom parts of the double-height tile, forcing Term_text to be called with non-info.

I've fixed the first problem (which also occurs with the normal 16x16 and 32x32 tilesets in > 1 width/height mode) with the following code in Term_fresh():

Code:
            /* Hack -- Restore the actual character */
            else if (oa || Term->always_text)
            {
                if ((((tile_width > 1)||(tile_height > 1)) && (!smlcurs) && (Term->saved == 0) && (ty > 0) && !((tx == scr->cx) && (ty == scr->cy))) || bigcurs) 
                {
                    int i, j;

                    /* Hack -- Erase a big cursor */
                    for (i = tx; i < tx + tile_width; i++)
                        for (j = ty; j < ty + tile_height; j++)
                            (*Term->text_hook)(i, j, 1, old->a[j][i], &old->c[j][i]);
                }
                else
                    (*Term->text_hook)(tx, ty, 1, oa, &oc);
            }
For the second problem, I didn't completely understand the code behind Term_mark(), so I'm struggling a bit to find a solution. But clearly, the double-height tile should keep its attr/char info, at least for the top part. Maybe it's just a question of considering the tile as having height = 2 * tile_height and modify the code accordingly...
__________________
PWMAngband variant maintainer - check http://powerwyrm.monsite-orange.fr (or http://www.mangband.org/forum/viewforum.php?f=9) to learn more about this new variant!

Last edited by PowerWyrm; March 5, 2012 at 13:17.
PowerWyrm is offline   Reply With Quote
Old March 5, 2012, 14:05   #4
buzzkill
Prophet
 
buzzkill's Avatar
 
Join Date: May 2008
Location: Indiana, USA
Posts: 2,939
Donated: $8
buzzkill is on a distinguished road
Quote:
Originally Posted by Blue Baron View Post
Edit2: it turns out the problem was in the pref file. it was just that the coordinates of the nothing tile were off the tile sheet. The fix for Shockbolt's tileset and the UT32 tileset will be in a pull request shortly...
I noticed this when updating UT32 to v3.3.2 just a few days ago. Darkness, all three shades (previously mapped to 0x7? something), is now mapped to 0x80:0x80 in my repo. Is that the correct solution?
__________________
www.mediafire.com/buzzkill - Get your 32x32 tiles here. UT32 now compatible Ironband and Quickband 9/6/2012.
My banding life on Buzzkill's ladder.
buzzkill is offline   Reply With Quote
Old March 5, 2012, 14:51   #5
Blue Baron
Adept
 
Join Date: Apr 2011
Posts: 103
Blue Baron is on a distinguished road
Quote:
Originally Posted by PowerWyrm View Post
One problem comes from the fact that the cursor is drawn with Term_pict and erased with Term_text. A second problem comes from the fact that double-height tiles use "Term_mark" which sets the attr/char to "Term_blank" on both top and bottom parts of the double-height tile, forcing Term_text to be called with non-info.
The first problem is because of the wrong info in the pref files (graf-dvg.prf and graf-shb.prf). the coordinates in the f:0 lines should 0x80:0x80, which is a tile glyph (which gets drawn at the right size). The coordinates that are there now are 0x79:0x79, which is a text glyph, and drawn at the font size. Setting the coordinates in the pref file to 0x80:0x80 fixes the issue for me.

Term _mark sets the attr/char pair of the old screen info so the current screen info would be considered a change and be drawn again, without actually changing the current info. (only changed areas are drawn). term_mark only sets the old screen info, which is not drawn, and expands the dirty rectangle, which controls what is tested to be drawn.

However, term_mark is a problem because it causes more draws than necessary. It is possible for term_mark to cause extra drawing every frame for a while, even if nothing changes. But term_mark was the only way I could get the double high tiles to draw properly with the current framework. (since creatures around and behind the double high creature can move without the double high creature moving.)

Also, there isn't an attr/char pair for the top part. its just if a tile is drawn from a particular set of rows in the tileset, the tile above is drawn as well. it works because except for the cursor, the dirty areas are drawn from the top down. A major graphical limitation of the current framework is that regardless of the number of layers in the cave grid, only two are drawn. If there were an attr/char pair for the top part, the program wouldn't be able to draw a creature beneath it.

So you were seeing the cursor not refreshing when moving around blank areas with the 16x16 tileset? when I looked at it on my computer, the cursor was being erased after it moved. are you seeing something different?
Blue Baron is offline   Reply With Quote
Old March 5, 2012, 15:18   #6
Blue Baron
Adept
 
Join Date: Apr 2011
Posts: 103
Blue Baron is on a distinguished road
Quote:
Originally Posted by buzzkill View Post
I noticed this when updating UT32 to v3.3.2 just a few days ago. Darkness, all three shades (previously mapped to 0x7? something), is now mapped to 0x80:0x80 in my repo. Is that the correct solution?
Yes it is. (If Powerwyrm and I are talking about the same thing : )

Also, in the pull request I made a little while ago, I included a UT32 tileset from late January with a some extra tiles for the trap detection border, piles, and some space for shaded doors,stairs. (Too answer a question you asked in another thread, AFAIK all features can use the shaded tiles.)

I attempted to download your current UT32 now, but this computer is acting up again. Anyways the graf-dvg.prf I uploaded a little while ago should have all of the features in it for 3.4-dev.

Lastly, the wrong coordinates for feature 0 were also in 3.2.0, so you might want to check your new file (since you did not mention it above).
Blue Baron is offline   Reply With Quote
Old March 5, 2012, 17:01   #7
buzzkill
Prophet
 
buzzkill's Avatar
 
Join Date: May 2008
Location: Indiana, USA
Posts: 2,939
Donated: $8
buzzkill is on a distinguished road
I may have lost or abandoned my Vanilla 3.2 graf-dvg.prf at some point. I can't seem to locate it, but my Vanilla 3.3.2 files have been corrected. I won't update mediafire/buzzkill until about 4PM EST today as I'm presently working on UT32, so any changes made today won't be available to the public until this evening.

I also noticed that the darkness tile was transparent in UT32. That may have been on oversight on my part when I created the png (overzealous masking). I'm not sure if that's also the case with the png currently being distributed with Vanilla or not. Fixed on my end, fresh UT32 files will be available later today.
__________________
www.mediafire.com/buzzkill - Get your 32x32 tiles here. UT32 now compatible Ironband and Quickband 9/6/2012.
My banding life on Buzzkill's ladder.
buzzkill is offline   Reply With Quote
Old March 6, 2012, 13:11   #8
PowerWyrm
Veteran
 
PowerWyrm's Avatar
 
Join Date: Apr 2008
Posts: 2,400
PowerWyrm is on a distinguished road
Quote:
Originally Posted by buzzkill View Post
I noticed this when updating UT32 to v3.3.2 just a few days ago. Darkness, all three shades (previously mapped to 0x7? something), is now mapped to 0x80:0x80 in my repo. Is that the correct solution?
In graf-dvg.prf, the <darkness> tile should be remapped to "F:0:all:0x80:0x80" yeah. Dunno the reason why it was mapped to something outside the tileset...
__________________
PWMAngband variant maintainer - check http://powerwyrm.monsite-orange.fr (or http://www.mangband.org/forum/viewforum.php?f=9) to learn more about this new variant!
PowerWyrm is offline   Reply With Quote
Old March 6, 2012, 13:16   #9
PowerWyrm
Veteran
 
PowerWyrm's Avatar
 
Join Date: Apr 2008
Posts: 2,400
PowerWyrm is on a distinguished road
Quote:
Originally Posted by buzzkill View Post
I may have lost or abandoned my Vanilla 3.2 graf-dvg.prf at some point. I can't seem to locate it, but my Vanilla 3.3.2 files have been corrected. I won't update mediafire/buzzkill until about 4PM EST today as I'm presently working on UT32, so any changes made today won't be available to the public until this evening.

I also noticed that the darkness tile was transparent in UT32. That may have been on oversight on my part when I created the png (overzealous masking). I'm not sure if that's also the case with the png currently being distributed with Vanilla or not. Fixed on my end, fresh UT32 files will be available later today.
The darkness tile is transparent because the drawing function first draws a black background before adding background and foreground tiles.
__________________
PWMAngband variant maintainer - check http://powerwyrm.monsite-orange.fr (or http://www.mangband.org/forum/viewforum.php?f=9) to learn more about this new variant!
PowerWyrm is offline   Reply With Quote
Old March 6, 2012, 13:24   #10
PowerWyrm
Veteran
 
PowerWyrm's Avatar
 
Join Date: Apr 2008
Posts: 2,400
PowerWyrm is on a distinguished road
Quote:
Originally Posted by Blue Baron View Post
The first problem is because of the wrong info in the pref files (graf-dvg.prf and graf-shb.prf). the coordinates in the f:0 lines should 0x80:0x80, which is a tile glyph (which gets drawn at the right size). The coordinates that are there now are 0x79:0x79, which is a text glyph, and drawn at the font size. Setting the coordinates in the pref file to 0x80:0x80 fixes the issue for me.

Term _mark sets the attr/char pair of the old screen info so the current screen info would be considered a change and be drawn again, without actually changing the current info. (only changed areas are drawn). term_mark only sets the old screen info, which is not drawn, and expands the dirty rectangle, which controls what is tested to be drawn.

However, term_mark is a problem because it causes more draws than necessary. It is possible for term_mark to cause extra drawing every frame for a while, even if nothing changes. But term_mark was the only way I could get the double high tiles to draw properly with the current framework. (since creatures around and behind the double high creature can move without the double high creature moving.)

Also, there isn't an attr/char pair for the top part. its just if a tile is drawn from a particular set of rows in the tileset, the tile above is drawn as well. it works because except for the cursor, the dirty areas are drawn from the top down. A major graphical limitation of the current framework is that regardless of the number of layers in the cave grid, only two are drawn. If there were an attr/char pair for the top part, the program wouldn't be able to draw a creature beneath it.

So you were seeing the cursor not refreshing when moving around blank areas with the 16x16 tileset? when I looked at it on my computer, the cursor was being erased after it moved. are you seeing something different?
Nope, the problem happens in only two cases:
- browsing dark areas with 32x32 tiles (fixed with changing graf-dvg)
- looking at unmapped tiles (no entry in graf-xxx, tile displayed as an ASCII symbol); that was the reason for adding the code to erase a big cursor when using Term_text
__________________
PWMAngband variant maintainer - check http://powerwyrm.monsite-orange.fr (or http://www.mangband.org/forum/viewforum.php?f=9) to learn more about this new variant!
PowerWyrm is offline   Reply With Quote
Reply


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
[3.4 dev] Two problems with jewelry descriptions PowerWyrm Development 6 February 13, 2012 12:32
Shockbolt's tiles now in 3.4-dev! Magnate Development 27 January 9, 2012 08:52
[3.4-dev] Rarity problems PowerWyrm Development 2 January 7, 2012 16:18
[3.4-dev] Problem with 32x32 tiles PowerWyrm Development 1 November 10, 2011 12:58
Problems Getting Tiles to Work in SteamBand Xombin Variants 6 January 29, 2010 15:06


All times are GMT +1. The time now is 11:46.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2018, vBulletin Solutions Inc.