• Advertisement

Erik S. Andersson

  • Content count

  • Joined

  • Last visited

Community Reputation

149 Neutral

About Erik S. Andersson

  • Rank
  1. Quote:Original post by Anonymous Poster Nobody NEEDS ADO.NET or .NET 2.0 Data Binding. For that matter nobody really NEEDS C# itself either. You can do things the "hard way" or the "old way" if you want to call it that. Specifically the requirement for Data Binding revolves around creating the game editor which allows you to basically alter every aspect of the game. It is a lot easier to write and update this interface using data binding. Of course you don't need anything in that sense, but the question was more if the requirement came from someone else or if it was a personal preference. Although I have no personal experience with ADO.NET/Data Binding I'd still say that it is highly unlikely that anything else is to be considered hard and antiquated. As far as I can tell you want to use your previous experience in SQL on the game which might be a good idea, but it might also make things more complicated than necessary. I'm genuinely curious, what about data bindings makes everything else look old and hard?
  2. First of all I'm not sure that a data-centric game necessarily requires SQL-style functionality. One of the few cases where transactions are important enough would be MMO-style games, but in those cases I'd worry a little more about the database itself and a little less about the .NET interface. If there is some specific database functionality you are looking for then this will obviously also help eliminating options. What exactly is it that you need, and why do you need ADO.NET and .NET 2.0 Data Binding? It's quite possible to use a database during development without actually having to integrate it or some lightweight alternative in the game itself. This could be both easier and faster in the long run.
  3. Where do you keep global variables?

    Maybe I should clarify a litte, I don't mean referential transparency(RT) as in "functional programming", even though I like as much RT as possible. The kind of RT I'd at the very least would like to see in C++ is that f(x, y) doesn't affect anything else than x and y. This isn't exactly RT, but it's a lot better than the situation with global variables where it's impossible to tell if a function affects them without actually inspecting it. Inserting logging into f(x, y) doesn't matter, it could be removed without changing the functionality of the program. I'm not sure what this kind of "weak" RT is called, but I suppose it might have a name too.
  4. Where do you keep global variables?

    I don't see why you would want to use a global anywhere in general, and this includes singletons and other ways to hide the global nature of the data. I'd say that it's best to keep as much of your program referentially transparent as possible. Yes, there will be input and output in some functions, but don't let the I/O "infect" the rest of the program. This also explains why many (including myself) considers logging to be one of the few valid global areas. The logging does not (or at least should not) affect the referential transparency of any function.
  5. C++ Good Naming Conventions?

    Quote:Original post by Anon Mike Quote:Original post by Erik S. Andersson I used to like some prefixes, but I don't find it necessary nowadays. I think this-> is a lot better than m_, m_ can lie and this-> can't... "this->" can be forgotten and the code will still compile, and might even work, and then again it might not depending on whatever else is in scope. If you forget the "m_" you know about it right away. "this->" also looks a lot sillier than "m_". IMHO at least. Sure, it can be forgotten, but I don't think it's necessary to use it all the time, only when it seems necessary to emphasize that it is a member variable. In those cases it's also unlikely that it will be forgotten. I don't think m_ adds any real value as a general rule. If you mean that the it solves the problem of having m_size and size as variables in the same function (where forgetting the this would lead to incorrect code) I think it's time to rethink the variable naming policy that governs the "primary" name.
  6. C++ Good Naming Conventions?

    I used to like some prefixes, but I don't find it necessary nowadays. I think this-> is a lot better than m_, m_ can lie and this-> can't... I also used to like camel case for aesthetic reasons, but DescriptiveAndLongVariableNamesInCamelCase are harder to read than descriptive_and_long_variable_names_with_underscores. I wonder how many of these topics there are at gamedev every month.
  7. Lisp Pimpin'

    Quote:Original post by Nathan Baum 1. Functions can be redefined at runtime. This means they must use a consistent calling convention, which means that if you pass scalar values (i.e. integers or floats) to a function, it must be wrapped in a pointer. You can remove this inefficiency by declaring the function inline, but then you also lose the utility of redefining it. This was something I was thinking about when I wrote a simple Scheme. Don't you think it possible to save dependency links between functions and recompile functions that depend on a function that's been changed? In many cases the changes you make don't affect the "signature" of the function anyway, and even if they do the change hopefully won't propagate for several levels (functions that depend on functions that depended on the changed function etc). It could get pretty messy of course, so I never tried it myself.
  8. Lisp Pimpin'

    Quote:Original post by Anonymous Poster During the course of this flame thread (and yes, with the title Nathan gave it, it *is* a flame thread), several very interesting and powerful aspects of LISP have been discussed, which make a good case that LISP is an excellent paradigm for creating programs. The call stack walking and changing debugging, the incremental execution changing, and the ability to change the language itself are very impressive, and for those reasons alone it sounds like LISP is worth looking into. But Nathan has continually stated that the final executables in LISP are just as optimal as programs in other languages (or can be made so without too much trouble). Nathan must either show this to be the case, or admit that LISP does have things inside the language itself that can limit the speed of the final executable itself. After all, he is the one trying to sell it to us. I don't think the word "pimpin'" in itself means that it's a flame thread. As you note there are several topics of general programming interest that will come up if you try to "sell" Lisp as a great programming language. Talking about the "speed" of a language is rarely that terribly interesting. Demanding someone to show that a specific Lisp implementation can come within 1.5% of a specific C++ compiler for an arbitrary benchmark algorithm isn't very reasonable. Even if no Lisp can come within some margin of some C++ compiler it doesn't mean that the language itself restricts the optimizations that would make it possible. Instead a lot of discussion is about the theoretical optimization limitations that come from the dynamic typing, eval, and similar things. I don't see why you should be so annoyed by that.
  9. Lisp Pimpin'

    Quote:Original post by Anonymous Poster Nathan: Please keep optimizing the LISP version until it executes to within 1.5% of the fastest C++ version of the code. You have bragged about the benefits of LISP so much, and implied that LISP makes doing things like this *so easy*, and in hardly any time, that I think it is only fair that you do so, and tell us how long it took you, as well as the completed code. Thanks. You know what I like most about this thread? That it can go on for so long and still contain some interesting discussions between people who disagree on many levels. So please take your stupid trolling to the DirectX vs OpenGL threads instead. Thanks.
  10. Lisp Pimpin'

    Considering that memory usage of the Lisp version I'd guess that you have less memory than Flatlander and Nathan. In that case the scaling wouldn't be anywhere near linear. If I could get the program to work in Corman Lisp I'd try to see why it behaves that way, but Corman didn't like the optimizations. If the mystery remains unresolved I guess I could try to install CMUCL and check though. I've used Gentoo Linux for a couple of years now, but while it's pretty easy to manage in general I've had a lot of trouble with Lisp which is why I don't have CMUCL installed now.
  11. Lisp Pimpin'

    Quote:Original post by jdh30 I see. What do you see as the main advantages of Lisp other other non-mainstream languages (e.g. Haskell, Ruby, OCaml, SML, Python) in the context of game development? Since I haven't actually made any game in Lisp I'm not sure if I'm the right person to answer that question. Of the languages you mention I've only used Python to make a simple Tetris with Pygame, and I haven't even used Ocaml or Ruby. It's possible that Lisp is well suited to the type of strategy games that Paradox are making if their file format is any indication. Even in the cases where I use C++ for games I alway start with a simple Lisp system for binding functions to a quake-style console. With the new templates and anonymous functions in C# I noticed that it had gotten pretty simple (to bind functions) in that language as well.
  12. Lisp Pimpin'

    Probably Corman Lisp on Windows and CMUCL/SBCL on Unix derivatives. I'm currently testing the SDL bindings for Corman Lisp to see how Lisp could work in games programming. In general I have a feeling that it's easier to handle I/O style operations in another language and handle more game logic related tasks in Lisp. If you check the Paradox games (Europa Universalis/Crusader Kings...) you can see that the event files and save games look like this: #Hugh O'Neills Irish Rebellion# # Edited by Johnny Canuck # event = { id = 3022 trigger = { NOT = { religion = catholic religion = counterreform OR = { owned = { province = 231 data = -1 } #Connaught - New owned = { province = 232 data = -1 } #Ulster - New owned = { province = 233 data = -1 } #Meath - New owned = { province = 235 data = -1 } #Munster - New owned = { province = 234 data = -1 } #Leinster - New } } } random = no country = ENG name = "EVENTNAME3022" desc = "EVENTHIST3022" style = 3 date = { day = 1 month = january year = 1592 } offset = 60 deathdate = { day = 30 month = december year = 1599 } action_a ={ #We are not amused!# name = "ACTIONNAME3022A" command = { type = revolt which = 232 } command = { type = revolt which = 232 } command = { type = revolt which = 231 } command = { type = revolt which = 231 } command = { type = revolt which = 235 } command = { type = relation which = SPA value = -150 } command = { type = stability value = 1 } } } They could probably have saved a lot of time by using Lisp for game logic.
  13. Lisp Pimpin'

    The strange Lisp main comes from the fact that it should handle different Lisps, and it also handles the case where no input can be found. I'm not sure exactly what you are expecting to demonstrate by that example, using the same problem and contest for C we get: int Ack(int M, int N) { return(M ? (Ack(M-1,N ? Ack(M,(N-1)) : 1)) : N+1); } which doesn't look very intuitive to me. In fact if we use these short examples we could counter a Java user complaining about parenthesis by comparing code for printing "hello" in the console: (print "hello") vs public class C {public static void main(String[] s) {System.out.print("hello");}} which has an extra pair of parenthesis as well as two other types of parenthesis (and points and semicolons etc).
  14. Lisp Pimpin'

    Quote:Original post by Nathan Baum When people say "intuitive", what they mean is "similar to other things I've used". There is, obviously, no other way for things to be intuitive: nobody pops out of the womb with an innate grasp of C++, so far as I know. Most people are familiar with mathematical notation. Certainly, most programmers are. And Lisp does have deeply non-standard mathematical notation. It also has notation which is almost completely unlike any notation of other programming languages. You might be right about what people generally mean when the say "intuitive", but I still think it's fair to point out that it is nonsense. Saying that Lisp syntax isn't intuitive because it isn't C syntax is kind of pointless. As you mention, the thing that is most uncommon is the syntax of arithmetic, but if this is important for your program you can of course create macros for that as well. Quote: I think most programmers are "zealots" in the sense that most programmers would only consider using one particular language for one particular problem. Few programmers would sit down and wonder whether to write their raytracer in Lisp, C, C++, Java, Pascal, Sather or ML. I think that fanatic is a strong word for someone who prefers to use a single language for any problem since there are benefits to that approach as well. While learning a language might not be incredibly hard I think that the problem of learning new libraries (particularly since the documentation often is poor) is enough to justify using sub-optimal languages for many problems. I've been thinking of the possibility of using .NET as well, it could be a way of attaching Lisp to something that is at least reasonably "fancy". I noticed that there for example was a wrapper called rdnzl, but the usual FFI-way was not what I was thinking of. Maybe something like a Lisp# with a more natural integration.
  15. Lisp Pimpin'

    Quote:Original post by Daniel Miller I absolutely love the idea behind Lisp, but it it's syntax is anything but intuitive (it's aweful). You can say, "Once you learn it, it makes sense!", but everything else unintuitive is like that. Also, it has the problem of its proponents generally being zealots, and much of its sample code being very poorly written (3-4 letter names). That being said, the idea of the language is awesome, and when I sat down to "fix" the sytax, I came out with, believe it or not, the same thing. [grin] I haven't come across a problem where Lisp was needed (or wanted), but it's still neat. I'm not sure if you could call any kind of syntax "intuitive". The interesting thing with Lisp's syntax is that it is consistent, is that somehow less intuitive than C-style syntax with a mix of pre/post/infix and lots of special cases? Saying that Lisp proponents are "zealots" is also nonsense. While I'm sure some Lisp users really like the language I'd say that a very small percentage of the proponents are fanatics. I'm sometimes a Lisp proponent but I'm not even fanatical enough to use it for most of my projects because of a lack of quality libraries for various areas.
  • Advertisement