|
Stramit posted:I'm going to go against what I assume will inevitably become the grain here and say Java. My reasons are this: This is and has been bullshit. Some languages simply are faster than others. I ported a rigid body dynamics library that uses separation axis theorem from c++ to java. The code is identical and built concurrency in mind, however c++ does 800 objects fine whereas the java version chokes on a dick after 200 objects. If you like an avalanche of words I invite you to read my rant of an anecdote: I posted the results and the code of my rigid body dynamics experiment to a well known java forum and asked what I was doing wrong. I actually anticipated to get constructive criticism that would speed up my code, but instead I got angry and frustrated responses "YOU ARE NOT DOING THINGS JAVA WAY.  " At first I thought I had hosed up my monitors and I was locking and unlocking my resources unnecesary, but after searching and profiling my code I found out that most of the time is spent in vector math calls. Oh well, time to check back to that java forum where the thread had received almost 90 answers at this point. Constructive criticism, Let Me In On This! Little did I know that according to java.sun.com forums I should store temporary classes and variables as static variables within the class. A++ all credibility gone. And if I wasn't doing things the Java way, how the gently caress should I do things? The argument JAVA IS SLOW gets shot down as flamewar far too often and I've yet to see a reasonable excuse why it is, in fact, so loving slow. Surely it isn't the fact that JAVA IS THE FUTURE. JAVA WAS THE loving FUTURE TEN YEARS AGO AND I STILL DON'T HAVE FAST ENOUGH COMPUTER TO RUN IT PROPERLY. Also LWJGL is worthless library. Search javagaming.com for "concurrency" and you'll see one of the librarys main developers is a beligerent twit who spouts out poo poo like "Concurrency will never work out for games, this is why we'll implement lwjgl in a manner that concurrency is impossible to add later on." Remember that all this was said when apples started to come out with dual cores, so not that long a go. I am not saying java isn't for game development. I am just saying that if your design document incorporates Java and Feasible in a competitive mass market game, better get back to the drawing board. It's a good language to build roguelikes, 2d rpgs and other innovative stuff. When used so, it can also be commercially feasible (see "Tribal Trouble"), but it isn't a FAST language, by no means. Sometimes that speed matters, granted not when you are starting out, but the second you gain ambitions Java becomes too slow. It turns into a bottle neck, with a cork on and you're inside of it, stuck without a way out. captain_g fucked around with this message at 11:18 on Dec 27, 2007 |
#
¿
Dec 27, 2007 11:13
|
|
|
|
| # ¿ May 7, 2024 23:13 |
|
|
Do directx 10 and 11 still continue the COM-style? If so then 
|
|
#
¿
Aug 13, 2008 06:57
|
|
|
OneEightHundred posted:- D3DX has tons of useful toys, GLUT is pathetic I didn't know GLUT is part of OpenGl? Surely you mean GLU, which no one uses anyway.
|
|
#
¿
Sep 10, 2008 21:04
|
|
|
Kimani posted:Well, you can do that. The system is very flexible! You've got to be trolling.
|
|
#
¿
Oct 20, 2008 16:01
|
|
|
vanjalolz posted:I've also got an XNA question (which has probably been answered a hundred times): What game library should I use to make a 3D third person RPG style game? You should definitely use an engine to start this project. Otherwise you'll get frustrated fast, since you have to write something that resembles an engine/framework, from ground to up and this is not a trivial task for an experienced developer. Ogre seems to be the most complete of these engines that are available currently. It has plenty of examples around and it is very beginner friendly. C# is also supported and you might want to check out MOgre. I haven't found any mature free engines for XNA, yet and I would definitely not pay any money for commercial indie engine like reactor, unity or torque. captain_g fucked around with this message at 11:26 on Mar 3, 2009 |
|
#
¿
Mar 3, 2009 11:23
|
|
|
timecircuits posted:I'm writing a DX9 game engine in C++ as a exercise in frustration and wasting time, and before I write too much more code, I want to separate my subsystems into different threads -- right now, just a rendering thread and a game logic thread. One rule of thumb is that you allocate and de-allocate memory from the same context. This makes things a bit complex. Things that need video memory need to be created from where your D3D rendering context lies. In terms of new and delete I am not sure how Windows serializes memory function calls, but I am sure it does some serialization. There's also the EXE / DLL problem where you might end up calling new and delete from different heaps. I am not sure if this still issue, but it used to be. What library are you using for concurrency anyway? Boost? You are about to enter never ending world of poo poo and I personally wouldn't count the exercise worth the time invested. You aren't going to learn that much useful in terms of concurrency, you are just starting an endless struggle against inane implementation details of the platform and the libraries. Furthermore there are countless of frustrating concurrency problems that might take stupendous amount of time to get solved. Mostly, because you won't simply have all the required information. captain_g fucked around with this message at 14:30 on Oct 26, 2009 |
|
#
¿
Oct 26, 2009 14:23
|
|
|
timecircuits posted:Yes, I do think that -- I've asked senior developers on AAA titles about this and they've told me as much. I don't expect my code to be blistering fast. I'm writing a game engine as an exercise to expose me to all of the performance concerns that need to be accounted for, so that I have a starting point for further research and experimentation. The rest of your programming career is going to suck and I don't think concurrency is going to play any major role in that.
|
|
#
¿
Oct 27, 2009 07:56
|
|
|
Internet Janitor posted:Java, especially with one of the OpenGL bindings, can be a practical choice, although it isn't the same degree of out-of-the-box magic as XNA. On the plus side it's fairly easy to get running on all three desktop operating systems and presumably an Android port wouldn't be too painful. Java has tons of great libraries for everything. Java is awesome from the library point of view and it also has nice community (https://www.javagaming.org). I guess the main selling point of XNA is that it works out of the box from Microsoft / Visual Studio impaired point of view. If I had not invested so much in C# I'd probably start a Slick project. There are some very nice libraries for it and it is integrable with some nice GUI systems. Of course you can say goodbye to iPad / iPhone development. I haven't tried XNA myself, but judging from its API it seems like you'd hit productivity ceiling pretty fast, unless you end up using an engine or implement the features yourself. Thankfully the C# world has moved towards better libraries, but still every now and then a library pop up with retarded proprietary licenses mostly due to poor understanding of proper open source licenses such as BSD, MIT or LGPL. This is all fine until the author disappears... Pisses me off so much... captain_g fucked around with this message at 06:22 on Mar 7, 2012 |
|
#
¿
Mar 7, 2012 06:18
|
|
|
HaB posted:If I understand you correctly, you need to decouple your movement code from your timestep, as explained here: My problem with this is that how are you supposed to store the drawing states as the example is extremely trivial. I've seen the article a lot in gamedev.stackexchange.com and I am starting to think it is actually part of SE groupthink that's aimed for ecredfishing. I've tried to figure out proper way to implement the render state in component-based design and I am on the verge of giving up, since you either have to do the integration twice and keep current frame and next frame, or somehow blend the rendered images. The other one requires a lot of work (basically creating copies of everything you are about to render, twice), and the other one sounds suboptimal. I am at the "free the physics" -part and I think the "Final touch" is too much in terms of time invested versus gain. Is there anyone here who has implemented the last part and been completely happy with it? So int its essence, I've never seen this getting implemented so that its even remotely pretty (and how does the previous integration even relate to this?): State state = currentState*alpha + previousState * ( 1.0 - alpha );
|
|
#
¿
Oct 9, 2012 19:04
|
|
|
xgalaxy posted:Xcode is much better at C and C++ then Visual Studio. But my ~find in files~ and ~comfort zone~!!!
|
|
#
¿
Nov 20, 2013 19:23
|
|
|
|
| # ¿ May 7, 2024 23:13 |
|
|
Dirty posted:I just used what Unity threw at me because at the time I wasn't really sure where everything was, or how using a non-Unity provided IDE would work. And I started off with UnityScript. That depends: http://docs.unity3d.com/Documentation/Manual/VisualStudioIntegration.html Yes, if you have Visual Studio Professional.
|
|
#
¿
Nov 20, 2013 19:28
|
|