Temple of The Roguelike Forums
Game Discussion => Traditional Roguelikes (Turn-based) => Topic started by: AgingMinotaur on August 15, 2013, 05:56:19 PM
-
Some of you remember Abura Tan (http://roguebasin.roguelikedevelopment.org/index.php?title=Abura_Tan), a promising RL set in a fantasy/western setting of "cowboy knights and lurking horrors", or something like that. It's been almost ten years since the last release, which is available as sources or a windows binary. Running Linux myself, I've been testing it a bit in a DOS emulator, but it does crash at intervals. I've not managed to compile it, but some other person might have had the skill to do it, so I figured I'd ask around here. This hominid (http://ttygames.wordpress.com/2013/06/26/abura-tan/) has it running on a Raspberry Pi, but my compile-fu is so very, very weak.
As always,
Minotauros
-
I do remember it. The crashing at intervals was recognized fault of the Abura Tan itself because it is buggy. Still, DOSBox (or whatever you used to make it work) may multiply the crashes so I sat and compiled it. The package contains compiled binary but if it refuses to work for you delete it and run make in this directory. Also, the source has been slightly modified to please g++ version 4.8.1.
http://arcywidmo.republika.pl/aburatan.tgz
-
http://arcywidmo.republika.pl/aburatan.tgz
Did I mention, you are my personal hero since childbirth? ♡♡♡
As always,
Minotauros
-
A while ago I had a failed attempt to bring Abura Tan's source code to modern age. I remember there was something weird going on with the gameview routines that I was unable to understand.
-
Yeah, and it's too bad AT is slightly unplayable at the moment, because of bugs. The game keeps crashing a lot of the times I use stairs. Great potential there.
As always,
Minotauros
-
I could try to find the newest source code I saved and check out what the problem was. One of the backups was from 2009, so I guess it was a while ago...
In fact I did find only that one backup. It was before my HD broke and I got a new computer. In that I lost actually a lot of stuff, because I had never before experienced a HD failure. These days I make more backups.
It could be fun to compile it with latest GCC and run cppcheck on it. I don't have idea was it the latest source, probably not.
Edit: what is this?
template <class T>
bfProxy<T>::bfProxy<T>( direction d, T &r )
: dir(d), ref(r) { }
It gives an error:
error: 'bfProxy<T>::bfProxy' names the constructor, not the type
error: and 'bfProxy<T>' has no template constructors
-
Never mind, only had to remove that last T from the constructor.
After fixing some errors it compiles and runs! But the display routine still has that strange bug. And it still has about 80 warnings (lot of shadow variables which may be a cause for bugs). I think I'm going to fix them and then release the source code if someone else is clever enough to fix the display problem. I have transformed the gui to SDL (using pseudo ascii), but it could be then replaced with something else.
-
After fixing some errors it compiles and runs! But the display routine still has that strange bug. And it still has about 80 warnings (lot of shadow variables which may be a cause for bugs). I think I'm going to fix them and then release the source code if someone else is clever enough to fix the display problem. I have transformed the gui to SDL (using pseudo ascii), but it could be then replaced with something else.
I'm not sure about the display error, but here's my hunch: If it runs in a terminal smaller than 80x25, everything gets completely garbled. While I can't be of much actual help, as C is like Greek to me (incidentally, I don't speak Greek), I think it's wonderful that you give Abura Tan some loving. In the meantime, I'm still hacking away at my own Weird West RL …
As always,
Minotauros
-
I'm not sure about the display error, but here's my hunch: If it runs in a terminal smaller than 80x25, everything gets completely garbled.
It's not that since this version (SDL) doesn't have a terminal type output... I've been fixing those shadow variables. It's somewhat annoying, because the guy used to write long functions with the original declaration at the top of course. He also just had to write his own string and list classes. Oh well I've made those same mistakes myself.
-
Yeah, once I realized your troubles arose from squeezing the thing through SDL, I felt slightly stupid having made that comment, actually ;D Anyways, best of luck on this, do keep us in the loop.
As always,
Minotauros
-
59 warnings left. Some shadows are in fact function names vs. local variable names. I don't know if they need to be fixed, possibly not. But there are still some locals shadowing others etc. Those can be a subtle way to create bugs. I really wish it would have been impossible to use the same variable name in the same scope in C++. That alone would have saved tons of work.
-
Eliminating most warnings was among the first things I did after officially taking care of Zap'M. They maybe were not the most urgent thing but very likely more than one bug was eliminated by fixing what the compiler sneered at. So you do the right thing by getting that dealt with early. However, I just couldn't resist adding another type of grenade meanwhile. Perhaps try modifying something else before all the effort drains your stamina.
Maybe, just maybe Abura Tan will become for you what Zap'M has become for me. A major project.
He also just had to write his own string and list classes.
Sounds familiar. Zap'M has its own vector class but the author noted in the comments he is aware of SDL container supplying this functionality. On the other hand his implementation is quite good. In the end I decided not to bother with replacing it.
-
Maybe, just maybe Abura Tan will become for you what Zap'M has become for me. A major project.
It's too messy. I've cleaned one project (Kaduria..) and it's about all I can handle. I just want to fix those warnings and then release the source for those who might be interested. It has 47000 lines of code, but only 27000 lines of actual code. So it's already quite large project.
One of the warnings is kind of strange. This operator:
std::iostream &operator << ( std::iostream &ios, Event &e ) {
e.save(ios);
return ios;
}
GCC warns that there is no previous declaration. Do operators need them?
-
I guess GCC takes seriously those missing declarations. Anyway, I have now fixed all warnings (except that operator) and also double check with CppCheck which also seems to have a problem, this time with enums that are used as consts. In some cases it tells that the enum is a variable... which can't be right.
I'd still like to change the font (it's from Teemu) and maybe at least try to fix the gameview bug.
-
Going good I see. The operator puzzles me. Sorry, no idea how to fix it.
A curious thing is the mechanic that lets you see monsters outside of your FOV is gameplay decision:
https://groups.google.com/d/msg/rec.games.roguelike.development/SmhunCZd9dM/pTTLMeONwycJ
-
Going good I see. The operator puzzles me. Sorry, no idea how to fix it.
It's only a warning so there is no need to fix it. But a funny thing is that I need to fix something I wrote in 2009 when I did the SDL port. It's the way areas of screen are updated. At that time I just updated everything but doing that can make the game slow. It's better record the biggest area and update it once when waiting a key press (which is probably the easiest way to check it, since everything is turn based). There is also a delay routine (for some kind of animations), but you can just add the same check in there.