Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[jaked122]

One of the frequent jabs I've seen people take at Java for game development is the garbage collector.  I have almost no experience with Java and none at all with games written in it, but people blame the garbage collector for periodic and noticeable hiccups in framerates.  Is there any sort of support for making garbage collection more deterministic or otherwise mitigating the odds that it will kick in and hang the game for "long" periods of time?

There is!  Granted, I only know this because a client at my previous job used manual garbage collection without understanding why or how, and made performance so ridiculously terrible that they expected us to change everything to fit what they could manage to do.

For the tank problem, call the tank position (x,y), the turret angle a, and the length of the turret from the pivot point as d.

The basic way to use this information is with cos and sin. As angle a goes from 0 to 360, (cos(a), sin(a)) traces out a unit circle (assuming you're using degrees and not radians. if things go weird here, it's probably because your maths library is using radians, and you have to convert the degrees when needed).

The key here is that cos and sin are useful for angles that you won't find in a right triangle, so their results can be negative.  It's okay to always add, because for half of the angles, you'll be adding a negative number.

This is it. This also used to get me until I learned how unit circles worked. Cos and Sin functions are used so widely because they almost always fit the bill for their typical usage.

[miauw62]

I like C#.  That is all. :v

I do too.

C# is my waifu

[doomchild]

So one of my classes (Principles of Languages) is done in a version of Scheme (specifically Racket, more specifically the legacy Racket language "Pretty Big"). While (being forced into) doing everything recursively is an interesting way of thinking, the lack of the program data divide is being pretty cool, and experiencing the great satisfaction being gained when a 3 line program solves your whole program is pretty awesome; it's horriblefying. I mean I don't particularly enjoy the idea of having to take multiple hours to come up with 4-line simple programs that I could crank out non-recursive versions (that probably work faster due to the C++ compiler) for in like 5 minutes. It's not helped by the fact that normal Racket has several very helpful functions that our legacy version doesn't support either.

And ye gods the parenthesis. I can't imaging how normal coders in similar languages survive; it's already gotten bad enough that I've pretty much said "Screw the 'recommended' official coding style, C's 1TBS style here I come!", since at least it wrassles the parenthesis beast enough to make stuff somewhat intelligible, albeit only a little.
*i2amroy goes and cries into his drink

(It is kinda funny that my professor for the class is one of those hardcore LISP guys who never really gave up on the idea that LISP is "the future of programming". I mean don't get me wrong, LISP-related languages have their uses in places like pioneering new research algorithms and other specific types of work that benefit from it's advantages [though even in some of those fields they're starting to be beat out by things like Python for similar benefits or C++ for speed requirements], but they aren't exactly the language the vast majority of people reach for when they think "I want to code X to do Y", even when said people have been exposed to the benefits of LISP-y languages. Is it a nice tool that you should definitely learn? Yeah, even if only for the practice in a very different way of thinking. But as for "the future of programming", it's almost certainly never going to be the generic language that people grab first when they just need to code a generic something up.)

I freaking love Lisp.  I hated it in college, because it didn't click, but the longer I go on developing, the more I wish I could use it professionally.  As far as the parentheses go, using a good editor can help a lot of that stop being so painful.  Emacs did it for me, I've seen other people successfully use vim, and I'm pretty sure there's a good paren-tracking plugin for Sublime, too.

The length of time it takes to more or less craft a program in any Lisp isn't terribly surprising, when you think about it.  If you tried to write a program of equivalent expressivity in something like C++ (which I hate) or C# (which I love), you'd either go insane before you managed it, or it would take you significantly longer to find cruel ways to subvert the various bits of boilerplate the languages impose on you.  I've found lately that if I can reduce a problem down to things that can be solved with map, filter, and other standard functional mainstays, my code winds up being shorter and so much less error-prone.  That's a lot of what makes me think that Lisp had it right all along.

[Orange Wizard]

I like Lisp on a theoretical level, but for actual development I'd rather throw bits of boilerplate together than muck around with billions of operators and brackets.

[doomchild]

I don't think it's the right language for every level of development.  But I think it would be pretty well-suited for a lot of the stuff I do, which is largely data curation, routing, and filtering.

[Orange Wizard]

_{pythonmasterrace}

[miauw62]

byond best gamedev language 1998

[doomchild]

I refuse to look inside that thing.  I would love a better-performing, less awful version of SS13, but apparently it's just not in the cards.

[Cthulufaic]

Holy shit.  Just got an Apple 2 emulator and installed GS/OS and found a manual for learning Apple BASIC and wow, THIS IS AMAZING.  MY GOD, 200 print "butts" 210 goto 200 WILL PRINT INFINITE BUTTS.

[Reelya]

10 PRINT "INFINITE BUTTS"

Done in one statement.

[jaked122]

I freaking love Lisp.  I hated it in college, because it didn't click, but the longer I go on developing, the more I wish I could use it professionally.  As far as the parentheses go, using a good editor can help a lot of that stop being so painful.  Emacs did it for me, I've seen other people successfully use vim, and I'm pretty sure there's a good paren-tracking plugin for Sublime, too.

The length of time it takes to more or less craft a program in any Lisp isn't terribly surprising, when you think about it.  If you tried to write a program of equivalent expressivity in something like C++ (which I hate) or C# (which I love), you'd either go insane before you managed it, or it would take you significantly longer to find cruel ways to subvert the various bits of boilerplate the languages impose on you.  I've found lately that if I can reduce a problem down to things that can be solved with map, filter, and other standard functional mainstays, my code winds up being shorter and so much less error-prone.  That's a lot of what makes me think that Lisp had it right all along.

As much as I hate to admit it, the boilerplate that most languages impose upon coders is generally meant to allow us to catch our mistakes before we run it. We can't do static analysis in lisp, we have to crawl through the branches of the code seeking the error. In C++, you can do magic with templates and make the compiler sweat until it tests those things for you. With C#, the code contracts can do the same, but without invoking the dark voodoo that are Turing complete templates.


Java can do that magic too, but that doesn't change my undying hatred of it. It lies on an axis forgotten between Lisp and C++, far off to one side, in the middle, but not in a helpful way.

[Orange Wizard]

As much as I hate to admit it, the boilerplate that most languages impose upon coders is generally meant to allow us to catch our mistakes before we run it.

It's also waaaaaay easier to debug when you can narrow down exactly what's causing problems

[i2amroy]

I don't think it's the right language for every level of development.  But I think it would be pretty well-suited for a lot of the stuff I do, which is largely data curation, routing, and filtering.

Sure, if it's good for what you commonly do than more power to you. Languages are tools and all that jazz, and you shouldn't be trying to nail screws in with a hammer. But for "expressivity" (Note:, there are a lot of definitions about what exactly it means for a language to "expressive", so pardon me if I'm using a different one here), I think I'm gonna have to say that in the vast majority of cases the human mind when thinking of a step by step process thinks in a way that is much more similar to a language like C++ with it's step and state focused paradigm than that of recursive functional languages. The proof of this can be observed simply by opening up a nearby cookbook, or by googling "instructions to do X" on google where X is anything that you want. I can almost assure you that the instructions you find there will be much more likely to be based around sequential steps with iteration than recursive calls.

Code: [Select]

mix butter
mix sugar
for(i = 0; i <3; i++)
    crack egg[i]
    put egg in bowl
    beat egg into mixture
add sugar
add flour
mix
So while LISP's power let's it be extremely expressive in the small number of cases that I have to think in a way that fits it's paradigm, in the other 90% of cases a language like C++ is actually going to be closer to my thinking than LISP is. (If on the other hand you're talking about "expressivity"as a language's ability to say just what it needs to then yeah, it takes a lot more work to get C++ there than it does in LISP. )

For brackets I think my big problem is simply that because everything uses a relatively same syntax it makes things a lot harder to parse visually, and as such will never be quite as easy as if the syntax was different for different things. It's like if every single building in a town, houses, school, hospital, fire department, police station, was built out of the exact same color yellow brick with fairly similar layouts. Sure I could get a GPS and that would help me find what I wanted, but it would still never be as easy as if every house was built of blue brick, every school of green, every hospital of white, and so forth (though as noted that would lose me the ability to build, say, a red house as the expense of being able to more easily find a hospital when I needed one).

Java can do that magic too, but that doesn't change my undying hatred of it. It lies on an axis forgotten between Lisp and C++, far off to one side, in the middle, but not in a helpful way.

Java to me has always seemed like a language that took the extreme utility that composes C/C++ and added just enough Python to it to lose all of the benefits that C/C++ provide, but not enough Python to actually gain the benefits of the easier syntax/etc. that Python provides. (The "run on anything" is kinda a nice feature, though).

[doomchild]

I don't think it's the right language for every level of development.  But I think it would be pretty well-suited for a lot of the stuff I do, which is largely data curation, routing, and filtering.

Sure, if it's good for what you commonly do than more power to you. Languages are tools and all that jazz, and you shouldn't be trying to nail screws in with a hammer. But for "expressivity" (Note:, there are a lot of definitions about what exactly it means for a language to "expressive", so pardon me if I'm using a different one here), I think I'm gonna have to say that in the vast majority of cases the human mind when thinking of a step by step process thinks in a way that is much more similar to a language like C++ with it's step and state focused paradigm than that of recursive functional languages. The proof of this can be observed simply by opening up a nearby cookbook, or by googling "instructions to do X" on google where X is anything that you want. I can almost assure you that the instructions you find there will be much more likely to be based around sequential steps with iteration than recursive calls.

Code: [Select]

mix butter
mix sugar
for(i = 0; i <3; i++)
    crack egg[i]
    put egg in bowl
    beat egg into mixture
add sugar
add flour
mix
So while LISP's power let's it be extremely expressive in the small number of cases that I have to think in a way that fits it's paradigm, in the other 90% of cases a language like C++ is actually going to be closer to my thinking than LISP is. (If on the other hand you're talking about "expressivity"as a language's ability to say just what it needs to then yeah, it takes a lot more work to get C++ there than it does in LISP. )

I think that's the underlying feeling that a lot of people have, and it's perfectly understandable and valid.  But I think there's a reason why Lisp still beats other languages for expressivity, and that is the fact that it allows you to not actually care how the machine is operating underneath.  There are plenty of scenarios where you need to know exactly how things are lined up in memory, exactly how much memory you're using, or if you're being optimal in cache usage, but I posit that those situations are actually far fewer than most developers think.  Unless you're writing airplane navigation systems, medical monitoring devices, large-format printers with giant lamps on either side that can start fires in less than three seconds (guess which one I used to do), I don't think it actually matters all that much if your program runs a particular function in 200 milliseconds or 400 milliseconds.

The introduction to SICP has a line that says "Thus, programs must be written for people to read, and only incidentally for machines to execute," and I think that holds true today.  So if I can express a program's actual point without a lot of jumping through bare metal hoops, that program is, all other things being equal, going to be easier for another person to pick up and look at.

I don't think Lisp is the end-all, be-all of languages.  But I feel like the fact that modern languages keep pulling features from it implies that it's, at the very least, an incredibly useful object lesson into what a program should look like.

[Willfor]

The Robinson roguelike is being programmed in Clojure. If that dev can do these sorts of things, I think writing a game in Lisp is perfectly within the realms of possibility.

I mean, I wouldn't want to do it, but it's definitely doable.