Angband.oook.cz
Angband.oook.cz
AboutVariantsLadderForumCompetitionComicScreenshotsFunniesLinks

Go Back   Angband Forums > Angband > Development

Reply
 
Thread Tools Display Modes
Old April 20, 2015, 22:08   #21
Derakon
Prophet
 
Derakon's Avatar
 
Join Date: Dec 2009
Posts: 8,378
Derakon is on a distinguished road
GOTO isn't innately bad. In particular, it's basically the only clean way I'm aware of to do "exception handling" in pure C. That doesn't mean that C# doesn't have a better construct to do whatever Angband's GOTOs are doing, of course.
Derakon is offline   Reply With Quote
Old October 17, 2017, 13:06   #22
Dean Anderson
Adept
 
Join Date: Nov 2009
Posts: 111
Dean Anderson is on a distinguished road
So, it's two (and a bit) years later. What's the current situation?

Well, as you might have guessed from the fact that I stopped posting on the thread, I gave up. I'd been approaching the project in the wrong way and it wasn't really progressing.

However, a couple of months ago - in the Summer - I decided to revisit Cthangband again. I started by making some changes to the program - I've got a Cthangband 5.1.0 sitting on my hard drive now with various fixes and enhancements. But then I decided to have another go at porting it to C#.

I approached it from a different angle this time. This time my method was:
  1. Remove all the redundant code and code for other systems (I'd already done this in Cthangband 5.1.0).
  2. Wrap all the code so that it is all in one big stonking class spanning 51 files (using C#'s ability to declare "partial" classes that span files).
  3. Comment out all the C code.
  4. Go through the code a function at a time replacing each commented out C function with a C# equivalent.
  5. Only after getting everything converted and working would I then start refactoring things to make it object oriented.

This might look similar to the prior attempt, but the significant difference is in #2. Previously I'd made each .c file into a static class while doing the conversion (so object1.c would be a class called Object1 and cmd4.c would be a class called Cmd4, and so forth). This meant that everything was static and I needed to reference between the classes constantly.

This time, by making it all one single class, I could just create an instance of the class and all the functions and variables could see each other just like in the C version of the code.

Similarly, in #4, I haven't been going through it file by file. Instead I've been going though it commenting out calls to functions that haven't yet been re-written and then slowly putting them back in in the right order to always have a runnable program.

So I started out with a program that would compile and run. Then one that would show the splash screen. Then one that would show the splash screen and let you start a new game. Then one that would also take you through character generation. Then one that would create a town. Then one that would have monsters. Then one that had objects. Then one in which the monsters also moved. And so forth.

And that made all the difference in the world. I now have a fully working and fully featured C# version of Cthangband 5.1.0 as well as a C version. There's no remaining un-ported code left.

So I've finished #4 and I'm currently most of the way through step #5 - refactoring everything to make it object oriented. Of the 51 original source files that I converted, I've moved all the code out of 38 of them and partially out of the remaining 13; moving the code into a proper object model and doing further re-writes as I go.

I haven't gone with Unity or anything as a front end for the moment. It's effectively just a Console app (I say "effectively", because technically it doesn't actually use the console window - they're horribly slow to update, so it uses a custom window that looks like a console but is actually just user-drawn graphics).
Dean Anderson is offline   Reply With Quote
Old October 17, 2017, 18:08   #23
Pete Mack
Prophet
 
Join Date: Apr 2007
Location: Seattle, WA
Posts: 4,777
Donated: $40
Pete Mack is on a distinguished road
Quote:
Originally Posted by Derakon View Post
GOTO isn't innately bad. In particular, it's basically the only clean way I'm aware of to do "exception handling" in pure C. That doesn't mean that C# doesn't have a better construct to do whatever Angband's GOTOs are doing, of course.
There is another way, but it's not a lot better than GOTO:
Code:
do {
     ...
     return;
} while (false);
Handle exception here
Pete Mack is offline   Reply With Quote
Old October 17, 2017, 21:56   #24
kandrc
Swordsman
 
Join Date: Dec 2007
Posts: 281
kandrc is on a distinguished road
Quote:
Originally Posted by Pete Mack View Post
There is another way, but it's not a lot better than GOTO:
Code:
do {
     ...
     return;
} while (false);
Handle exception here
By "not a lot better", I think you mean "a lot worse". This solution doesn't handle the fall-through, reverse-ordered de-init that is (sometimes, often) necessary. Goto gets you that for free. I (and most old systems programmers like myself) would argue that this is not only an "acceptable" or "not bad" use of goto, but that it's actually good and elegant. It's certainly more elegant than exception handling in C++ or other "modern" languages unwinding my stack (yes, I know that many will argue with this claim, but not old systems programmers).

ITT: "Fixing" things that aren't broken.
kandrc is offline   Reply With Quote
Old October 17, 2017, 22:22   #25
Pete Mack
Prophet
 
Join Date: Apr 2007
Location: Seattle, WA
Posts: 4,777
Donated: $40
Pete Mack is on a distinguished road
Oh I agree that GOTO is generally preferred to "do...while false."
That said, long jump GOTO really is horrible; I have to disagree on this one.
Pete Mack is offline   Reply With Quote
Old October 17, 2017, 23:00   #26
Dean Anderson
Adept
 
Join Date: Nov 2009
Posts: 111
Dean Anderson is on a distinguished road
Of course, C# has the classic:

Code:
try
{
    code here
}
catch (Exception e)
{
    exception code for handling exceptions here
}
finally
{
    clean-up code here
}
In the above, the catch can handle some types of exception or all exceptions (and you can have more than one catch block for different types of exception), and any that are not caught will be propagated back to the code that called the function - which is what will also happen if you don't put a try/catch block in at all and an exception happens.

The code in the finally block is guaranteed to execute before the function returns regardless of whether or not there is an exception and regardless of whether or not it is handled.

Having said that, I've not got any exception handling code in there yet. At the moment, I want exceptions to be unhandled and to be caught by the debugger so that I can see what's going wrong.
Dean Anderson is offline   Reply With Quote
Old October 18, 2017, 00:22   #27
Gwarl
Knight
 
Join Date: Jan 2017
Posts: 550
Gwarl is on a distinguished road
Does this mean real consoles are no longer supported?
Gwarl is offline   Reply With Quote
Old October 18, 2017, 02:43   #28
Pete Mack
Prophet
 
Join Date: Apr 2007
Location: Seattle, WA
Posts: 4,777
Donated: $40
Pete Mack is on a distinguished road
@Dean:
Yes, I agree C# is a nice language, tho I think it's biggest contributions are ad hoc functional programming (LINQ) and a cleaner implementation of attributes than Java has. The task library is very well done, too. MSR deserves real kudos for these contributions.
Pete Mack is offline   Reply With Quote
Old October 18, 2017, 16:18   #29
Dean Anderson
Adept
 
Join Date: Nov 2009
Posts: 111
Dean Anderson is on a distinguished road
Quote:
Originally Posted by Gwarl View Post
Does this mean real consoles are no longer supported?
Hmm... I'm not quite sure what you mean here.

The current architecture is that it's a Windows desktop application. The main window uses WPF to display its contents.

That's not ideal (I'm not a big fan of WPF) but - at least initially - I wanted something that would work "out of the box" rather than something that relied on third party libraries and complex install sequences.

That left me with three options:

1) Console
2) WinForms
3) WPF

I experimented with making it a pure console application, but the C# console implementation isn't all that quick, and things like wiping the screen and displaying a page full of text are noticeably slow. It's also restricted in colour usage to a pre-defined set of sixteen colours, and that set doesn't match the default Angband colours, so you have to put up with some merging and

So that left me options 2 and 3. Given that WPF takes advantage of hardware acceleration, and WinForms doesn't, I went for that. It has the advantage that you can easily change the font and window size on the fly without needing a re-start, and all the text takes advantage of ClearType font rendering so it looks nice and crisp regardless of resolution.

However, I do say that this is the current front end. I've deliberately abstracted the front end so I can switch to a different technology or library very easily.
Dean Anderson is offline   Reply With Quote
Old October 18, 2017, 17:30   #30
Pete Mack
Prophet
 
Join Date: Apr 2007
Location: Seattle, WA
Posts: 4,777
Donated: $40
Pete Mack is on a distinguished road
Quote:
Originally Posted by Dean Anderson View Post

So that left me options 2 and 3. Given that WPF takes advantage of hardware acceleration, and WinForms doesn't, I went for that. It has the advantage that you can easily change the font and window size on the fly without needing a re-start, and all the text takes advantage of ClearType font rendering so it looks nice and crisp regardless of resolution.

However, I do say that this is the current front end. I've deliberately abstracted the front end so I can switch to a different technology or library very easily.
This sounds great. Too bad it's so difficult to do the same thing with Angband, because of the C++mangling in WPF. The benefit of Win32 is that at least it's compatible with gcc/mingw. Installing MSVS is a big, big deal: rather too much for the casual angband hacker. Your effort is pretty impressive in any case. Hand porting from onr language to another is non-trivial.
Pete Mack is offline   Reply With Quote
Reply


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
Reviving Iso-Angband, an isometric view addon for Angband Hajo Development 111 August 3, 2014 19:44


All times are GMT +1. The time now is 17:37.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2018, vBulletin Solutions Inc.