Well... I have a big list of stuff to write about, so, I'll cheat.
Ctrl+C, Ctrl+V
Game updates
- OpenFracas (http://www.openfracas.org/) from Ubuntu forums (http://ubuntuforums.org/showthread.php?t=692342)
- Oolite 1.70 development version (http://www.aegidian.org/bb/viewtopic.php?t=4060) with enhanced scripting
- OpenTTD OpenGFX project (http://wiki.openttd.org/index.php/Graphics_Replacement)
- Daimonin tileEngine v2 (http://www.ogre3d.org/phpBB2/viewtopic.php?t=38992)
- Pathman, 3D pacman (http://pathman.sf.net/)
- AsteroidWars (http://www.ogre3d.org/phpBB2/viewtopic.php?t=27326)
- Official ETCE homepage (http://etce.usef-et.org/)
- Sector91 (http://www.sector91.com/) from Wesnoth forums (http://www.wesnoth.org/forum/viewtopic.php?t=19845)
- Flightgear 1.0 vid (http://www.youtube.com/watch?v=FnKg0Gpm00o)
- Platinum Arts Sandbox Beta 2.0 (http://www.kids.platinumarts.net/) is a Sauer mod for kids, including karts (http://www.cubeengine.com/forum.php4?action=display_thread&thread_id=1657)
- Forsaken Sanctum (http://www.forsakensanctum.com/?sid=home) maybe an open source Sci-Fi MMORPG (http://ubuntuforums.org/showthread.php?t=564160)
- Freelords 0.0.2 (http://freelords.sf.net/) new Java version now isometric
Thats more Free gaming news that you can shake a fist at...
If you don't want to follow the links to find out stuff for yourself, don't worry as I'll revisit the interesting bits in the next few days.
14 comments:
Forsaken Sanctum looks to be pretty cool. I was a little sad they went with Torque as an engine, but hey, if it works, it works I guess. I bought a thick book on graphics programming a while back and it came with Torque, but I couldn't use it because my distro (FC7) didn't have the correct SDL version.
Believe me I have tried to help them to find a different engine.
I have showed the main dev about 8 of the best free (not always free as freedom) engines we have, but he just didn't find what he needs.
I am too not so happy that they went with Advanced Torque because even if they do open source their game, they couldn't as far as I understand open ALL the game and so we can't really use it to the fullest.
But if it will have a GNU/Linux client it's fine by me ...every little step counts.
And from what I can see 2008 will have more native GNU/Linux games (indie games) then ever before.
Regards
Maxim (from UF post ;)).
OpenFracas? Yiiipaaayyy! *jumps around*
I've been waiting for this game to become free for YEARS.
I'm so happy *sniff*
AsteroidWars -- in url "s/hhttp/http/".
FreeLords -- Why java? Why?! \:
Why not Java? And don't say 'cos it's slow' unless you can back that up with statistics.
The problem with Java is that it is still a problematic language, in the sense that it doesn't come preloaded with many GNU/Linux distributions and doesn't work very well on different, more esoteric, architectures. For example, I'm on Linux PPC and it's Java support sucks quite a while.
Fortunately, Java 7 will be completely Free Software and the problems that I've mentioned above will vanish, I hope.
In my opinion, Python would a better option than Java.
lol, python over java? maybe for reading code... not for appliactions ^^
Why not? There are many applications and games written in Python.
Java may have the libraries, but it wasn't designed to be a good language; it was designed to be better than C++, and that isn't hard. I dislike programming in Java because the language gets in your way with stupid things and you have to write a lot of code for small things. And, since not everything is an object, type casting can be a big, big PITA.
LISP is the best, though, no doubt about it. :-)
I whish there were decent opengl and sdl bindings in lisp
I wish there was any decent support for anything in Common Lisp. I really like LISP, but there are missing libraries for everything. GTK+ support is an absolute chaos, for example.
Wow, somebody standing up for Java!
A programming language is by definition a trade-off. Between performance and flexibility. Between RAD and maintainability. etc. Lets look at the tradeoff the geniusses of Java made.
Topic 1: Type Safety.
=====================
When a language is type safe, the type-checking can occur at compile-time, therefor, if it compiles you won't get any hard-to-catch bugs because types clash at run-time. Unfortunately, unless the compiler is really smart and too complex to understand by mere mortals (read: if you are using Haskell) you will have to supply the type information yourself. This is also true in Java. Half the stuff you write are types. But do you get type-safety in return? NO! You can still get a NullPointerException. Since eh, well, eh, oops they forgot to put null types in the type-system. (idiots). They also initially forgot to support polymorphism. (mistakingly called generics by Sun's marketing people and third-rate-programmers). First they tried to fix that by giving you a cast method. Essentially turning all type-safety off and defaulting back to run-time type checking. So you had to supply times, and then they were not used to provide any garantues or to optimize the performance (by utilizing type-erasure). Then when they found one the causes their completely framework was utter garbage, they tried to add polymorphish. Well, they were only able to implement first-order polymorphism. I guess expecting a CS degree from language designers at Sun is bit foolish. Such complex algorithm. Right.
2. Memory Management
======================
There is manual and automatic garbage collecting. Also, some languages allow you to do the memory allocation manually as well. The wizards at Sun went with automatic memory management (good choice) and automatic garbage collecting (bad choice). So, not only is all memory management garanteed to be safe, you are also garanteed to be not able to specify when you intend to loose information. Instead you need to manually make sure no object references the object you want to delete. You can't just tell them to use 'just get rid of the object'. This is so complex they decided to hack on weak references. Not that any Java programmer ever look at it. Hell, but they usually don't profile their code anyway. How would they know they are leaking memory.. Oh and to finish it off, you have no control over when Java will completely halt your program, double your memory usage temporarily, and do an expensive mark-and-sweep. Most likely with objects we're not using, and were problely swapped away to disk the last time it pulled that crap. You know that rattling sound every minute of so with your Java app? That's right. That is what is happening.
3. Virtual Machiene
===================
Platform neutrality is great. One way to do so is to run a program in an emulator. Like say VMWare or OpenBox. The JVM is very much like that. It has a virtual machiene format that mimicks real hardware. It has registers, op-codes, etc. So rather than putting some high-level generic operations in there, like say an iterator or FSM, its like assembly for a chip that doesn't exist. It run's about as fast as OpenBox or VMWare, because it's the setup is pretty much identical. So, why are some languages even slower? Because their implementors suck even more or because they made different trade-offs. Also, while we busy making brilliant choices, why not decide to _always_ assume code is hostile. Even when we run the program a 100 times a day. Just keep assuming we need to verify the types and memory access before we launch _every_ time. So instead of creating a JVM format that consists of type-safe operations, mimick hardware level operations and add extra type information that will need to be verified every single time we run a java app. Nice. Who wouldn't want to wait?
4. Concurrency
==============
Why not go with the old thread locking model? I mean, i've never heard a c++ programmer complain about that. Never. Yeah, all that fancy academic stuff about a world where you can have atomic transactions or referential transparity with (virtual) message passing. As if things with more than 4 letters can exist! We're already using that hip objec-oriented model thingie. I mean, that pretty radically academic already. We can just hack the concurrency in, right?
5. Abstractions (AKA code reuse)
================================
Why not make classes the only form of abstraction we support? So, if you want a custom sorting function, just wrap it in a class. That needs to be in a seperate file. For which you need to make up a name. Lets do the same for iterators. I mean, who wouldn't want to write 30 lines of code just to sum a list? Can you just imagine how big our framework is going to be this way? People are going to think its really enterprisy when they see 10,000 lines of code, just to do standard ADT stuff. We can have different lists, different iterators and such for every different data type. This way they can't really reuse that code, but they can't use it at the same time either unless they _also_ define an interface. Whoomp! Our framework just got another 30% bigger. Can you say Enterprise (tm)?
==========================
I could on like this for a while. But anybody who thinks Java is great language, really needs some basic schooling. I mean, if its your cup of tea, go ahead. Some people like to tie each other up and burn each other with candles for fun. But _never_ act like there would be a rational ground to using Java.
If you want performance, use C. If you want flexibility use Python or Ruby. If you want to model very abstract stuff and need a lot of hand-holding go for the language with the strongest type system: Haskell. If you need to make an application that is inherently very concurrent and/or distributed, go with Erlang. If you need to interop with Java stuff, use Scala (which also compiles to the JVM).
That was a great rant well disguised as a list of facts. The facts are that Java has become the industry standard* for Enterprise development**. It's robust, reliable, proven, and performs. You just can't contradict that with an opinion. There's just too much damned good software that destroys your argument on why Java is rubbish. Development in Java is far quicker*** than in C/C++, especially when it comes to larger projects where debugging C/C++ becomes a sodding nightmare. Debugging in Java is a relative walk in the park - information everywhere. Non-trivial C/C++ app development is the realm of total experts.
You can force garbage collection - System.gc(). Also frankly it's pretty great to have that all automatically handled by an amazing garbage collector. The number of mature C/C++ apps that just segfault or have leaks is beyond belief.
If Java is so heavy, how come it's so popular for writing games on mobile phones?
Java is not perfect, nor the solution to every problem. Indeed there are many cases in which Java isn't the best choice. It is, however, almost always a good choice.
* Before you shout "but Windows is the standard too" bear in mind that Java was not forced on anybody through cynical business practises that have resulted in billions of dollars worth of antitrust cases, and Java has been actively fought by Microsoft since it came out.
** Enterprise does matter. Trillions of dollars says it matters.
*** Compare the development rate of Eclipse (as a project) to your written-in-C-or-C++ IDE of choice.
"Java may have the libraries, but it wasn't designed to be a good language; it was designed to be better than C++."
Whoever thinks that may want to read up on programming language history. Java was way ahead of it's time.
Whoever thinks that may want to read up on programming language history. Java was way ahead of it's time.
Whoever says that really needs to read up on programming language history. Java was clearly _not_ ahead of it's time. Please do a favor to yourself and go read about LISP and Smalltalk.
The success of Java is the availability of infinite mature libraries for everything, provided by millions of dollars of investment (it's a not a bad thing, IMHO). Unfortunately, the language isn't that great. Instead of advancing computing, I believe Java kept computing lagging for a few years. We really should be using something better. There are lots of useful features of LISP that Java can only dream about, and LISP is 50 years old. Why? Because LISP has a very good math theory behind it, while Java does not, creating ugly holes and hacks.
>The facts are that Java has become the industry standard* for Enterprise development**.
Which does not say much about the intelligence of the language design.
To become an industry standard other factors are likely more important, like:
- syntactically close to the previous 'mainstream' enterprise language
- a huge and complete framework
- backing from a serious company and ecosystem
- marketing/hype/timing
It is not so much Java, as well as the Java framework and toolchain that has become the industry standard.
>It's robust, reliable, proven, and performs. You just can't contradict that with an opinion.
It's robust, reliable, proven and performs. So did the previous 'most' popular programming language and so will the next. You don't get to be the industry standard because you are robust and reliable though. You get to be robust and reliable because you are the industry standard.
>There's just too much damned good software that destroys your argument on why Java is rubbish.
True, in general Java programs are of good quality. This still doesn't really reflect on language design.
>Development in Java is far quicker*** than in C/C++, especially when it comes to larger projects where debugging C/C++ becomes a sodding nightmare.
Walking is faster than crawling. Even driven a car? The speed and integration with the system in much better with C/C++. The question is: is Java development quick enough, given the trade-offs for performance? I say, no.
>Debugging in Java is a relative walk in the park - information everywhere. Non-trivial C/C++ app development is the realm of total experts.
Again, true. Debugging non-concurrent, non-distributed Java is as good as say debugging Python, Ruby or any other _dynamically_ typed language.
However, Java is not dynamically typed. It lacks many of the features that dynamic typing brings to the table. That could be an intelligent trade-off, would it provide debugging features _beyond_ what dynamically typed languages can provide.
>You can force garbage collection - System.gc().
Oops. I stand corrected.
>Also frankly it's pretty great to have that all automatically handled by an amazing garbage collector.
Automatic memory management is a good thing. Wether automatic garbage collection is a good thing, however, is debatebly.
An object gets removed from memory, when all references ato that object are gone. Yet you may have a lot of those references, because of the object semantics. Are you sure that you removed all references? How much code do you write to remove references everywhere? Off course the solution is weak-references and Java supports them. Unfortunately almost nobody uses them. Including the most of the frameworks.
>The number of mature C/C++ apps that just segfault or have leaks is beyond belief.
True. Automatic memory management is a good thing. But do not confuse it with garbage collection. Garbage collection means you can't tell to just destroy an object, but that it figures it out, because you went through all iterators and all places to remove all references to it manually. Assuming the memory of objects you no longer use gets freed is foolish. You still have a reference somewhere, where your program might not access it anymore.
>If Java is so heavy, how come it's so popular for writing games on mobile phones?
The word popular is misleading here. On most phones its the _only_ way to offer a game. There was no choice for the mobile game companies or hobbyist. Also, considering you can run Doom on an iPod, but you can barely run a frozen-bubble-like-game on the much better equipped mobile phone of last year, we only conclude that the phone companies made a trade-off _against_ performance. Off course being able to program a mobile game and put it on different phones, from different vendors, with different hardware is a Good Thing (tm). I can understand why they went for a non-native programming language.
Java is not perfect, nor the solution to every problem. Indeed there are many cases in which Java isn't the best choice. It is, however, almost always a good choice.
It is however, almost always a good bussniss choice. Yes. Chicken, egg story. The industry bet on Java and now they are stuck with it.
Whoever thinks that may want to read up on programming language history. Java was way ahead of it's time.
Ahead of the academic programming languages? Or do you mean ahead of the previous industry standard?
Was it ahead of their time? Or could we have known better at the time? To close the deal, check this link: (Oak was the codename for java when they were designing it)
Seeking the joy in java
They didn't even try to design a good language. They one guy that did was pulled off.
Off course the language could likely be less popular in the Industry if they did design it right the first time. You can't sell a good language, you can sell a language people (managers) think is good.
Then just pour money on to it. And you will get a reliable, robust, well supported, highly succesfull crappy language.
Post a Comment