Angband.oook.cz
Angband.oook.cz
AboutVariantsLadderForumCompetitionComicScreenshotsFunniesLinks

Go Back   Angband Forums > Angband > Variants

Reply
 
Thread Tools Display Modes
Old March 17, 2009, 10:33   #11
curinor
Scout
 
Join Date: Mar 2008
Posts: 25
Donated: $20
curinor is on a distinguished road
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.
curinor is offline   Reply With Quote
Old March 17, 2009, 18:51   #12
Gen0cide
Rookie
 
Join Date: Mar 2009
Posts: 10
Gen0cide is on a distinguished road
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.

Last edited by Gen0cide; March 18, 2009 at 00:14.
Gen0cide is offline   Reply With Quote
Old March 23, 2009, 05:18   #13
darke
Rookie
 
Join Date: Mar 2009
Posts: 8
darke is on a distinguished road
Quote:
Originally Posted by Arralen View Post
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.
darke is offline   Reply With Quote
Old March 23, 2009, 21:18   #14
Gen0cide
Rookie
 
Join Date: Mar 2009
Posts: 10
Gen0cide is on a distinguished road
Quote:
Originally Posted by darke View Post
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?
Gen0cide is offline   Reply With Quote
Old March 23, 2009, 23:54   #15
darke
Rookie
 
Join Date: Mar 2009
Posts: 8
darke is on a distinguished road
Quote:
Originally Posted by Gen0cide View Post
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.


Quote:
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.)

Quote:
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.
darke is offline   Reply With Quote
Old March 24, 2009, 04:53   #16
Pete Mack
Prophet
 
Join Date: Apr 2007
Location: Seattle, WA
Posts: 3,879
Donated: $40
Pete Mack is on a distinguished road
Don't use #ifdef, use conditionals with global variables instead.

conditional code tends to get extremely confusing and hard to debug.
Pete Mack is offline   Reply With Quote
Old March 24, 2009, 06:24   #17
darke
Rookie
 
Join Date: Mar 2009
Posts: 8
darke is on a distinguished road
Quote:
Originally Posted by Pete Mack View Post
Don't use #ifdef, use conditionals with global variables instead.

conditional code tends to get extremely confusing and hard to debug.
How so? The #ifdef's are only one level deep. It's nothing like the macro-recursion-nightmare of the ALLOC/FREE code for instance. Granted it's butt ugly, but C has never been the most elegant looking language, only C++'s template-meta-programming work manages to look worse.

In any event, assuming this was not quick-hack code (and thus the quickest and easiest solution is the best), should I go the `if(has_gui) { print_gui(...); } else { print_term(...); }` route, this would result in the print_gui symbols being exposed in all builds, not just the currently windows only gui build, and thus requiring a stub library of "do nothing" functions for all systems that don't support an actual gui.

Also for those picky about performance (say, building a DS or Iphone port) it also has an unnecessary set of runtime (rather then compile time) execution-stall/microcode-cache-flush, test-and-branch instructions every call, and has extra code-memory overhead (I'm regularly enough not just doing a print_gui() call, which could be optimised out if the body is empty, so any string fiddling code, or constants, will still be in there taking up space...). No idea if it'll have any effect though, bit out of practice since the last time I was doing anything of that level of optimisation was way back in the era of blazing-fast-100mhz sparcstations...
darke is offline   Reply With Quote
Old March 24, 2009, 07:45   #18
Pete Mack
Prophet
 
Join Date: Apr 2007
Location: Seattle, WA
Posts: 3,879
Donated: $40
Pete Mack is on a distinguished road
Conditional code is generally considered a bad thing.
Reasons include:
1. Prevents code rot. If both paths are always compiled, you can't introduce syntax errors in the other path.
2. Ensures that parenthesis matching will agree in the editor and in your code. (Tracking down improperly #-embedded braces is a huge pain.)
3. Means that you don't need two different conditional compiles to test your code. You can test the gui vs ascii versions without recompiling.
4. It's easier to read the indenting from {} than from #if code.

See, for example:
http://www.ddj.com/cpp/184401475
Pete Mack is offline   Reply With Quote
Old March 24, 2009, 09:46   #19
darke
Rookie
 
Join Date: Mar 2009
Posts: 8
darke is on a distinguished road
Quote:
Originally Posted by Pete Mack View Post
Conditional code is generally considered a bad thing.
I'll be the first to agree with you on that, since I normally follow the exact advice in the last line of the article "Even in the case of header files, use of #ifdef is generally a poorer approach than a redesign."

The appropriate way to redesign would be to create an additional abstraction layer between the print_ functions and the term_ related functions (just like the term_ functions are an abstraction layer on top of the different hardware) so as to properly handle terminals, guis, or random other interfaces (ARS-33 teletypes? ).

Assuming I'm working on Un for real, rather then as a random hack, the issue is that I'm trying to work within the current framework, as a result if I use if() rather then #if, it exposes gui_ functions, which currently aren't supported on all compile targets. Which means I need to make even more changes to add "do nothing" functions, and test these changes somehow on platforms I can't compile on (I've already had this issue with breaking the Mac build to fix an odd problem on windows, that worked fine on both windows and linux).

For me it's a cost/time/correctness trade off. I can "solve" the problem with #ifdefs, by using if()'s, only at the cost of more complexity.

Quote:
Reasons include:
1. Prevents code rot. If both paths are always compiled, you can't introduce syntax errors in the other path.
We already have this issue with multiple compile targets. There's already windows/linux/mac that are being maintained, and it's pretty rare to introduce a bug in one that's not in the others (I've only done it once so far in my massive batch of bug fixing), so having an extra windows-gui one would add negligable extra maintenance issues. Plus there's already a half dozen other platforms that are sitting there unmaintained (Amiga? OS/2? DOS/32? RISCOS?), so yet-another broken and unmaintained platform wouldn't hurt.

Quote:
2. Ensures that parenthesis matching will agree in the editor and in your code. (Tracking down improperly #-embedded braces is a huge pain.)
Ya, that does suck. Which is why I try to avoid using them.
Quote:
3. Means that you don't need two different conditional compiles to test your code. You can test the gui vs ascii versions without recompiling.
I just have multiple configurations in Visual Studio, one that builds a debug tree minus 3dgui, one that builds it with gui, and my changes are usually pretty local so it's only 5 seconds waiting to compile the other release with the one or two changed files. Also I'll often have both debug builds running simultaneously so I can replicate what I do in one, in the other, to make sure they are working the same. It would be much harder to do that, or at least much more fiddly to do that, if I were running two copies of the same program.
So for me this would actually be a disadvantage.
Quote:
4. It's easier to read the indenting from {} than from #if code.
Yup. Multiple nested #ifdefs are a pain, but unfortunately pretty common in config.h's if you have to support multiple platforms.

Anyway, I think I've meandered quite off track from discussions over gui-ification of *bands.
darke is offline   Reply With Quote
Old March 24, 2009, 09:49   #20
andrewdoull
Unangband maintainer
 
andrewdoull's Avatar
 
Join Date: Apr 2007
Location: Sydney, Australia
Age: 42
Posts: 872
andrewdoull is on a distinguished road
Quote:
Originally Posted by darke View Post
...but when I hacked Un into a 3d engine out of curiosity...
Um... could you clarify? Perhaps with screen shots?

I'm not against moving to the the newer Angband display model, but its not had time to prove itself yet.

Andrew
__________________
The Roflwtfzomgbbq Quylthulg summons L33t Paladins -more-
In UnAngband, the level dives you.
ASCII Dreams: http://roguelikedeveloper.blogspot.com
Unangband: http://unangband.blogspot.com
andrewdoull is offline   Reply With Quote
Reply

Tags
zangband tk band tcl


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
Variant writing.. quickstart guide? Also, Hengband variant suggestions? dzhang Variants 34 April 1, 2009 00:45


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


Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2017, vBulletin Solutions, Inc.