Angband.oook.cz
Angband.oook.cz
AboutVariantsLadderForumCompetitionComicScreenshotsFunniesLinks

Go Back   Angband Forums > Angband > Development

Reply
 
Thread Tools Display Modes
Old May 7, 2016, 01:30   #11
Nick
Vanilla maintainer
 
Nick's Avatar
 
Join Date: Apr 2007
Location: Canberra, Australia
Age: 54
Posts: 7,842
Donated: $60
Nick will become famous soon enough
This is fantastic. I hope you realise what a dangerous precedent you've set for yourself:
  1. Do unsolicited useful work
  2. Get answered with a wishlist
  3. Fulfil wishlist

From my point of view, you're serving as some kind of code oracle.
__________________
One for the Dark Lord on his dark throne
In the Land of Mordor where the Shadows lie.
Nick is offline   Reply With Quote
Old May 7, 2016, 03:10   #12
calris
Adept
 
Join Date: Mar 2016
Posts: 194
calris is on a distinguished road
Fixed one major problem - I missed setting 'use_graphics' which reset_visuals() uses to processes the appropriate tileset preference files - hence why only tileset #1 worked.

So now all the tilesets are drawn using the correct tiles, but I have a few issues
  • Resizing does not appear to effect to size of the tile display area - It always worked for text. I've adjust the x11 resize code to call Term_resize(x, y) based on the tile size rather than the font size
  • The tile display window position is generally pretty messed up - I turned on 'Continuously Center Map' (I thought it would have terrible performance, but turns out to be not too bad) - The 'centre' of the map is somewhere way to the bottom right (if using tileset #3) - last three screenshots are essentially the same using the different tilesets.
  • As I understand it, the room taken up on the left edge is basically the amount of room taken up if the text was the same size as the tiles - is this something the Windows 'use_graphics_nice' and/or 'td->bizarre' flags are used for to create a better text/graphics mix?
  • You'll notice a couple of tiles to the right of DEX/CON - I was wondering what they were, and realised they are my equipment slots - would be nice to have these as text so they didn't waste so much space
  • Somehow I've trash text only support

Patch has been pushed
Attached Thumbnails
Click image for larger version

Name:	latest_x11.jpg
Views:	80
Size:	13.0 KB
ID:	1415   Click image for larger version

Name:	latest_x11 (tileset 2).jpg
Views:	67
Size:	14.6 KB
ID:	1416   Click image for larger version

Name:	latest_x11 (tileset 1).jpg
Views:	67
Size:	10.0 KB
ID:	1417   Click image for larger version

Name:	latest_x11 (tileset 3).jpg
Views:	71
Size:	13.7 KB
ID:	1418  
calris is offline   Reply With Quote
Old May 7, 2016, 03:48   #13
takkaria
Veteran
 
takkaria's Avatar
 
Join Date: Apr 2007
Posts: 1,936
Donated: $40
takkaria is on a distinguished road
I think you're assuming Angband has more advanced graphics support than it actually does. Graphics in Angband are displayed on the same grid as the text and are stretched/squished to fit. So while you have nice square tiles displayed, the game doesn't know that.

We have some options - the globals tile_width and tile_height - which allow a single tile to be stretched over multiple text grid positions. e.g. if tile_width is set to 2, then after each tile horizontally a 'spacer' tile is drawn (I think with char&attr = 255, but I've never looked that closely) to give space for the frontend to stretch the tile. Similarly with tile_height = 2, it'll add a spacer grid underneath each tile (I think it's underneath, anyway - you can find out by setting those parameters in text mode and seeing the spacing). This is poorly documented and hacky, obviously. It's a system that's evolved over years to try and improve things without fundamentally redesigning stuff.

Anyway, I think this is the root of your problems. So your call to Term_resize() should be based on text size, not tile size, and you need some tile resizing code too. Either that or work out how to make graphics and text coexist better
__________________
takkaria whispers something about options. -more-

Last edited by takkaria; May 7, 2016 at 03:55.
takkaria is offline   Reply With Quote
Old May 7, 2016, 13:44   #14
calris
Adept
 
Join Date: Mar 2016
Posts: 194
calris is on a distinguished road
Thanks takkaria - by setting the 'window tile' size the same as the 'tileset tile' size, everything renders nicely. Of course the text looks totally whacky, and using the 64x64 shockbolt tiles is out of the question. So two things would be nice:
  1. Finding a way to scale the tiles in X - not fun, but I'll see what I can find
  2. Split the Term window into 'dungeon view' and 'textual fluff' so the text can have a different size to the tiles
calris is offline   Reply With Quote
Old May 7, 2016, 22:08   #15
molybdenum
Apprentice
 
Join Date: May 2013
Posts: 84
molybdenum is on a distinguished road
Quote:
Originally Posted by takkaria View Post
Either that or work out how to make graphics and text coexist better
So, I actually did something for this a few years ago, but I never got it to a finished-enough state to push (it was also dependent on a lot of grubby OS X code I had rewritten which also wasn't ready). It's one of the things on my list to fix up and implement in the OS X overhaul, in addition to other grid things like big tiles.

The basic idea is that there are actually two grids: a logical grid (the term x/y/width/height) and a physical grid (the grid you are actually drawing to). When Angband wants to update a tile at logical (x, y), the conversion code checks if this coordinate is (a) in the main term and (b) in the region of the term that we should consider using separate tile sizes. In the case of OS X, the default was to use the text size as the grid size and the special region was the area not occupied by the message row, status row, and sidebar.

Once I got a good chunk of logic issues out of the way, it really wasn't that much code. I don't think I had gotten all of the edge cases though.
molybdenum is offline   Reply With Quote
Old May 8, 2016, 04:08   #16
calris
Adept
 
Join Date: Mar 2016
Posts: 194
calris is on a distinguished road
What we really need to do is to separate the 'cave' grid from the 'term' grid, thus allowing the size of the cave grids to be independent of the term grids. But we also need to account for drawing menus using text. My thought is fairly simple:

- Have the main term windows (i.e. angband_term[0]) grid be sized to the font - this is used for all text operations including menus
- Define a new term windows (struct term cave_term) which all attr/char for the cave are draw into
- Have angband tell the front end where the 'cave term' gets mapped relative to the main term - for example, an 80x25 main window and a cave term mapped from (10,1) to (79, 23) give one row of text at the top, one row of text at the bottom, and 9 columns of text on the left.
- Have the front end use Term_resize() to specify the size (in text grids) of the angband_term[0] term (and other terms)
- Add a new cave_term_resize() function to specify the size of the cave view in graphical tile sizes (or text sizes if we are in text mode)

Now, the front-end simply renders the cave term first, then the main term over the top - so menus will appear over the main cave. I think the front end changes will be fairly minimal.

My big problem is, figuring out how the cave drawing code fits in - I'm trying to figure out how to make the cave draw to a term other than angband_term[0] - any help would be appreciated
calris is offline   Reply With Quote
Old May 8, 2016, 10:17   #17
Nick
Vanilla maintainer
 
Nick's Avatar
 
Join Date: Apr 2007
Location: Canberra, Australia
Age: 54
Posts: 7,842
Donated: $60
Nick will become famous soon enough
Quote:
Originally Posted by calris View Post
What we really need to do is to separate the 'cave' grid from the 'term' grid, thus allowing the size of the cave grids to be independent of the term grids. But we also need to account for drawing menus using text. My thought is fairly simple:

- Have the main term windows (i.e. angband_term[0]) grid be sized to the font - this is used for all text operations including menus
- Define a new term windows (struct term cave_term) which all attr/char for the cave are draw into
- Have angband tell the front end where the 'cave term' gets mapped relative to the main term - for example, an 80x25 main window and a cave term mapped from (10,1) to (79, 23) give one row of text at the top, one row of text at the bottom, and 9 columns of text on the left.
- Have the front end use Term_resize() to specify the size (in text grids) of the angband_term[0] term (and other terms)
- Add a new cave_term_resize() function to specify the size of the cave view in graphical tile sizes (or text sizes if we are in text mode)

Now, the front-end simply renders the cave term first, then the main term over the top - so menus will appear over the main cave. I think the front end changes will be fairly minimal.

My big problem is, figuring out how the cave drawing code fits in - I'm trying to figure out how to make the cave draw to a term other than angband_term[0] - any help would be appreciated
I really like this idea, but I think I need some time for it to sink in so I can understand how the code would need to change.
__________________
One for the Dark Lord on his dark throne
In the Land of Mordor where the Shadows lie.
Nick is offline   Reply With Quote
Old May 8, 2016, 10:34   #18
calris
Adept
 
Join Date: Mar 2016
Posts: 194
calris is on a distinguished road
Quote:
Originally Posted by Nick View Post
I really like this idea, but I think I need some time for it to sink in so I can understand how the code would need to change.
PWMAngband already does something along these lines I believe - See for example this screenshot
calris is offline   Reply With Quote
Old May 8, 2016, 18:20   #19
takkaria
Veteran
 
takkaria's Avatar
 
Join Date: Apr 2007
Posts: 1,936
Donated: $40
takkaria is on a distinguished road
Quote:
Originally Posted by calris View Post
What we really need to do is to separate the 'cave' grid from the 'term' grid, thus allowing the size of the cave grids to be independent of the term grids. But we also need to account for drawing menus using text. My thought is fairly simple:

- Have the main term windows (i.e. angband_term[0]) grid be sized to the font - this is used for all text operations including menus
- Define a new term windows (struct term cave_term) which all attr/char for the cave are draw into
- Have angband tell the front end where the 'cave term' gets mapped relative to the main term - for example, an 80x25 main window and a cave term mapped from (10,1) to (79, 23) give one row of text at the top, one row of text at the bottom, and 9 columns of text on the left.
- Have the front end use Term_resize() to specify the size (in text grids) of the angband_term[0] term (and other terms)
- Add a new cave_term_resize() function to specify the size of the cave view in graphical tile sizes (or text sizes if we are in text mode)

Now, the front-end simply renders the cave term first, then the main term over the top - so menus will appear over the main cave. I think the front end changes will be fairly minimal.

My big problem is, figuring out how the cave drawing code fits in - I'm trying to figure out how to make the cave draw to a term other than angband_term[0] - any help would be appreciated
Yup this is defintely the right way to go, I think. I spent a while fiddling with this a while ago too and these are some of the things I thought made sense; take them or leave them as you wish.

1. screen_load()/screen_save() need changing. As well as the terminal package keeping track of the different saved screens, with graphics done separately you need frontends to have their own 'save' / 'load' hooks which save/re-load the actual graphic image displayed on the screen.

2. to avoid reimplementing logic across frontends you need some kind of graphics compositor that does all the work and just gives frontends a few hooks: save/load currently displayed image, some way of telling it what the font dimensions are and what size the window is, and obviously a tile plotting hook (which plots a given tile at a given pixel location, rather than grid location).

3. I also think there's scope here for stopping using the ugly system where we encode graphic tiles for the term package as attr/chars by turning on the highest bit. Instead we could just have a plotting function which takes row/col in the bitmap.

4. We need support for transparent backgrounds in the terminal package

In answer to your question, map drawing for the main terminal is set up/torn down in ui_enter_world() and ui_leave_world() in ui-display.c, and hooks into the EVENT_MAP event type. The hook is ui-display.c:update_maps(), which either redraws the whole map (see ui-map.c: prt_map()), or if a particular point is to be redrawn (specified in the event data), redraws just that point. The same hook is also used to display the map subwindows. HTH.

(PS I wrote something quite similar to what you're proposing a few years ago but I think I probably architecture astronauted it out of existence. Linking to it because you might find it useful, but feel free to ignore! http://trac.rephial.org/wiki/NextUi)
__________________
takkaria whispers something about options. -more-

Last edited by takkaria; May 8, 2016 at 18:42.
takkaria is offline   Reply With Quote
Old May 9, 2016, 04:49   #20
calris
Adept
 
Join Date: Mar 2016
Posts: 194
calris is on a distinguished road
What is really going to start messing things up is this global Term variable. I purged the x11 frontend of all it's 'activate window/colour/font' rubbish, and I think it's about time the main UI got the same treatment. But for now, I'm hacking around it.
calris 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
Code (style) cleanup patches calris Development 5 April 24, 2016 04:33
major ood drop at 550 feet tynan Vanilla 5 April 20, 2014 11:10
Angband under X11 Magnate Vanilla 3 December 13, 2009 22:56
[Dev] I've located the cause of this major bug with fear. Irashtar Vanilla 0 August 31, 2008 12:04
[Dev] major Fear bug. Irashtar Vanilla 1 August 31, 2008 04:03


All times are GMT +1. The time now is 22:56.


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