My first post to this board, but some of you might recognize me from my posts on the javagaming and lwjgl boards.
I’m basically working on a game that has elements similar to FF Tactics and some from Diablo. The game has reached the point where simple random levels are created and a single main character can be moved around the map. I have some basic weather effects with a particle system (eg, rain). The levels are fairly big, so I have an auto map feature and the map opens up as you walk around. The camera view is isometric. I have bump mapping implemented with vetex and fragment programs. Lighting is centered around the character (as if he’s holdign a torch or so forth.) Finally, I’ve also implemented a simple menu system with spgl and spaghetti.
My map is drawn using cubes for the wall segments and quads at floor height for the floors. I use interleaved arrays to quickly throw these up on the screen and have thus kept the frame rate fairly high (without the bump mapping on, it’s about 500FPS)
That said, and having gone this far, I’ve begun to reach a point where maintaining all of this data without a scenegraph and so forth is getting unwieldy… So I’m investigating switching over to using something like jME. I need pointers!!
A few questions:
Mojo mentioned I would need to make an Isometric input controller and mentioned that this would maintain the camera position. Am I correct in assuming then that the input controllers tie key and mouse input to camera workings?
I want to rewrite my level data structure. Currently I use a 2d array of tile objects (the game started out in life as a java awt tile based game…) that have a height value. I looked at bsp trees and such and it seems like my viewing angle doesn’t translate well… Any suggestions? Or maybe you could prompt me for specific info that would help you in giving suggestions.
My character is currently a timebased animated billboard. I would entertain using 3d character models but don’t have the talent or know anyone with such talent… so, I am using 2d animations. Is that possible in jME? Suggestions on doing it my way or on replacing with another way?
How advanced is the GUI code? spaghetti is nice in that you can specify images for fonts and button backgrounds, etc. Also, it has checkboxes, textfields and selection lists. In the gui screenshots for jME the buttons are not all that "pretty" Options?
Finally, I’d rather have the choosing of graphics mode happen in the game (at least after the first run.) I notice on the jnlp particle example, it asks you to verify the settings in a dialog before every run. Is that necessary?
Thank you for reading this long long post. I hope I can be a contributing factor in the future of this project.
Secondly, it sounds like you have quite a bit of cool features working already. For instance, while bump mapping and shader programs are on the list to do, they are not currently available. Meaning, I can’t say when they will be available. So, you’ll be losing a bit of wow factor there. Unless of course you’d like to help contribute
There is a base class InputAction, this handles a single action (key pressed, mouse moved, etc). These are added to an InputController object, any number. So, a collection of actions added to a controller makes a specific controller. In the case of the FirstPersonController, WASD keys move a camera forward, backward, strafe left/right. While the mouse controls the look. But not all input actions have to work on a controller, they can do whatever you specify in their performAction method.
jME’s planned level support is: heightfield based terrain with CLOD. This is actually next on the todo list after LOD. After terrain we plan on supporting BSP and portals. In your case, because you are high above the level, there will be very little occulsion culling, and primarily frustum culling. So, perhaps a level should consist of a series of TriMeshes that are connected spatially. This will allow the scenegraph to cull quickly.
Part of the things to do for LOD is Imposters. Imposters will basically be 2D billboards. We could create a controller that animates the texture on the billboard.
I’ll let Gregg handle that.
Yes, you have three options: Never show display selection, always show, only show if the properties file is not present.
The feature set I have now was fun to put together, but unsustainable without a good deal of refactoring… work that would probably duplicate what is available here. Thus my desire to check jME out.
How does contribution work? I’d be happy to work on various parts of jME, but I’m concerned that what I built would only be useful to me without enough design forethought (something I am good at for customer projects, but is a bit daunting for a general purpose project such as this.)
Makes sense. If I built one for Isometric and just mapped the arrow keys (or WASD) to panning the camera (which would be preset in the proper position and attitude) would that be a good start to such a controller?
I’ve yet to use meshes. Suggestions on a doc or tutorial to brush up with?
Sounds interesting. I suppose the character quad would be a node in the scene? (Sorry, still coming up to speed on scenes and node and such.)
Cool… Can you specify where the properties come from? Say you wanted to use java1.4’s ability to store in the registry?
Basically, yes, that will work. You’ll have to properly rotate the camera to face down, and adjust the forward movement of the camera so it only moves in the x/z plane so it doesn’t “fly” towards the ground when you move forward. In other words, you need to define forward as something different than the camera’s direction. This is a lot easier than it sounds. We can cover that when you reach that point.
Hmmmm, well, unfortunately, I haven’t written anything on TriMeshes. I can explain them fairly quickly though, especially, since you said you used interleaved arrays before. Basically, a base TriMesh contains: vertices, normals, colors, texture coordinates and indices. Vertices hold Vector3fs for each vertex that makes up a model (wall, bush, orc, etc), normals Vector3f holds the normals of each vertex, Color (ColorRGBA) holds the color value of each vertex, texture coordinates (Vector2f) holds the texture coordinate for each vertex. So, as you can imagine each array (vertex, color, normal, texture) should be the same size and each entry should correspond to each other. Then the indices array is an int array. It can be any size, but typically a multiple of three. Here you define each triangle. Let’s say we have a rectangle, so vertices has four entries. You indices array might be something like: {0,1,2,1,2,3}. Color, normals and texture coordinates are optional. This is then passed to the renderer (automatically) and rendered as vertex pointers, normal pointers, etc.
Yes, you might have a scene like this:
root
/
room1 room2
/
man chair orc
so if the camera only sees room1, room2's geometry will not be passed to the video card, nor will the orc since it is in the room AND the big benefit comes from the orc doesn't even have to be checked, because we KNOW any child of room2 can't be seen.
5. Right now properties is just a text file that is read by the Properties class of java. However, we could enhance it to make use of some newer features. Eric, you might want to chime in on this.
As far as contributing work... I figure if you do something for your game, say add bump mapping, and see how it could be generalized to allow bump mapping for any TriMesh, then that could work for any app written in jME. If you decide to contribute it, just show it to us, we sign off on it, you become a developer and get CVS access, and commit it.
Regarding the properties, I was first thinking of allowing the user to specify the file where the settings are stored. This would allow a bit more flexibility for users. And it’d make it easier for both game properties and jME properties to coexist in the same file. As for storing settings in the registry, I’m not quite sure where that functionality exits in 1.4! Would you mind pointing me in the right direction? I’ll certainly consider implementing it, as long as it’s cross-platform.
As for using shaders, I’ve already given some thought to their possible implementation in jME. I’ve just finished Webstart-ing our demos, so I could make it my next project, or you could do it yourself if you’d like. Either way, my email is ericthered’at’dev’java’net if you want to discuss it further.
As for storing settings in the registry, I'm not quite sure where that functionality exits in 1.4! :P Would you mind pointing me in the right direction? I'll certainly consider implementing it, as long as it's cross-platform.
Check out java.util.prefs.Preferences It is platform independent... On Windows, it will store it in the registry, on Linux, a flat file, etc...
As for shaders, I'm sure it will take me at least a good month or more to get back to the point where I'm reimplementing shaders. (I wish this was my full time gig...) So, nothing from me on that for the meantime.
It’s certainly possible to have more than one font/font file, I’ve just had problems getting reasonable quality from other fonts.
Anyway, I haven’t found a font solution that I’m satisfied with. One approach might be to write a native interface to the FreeType (http://www.freetype.org/) font system that works with the rendering system, LWJGL (or JOGL if it comes to life again).
Whatever we do, a flexible, quality font system is a signifcant undertaking. I’ll probably take on the task, I just don’t know when that will be.
The font solution Cas uses in spgl could be worth using if we can get some permission from him (or whoever he got it from if that’s the case). I’ve had some success with that.
I did the work with spaghetti and jME 0.1 back in October. I’ll email you my demo which is on the web site front page. I’m afraid I can’t remember what I did.
As Mark suggests go to puppygame.net forum & spgl bit - look for naj’s postings. I remember following the instructions princec gave naj & had no problems.
Anyway I’ll send you the files & you can see if they help. I just need to find it next.
Part of the spgl package is a tools section that contains the class FontConverter. You run it from the command line (although I recall a poster on the puppy forum who said they had built a simple gui for this.)
Check out this posting for getting spgl to work… (read the whole thing as he forgets a few things in his first explanation)
Options?
Would you mind pointing me in the right direction? I’ll certainly consider implementing it, as long as it’s cross-platform.