Variant Tcl+TK Fusion?

**PaulBlay** · March 16, 2009, 20:13

I don't know much about ZAngbandTK in particular (and my Internet account might be going over bandwidth this month so I'm not going to download it ;-) however you might be better off trying to get the features you most like included in Vanilla (or NPP might be easier) without Tcl / TK.

**Gen0cide** · March 16, 2009, 20:55

Well, if you havent played ZangbandTK, it has a modular window setup, with all the non turn using information already displayed. That includes, health and mana, message history, inventory, a quick menu for moves like using wands, rods and spells, quaffing potions and eating. A minimap display, a GUI like quest, shop etc. And numerous more things, like the creature information on mouse-over and icons for going up and down dungeon levels.

It just basically takes the gazillion keys for the *band games and maps them out in the GUI, its supposed to be easily adaptible too, as if I remember correctly he had ported it to Kangband (I think this has been lost to the times) and Angband (Which was bundled with the version I have.)

Have a look here for the general look. http://www.zangband.org/common/gfx/screenshots-tk.jpg

ZangbandTK (PC) download

http://free-game-downloads.mosw.com/abandonware/pc/role_playing_games/games_u_z/zangbandtk.html

put your mouse to the bottom of the main window and options will appear offering common comsuming habits etc.

**PaulBlay** · March 16, 2009, 21:20

The mini-map certainly sounds like something that could be implemented in other *band variants fairly straightforwardly and it would be useful for people who play with large tiles.

(Not to say that there's anything wrong with the rest of the UI)

Basically, whatever method used, you're going to need to spark enthusiasm in somebody who can do enough programming and has enough time. Unfortunately I think I have more than enough on my hands (and maybe not so much programming skill

). So I'll have to just settle for wishing you luck.

**Gen0cide** · March 16, 2009, 21:28

Any idea who would be a good bet?

And why cant it simply be ported? Aren't the cores of each variant the same?

**PaulBlay** · March 16, 2009, 21:34

Originally posted by Gen0cide

Any idea who would be a good bet?

And why cant it simply be ported? Aren't the cores of each variant the same?

I'm no sort of expert, but Zangband is considerably different from Angband. Porting may be possible, but it's something too big for me to look into at the moment. Your best bet at this point is probably just to cross your fingers.

**Gen0cide** · March 17, 2009, 01:07

The tcl UI has already been been ported to Angband, I have "AngbandTK" as the port is called. If the program has already been ported to Angband, won't that make it a whole lot easier to port it to other versions. (seeing as Angband is the root of all variants.)

On my personal importance list, I rate this second only to Gervais' 54x54 tiles

**takkaria** · March 17, 2009, 01:10

Originally posted by Gen0cide

The tcl UI has already been been ported to Angband, I have "AngbandTK" as the port is called. If the program has already been ported to Angband, won't that make it a whole lot easier to port it to other versions. (seeing as Angband is the root of all variants.)

On my personal importance list, I rate this second only to Gervais' 54x54 tiles

It's actually a right PITA to port the Tk stuff to other variants—and even newer versions of the same variants. It's unlikely to happen unless someone gets the energy up for it, but I hope that eventually an SDL port can be developed which will achieve much the same function.

**Gen0cide** · March 17, 2009, 01:19

What a shame. In my experience, the TK series was by far the most newcomer friendly, I-can-learn-to-play-without-the-use-of-a-guide-plainly-with-trial,-error,-and-hard-work, variant in my opinion.

What about Wish. That program that comes bundled with Zangband, what is it and what does it do, I thought it was some kind of compiler or variant importer, but I am obviously mistaken.

EDIT: Surprisingly quick replies on this forum considering the numbers, thank you very much posters

**Arralen** · March 17, 2009, 03:08

I know a little bit Tcl/Tk, just enough to wholeheartedly agree about the PITA thing

... :

Let me first talk 'bout Tcl/Tk in general:
It's a script language ("Tool Command Language"), originally designed to "glue" together command-line tools written in (e.g.) C/C++, like those found on *nix machines. Tcl/Tk itself is written in C, but still its an interpreted language and especially GUI output can be a tad slow sometimes ... .
Tk is the "Took Kit" to give the whole thing an easy to make GUI - it's actually the easiest to use GUI toolkit I know (easy enough that I can use it...). The Tk GUi-toolkit has been used with other languages as well ("Perl/Tk", "Lua/Tk", even "Fortran/Tk"!)

The Wish.exe you found in some subdir is actually the WindowsShell - the GUI-enable Tcl interpreter. There's a Gui-less Tclsh.exe (TclShell) as well ... . Actually, with the current v8.4.+ the use of wish has been mostly discontinued, as tclsh can load the gui (tk) packages now as well.

Got me the Z/AngbandTk ("OmnibandTK") Windows Package from Abadonia Reloaded and had a look at the whole thing .. here's the little I was able to figure out:
- you'll need a special *band build, with the EXE split into a loader and a *.dll file. Needs "extra" compilation and AFAIK would give you extra trouble for making it OS independant
- it loads several Tcl/Tk packages as *.dll files, what gives you even more headaches when porting to *nix and OS/X AFAIK, as those packages are not necessarily available as *nix versions, or pure tcl scripts.
- I wasn't able figure out how the output from the original angband.exe is captured at all. Surely I missed something important, but then I didn't spent so much time on it, and, as I said, I'm really not a good programmer. I do know, though, that there's no "magic capturing package" build-in in Tcl/Tk, so most likely the *band code has to be tweaked as well.

+ The tcl script files look nicely-coded and documented, though !

**curinor** · March 17, 2009, 11:33

Quick question. How on earth did you manage to complete the game. I've been playing it for years and I'm not even close to winning. I'm down about level 65, and I'm stuck....I'm a level 50 High Elf Chaos Warrior. I'm writing this from work so don't have a character dump. Any help that you can give me would be appreciated.

**Gen0cide** · March 17, 2009, 19:51

Curinor.

I have reason to belive from the posts on this forum, that there is a certain quest that has a glich in it that never allows you to manually pass a level around 60-75. This is what I did, but to be honest, I did make multiple copies of my gamesave before doing this, and enabled cheatmode on the save I first did this with, incase I died.

Well, once you judge your self powerful enough, consider using the trump tower shop in the big town north of the starting one. For 10000 coin, he will teleport you down to any level you wish. I used that to teleport down to about level 80 with my Chaos Warrior, and when ever I got into a spot of trouble, pulled out the spell book and cast Destruction (I think its called that. It shakes the screen and randomly moves the walls, whilst destroying or teleporting most things.) Then Recalled and cast the same spell in the event I was attacked by something faster and stronger than me again. Your main problem once you get down there will be Breath attacks, Raw Logrus (The eaasiest to gain resistance to), and Nether. Time is also a b*tch, and I was still victim to time and amnesia when I reached Oberon. Send your dump, and I will have a good look and suggest, but for now, I will just tell you resistance is king, and a good escape route is also very important JIC.

(Oh and use any Scrolls of Genocide wisely and sparingly, they are easily the most important scrolls once you reach the deep levels, that said, better use them than die. And not just because they share my screen name

)

EDIR, Im time pressured atm, so ill edit this post with your answer.

**darke** · March 23, 2009, 06:18

Originally posted by Arralen

I know a little bit Tcl/Tk, just enough to wholeheartedly agree about the PITA thing

... :

- I wasn't able figure out how the output from the original angband.exe is captured at all. Surely I missed something important, but then I didn't spent so much time on it, and, as I said, I'm really not a good programmer. I do know, though, that there's no "magic capturing package" build-in in Tcl/Tk, so most likely the *band code has to be tweaked as well.

Haven't played with Tcl/Tk scripting, but when I hacked Un into a 3d engine out of curiosity the main issue I had (other then the bass ackwards method I had to add of driving the 3d rendering stuff from deep within the "wait for a keypress" code), was all the "print information to screen" functions. They all normally do three different tasks: calculate what data they're going to render, and how they're going to render it; print the caption (if any); print the data. For quite a few of the functions (for example, selling stuff in the stores) the printing and calculating are quite well entwined so it's not simple to separate them into their own functions.

Whilst the term layer is nicely abstracted, if you're ditching a term to put everything (or just most things) into a gui, then you're going to end up either replacing all the Term_ calls within the functions, or having to #ifdef out the raw term calls and replace them with a set of Gui_ calls, or otherwise clone the original functions and rewrite them in your scripting (or even within the C code itself).

I ended up #ifdef-ing them so I could flip a compile flag and output a portable 3d version, or a stock windows version so I could test things. It's more tedious then hard to hook a gui into it, but it does require some familiarity with the code, and it's not something that can be done band-agnostic at the moment as far as I can tell.

**Gen0cide** · March 23, 2009, 22:18

Originally posted by darke

Haven't played with Tcl/Tk scripting, but when I hacked Un into a 3d engine out of curiosity the main issue I had (other then the bass ackwards method I had to add of driving the 3d rendering stuff from deep within the "wait for a keypress" code), was all the "print information to screen" functions. They all normally do three different tasks: calculate what data they're going to render, and how they're going to render it; print the caption (if any); print the data. For quite a few of the functions (for example, selling stuff in the stores) the printing and calculating are quite well entwined so it's not simple to separate them into their own functions.

Whilst the term layer is nicely abstracted, if you're ditching a term to put everything (or just most things) into a gui, then you're going to end up either replacing all the Term_ calls within the functions, or having to #ifdef out the raw term calls and replace them with a set of Gui_ calls, or otherwise clone the original functions and rewrite them in your scripting (or even within the C code itself).

I ended up #ifdef-ing them so I could flip a compile flag and output a portable 3d version, or a stock windows version so I could test things. It's more tedious then hard to hook a gui into it, but it does require some familiarity with the code, and it's not something that can be done band-agnostic at the moment as far as I can tell.

I think I understood that, correct me if I'm wrong, as I know nothing of the underpinnings of the *bands, but your saying most of the information that is called to be printed onscreen by entering a keypress is calculated when you want it to be printed to screen, as opposed to just being stored in memory. If this is the case, it seems you have already found your way around it with unangband, which must mean it certainly is possible to make a GUI thats 2d.

I dont know much about coding as of yet, but #ifdef sounds like an interrupt call (as in "if something becomes this, freeze and run the following" type of call) If thats the case, how much do each of the definitions your running this on differ from *band to *band, and would porting your 3d engine take a long time to make compatible with, say, angband itself, or Z+angband?

Oh, and while your at it, what did happen to your 3d engine Unangband? It sounds like a cool idea.

And how long did it take to get as far as you did?

**darke** · March 24, 2009, 00:54

Originally posted by Gen0cide

I think I understood that, correct me if I'm wrong, as I know nothing of the underpinnings of the *bands, but your saying most of the information that is called to be printed onscreen by entering a keypress is calculated when you want it to be printed to screen, as opposed to just being stored in memory. If this is the case, it seems you have already found your way around it with unangband, which must mean it certainly is possible to make a GUI thats 2d.

Take for example this code, it's part of the "print hit points" function, and is a good, simple example:

Code:

#ifndef HAS_GUI
	put_str((show_sidebar ? "Cur HP " : "HP:    "), ROW_CURHP, COL_CURHP);
#endif

	sprintf(tmp, (show_sidebar ? "%5d" : "%d"), p_ptr->chp);

	if (p_ptr->chp >= p_ptr->mhp)
	{
		color = TERM_L_GREEN;
	}
	else if (p_ptr->chp > (p_ptr->mhp * op_ptr->hitpoint_warn) / 10)
	{
		color = TERM_YELLOW;
	}
	else
	{
		color = TERM_RED;
	}

#ifdef HAS_GUI
	prt_gui("CurrHP", (show_sidebar ? "Cur HP " : "HP: "), tmp, color, ROW_CURHP, COL_CURHP);
#else
	c_put_str(color, tmp, ROW_CURHP, COL_CURHP + (show_sidebar ? 7 : 7 - strlen(tmp)));
#endif

The bit in the first lines between the #ifndef HAS_GUI and #endif was the bit that originally wrote the "Cur HP" caption on the main screen. Because I'm currently handling the caption:value pairs as a single element rather then as a caption seperately, I've said not to include it (the "n" in the "ifndef") if I HAS_GUI (sounding like a LOLcat).

Then it calculates how it's going to display the hit points (the "sprintf" function call), then it does some calculating to find out what colour to display it as given how wounded you are (the TERM_L_GREEN/TERM_YELLOW/TERM_RED) bit.

Then normally at the end it uses c_put_str to place that code into your terminal window, however in my "#ifdef HAS_GUI" section, I'm instead making a call to set my "CurrHP" gui element with a caption of either "Cur HP" or "HP", a value of "tmp" (how much health that was calculated earlier), and the colour, and also the ROW_/COL_ of where originally the text would have been placed in a terminal window.

I currently use the ROW_/COL_ values to drop the gui element approximately in the same place on the screen, though it's just hacky/lazyness at the moment, really it would end up being user specified so they could customise their own gui.

So basically for every prt_ function, or store_ function, or the various menu functions (like the "birth" character creation stuff), I need to go in there and less then delicately place these #ifdefs. If I went the other way and didn't try to make it work nicely with updates of Un, I could just remove all the terminal stuff, and rewrite it to use the GUIs exclusively, but since the reason I was doing this was out of curiosity as to whether it would work in the current framework, that would have been counter productive.

I dont know much about coding as of yet, but #ifdef sounds like an interrupt call (as in "if something becomes this, freeze and run the following" type of call) If thats the case, how much do each of the definitions your running this on differ from *band to *band, and would porting your 3d engine take a long time to make compatible with, say, angband itself, or Z+angband?

The #ifdef/#ifndef directives are calculated at compile time. So by the time the nice shiny executable is produced, the code has either been included, or excluded. So pretty much the exact opposite of runtime. It would be possible for me to make this user selectable (rather the programmer selectable) like for example the graphical tiles are, but this was just a quick hack out of curiosity.

Any porting time would be almost entirely consumed with all the code changes above. (Plus any changes to map display between versions of course.)

Oh, and while your at it, what did happen to your 3d engine Unangband? It sounds like a cool idea.

And how long did it take to get as far as you did?

It's only just barely working (ran out of free time; full time work and part time university semester starting leaves little time for much else), it basically displays the main dungeon/town UI, doesn't handle stores or birth menu, and currently doesn't actually render the map.

You can wander around, climb into trees, hit monsters, etc, all the bits and pieces of status effects update and everything plays, but it's a bit on the blind side of things.

Only took me 10 or so hours to hack it together over a weekend, but I was already relatively familiar with both Un's code and the 3d toolkit I used to put it together.

Variant Tcl+TK Fusion?

Variant Tcl+TK Fusion?

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment