Reviving Iso-Angband, an isometric view addon for Angband

[andrewdoull]

I feel a bit uncertain if this is the right way to picture "open vents" and "empty basins". But it looks interesting to me anyways

That's as good as we're going to get, without me having to hack up another '32-way support for vents' code.

I'd assume that the basins are meant to be aligned with the wall, maybe like fountains as part of the wall. Such directional objects are kind of tricky in a block-oriented display though ...

IIRC there is support for 2 way alignment of items against walls (either north-south, or east-west). Use the ATTR_DOOR indicator to get this.

It won't correctly handle facing from the south or west side of walls though.

Andrew

[Hajo]

If the vents are meant to be pipes along the corridors, I might be able to do something, too - this will be for the farther future, though. In these two cases I was mostly uncertain how the things are intended to look.

For the basins (and other wall-aligned features) I can imagine a few solutions. Important was to know these are meant to be part of the walls and not single, detached, basins.

Thanks for the clarification, Andrew

[andrewdoull]

If the vents are meant to be pipes along the corridors, I might be able to do something, too - this will be for the farther future, though. In these two cases I was mostly uncertain how the things are intended to look.

Think 'air conditioning ducts'. They might be in an open space, in which case you are crawling around them, or they might be in a closed up space in which case you're crawling through them.

For the basins (and other wall-aligned features) I can imagine a few solutions. Important was to know these are meant to be part of the walls and not single, detached, basins.

A detached basin is a fountain, if that helps any. (At least a water filled fountain).

Andrew

[Hajo]

I've been experimenting with a few basin design ideas, but I haven't found something yet that I really liked. At the moment I'm a bit ill, and the medicine has side effects that aren't very pleasant either. I'll try to pick up work again once I feel better, hopefully next week.

[Hajo]

Staying in style ...

A while I thought it might be cool to have a full detailed basin thing - so I modeled one and rendered it, just to find out it totally does not fit with the other images. So for the time being I'm back to a very simple outline style standalone basin, which is boring, but consistent with the rest of the graphics.

[Hajo]

Last post here was 2 and half a year ago ... it's hard to believe how fast time passes. I've been ill, been busy with other projects, distracted, well and when I finally thought it would be fine to work on Iso-Angband some more, I had to see that the world has changed again. Much.

Angband has gotten a much advanced main-sdl.c now, new and better tile sets, and I'm even no longer sure if isometric display is a good idea. But to get a start, I've downloaded Angband 3.4.1 sources and tried to learn how the new main-sdl.c works. I've manged to compile it, run it, and replace a few routines in the main-sdl.c to see ho a graphical display could be linked to it, and it seems to work all fine now. It's just been very slow progress the past days, because so much is new and I'm slow in reading code, and finding out how everything is supposed to work.

To avoid loss of code, screenshots and all that again, this time I've registered a project on SourceForge:

http://sourceforge.net/projects/yanotavar

There isn't anything to show or see yet, since I'm just starting again. Still with the idea of nice and easily readable graphics in mind, but better integrated with Angband than the former display was. I hope I'll have something to show in a few days.

PS: Angband 3.4.1 can't read it's own pref-file dumps for objects, since it expects object names in a slightly different format than the one that it writes.

I have no idea if my fix was right, I changed the dump routine to produce the same object name format which the parsing routine uses when it compares object names with the names read from the pref file.

--- a/yanovatar_source/trunk/src/prefs.c
+++ b/yanovatar_source/trunk/src/prefs.c
 
@@ -239,13 +239,16 @@
 	{
 		object_kind *k_ptr = &k_info[i];
 		const char *name = k_ptr->name;
+                char buf_name[1024];
 
 		if (!name) continue;
-		if (name[0] == '&' && name[1] == ' ')
-			name += 2;
-
+		// if (name[0] == '&' && name[1] == ' ')
+		//	name += 2;
+                
+                obj_desc_name_format(buf_name, sizeof buf_name, 0, name, 0, FALSE);
+                
 		file_putf(fff, "K:%s:%s:%d:%d\n", tval_find_name(k_ptr->tval),
-				name, k_ptr->x_attr, k_ptr->x_char);
+				buf_name, k_ptr->x_attr, k_ptr->x_char);
 	}

[Nick]

To avoid loss of code, screenshots and all that again, this time I've registered a project on SourceForge:

http://sourceforge.net/projects/yanotavar

There isn't anything to show or see yet, since I'm just starting again. Still with the idea of nice and easily readable graphics in mind, but better integrated with Angband than the former display was. I hope I'll have something to show in a few days.

Excellent! A couple of things you might want to take note of:

• The angband variant repository has an IsoAngband page
• The latest code angband code is also on github; I don't know if that makes moving to github a good idea for you or not.

[takkaria]

PS: Angband 3.4.1 can't read it's own pref-file dumps for objects, since it expects object names in a slightly different format than the one that it writes.

I have no idea if my fix was right, I changed the dump routine to produce the same object name format which the parsing routine uses when it compares object names with the names read from the pref file.

The latest dev version has fixed this in a slightly different way but I think your fix looks correct too.

[Hajo]

@Takkaria: Ok, thanks. I'll not need this function often, just to create an inital set of pref files for my graphics. It's been a bit a stumbling block though, since I was pretty puzzled that reading the newly created file failed and I had to dig into the parser code to find out why.

@Nick: Cool, I didn't know that the code is still available on the web. Good job there!

I'm not sure if I want to move to github yet though, but I'll think about it. It will also mean to learn a new version management tool for me, something I'm a bit hesitant about.

Also, I think I must drop the name "Iso-Angband" since I've changed my mind and think that a simple rectangular view fits better to the Angband display and needs less hacks.

At the moment I have removed the dependencies to SDL_ttf and SDL_image from main-sdl.c since those required a lot more libraries to be installed. I have added selfmade font drawing routines which can load glyphs from PNG files, so there are still dependencies to libPNG and libz.

It doesn't look like much at the moment, and I believe that I even have broken some features of main-sdl.c in my attempts to lift the dependencies, but I hope I can restore everything which went broken:

http://yanotavar.sourceforge.net/screens/pre-alpha-001.png

The project goals are still the same which I had before, just without the requirement of using an isometric display:

- World representation by shape+color combinations
- Depth illusion by stacked graphics

Basically the idea is like the traditional text mode, where colored ASCII symbols are used to display the game's world, just that I want to replace the ASCII symbols by shapes which resemble the shape of the represented objects. This will still be very abstract, and "realistic" graphics are not a goal.

To give the illusion of depth, these shapes will partially ovelap. This also allows to condense the map display in one direction, offering more information in the same space. I hope it won't hurt readability, and a good choice of shapes and colors can help there. Interesting to see that Angband nowadays has 28 differnet colors, while I had been thinking that even 16 are hard to distinguish at times, and pondered to use only 12.

I'm unsure though about a good size of the shapes and the display raster. The former Iso-Angband incarnations used 64x64 pixel tiles arranged in a isometric raster of 64x32 pixels.

Now the raster is no more isometric, but rectangular. In the example screen above I used a display raster of 24x11 pixels. I don't have configured any graphics yet, so I just placed colored characters on the raster, overlapping as the graphics will do too.

There is a whole lot to adjust, including the colors and display brightness. First I must get a feeling what will work well, and what doesn't. With the used raster, there is space to the left or right of the main term for additional term windows, which might be useful.

[Hajo]

I think I have most things in place now. The code can draw fonts/characters and graphical symbols. Now I 'just' need to tune everything so that it runs well and looks good.

A first screenshot that might give an idea where this is heading:

http://yanotavar.sourceforge.net/screens/pre-alpha-002.png

It's very likely that a lot of details will change, but a start has been made. I might adjust the raster from 24x11 to something a little larger, but even 24x12 already is too tall for my notebook screen - and if I turn the map, it is too wide

But with time there come ideas

[Nick]

This is looking great. Am I right in thinking it's going to be essentially a graphical front end that can be put on any variant? Just, you know, asking

[Hajo]

It's mostly a modified main-sdl.c and a few files with support code (PNG image loading, and drawing color-adjusted bitmaps onto SDL surfaces). So it should work with all variants which use the standard term system and the main-xxx.c files.

But turning the map screwed the direction input. Menus still want cursor up/down keys to be up/down, but the map's x-axis now runs downwards and the y-axis now runs to the right. I have changed two places in cmd1.c and cmd3.c to make movement work "as expected", but I don't think it was correct to fix the problem this way. I need to find a distinction if input will control a menu or means a direction on the map. If there is a good solution for this problem, it should become a fairly clean graphical frontend.

[Derakon]

Is there any particular reason why navigation input needed to be rotated 90°? I mean, the grid is still axis-aligned so why should it matter?

[Hajo]

Well if you press the "down" key and your character moves "right" on the screen you feel confused :P

I've turned the map display to make better use of the screen space. To give illusion of depth, the smybols in front overlap the symbols in the back, and map display space along the screen y axis becomes smaller.

To show 60x20 tiles horizontally with 24x12 raster means an area of 1440x240 pixels being used, which seemed very awkward to me. Displaying 60x20 tiles vertically in this raster uses 480x720 pixels, which seemed to be much better. And there is extra space besides the map now to show inventory, message or other additional windows (terms). Rotating the map requires to translate all input to the right map directions, but I'm somewhat confident that Angband internally has solved this problem already and it's just for me to find the right place to make this translation.

[Derakon]

Right, I get that the orientation looks nicer, but why not just rotate the town? And the dungeon, of course. That way you can display things exactly as they are and still get the orientation you like. Have the in-memory representation of the world match the displayed representation and you'll have a lot fewer headaches.