When can I expect a stable release with these new features?  I'm wondering because I'm worried about releasing code that relies on a beta version of the API. 

Quote from: EgonOlsen on March 24, 2012, 11:33:08 PM
I've updated the beta jar...FrameBuffer now has a resize(width, height)-method. It works when using OpenGL only and is silently ignored when using the software renderer. Please give it a try: http://jpct.de/download/beta/jpct.jar

Works brilliantly.  For anybody trying to get this to work, here's how to do it. 

After you create the buffer and enable OpenGL rendering, add this line of code:
Display.setResizable(true);
make sure you have org.lwjgl.opengl.Display imported. 

Then, in your frame loop, before you start the world rendering process, add the following code:
if (Display.wasResized()) {
buffer.resize(Display.getWidth(), Display.getHeight());
}

Thanks, that works perfectly.  I was confused at first, but I figured out that 1 meant 2x, 2 meant 4x, and so on.  That could have been clearer, but it still works out.  It would be nice to have a method to tell how much the specific system can support, but I can see if that's unavailable. 

You seem to be the only person keeping this forum alive, and I would like to thank you for all the questions you have answered.  You have helped a lot getting my game started. 

Quote from: AGP on March 24, 2012, 02:57:26 AM
I would think destroying the Display (if possible) and just re-creating the FrameBuffer would do it. But you can't do it while the user is dragging window's edges (you could do it as I suggested: set the new size and then try that). But I really don't see the usefulness of doing it in the same program instance. Restarting is fine.

I did some testing with this.  I tried disposing the OpenGL Render, making a new FrameBuffer, and reenabling it, and it seems to have only one flaw: when this happens, it tries to reconstruct the screen and will throw an "Unsupported Size" error, as it will look for a display mode.  Support for changing the display size will require an update to the FrameBuffer class that makes sure it doesn't try to reconstruct the Display and just changes the buffer size for the render. 

EDIT: Mr. jPCT Developer Dude (Sorry, I don't know your name ), if it would be something that would interest you, I think I figured out what would need to be added to make window resizing easily done.  With a few lines before the world rendering (probably activated by a new function) and the game code calling Display.setResizable(boolean resizable) would do it, but it would require access to private and protected fields in the FrameBuffer. 

Ok, I found Config.glTrilinear, which allows me to use trilinear filtering, and Texture.setGLFiltering() and Texture.setMipMap(), which allows me to use Pick Nearest Filtering (although I hope I never have to use them) (Unrelated, but is there a way to change the default values of these two?).  With my game, I'm wondering if I can get Anisotropic Filtering.  Is this supported?  If yes, how?  If no, is it a planned feature?

Quote from: TimmerCA on March 23, 2012, 03:14:52 AM

Quote from: AGP on March 23, 2012, 02:46:18 AM
Usually I make my programs read a configuration file which either specifies a resolution (which the user can change) or has something like fullscreen=true and getCurrentResolution in place of the numerical values, which initializes the app in fullscreen and with the current resolution. If you notice, most games tell you after you change their resolution that in order to see the change you'll have to restart the game. So just do that.

I have the following code in my game loop:

Code Select Expand

if (Display.wasResized()) {
  GL11.glViewport(0, 0, Display.getWidth(), Display.getHeight());
  scene.resize();
  gui.resize();
}

Why wouldn't this port over to jPCT well?

Maybe you can.  I'm still getting used to jPCT, but, obviously, calls can be made directly to LWJGL if necessary, however, I foresee two problems: 1) there has to be a config somewhere in LWJGL that makes the display adjustable.  Without it, the handles for resizing won't appear.  2) Since jPCT uses it's own class for rendering (FrameBufferer), it would also have to be reconfigured to work.  I believe both of these are achievable but I don't know how of the top of my head. 

Good Luck if you try it. 

Quote from: EgonOlsen on March 18, 2012, 08:24:41 AM
You'll run into the same issues with hardware rendering as long as you are using anything but pick nearest filtering (which looks ugly).

*googles 'pick nearest filtering'* oh, so like minecraft rendering .  Just out of curiosity, how would i tell jPCT to use that?

EDIT: Found it .  Texture.setFiltering(boolean filter);  Feels kind of weird, though, having trilinear filtering set in another place...

Quote from: EgonOlsen on March 18, 2012, 08:24:41 AM
I would go for separate textures instead.

1) can I do this with software render, or should I just go over to OpenGL, which I will probably do inevitably?

EDIT: Forget the software render.  It's ugly and I would have needed to ditched it before any sort of release anyways.  I have already converted to full OpenGL

2) how exactly do I go about multi-texturing?  Do I need to make multiple Object3D instances to get it to work??

EDIT: I figured it out .  Now I feel stupid.  Now it looks a little weird without anti-aliasing, but whatever.

Quote from: Hrolf on March 18, 2012, 04:02:18 AM
Texture bleed. The best answer I've found is to tweak the uv coords from say 0,0 - 0.5,0.5 to 0.05,0.05 - 0.495,0.495 - not so pretty.

Yeah, and from what I tried, not even a full solution

Quote from: Hrolf on March 18, 2012, 04:02:18 AMUnless memory or latency are really important issues it would be much better to simply use one texture per surface.

although memory and latency are not issues *yet*, I had thought (from what research I tried to do) that using multiple textures on a 3D model was a pain, especially using software render.  I don't really know why I'm using a software render and would probably switch over to OpenGL if I had a reason to...

Quote from: Hrolf on March 18, 2012, 03:19:29 AM
...

That was an excellent idea Hrolf, thanks, but it only confused me at first.  When I isolated a single wall, weird things started to happen.  Wondering what could be causing such strange actions, I went ahead and looked in the launcher class, and found the problem.  I accidentally left in the line room.setEnvmapped(Object3D.ENVMAP_ENABLED);
and that was screwing it up .  Thanks though to everybody that has helped. 

I still have one more problem, however it's kind of minor.  Because the textures are right next to each other in the image file, sometimes little seams appear where one texture tries to grab a column or row from the next texture.  Is there an easy way to prevent that without clipping the texture I'm trying to place?

Screenshots:
Shot 1
Shot 2

Quote from: EgonOlsen on March 17, 2012, 09:51:33 PM
I can't try the code right now...do you have a screen shot that actually shows this in a clearer way!? I've no idea what i'm looking at nor how it is supposed to look.

This is actually quite hard to explain what's going on.  The room is a cube, but viewed from the inside.  It appears that the texture is centering on one wall, warping around the other walls, and converging again on the other side.  It's really hard to explain exactly what's happening because I'm not sure entirely what the problem is. 
To see what it's suppose to look like, the walls.png shows the three textures. The dark green/brown one should span the bottom face of the cube, the light face covers the upper face, and the texture on the upper-right of the image file spans the remaining four sides. 

Hope this clarifies somewhat.

Quote from: Marlon on March 17, 2012, 08:45:37 PM
Keep in mind that the resolution of the texture should be a power of 2.
E.g:
64X64, 128x128,256x256 or 512x512

The image is 256x256, so that can't be the problem...

Ok, I tried doing that, and I'm getting a weird outcome.  I have no clue what's going on, so I've uploaded the files to see if anybody else can figure it out before me.  Please tell me what's wrong

EDIT: Where is the origin in the image? Upper-Left?

<Links removed because the files are no longer hosted>

Ok, I have a basic understanding of how uv-coordinates work to put an image on a 3D object, but I don't get how jPCT is using it, or with what unit's it does it. 

Specifically, this is what I'm trying to do: I have a texture file which is 256 pixels square.  The image is designed as four 128 pixel square textures (but put in the same image file so I can load it all at once).  In order of first left to right, then up to down, the textures are the floor, all four walls (they share one texture), and the ceiling.  The fourth sub-image is blank and currently holds my secrets to world domination, but it shouldn't be shown in the cube at all. 

How might I go about setting up the uv-coordinates to get this to work?

Quote from: EgonOlsen on March 15, 2012, 12:18:59 AMWhy not simply transfer the rotation matrix?

That makes sense.  Now I just need to serialize it...

Quote from: EgonOlsen on March 15, 2012, 12:18:59 AMThere is no matching between a unit in world space and in the real world. You should use a reasonable value though, like 10 units=1 meter or similar.

I had a feeling that there was no universal unit for this, but with the standard FOV of 1.25, 10 seems quite close.  Is there a standard at all between FOV and distance when it comes to making things look like it's normal sized?  Should the player's hit box be at least 1 in front of the player to prevent the clipping that I saw in the code I provided? This is my first experience with 3d game development, so I don't really understand how the units will inevitably add up. 

Quote from: kburden000 on March 14, 2012, 06:46:34 AMThat means your turning it about your neck, not about your body.

Oh .  That makes a lot more sense.  Thank you very much!

Quote from: EgonOlsen on March 14, 2012, 09:17:44 AMThis is caused by the clipping on the view plane. You are very close to that triangle and the triangle is very small.

I didn't think that would have been so much of an issue, but the code you provided fixed the problem, so it had to be the issue.  Thanks. 

Now I have two more, somewhat related questions that have popped up through working this out.

1) I want keep track of the current angle, not the change in angle needed to rotate.  This is because along with wanting to be able to ask jPCT if I have a ray-colision for when the weapon gets fired, I also need to be able to communicate to a server where my player is, both in place and in rotation, so that it can verify my hits.  I can keep track of both a delta and a total, but I'm worried that there might be a bug, the numbers go out of sync, and I can't get the numbers back into place.  Is there a way to SET the pitch/yaw angle?

EDIT: Ok, I went ahead and looked at the javadocs and (yes) the JD-GUI of the Matrix class to see if I can understand what's going on, and WOW THAT'S COMPLICATED!  I might need to look into it deeper if I plan on understanding what the heck is going on there and how I can utilize it to set pitch and yaw values...

2) I had thought that 1 in the word object would represent something like 1 foot, but obviously it's a lot closer than that.  About how big of a box would I need to make a 10 foot (3 meter) cube room? (I do realize that I would need to first invert() the box)