Compiling with VS2015

Collapse
X
 
  • Time
  • Show
Clear All
new posts

  • Nick
    replied
    Originally posted by Derakon
    It's sad that we have so much duplication of effort in Angband and its variants.
    I used to think that, but I see it as more like an ecosystem now. As a maintainer it's great to have so many variants around to steal ideas from. So the process of a maintainer developing their ideas, and then others copying it doesn't just give a chance for all the variants to improve, but in the end it probably ends up with better implementations.

    That's especially the case for "creative" ideas, but I think it also is for coding techniques (sorry, I English bad today). There's also the thing that Angband and variants have such a broad design space that you can do things like wilderness or randarts in many, many different ways.

    Leave a comment:


  • Pete Mack
    replied
    The improved data model for parsing makes all the difference.

    If you look at the code, there's a tiny core in initialization and effect_do, and a lot of busywork (cut and paste of effects from original code, and cut and paste of projection side effects.) Using unanband would have cut busywork only slightly--you still have to verify the list of effects for V.

    Leave a comment:


  • AnonymousHero
    replied
    [I]
    Originally posted by Derakon
    It's sad that we have so much duplication of effort in Angband and its variants.
    Such is the life of a maintainer.

    EDIT: I was going to do a whole "janitor"/"maintainer" analogy here, but... meh.
    Last edited by AnonymousHero; April 14, 2017, 18:29.

    Leave a comment:


  • Derakon
    replied
    Originally posted by Pete Mack
    The first one to separate spell effects was Andrew Doull (Unangband.)
    It's sad that we have so much duplication of effort in Angband and its variants.

    Leave a comment:


  • Pete Mack
    replied
    The first one to separate spell effects was Andrew Doull (Unangband.)

    Leave a comment:


  • t4nk
    replied
    Originally posted by AnonymousHero
    Just to be a little constructive: I actually have a little experience in converting an existing code base from C to C++ and it does actually work out pretty smoothly[1]
    Interesting! I skimmed some files; the codebase is still very C-like (at least the parts that I saw). Well, that's not necessarily a bad thing

    I actually thought seriously about using D "back in the day", but honestly: At the time it was extremely niche, but even today it's (unfortunately) still quite a niche language.
    So what, it's just Angband
    Overall I do think that D might be a better language if you want to do metaprogramming
    Nah, what I want is automated garbage collection (apparently that's coming to C++... at some point), Unicode in standard library, faster compile times...
    Last edited by t4nk; April 14, 2017, 17:01.

    Leave a comment:


  • AnonymousHero
    replied
    Originally posted by Derakon
    ...
    +1, agree with, basically, everything. Btw, are you married to anyone right now?

    (EDIT: That was a joke, just btw.)

    Leave a comment:


  • Derakon
    replied
    Originally posted by AnonymousHero
    EDIT: Actually, I'd like to add: Even if nothing further comes from it, I think Pyrel was definitely a worthwhile experiment.
    I'm inclined to agree, and I think that it made major inroads on data-driven gameplay at a time when all spell effects, spells in spellbooks, etc. were still hardcoded in Vanilla. The container-driven "dungeon database" was also a neat concept -- you could basically query for specific categories of things in the dungeon by doing a series of set intersection operations, which made it easy to do things like "give me all of the evil monsters" or "give me all of the flammable items in this square".

    In principle I believe its approach to equipment modifiers was also an interesting experiment; I'm just sad that it never reached the point where it could really be playtested.

    Re: strong typing, with a project of this size, I agree, having typechecking is a must. Python does allow you to annotate variables with types and has for ages; back in 2008 I had a game project where I made a 2D coordinate tuple type that was at least an order of magnitude faster than the untyped version. But having the capability is not the same thing as mandating its use, of course.

    Leave a comment:


  • AnonymousHero
    replied
    @t4nk: I actually thought seriously about using D "back in the day", but honestly: At the time it was extremely niche, but even today it's (unfortunately) still quite a niche language.

    Overall I do think that D might be a better language if you want to do metaprogramming (an obvious win in Angband-like code, I feel), but C++ is catching up via "static if" and constexpr...

    Leave a comment:


  • AnonymousHero
    replied
    Originally posted by Derakon
    And write it in Python.
    Ha. Ha. Ha. That's a noob language that nobody uses!!111one

    Just to be a little constructive: I actually have a little experience in converting an existing code base from C to C++ and it does actually work out pretty smoothly[1]. Of course, there's a lot of code and it takes quite a long time to even get the basic things converted. (The pain was doubled because I first had to get rid of the Lua code by converting to plain C. "Fortunately" the Lua code was already very C-like, so it was doable. Painful but doable.)

    One thing I feel very strongly about is that any large scale project must have static type checking. Maybe it's just me, but I believe very strongly in Type-driven Design... even if C++ is kind of an anemic and horrible language to do it in.

    [1] I find that C++ is actually a reasonably nice language these days (post-C++14 with good-constexpr), but YMMV.

    EDIT: Actually, I'd like to add: Even if nothing further comes from it, I think Pyrel was definitely a worthwhile experiment.
    Last edited by AnonymousHero; April 14, 2017, 12:04.

    Leave a comment:


  • t4nk
    replied
    Originally posted by Derakon
    C++ makes a modicum of sense here because you can do the upgrade piecemeal. If you're going to completely rewrite the game in a different, incompatible language, you might as well do a top-down redesign.
    That's why I thought of D (and not something else). It's about as compatible as C++ is ("extern (C)"...), and less nasty.
    Also, Angband is a normal procedural program and I don't see any particular reason to change that radically.

    And write it in Python.
    As if Python is such a gift... I hate Python

    Leave a comment:


  • Derakon
    replied
    Originally posted by t4nk
    Actually, you know what. How about converting it to D
    C++ makes a modicum of sense here because you can do the upgrade piecemeal. If you're going to completely rewrite the game in a different, incompatible language, you might as well do a top-down redesign. And write it in Python. Oh look, it's Pyrel again. Too bad I ran out of steam before getting it all the way finished.

    Leave a comment:


  • t4nk
    replied
    Originally posted by AnonymousHero
    I feel that this the perfect moment to chime in and say that Angband should convert to C++. C'mon, people!
    Well that's not a bad idea. It might not be a practical idea, but I do think C++ is more appropriate for software like Angband (even though it's a horrible language )
    Actually, you know what. How about converting it to D

    Leave a comment:


  • AnonymousHero
    replied
    I feel that this the perfect moment to chime in and say that Angband should convert to C++. C'mon, people!

    /trolling

    EDIT: FWIW, the quality of the MS compilers for C or C++ are appalling. (I mean they're trying to catch up... and getting a lot better, but they're still nowhere near Clang or GCC in terms of rapid compliance to new standards.)

    Leave a comment:


  • t4nk
    replied
    Originally posted by Pete Mack
    MSVC does work for C
    For some definition of "C"...

    it just never was updated fully to later standards. I don't know why.
    Explore Visual Studio product documentation for the Visual Studio IDE for Windows and Mac, Visual Studio Code and App Center, GitHub Codespaces, and subscriptions.

    Pretty self-explanatory, IMO...

    Leave a comment:

Working...
😀
😂
🥰
😘
🤢
😎
😞
😡
👍
👎