1
Support / Re: Make Window Resizable?
« on: March 27, 2012, 05:41:30 pm »
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.
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
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.jarWorks brilliantly. For anybody trying to get this to work, here's how to do it.
Display.setResizable(true);
make sure you have org.lwjgl.opengl.Display imported. if (Display.wasResized()) {
buffer.resize(Display.getWidth(), Display.getHeight());
}
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.
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]if (Display.wasResized()) {
GL11.glViewport(0, 0, Display.getWidth(), Display.getHeight());
scene.resize();
gui.resize();
}
Why wouldn't this port over to jPCT well?
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?
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?
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
Unless 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...
...
room.setEnvmapped(Object3D.ENVMAP_ENABLED);
and that was screwing it up . Thanks though to everybody that has helped. 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.
Keep in mind that the resolution of the texture should be a power of 2.The image is 256x256, so that can't be the problem...
E.g:
64X64, 128x128,256x256 or 512x512
Why not simply transfer the rotation matrix?That makes sense. Now I just need to serialize it...
There 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.
That means your turning it about your neck, not about your body.Oh . That makes a lot more sense. Thank you very much!
This 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.