×

Announcing: Slashdot Deals - Explore geek apps, games, gadgets and more. (what is this?)

Thank you!

We are sorry to see you leave - Beta is different and we value the time you took to try it out. Before you decide to go, please take a look at some value-adds for Beta and learn more about it. Thank you for reading Slashdot, and for making the site better!

Godot Game Engine Released Under MIT License

Unknown Lamer posted about 10 months ago | from the shiny-new-toys dept.

Open Source 73

goruka writes with news that a new game engine has been made available to Free Software developers under the permissive MIT license "Godot is a fully featured, open source, MIT licensed, game engine. It focuses on having great tools, and a visual oriented workflow that can deploy to PC, Mobile and Web platforms with no hassle. The editor, language and APIs are feature rich, yet simple to learn. Godot was born as an in-house engine, and was used to publish several work-for-hire commercial titles. With more than half a million lines of code, Godot is one of the most complex Open Source game engines at the moment, and one of the largest commitments to open source software in recent years. It allows developers to make games under Linux (and other unix variants), Windows and OSX." The source is available via Github, and, according to Phoronix, it's about as featureful as the Unity engine.

Sorry! There are no comments related to the filter you selected.

Been waiting for this for a long time (4, Funny)

Chuck Chunder (21021) | about 10 months ago | (#46213819)

(Sorry)

Re:Been waiting for this for a long time (0)

Anonymous Coward | about 10 months ago | (#46213841)

With its release it becomes misnamed.

Re:Been waiting for this for a long time (0)

Anonymous Coward | about 10 months ago | (#46213885)

Re:Been waiting for this for a long time (1)

lucm (889690) | about 10 months ago | (#46214877)

I gave a shot at your youtube link and I have to say, I would rather try to return a laser printer without a receipt at Best Buy in the days following Black Friday than watch one more minute of that horrible sitcom. It makes Three's Company look like a complex plot-driven drama starring top models...

Also: why did they hire trannies to play female characters? Must be a British thing.

British thing indeed. (3, Funny)

ne0n (884282) | about 10 months ago | (#46215721)

Also: why did they hire trannies to play female characters? Must be a British thing.

I believe it's because their women lack estragon during development...

Re:British thing indeed. (0)

Anonymous Coward | about 10 months ago | (#46216485)

Need... More... Mod Points!

Seriously? More people should get this joke.

Re:British thing indeed. (1)

hoggoth (414195) | about 10 months ago | (#46218935)

well done, sir. *golf clap*

Re:Been waiting for this for a long time (2)

NoImNotNineVolt (832851) | about 10 months ago | (#46214621)

I don't get it.

Waiting for what? Why are you sorry?

*whoosh*

Re:Been waiting for this for a long time (4, Informative)

Anonymous Coward | about 10 months ago | (#46214979)

- Let's explain it to him.
- We can't.
- Why not?
- We're waiting for Godot. [wikipedia.org]
- Oh, right.

Re:Been waiting for this for a long time (2)

NoImNotNineVolt (832851) | about 10 months ago | (#46215273)

Well now I feel ignorant.
Thanks, though.

Re:Been waiting for this for a long time (0)

Anonymous Coward | about 10 months ago | (#46215975)

They do not move.

Re: Been waiting for this for a long time (0)

Anonymous Coward | about 10 months ago | (#46217089)

Waiting for godot is a play by Samuel Beckett.

Re:Been waiting for this for a long time (0)

Anonymous Coward | about 10 months ago | (#46214805)

Someone better wake Vladimir and Estragon.

Is this like CrystalSpace? (1)

Anonymous Coward | about 10 months ago | (#46213921)

Lots of features early on, some screenshots of pretty, but most of the bloat is in generated, generally useless docuomentation?

I've yet to play a Crystal Space game worth playing.... or Love and Irrlicht for that matter.

Re:Is this like CrystalSpace? (3, Interesting)

UnknownSoldier (67820) | about 10 months ago | (#46214281)

The AC actually brings up a good point ! Whatever happened to CrystalSpace, Orge3D and other 3D game engines?

The only one I hear about these days is the FPS "Cube" and "Cube 2: Sauerbraten"

* http://cubeengine.com/ [cubeengine.com]
* http://sauerbraten.org/ [sauerbraten.org]

Re:Is this like CrystalSpace? (1)

goruka (1721094) | about 10 months ago | (#46214699)

None of those are nearly as complex or featured as Godot. Also, they were designed for hardware architectures not relevant any more today.
Godot tries to avoid the same mistake by abstracting the graphics part as higher level, so changes in hardware trends don't affect the rest of the engine as much.

Re:Is this like CrystalSpace? (1)

atlasdropperofworlds (888683) | about 10 months ago | (#46216071)

> Also, they were designed for hardware architectures not relevant any more today.

Actually, that hardware is completely and still dominantly relevant in the gaming scene. Perhaps you missed the billion-dollar releases?

Re:Is this like CrystalSpace? (2)

DeSigna (522207) | about 10 months ago | (#46216533)

None of those are nearly as complex or featured as Godot.

After having a look over the doco for Godot, I'd say that CrystalSpace isn't as far behind as you'd think (especially if you include CEL). However, Godot seems to have more nice features if you're actually developing a game (nice UI, publishing integration).

CS suffers from being more of a programmer's playground than a practical game engine and having quite a steep learning curve, but I've been toying with it for more than a decade.

Also, they were designed for hardware architectures not relevant any more today.

This hits closer to the mark - CS was started a long time ago, but it's ended up being well designed and modular. However, it's difficult to pick up new talent to implement new stuff with such a large existing codebase, leading to quite a bit of development inertia in certain areas.

Still, it works with modern OpenGL and console ports have been made.

I'm more interested in how Godot stacks up against a framework like Marmalade.

Re:Is this like CrystalSpace? (3, Insightful)

exomondo (1725132) | about 10 months ago | (#46214847)

They still exist, but are often used for student projects and tech demos. Building the game engine and the associated tech demos to show it off is the (relatively) easy part. Creating a decent game with proper art assets, animation, music, voice actors, level design and a good storyline with well-developed characters is the hard part. It requires a lot more effort than collaboratively building application middleware and many studios prefer to use proven commercial engines like UE, iD tech, CryEngine, Source, etc... that are artifacts of actually building a commercial game rather than building just an engine.

I'm not saying these things are essential for all games but often for notable ones and in the case of simple games it is often not worth the effort to learn/use an engine that has so many features you aren't going to need.

Re:Is this like CrystalSpace? (2)

Daemonik (171801) | about 10 months ago | (#46216591)

You've never played Star Wars: The Old Republic, have you. The majority of the problems they've had with development has been wrangling their 3rd party game engine to fit their game concept.

The art & the story are hard to do, but picking the right game engine can make or break your game as well.

Re:Is this like CrystalSpace? (1)

exomondo (1725132) | about 10 months ago | (#46222227)

You've never played Star Wars: The Old Republic, have you.

I have actually, what information exactly should I have gleaned from playing it that you believe I haven't?

The majority of the problems they've had with development has been wrangling their 3rd party game engine to fit their game concept.

I suppose they made a bad choice then.

Re:Is this like CrystalSpace? (2)

mark-t (151149) | about 10 months ago | (#46215009)

Thos are 3d engines, not full fame engines.

Scope of fame engine? (3, Funny)

syockit (1480393) | about 10 months ago | (#46215247)

Does a fame engine do anything useful outside SEO? I don't want to be famous on just the internet you know. Sure, the internet has a very large demographics, and it's international, but everything feels so virtual. And being "virtually famous" doesn't make me look good.

Re:Scope of fame engine? (1)

mark-t (151149) | about 10 months ago | (#46215279)

SEO?

RE:SEO? (1)

clcto (2489850) | about 10 months ago | (#46222137)

Search Engine Optimization

Re:SEO? (1)

mark-t (151149) | about 10 months ago | (#46230823)

Which has what to do with games or 3d engines, exactly?

Re:SEO? (1)

clcto (2489850) | about 10 months ago | (#46233581)

This all started by a typo "fame" instead of "game." I guess the joke was a "Fame engine" only does SEO.

Re:Is this like CrystalSpace? (1)

The boojum (70419) | about 10 months ago | (#46216141)

Torchlight [ogre3d.org] was made with Ogre3d.

Re:Is this like CrystalSpace? (1)

Half-pint HAL (718102) | about 10 months ago | (#46216673)

2009.

Re:Is this like CrystalSpace? (0)

Anonymous Coward | about 10 months ago | (#46217021)

The rendering was done with Ogre3D. To create the game they built their own tools.

Objection! (0)

Anonymous Coward | about 10 months ago | (#46213929)

Godot beta blend... Not quite bitter enough.

Re:Objection! (1)

Anonymous Coward | about 10 months ago | (#46214093)

Beta is just nice wording for "We own you now"

Godot be praised! (-1)

Anonymous Coward | about 10 months ago | (#46214095)

It's a miracle!

Lets define our own string, vector, list classes! (1)

halfdan the black (638018) | about 10 months ago | (#46214397)

General rule of thumb is when a library defines their own types like string, vector, hash map, list, etc, ... run, don't walk away from it.

Seriously, WTF is wrong with just plain old STL???

Lets implement our own string class so we can be completely incompatible with everything else.

It seems like every first year CS student writes their own string and list classes (I know I did when I started).

Re:Lets define our own string, vector, list classe (0)

Anonymous Coward | about 10 months ago | (#46214457)

Portable consoles and small devices is what's bad with STL.

Re:Lets define our own string, vector, list classe (0)

Anonymous Coward | about 10 months ago | (#46214581)

Which is why we have alternative implementations like uSTL [github.io] and custom allocators.

Back when I did that kind of thing for a living, we shipped multiple titles on the PS2, GameCube, and even DS using that solution. It was fast, space efficient, and portable. It also let us focus on things like rendering code and game logic rather than trying to write and maintain The One True String Class (and list, vector, map, etc.) internally.

Chinese/Korean/Japanese localization was still a major pain, mind you, but one can't have everything.

Re:Lets define our own string, vector, list classe (1)

atlasdropperofworlds (888683) | about 10 months ago | (#46216075)

Portable consoles/mobiles can't handle STL? Please, give me some of what you're smoking.

Re:Lets define our own string, vector, list classe (-1)

Anonymous Coward | about 10 months ago | (#46214573)

Cause he exports to html which doesn't have STL?

Re:Lets define our own string, vector, list classe (3, Insightful)

goruka (1721094) | about 10 months ago | (#46214667)

This is an easy answer, STL is good but often not as good, specially for projects this size and requirements because:

1- It generates huge debugging symbols.
2- It generates a lot of code because most compilers inline it by default.
3- It's so complex that compile time increases by a few times.
4- Errors are huge and uncomprehensible.
5- Support for custom allocators is limited to alloc/dealloc functions.
6- Support across compilers is not as good (specially console compilers).
7- Lack of support for COW with atomic ops for thread safety

Some of these probably improved significantly since the time work on the engine started, but I'm sure most issues still stand.

As for why not std::string or std::wstring, have you actually used those? They suck, the amount of operations you can do is really little, check core/ustring.h in Godot to std::string and you'll easily see why everyone rewrites the string class.

Re:Lets define our own string, vector, list classe (4, Interesting)

mark-t (151149) | about 10 months ago | (#46215467)

The first thing I noticed is that the string class wasn't well thought out at all.

In particular, while it is already generally considered among experienced C++ programmers to be unsafe to derive a class from another that does not have a virtual destructor (a rule that the godot author(s) seem to have violated by inheriting their custom string class from their vector class), when the base class does not contain any virtual members at all, and the base class is still intended to be a general utility class, then inheritance is almost always the wrong tool for the job. The proper tool, in this case, would probably have been to use containment, and not inheritance... or if inheritance was really to have been the way to go, then it should have been derived from a base class that was common to both itself and Vector, where the necessary base class is never directly used by anyone other than those classes, (with all of its constructors declared protected, including the copy constructor, so that it is not possible to use the class unsafely outside of those controlled contexts).

I can think of absolutely no good reason to ever inherit from a class that has absolutely no virtual functions when the base class is one of general utility, and may be utilized by callers.

Re:Lets define our own string, vector, list classe (1)

goruka (1721094) | about 10 months ago | (#46219755)

Thanks for the preaching, but I don't know what an "experienced C++ programmer" is. There are several different ways people programs C++, including different styles and different purposes.

Clean code is useless when it doesn't perform as expected, and performant code is useless when it's more difficult to write. C++ is meant to mix both things, so by definition it will never be entirely clean or performant. It's a language that strikes the right balance for this specific purpose.

In other words, the reason for the lack of a virtual destructor is performance. This way, the class will not need for a vtable and vpointer, and will be destructed inline. Containment will make it more difficult to write and debug, you would need to replicate operators such [], mehods such as size, etc.

So, I hope I could make my point of why the current choice is the right choice in that context.

Re:Lets define our own string, vector, list classe (1)

mark-t (151149) | about 10 months ago | (#46220125)

There's no problem with not having a virtual destructor. Of course one may often wish to avoid virtual functions for performance reasons, The problem is inheriting fom such a class when the base class is also a general utility class. It is incredibly unsafe, and almost always logically wrong. It is usually n indication of overeagerness on the part of the programmer to utilize inheritance as a code reuse measure. Ther is no problem code reuse by itself, but how this implement or chose to accomplish. It is almost inevitably going to cause errors.

There's a reason that programmers are devised to not inherit from stl classes like std::vector, and t has far less to do with the design of those classes, and far more to do with how the objects and their descendants may get used.

Re:Lets define our own string, vector, list classe (1)

mark-t (151149) | about 10 months ago | (#46222583)

By the way, if containment were used, the necessary public functions and operators would just be implemented as single line inline (or even forced intline) functions that delegated their responsibility to the contained class... this would incur no performance or memory overhead above inheritance,, and in particular, you make both the general purrpose vector class and string class completely safe to use in all contexts...where otherwise there is the distinct chance of errors cropping up when a reference to the vector is used while it is actually referring to a string.

However, another approach would have been to change the current declaration of Vector to something like, say, "_VectorImpl", a class that is never meant to be directly used by anyone other than descendant classes, and which has a protected default and protected copy constructor, so the class cannot ever be used outside of controlled contexts. Vector would then be implemented as a class inheriting publicly from _Vectormpl, and thew only necessary declarations to add to it would have been one-line inline constructors, which would call the _VectorImpl constructor. The custome String class could them also inherent from _VectorImp, redirecting calls in the constructors that once when to Vector to now be received by _VectorImpl.

I fully understand that not using virtual functions is desirable when you are coding for efficiency... but in my experience, you have to be careful how to handle object inheritance in such situations or you open yourself to a potential world of hurt of when people utilize the classes in ways that you did not predict.

Re:Lets define our own string, vector, list classe (0)

Anonymous Coward | about 10 months ago | (#46224291)

Clean code is useless when it doesn't perform as expected, and performant code is useless when it's more difficult to write.

And code that was written for performance is useless when it introduces bugs and memory leaks. That's what you're inviting by inheriting from a class with a non-virtual destructor. Containment wouldn't be more difficult to write unless you consider one-line wrappers around functions that are delegating their functionality to a derived class "difficult", and in return you'll get much better behaved code whose behavior can be predicted by the language standards definition, regardless of how your classes may get used. GP is right. Do not ever use inheritance when the base does not have a virtual destructor unless the base is a class that never gets used by anybody else. Containment, even though it requires writing a few extra lines, is the much better way to go here. The additional type safety you'll gain from it is well worth the effort, and if functions are properly inlined, there will be absolutely no performance penalties introduced that you seem to be worried about.

Re:Lets define our own string, vector, list classe (0)

Anonymous Coward | about 10 months ago | (#46224571)

"or if inheritance was really to have been the way to go"

Has anyone told you that you write incredibly awkwardly? Not exactly illiterate, but also not far from it.

Re:Lets define our own string, vector, list classe (1)

mark-t (151149) | about 10 months ago | (#46225101)

Fair assessment... I was kind of pressed for time when I wrote that, but there was still a lot I wanted to say... my brain was firing so much faster than my fingers that what I was saying didn't come out particularly as well as I had intended.

7- Lack of support for COW with atomic ops for thr (2)

Dareth (47614) | about 10 months ago | (#46218215)

Well that ruins it. I wanted my game to have a totally awesome secret cow level.

Re:Lets define our own string, vector, list classe (1)

gl4ss (559668) | about 10 months ago | (#46218387)

and .stl doesn't have (at least widely accepted) texture support anyways and even the color support is dodgy.

Re:Lets define our own string, vector, list classe (0)

Anonymous Coward | about 10 months ago | (#46214725)

Compatibility is one of the reasons they *don't* use STL. It is right there under "Deploy":

"One-Click deploy to several platforms, such as Windows, Linux, Mac, Android, iOS, BB10 and HTML5."

In addition they built in reference counting and COW.

Re:Lets define our own string, vector, list classe (1)

gbjbaanb (229885) | about 10 months ago | (#46216633)

STL strings used to have CoW, until they realised that performance dies horribly with such a thin on multi-threaded applications. The memory cost of copying the string data (nowadays) is much less than blocking the CPU with a context switch every time you want to copy or modify a string.

There's no reason to worry about compatibility - use STLPort and you're good to go; or use uSTL and you're good even on really crappy hardware (which kind of defeats the point, if you're using really crappy hardware 80% of your full featured game engine won't run anyway)

Reinventing the wheel is a stupid thing to do, especially with something standardised like the STL.

Re:Lets define our own string, vector, list classe (0)

Anonymous Coward | about 10 months ago | (#46214737)

The STL containers are the least usable part of the standard library for game development. They can't cope with alignment (i.e. structures containing SIMD data types requiring 16 or wider byte alignment). They churn allocations way too much. If you feed a custom allocator template to a container it has to be able to be used for all extraneous allocations the container does in addition to the object being allocated (they should have had a leaky abstraction so that we could have control over the allocators going to different types of allocations the containers must perform). This is basic stuff off the top of my head there are a few other more insidious issues which are lurking around in the back of my head somewhere as well.

Most of the useful stuff is in the algorithms anyway which will work on any container with std compliant iterators, which can easily be added to your own containers or wrapped with some adapter magic.

Re:Lets define our own string, vector, list classe (1)

mark-t (151149) | about 10 months ago | (#46215033)

If you feed a custom allocator template to a container it has to be able to be used for all extraneous allocations the container does in addition to the object being allocated

Actually, this one's not true anymore.

Re:Lets define our own string, vector, list classe (1)

Pseudonym (62607) | about 10 months ago | (#46214745)

What's wrong with plain old STL? It's not compatible with the current revision of the C++ standard library.

(You do know that the STL is the name for a specific library that predates ISO C++, right?)

Re:Lets define our own string, vector, list classe (-1)

Anonymous Coward | about 10 months ago | (#46214773)

STL blows. push_back(), seriously?
Standard strings that don't copy-on-write?
Calling arrays vectors so that you can be confused when you're using 3d vectors for your 3d game maths?
numeric_limits::min() that returns a positive value for floating point types?
STL is worse than slashdot beta, and that's saying something!

Re:Lets define our own string, vector, list classe (0)

Anonymous Coward | about 10 months ago | (#46214819)

And let's call it STL but make the namespace "std". Two names for the price of one.

Re:Lets define our own string, vector, list classe (1)

gbjbaanb (229885) | about 10 months ago | (#46216637)

the S stands for "standard", abbreviated to std for convenience.

Re:Lets define our own string, vector, list classe (1)

microbox (704317) | about 10 months ago | (#46215023)

Haha, totally agree. Now, if only GCC used the SSO like clang and MSVC.

Yay for boycott's! (-1)

Anonymous Coward | about 10 months ago | (#46214785)

Wait a minute... Nobody complaining about Beta? Has the boycott started? Let's just pray they stay gone...

Re:Yay for boycott's! (0)

the_B0fh (208483) | about 10 months ago | (#46214887)

someone finally posted something that too many slashdotters have to comment on... :)

Mac support (1)

Anonymous Coward | about 10 months ago | (#46214905)

I like how the Mac version crashes immediately. I'll be using this a lot!

Re:Mac support (1)

atlasdropperofworlds (888683) | about 10 months ago | (#46216077)

This is where "It just works" hurts you...

According to..? (4, Insightful)

Bogtha (906264) | about 10 months ago | (#46215727)

according to Phoronix, it's about as featureful as the Unity engine

From the article:

The tech has now proven to be quite mature and is now very complete and according to its developer to be on-par with Unity, or arguably superior to Unity when it comes to the area of 2D and animation support.

Phoronix was just repeating the developer's claim. Would anybody who isn't the engine's developer care to comment on its feature parity with Unity?

Re:According to..? (-1)

Anonymous Coward | about 10 months ago | (#46216155)

Yeah. Not even close. Like, not even 10% there.

Videos? (0)

Anonymous Coward | about 10 months ago | (#46216641)

As far as I can tell, there are zero videos on the internet of anyone claiming to have produced something with this engine.

If anyone has links to any example or promo videos, I'd love to know about them. (Oh - the main story link is slashdotted right now, so if there's something there, I can't see it).

Thanks

May be this is one (0)

Anonymous Coward | about 10 months ago | (#46217661)

May be this is one
http://www.youtube.com/watch?v=gT-wwuAnoGU

Unitiy is "the" benchmark? (1, Informative)

Dan Askme (2895283) | about 10 months ago | (#46217091)

Honestly, i wish Godot the best of luck with their engine.
But comparing anything to Unity is just telling me it may be "easy" to use, but the performance will never exist.

I'am yet to play any Unity game that doesn't make my PC feel like its 10 years old. It annoys me when i see a Unity logo on any game, as i know what to expect.
If Developers spent a little more time using a pure IDE based engine, the current indie games market would promote excellence, rather than cheap physx titles running on some hashed job Java code and being emulated by the engine.

Good luck to Godot, but I'd like to see more performance related project examples and stats. Show me your engine cares about performance and not just ease of use. A project demo to showcase the engine's capabilities wouldnt go a miss either :)

Re:Unitiy is "the" benchmark? (1)

ctid (449118) | about 10 months ago | (#46220867)

What on earth is a "pure IDE based engine"? And what do you mean by "hashed job Java code"? Unity has Unityscript (which is like Javascript) and Boo (which is a little like Python), but I'd guess that most games are written in C#. And what does the language matter anyway?

Re:Unitiy is "the" benchmark? (1)

Dan Askme (2895283) | about 10 months ago | (#46223649)

Oh dear oh dear lol

What on earth is a "pure IDE based engine"?

http://en.wikibooks.org/wiki/V... [wikibooks.org]
eg: a engine which uses a IDE, either by .dll linkage, or, included .h .cpp files.

And what do you mean by "hashed job Java code"?

Shit code made in a shit language which runs like shit = Java.
Thats not to say all Java programmers are bad, but, the same code in C++ would run at least 10x faster.

Unity has Unityscript (which is like Javascript) and Boo (which is a little like Python),

Last time i checked, it supported Java or C#.

but I'd guess that most games are written in C#. And what does the language matter anyway?

No, most games are written in C++. For the performance (hence why the language matters).

Re:Unitiy is "the" benchmark? (0)

Anonymous Coward | about 10 months ago | (#46224659)

eg: a engine which uses a IDE, either by .dll linkage, or, included .h .cpp files.

First, "an" engine. Learn English. Second, learn what IDE means.

Shit code made in a shit language which runs like shit = Java.

How do you get from that to "hashed job Java code"? See First above.

Last time i checked, it supported Java or C#.

Check again, moron.

No, most games are written in C++. For the performance (hence why the language matters).

Most _Unity3D_ games are written in C#. Seriously, go learn English and come back. You're too illiterate to engage in any sort of conversation.

Re:Unitiy is "the" benchmark? (1)

Dan Askme (2895283) | about 10 months ago | (#46228231)

Most _Unity3D_ games are written in C#. Seriously, go learn English and come back. You're too illiterate to engage in any sort of conversation

Roger that Mr A C Unity.
I wasnt aware you were conducting English lessons for Slashdot?

I'd suggest reading the below regarding your emulated C# code.

All of those are then converted into the same common code then compiled to the final platform ala a custom version of mono.

Re:Unitiy is "the" benchmark? (0)

Anonymous Coward | about 10 months ago | (#46224941)

Unity has Unityscript (which is like Javascript) and Boo (which is a little like Python),

Last time i checked, it supported Java or C#.

but I'd guess that most games are written in C#. And what does the language matter anyway?

No, most games are written in C++. For the performance (hence why the language matters).

It never supported Java. They do have a habit, however, of calling Unity Script "Java-Script" even though Unity Script is superior to Java-Script in many ways. They also support Boo (Python) and also C# (which is what GP was likely referring to; most "serious" Unity3D devs seem to use C#).

All of those are then converted into the same common code then compiled to the final platform ala a custom version of mono.

Re:Unitiy is "the" benchmark? (0)

Anonymous Coward | about 10 months ago | (#46220869)

How old is your PC? They run like shit on my $300 PC from 2009, but my _very decent_ (but hardly "gaming") laptop from last year runs them great.

It's gonna be... (0)

Anonymous Coward | about 10 months ago | (#46218665)

LEGEN...

wait for it

Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?