I'm trying to design a side scroller for android and a level editor for windows. A lot of the code between the two programs will be the same. The bit I'm currently working on is drawing textures.
What I currently have is a library that includes code related to loading and drawing the texture information. The bit that I'm stuck on is how would I incorporate OpenGL (for windows) and OpenGL ES (for android) into the library?
I thought about having an interface that includes all the drawing functions and then implementing that interface separately within each program (since one will use OpenGL and one OpenGL ES) but that still produces a lot of duplicated code (and kinda defeats the purpose of trying to create this shared library).
Is there a better way to approach this problem? Am I just over complicating this by trying to make it too flexible? I have been thinking about this for a few sdays now, so any input would be greatly appreciated!
Please ask if anything doesn't make sense!
OpenGL and OpenGL-ES are similar enough, that you can share large amounts of the codebase. Since you're probably going to target OpenGL-ES-2, you will then probably use OpenGL-3 on the desktop. OpenGL-3 has a lot of what OpenGL-ES-2 has. So I suggest you develop your code primarily for OpenGL-ES-2 and then only for the small differences toward OpenGL-3 you add alternative codepaths.
Related
I'm a student in computer engineering and I am working on a game engine and small game to be built on top of it. As we add more and more to the project, it gets clearer that we are not going to be able to render everything that we'd like using just the CPS. Some faster CPU's like my desktop can handle the game rendering, but laptops are getting quite slow.
As of right now, I have been only using the Java.Awt graphics class to accomplish rendering. I have also been optimizing what needs to be rendered and have tried to make it so that only things that the user can see is actually rendered. Unfortunately, my efforts have not made a large enough impact which points me down the road of using a graphics based library.
I had already tried using OpenGL, but the language is so primitive that it is very hard to understand and due to my lack of understanding is not really moving forward much. If anyone has another library that could utilize the graphics card more effectively without such a steep learning curve, I would love to hear about it and where I could learn more.
Note: The entire engine has been built from the ground up and is not built on any libraries at this moment.
Swing might work. You can import it using import javax.swing.*;
Pretty sure you use it by extending JFrame and JPanel. Or I might just be thinking about AWT. Hope this helps!
EDIT: Extending JFrame and JPanel IS Swing. Look at the first example in this site for help.
I've noticed that using the Java libraries that are default built in, rendering the simplest graphics absolutely kills the FPS, and furthermore, looks ugly.
Now I was wondering if I could use JOGL or LWJGL libraries to use in my pre-existing program. (I'm making a game which renders cubes as planets, and you have to build planets.) Do I need to completely rewrite my code? Or can I just install these and render freely? And which one of the above is easier to understand, because I have limited knowledge in these libraries.
Btw, right now, I am using JFrames, does that need to go as well?
Also, what is OpenGL, is that good to use as well without rewriting code?
OpenGL is a standardized graphics interface for use between programs and your graphics card. A proprietary version of this by Microsoft is known as DirectX. LWJGL and JOGL are two different Java bindings to OpenGL libraries, both of which have native code they load in.
LWJGL is much more aimed towards gaming with OpenGL, where as JOGL is more worried about complete and perfect bindings to OpenGL/OpenCL. I would recommend LWJGL if you're just getting started.
You're going to have to rewrite your rendering code, yes. But assuming you designed your project well, you shouldn't need to rewrite the game logic. JFrames will probably also have to go, but I'm not completely sure about that.
Please don't turn this question into another "JOGL vs LWJGL" thread. Moreover, JOGL is used in several games including Poxnora and Salem (MMO). You'll have to learn OpenGL if you want to use any Java binding of this API anyway.
Finally, you can use GLG2D in order to get a better hardware acceleration with plain Swing, it would allow you to benefit of better performance only with a very few changes in your program. GLG2D relies on JOGL 2, you can find more information about it here: http://brandonborkholder.github.io/glg2d/
I plan to build a game for mobile. My target platforms are iOS and Android. I hope to be able to carry out testing on windows and/or linux. I'm a bit over my head in this as aside from general game development experience, all the technologies are fairly new to me. I've done a decent amount of research and have concluded that the game should be written in/ported to C++ to ensure that most of my engine can be easily ported to multiple devices.
Another thing I'd prefer is to write the game initially in java and port to C++ since that's where I'm most comfortable and will get it done the fastest.
Now I have the issue of choosing whether to use a game engine such as cocos2d-x, or to write the engine from scratch and use OpenGL ES 2.0 for rendering. Initially I thought it would be better to use cocos2d-x since I don't have a lot of experience with OpenGL. My problem with using cocos2d-x, however, is that since I want to write the game initially in java, that I'm going to have a hard time porting the engine to conform to cocos2d-x (or I'd have to learn all about the cocos2d-x engine to begin with and then write my engine to mimic the cocos2d-x engine.. seems redundant).
Upon further consideration, I thought that writing my own engine using OpenGL would actually be the better option. I'm able to use the PowerVR SDK along with JOGL to emulate a GLES environment. Also it seemed nice since I would be able to allow GL to do most of the work for me in terms of collision detection and transformations. My only issue with this is that since the game is going to have multiplayer support as well, the GL collision detection and such is basically moot since I'm going to have to do collision checking server side anyway to prevent the game from being easily hacked. Of course for the single player game play this method is viable.
Obviously this decision is subjective and depends on my personal preference, though I hope to have given enough background for some more experienced persons to lend their opinions.
That being said, my question is: given these parameters - would it be better for me to use cocos2d-x and suffer the head trauma of building the game from the ground up in C++, or would it be better to write my own engine initially in java and struggle through the OpenGL aspect of it?
Building your own engine from scratch would be too much of a work and would attract lot's of bugs to creep into. The tried and tested engines are better choice in my view. The porting would be far more easier to do, since you would be having a working game.
I am using Marmalade engine currently and I am quite happy with it's performance. It gives you direct access to the OpenGL libraries, although I've never tried it. You should give it a try too, although it's not free, but the 90 days evaluation license is free to check it out.
I've decided to write it from the ground up in c++ using cocos2d-x. It hasn't been as bad as I expected.
I've worked my way through the tutorial series of jme and feel like I've understood the basics. Now I would like to create a first very simple game. Nothing fancy just a simple test scenario: The player should be able to move an object. Then I would like to expand it. However I don't know how to start. It's hard to explain but I just don't know where to put my code. The manual says that there are "controls" (implemented as interfaces) that let you hook your code up to frequent update calls or other events (that's what I understood) but I can't grasp how to use them.
More detailed description. You could skip this:
To get the point clear - I'm coming from the engine Unity3d. The usage was quite pleasant, the community helpful and the documentation great. But you have to spend about 1000$ to get the full version and be allowed to use pro features (shadows, custom shaders, some advanced tools,...). After a while the temptation of open-source was simply to big. In unity3d you basically have an advanced 3d editor and a scene graph. You can place objects in the scene and access and modify them over the scene graph. You can use predefined objects such as lights or particle systems and change them to suit your needs but most things you use are custom made and puzzled together by different components: a mesh, a collider, a few scripts. And this is where your code comes to work. In unity3d your program is split into small scripts and these are added to the objects of each scene. The scripts have access to the underlying engine, the properties of their object and can use a special framework for math, networking,... Each script can also define functions to be called in certain events: update(), onCollisionEnter(Collider other), onTriggerEnter(Collision other), ...
This was extremely easy to use. Admittedly huge architectures can be difficult to implement but this setback was complemented by very high productivity.
Frankly: I need advice how to structure a simple game with JME.
What architecture do you recommend ?
How are controls used ?
I would appreciate a link to a tutorial (I already read the flagrush series) or any other resource.
Thank you for your help
I'm not sure how well you read the tutorials but they quite literally explain the things you asked for.
Anyway, you code everything so you don't add an object and put code in it you instance an object trough code.
Input is handled by the InputManager, as long as you still use SimpleApplication as foundation you don't have to think about it and use it the way you learned in this tutorial
I've made my share of 2D games on various platforms but I have never developed a 3D game.
I want to make a small "mmorpg". I already made my server in python and it works just fine with my flash 2D game but I decided I want to step it up and try out 3D. I want to make a 3D game for the web browser and I think Java might be a good choice for this.
So basically I'm just looking for a straight forward and well documents 'framework' to make LOW-END 3D games. Keep in mind that I will be targeting peoples with very low-end PC's (plus my 3d modeling skills aren't great so I wouldn't mind hiding it somewhat, haha)
If you care to develop your own software 3D engine, which is pretty cool, Developing Games in Java is a complete walkthrough, step-by-step, of developing a 3D engine in pure Java, capable of rendering textured and lit polygons. You learn a lot about the math involved and you realize that it's really not a terribly hard thing to do; in addition, the engine is all yours, so you know it inside and out and you don't have to learn an API. On the flipside, it might be outdated. It's been sitting on my shelf for a number of years now, but it is made with Java 1.4 so it's not all too old.
Otherwise, I would definitely recommend JOGL or its competitor LWJGL; however, both require OpenGL knowledge, so if you want to just deal with loading 3D models and moving them around, jMonkeyEngine could be a better option for you. There is also the lesser-known Xith3D engine, somewhat a competitor to jME, though it hasn't been updated in over a year.
P.S. Ever seen RuneScape? It used JOGL, though now I think they switched to their own port of only the OpenGL functions that their code uses, kind of like a stripped-down version of JOGL.
JOGL would be a good possibility. You could look at the older "Java3D" framework as well.
You might want to check out the jMonkeyEngine.
I would advise against Java3D. We're using it for a project and frequently run into gotchas. If we had the resources, I'd migrate to something else in a second.