Tweet
As I pootled home on my bicycle today my mind turned to tile support in Angband. This is something I really wanted to work on while I was maintainer but was always crowded out by other stuff.
I figure there are two broad approaches to better tile support: the first is to go for it, and write a new frontend for some platform or framework (like Qt) that does stuff differently without touching the existing frontends. The second is to try and improve the game core to support something like the existing terminal package but for graphics and then write something on top of it. As a code reuse and tidiness freak I'm more into the second. Also, maintaining one way of doing graphics for three frontends with pref files and tilesets (which the current approach requires) and another way using separate tiles will be a nightmare, so if we want to move to a file-per-tile we're going to have to bring along the old frontends, or abolish their graphics support.
I wrote up my initial thoughts on some building blocks for this work here, but basically, they involve writing a couple of layers of graphics primitives so that the core game has some concept of graphics support (including e.g. shockbolt's double-height tiles). Then attempting to move existing frontends to use this, before ripping out graphics from z-term and then moving to a file per tile instead of these ridiculous massive tilesets with 128 added to every location.
I'm going to have a go at writing this at some point but it might take a while, but if anyone else fancies a go, I'd say don't wait, bearing mind I have spent years not finishing some subprojects in Angband!
I think my plan is to start with the SDL frontend, and make a window that just draws a map, get map updates working properly there with full tile sizes and then try to integrate that into the main term. I think the API above would be relatively easy to test in unit tests too, which would make not breaking everything horribly without noticing a lot easier.
I think Nick also has some thoughts to share on this.
I figure there are two broad approaches to better tile support: the first is to go for it, and write a new frontend for some platform or framework (like Qt) that does stuff differently without touching the existing frontends. The second is to try and improve the game core to support something like the existing terminal package but for graphics and then write something on top of it. As a code reuse and tidiness freak I'm more into the second. Also, maintaining one way of doing graphics for three frontends with pref files and tilesets (which the current approach requires) and another way using separate tiles will be a nightmare, so if we want to move to a file-per-tile we're going to have to bring along the old frontends, or abolish their graphics support.
I wrote up my initial thoughts on some building blocks for this work here, but basically, they involve writing a couple of layers of graphics primitives so that the core game has some concept of graphics support (including e.g. shockbolt's double-height tiles). Then attempting to move existing frontends to use this, before ripping out graphics from z-term and then moving to a file per tile instead of these ridiculous massive tilesets with 128 added to every location.
I'm going to have a go at writing this at some point but it might take a while, but if anyone else fancies a go, I'd say don't wait, bearing mind I have spent years not finishing some subprojects in Angband!
I think my plan is to start with the SDL frontend, and make a window that just draws a map, get map updates working properly there with full tile sizes and then try to integrate that into the main term. I think the API above would be relatively easy to test in unit tests too, which would make not breaking everything horribly without noticing a lot easier.I think Nick also has some thoughts to share on this.
Comment