I think that I had to become more "mature" to look my creations with some more hindsight. I'm used to have some complaints from players who are too lazy to read the instructions. Some people who don't understand game development can underestimate the efforts required to create a complete game and the difference between computer programming and computer graphics. Poor graphics don't mean that a developer is bad, it just indicates that he doesn't have good skills in graphics. Those people don't (often) understand that adding a multi-player mode can require a major rewrite if the game was not designed to support it and some young computer artists don't understand that I need more than a single key frame to add a weapon into my game.

LibGDX of course.

Hi

You can modify the sensitibity of the mouse and reverse up/down. I know this is not fantastic but I did that as it was asked by Erikd (several years ago) and I thought it would be useful.

I avoid adding tons of concrete features into the road map of my game because it will be already very difficult to do what I've already planned but when I spend some time in evaluating the remaining amount of work to get the job done, I realize that things will be more complicated than I thought at the beginning. For example, when I planned to improve the artificial intelligence, I didn't think immediately about pathfinding (I'll probably use Dijkstra's Algorithm). When I planned to create some new ennemies, I didn't know that the very old MD2 key-frame controller contained a bug that would directly have an impact on low end machines I use daily and that Blender (>= 2.50) has almost no reliable import scripts for the formats I use. When I planned to switch to Ardor3D, I didn't know I would have to port its JOGL renderer to JOGL 2.0 by myself (because a guy claimed to have a working ported renderer and I thought he would contribute, I was naive). My game won't be complete in 2016. I have a real lack of visibility, I hope that the situation will be better soon. I wonder whether I should keep Android support in my roadmap and my tablet doesn't work any more, I have no device supporting at least Android 2.3.

I'm currently creating several new states:
- game over (at the end of a game, when the players dies, wins or aborts a mission)
- pause menu
- exit (final cleanup)

I'm going to separate the mutable part of the game state from its immutable part so that things required by all levels in all modes will be loaded once and things required by some levels will be loaded on demand and "unloaded" in the loading state if they are no more required. I need to do that before adding a second level, to test OSM2World.

I still want to add at least another enemy into the first level.

Actually, it is still impossible to win... There is no way to leave the first level, I have to fix that.

@HeroesGraveDev, TheThirdOne suggested you to release your source code but he won't be alone to look at it and it's easier to understand how the code evolves and to contribute with a software versioning and revision control system. I use Sourceforge even though I'm the main contributor of my main project and sometimes it helps me to detect a regression and to revert some changes.

When I see Artemis and your framework, I just feel like they encourage the developers to use an object-oriented language not to respect the OOP principles, by separating the objects and their mutators the former as entities and the latter as "systems".

Hi

Your verbs should be at the 3rd person in your Java online documentation ("Gets" instead of "Get", "Returns" instead of "Return", ...). I don't clearly see the service(s) this kind of API provides. Is it still possible to pack all components into a primitive array?

Hi

At first, you speak about refactoring. Personally, I prefer doing some small code refactoring regularily rather than doing bigger refactoring less frequently. Maybe you know my funny comparison, I try to keep my source code pretty in order to prevent myself from losing my motivation. I can't spend a lot of time in ugly source code.

Secondly, you speak about optimizing. Don't forget that "premature optimization is the root of all evil". I agree with Nate, it should be done when there is a problem. You have to check whether there is something wrong, you have to measure (I agree with pitbuller, "always profile") before starting to modify your source code in order to be able to check further whether your modification(s) really improve(s) the situation. For me it is possible to have a clean and efficient code at the same time. You can write unreadable and inefficient code too. In my humble opinion, before planning to use any known micro-optimization, think about macro-optimizations, think about using more efficient algorithms before thinking about how to improve their implementations. I obtained the biggest speedups by avoiding to do the most silly things when using OpenGL (for example never call Thread.sleep() when your OpenGL context is current) and by spending some time in choosing the algorithms (and implementing them) that fit the best to my problems. I have to admit that this last step can require months or even years of work but it has been very useful in my case. It wouldn't have been necessary if existing engines, frameworks and libraries already provided some working implementations of these algorithms even though some of them provide some useful abstract data types to implement them. I prefer releasing my source code so that other developers won't have to start from scratch if they need the same tools as long as they agree with the licensing terms.

At the end of nineties, C/C++ fans gave the same kind of arguments to explain that as Java is written in C (Jikes was written in C++), it can't outperform C which is wrong. One of my teacher wrote a program that converted Java (1.3) to C code during his thesis and he only obtained a very small gain (less than 5%) after years of work. Brian Goetz explained that memory allocation and method calls are between 2 and 4 times faster in Java. I really think that almost no human being is able to write a better machine code or assembler code that a compiler like GCC except in particular cases on a small piece of source code and if you really believe you can be more efficient than the JVM, don't use Java. I'm sad to see these kinds of prejudices about Java even here on JGO.

In my humble opinion, JogAmp is a set of low level bindings with a few helpers, LibGDX is a middle level library, a framework, a tool kit. It helps you to write games but you can write an engine with it. Jagatoo is a library used in the 3D engine Xith3D. JMonkeyEngine is a game-oriented 3D engine but not a game engine because some key aspects are missing (AI for example). You can write a game engine with a 3D engine. For example, JClassicRPG (a game engine for RPGs) is based on Ardor3D which is a generalist 3d engine. You can write a WYSIWYG editor with a game engine. For example, JFPSM is based on my own game engine which is based on Ardor3D.

Have you tried to create a game with JMonkeyEngine? It is very helpful but there is still a lot of work to do even though its integrated game development environment is nice

Edit.: I ported the JOGL backend of LibGDX to JOGL 2.0 some months ago (Xerxes helped me), that's why I've just mentioned JogAmp, it's not off topic.

Hi

When I add tons of logs, the mouse look becomes less responsive under Linux too, I'll try again with a lower resolution.

My younger brother gave me a laptop whose Windows install is half broken, some files are corrupted according to "sfc scannow" and they can't be repaired (according to the CBS logs), one sector of the partition is "bad", the file explorer can't be opened from the shortcut of the task bar despite the correct path in the environment variable "windir". I think that this Windows install is too crappy to draw any conclusion, SetCursorPos is extremely slow on it even in Jake 2, I notice that the mouse inputs sometimes block the keyboard inputs both in TUER and in Jake 2 only on this crappy machine. I'm not sure that the use of Raw Input API would solve the problem. I tried to reproduce this bug on some Windows machines without success. I can't spend several weeks (months?) in adding support of this API into NEWT if I don't know the root cause of this bug but HIDAPI, GLFW, JInput, OIS and LibGDX are great sources of inspirations and I will have to implement this feature later.

JMonkeyEngine 3 and Jake 2 are not concerned by this bug because their implementations of the mouse look use a fixed position when recentering the mouse cursor. This is a safer but more rigid approach. Ardor3D starts grabbing the mouse pointer from anywhere in the screen (you don't have to set this position and you're not forced to choose the middle of the screen) which is sometimes helpful in scientific visualization.

As a conclusion, I have to give up until I'm able to reproduce this bug in a "better" environment and I don't really want to give some money to Microsoft. Maybe I'll use ReactOS.

I get this on my crappy laptop under Windows:
http://pastebin.java-gaming.org/be57d4a8659

I get this under Linux:
http://pastebin.java-gaming.org/e57da56895f

That was one of my first suppositions but Jake 2 works very well on "my" laptop despite its use of JOGL 2.0.2, even with the very latest build.

Mario spoke about OIS to me some months ago, really nice job, it was a great source of inspiration for NEWT Controller API (I only wrote a draft for the moment). Thank you very much for your suggestions. I know that I will have to support HID devices as using absolute screen coordinates instead of relative raw data is a bit counter-intuitive for a typical first person mouse look.

Hi

I confirm it works very well on the workstation HP Z220 under Windows 7 64 bits, Intel® Xeon® E3-1225v2, 4 GB RAM, Nvidia Quadro 600. I'm still investigating.

This page explains a bit how it works in LibGDX.

Hi

I don't know whether it is already supported in LibGDX but if it isn't, let me help you out. I have a similar problem in my first person shooter. The first level uses a museum with some soldiers but the second one uses a completely different environment.

An easy step consists in keeping no reference on these meshes (and maybe on their textures too) so that the garbage collector can do its job with Java objects on the Java heap.

Another (less) easy step consists in releasing OpenGL resources (mainly the identifiers), by calling glDeleteBuffers for all VBO identifiers and by doing something similar with textures.

The hardest and less safe step consists in releasing the native memory on the native heap, typically used by direct NIO buffers. You can find tons of examples on Internet to "destroy" direct NIO byte buffers by using their cleaners. However, if LibGDX doesn't create them by using allocateDirect(), it won't work. You will need to treat the viewed buffers differently. If you use a direct NIO buffer after releasing its native memory, you will get an access violation error   Lots of 3D engines and APIs use asFloatBuffer(), you can't retrieve the cleaner so easily in this case, you need to make some supposition on how they are implemented, you have to get the real direct NIO byte buffer contained by this fake float buffer and then you can use the cleaner as usual.

@davedes feel free to make a better suggestion

Edit.: You have to ensure the backend you use (based on JogAmp or on its competitor) do not keep references on deleted buffers (typically after calling glDeleteBuffers) or you may have some big problems.

Hi

I have rarely tested my game under Windows since my switch from JMonkeyEngine 2 to Ardor3D and as it was very slow until I added a performance test, I thought the lack of responsiveness came from the low frame rate. However, it still stutters now on a laptop Packard Bell MH36 under Windows 7 64 bits with Java 1.7. I use the latest aggregated build of JOGL 2.0.2 and NEWT. I notice some lag only under Windows when I use the mouse look even though the frame rate is correct (around 60 FPS). Using a mouse instead of the build-in touchpad doesn't improve the situation. This bug is not reproducible on the same machine under Mageia Linux 2. I thought it came from NEWT, then I modified Jake 2 (Quake 2 Java port) in order to use the same version of JOGL and it worked correctly. When I run my game on an high end desktop computer under Windows 7, it works very well. I assume the problem comes neither from my hardware nor from NEWT but rather from Ardor3D. NEWT uses SetCursorPos under Windows and XWarpPointer under Linux. After some investigations, I have discovered that the method JoglNewtMouseWrapper.mouseMoved(MouseEvent) has a different behaviour under Linux and Windows:
https://github.com/gouessej/Ardor3D/blob/master/ardor3d-jogl/src/main/java/com/ardor3d/input/jogl/JoglNewtMouseWrapper.java#L147

Under Windows (on my laptop), no event is properly ignored, it never goes to the line 170 whereas it does under Linux.

I know that there are more accurate options to handle relative mouse moves under Windows, for example Raw Input API and DirectInput, but it would require a lot of work, I would have to write a separate mouse wrapper based on JInput. Moreover, if it works with Jake 2 without JInput, there is probably something wrong in my code. I plan to use JInput or a similar API later only for controllers. I have tried to fix this bug for about 2 weeks without success, your help would be more than welcome. I know some of you already implemented similar features in other engines (cylab?), I would be glad to see your suggestions. You can test my game here. You can force the mouse pointer to stay visible by modifying this setting in the options. At first, can you tell me whether you reproduce this bug under Windows please? Best regards.

I find Esterel and OCaml very weird, like their creators chose to disturb developers with their syntaxes.

It's not a reason to write approximate things. I give some references in my articles.

IBM draws different conclusions in HPC (IBM engineers conclude Java beats Fortran except in scalability) and I have no trouble believing that smart Java code can blow C++ out of the water in more and more cases.

That's what I meant. It's just a fallback, it isn't intended to provide all features of the shader based pipeline.

I'm not sure a lot of end users would understand that they need a recent Nvidia graphics card with a very reliable and up-to-date proprietary driver to play with a simple 2D shoot'em up... which is a bit the case with WebGL. The problem is similar with 3D engines in Java: if you don't use any fancy effects, the end users who own only laptops with crappy Intel chipsets won't understand why it doesn't work fast enough on their machines and will complain about that. The problems you can face with old hardware from year 2000 is similar to the problems you can face nowadays with an HTC Tattoo with very poor OpenGL performance. I don't expect from JMonkeyEngine 3 the same "lessons" than from the industry. A clone of Quake 2 shouldn't require OpenGL 2.1 whereas Quake 2 supports OpenGL 1.2.

That's why I meant. Some test assets are very beautiful but I wouldn't imagine someone creating a whole game with them.

I agree with that too even though JMonkeyEngine can help a bit.

But JMonkeyEngine doesn't prevent you from doing these low level things anyway.

I remember a company that said it would contribute back its implementation of portal culling for JMonkeyEngine and it has never done it. Something similar happened several years ago in Ardor3D, for the renderer based on JOGL 2.0. I had to write it myself.

This modular shader system seems cool but I think that something higher level could be done (that's in my todo list for JOGL).

JogAmp APIs are not only an alternative when its main competitor doesn't make the job correctly and you still don't see the benefit of using it. You just confirm what I wrote, "my" renderer is seen as a second class citizen but now that Pixelapp uses it, it isn't useless. Thank you for your help. I still think that the main reason the JMonkeyEngine core team dropped JOGL support was the FUD campaign against our APIs. It's really difficult to defend our APIs from defamatory comments and any JOGL renderer becomes a first class citizen only when a customer says "use it or I won't pay for any support contract". That's the same capitalist way of thinking that leads you to surreptitiously encourage planned obsolescence by considering not a lot of people are interested in supporting earlier versions of OpenGL than 2.1. My computer has been bought in 2005, my ecological footprint is lower than the one of a geek who buys a new computer every 6 months.

The last known custom bridges to OpenGL are in the previous major version of Java3D and in JavaFX 3D (same guys, same contestable choices, same design flaws).

I'm not sure we need competition. The diversity can become a problem. Some engines have a very few active contributors. The possibility of forking is interesting when it leads you to explore new ways and to contribute back to the community but when it leads to create very similar technologies with a very few new features or none, it has a name, it's called effort duplication. HTML5 attracts more and more developers. If we want to survive, we'll have to do exactly the opposite of forking... that's what happened for JOGL who was born from the informal "merge" of several existing bindings (Jungle, GL4Java, Magician GL?, ...). Why do I have to port features and bug fixes from JMonkeyEngine to Ardor3D and vice versa? Why do I have do to the same sometimes for Xith3D and Java3D? Why do I have to fix a bug in an example of picking provided with JOGL 2.0 and to post something in this forum as the same mistake has been done in an example using the main competitor of JOGL? Why do the contributors of these bindings have to implement similar features in their native windowing systems whereas we could work together? Yes we need people who know how things work under the hood but we don't need more engines than people to use them. My engine was almost useless as is, I was aware of that.

Maybe this thread shows you a diversity that you wouldn't have imagined.

What do you mean? I plan to use a quadtree (or a BSP tree) to build a network of cells and portals.

My game is in 3D but as I can't jump, the collisions are handled in 2D.

Avian (+ NEWT). What else? 

Ok. Actually, I would have loved to show you the source code but some people will say that this is a GPL trap and if someone reuses a non trivial part of my code, I will be the bad guy reminding that derivatives must be under GPL too... I can still explain to you what I did:
- I compute the theorical distance between the previous position and the new position (like there was no collision)
- I compute a step count which depends on the size of the bounding volume and this distance
- I compute a separate step count per dimension (x, z)
- I loop while no collision is found and while my counter is less than the step count
     - I compute the temporary position of the player at this step
     - I look at several candidates around this position by considering the player can modify x and z
     - if there is a collision, I try to do the same but by considering the player can't modify x
     - if there is a collision, I try to do the same but by considering the player can't modify z

In my humble opinion, if you're unable to prove that, don't write than Java is really slower than C/C++/whatever. There is no consensus about that. Doug Lea's (biased?) microbenchmarks and the reactions it caused illustrate what I mean.

They will be garbage collected if and if only you run out of memory on the Java heap whereas they allocate memory on the native heap. If you run out of native memory, your game will simply stop working which is worse than some stutters  . You say in your article that we need to be more careful with direct NIO buffers but you miss the main point. Reusing direct NIO buffers is a good idea but it is not enough and it is not always possible. Several JMonkeyEngine and Ardor3D users already ran out of native memory. However, I have to admit that explaining how to handle direct NIO buffers is not easy. I would advise to avoid unnecessary duplication of data (not only in this kind of object) including mesh data (you already wrote that), use slicing when it is possible, favor indirect NIO buffers when direct NIO buffers are not absolutely necessary (for example when they are not used for OpenGL) and to free the native memory they use when you're sure of what you're doing. My last suggestion is very important especially if your game doesn't use a lot of memory on the Java heap.

Hi

Sorry to refresh this thread. I started to use Netbeans RCP at work a few days ago and I still don't like Netbeans. Therefore, I will try to use Eclipse but cylab is right about the pitfalls and the respect of conventions. I don't succeed in getting rid of layer.xml :s

Which drivers? Proprietary or free open source ones? Don't mix up everything. The last version of Windows having a better support of OpenGL than GNU Linux was Microsoft Windows 98. After that, OpenGL was known to be faster and more reliable under GNU Linux in general.

Hi

I used software rendering at the very beginning of my project in 2006. The engine I used was called d3caster, it uses a very basic raycasting algorithm. There are more efficient solutions even in this field, 3DzzD is very fast and supports both hardware and software rendering. However, I agree with kappa. You can get a decent frame rate even on low end machines if and only if you use very simple meshes. Todays CPUs move the limits further but when you use Java, some operations are already hardware accelerated "under the hood" and your rendering will always be noticeably slower on the CPU anyway.

I have used JOGL for several years, it contains some nice renderer quirks to work around some very famous driver bugs which drives it safer than home made OpenGL plain C/C++ code except if you are a specialist of drivers :s The very first version of my game only has 2D ennemies in a flat 3D level, a bit like Wolfenstein and hardware acceleration gave me a huge boost, the game was initially unplayable in full screen mode, it was so slow, I got only one frame every 2 seconds with software rendering 

Use software rendering only if you don't aim low end CPUs or if your graphics are extremely rudimentary but I don't see the point except that you don't need to sign your application.

Hi

Normen should be able to answer you:
http://jmonkeyengine.org/forum/topic/alpha-ios-deployment-available-in-sdk-please-test/

NEWT and JavaFX already support touch screens, MT4J has become less interesting...

Really? Can you give me an example please?