www.jpct.net
jPCT - a 3d engine for Java => Support => Topic started by: TimmerCA on March 22, 2012, 03:14:42 am
-
I see where I can make my jPCT game full-screen:
Config.glFullscreen = true;
But where can I make the window resizable?
-
You can't. It might be possible when using the AWTGLRenderer and disposing/recreating the FrameBuffer on each change, but i don't recommend to do this.
-
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.
-
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.
In pure LWJGL, I can easily do this, and since jPCT is based on LWJGL, I thought it should be possible here. I have the following code in my game loop:
if (Display.wasResized()) {
GL11.glViewport(0, 0, Display.getWidth(), Display.getHeight());
scene.resize();
gui.resize();
}
Where scene is a custom object I've created that holds all my game objects, and gui is a TWL GUI Widget that contains all my 2D game controls. Why wouldn't this port over to jPCT well?
-
I didn't completely get what your scene variable is, but you have to use the FrameBuffer. You don't reference LWJGL directly when using jPCT (other than writing a hardware game loop like while !Display.isCloseRequested()). And my suggestion was that you don't change the resolution while your app is running. You could change the setting, but the change only takes place the next time you run it.
-
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:
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.
-
obviously, calls can be made directly to LWJGL if necessary
This:
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
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 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 :P), 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.
-
Albeit i don't really feel the need for this feature, i'll look into it tomorrow.
-
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 (http://jpct.de/download/beta/jpct.jar)
-
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 (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());
}
-
It works when using OpenGL only and is silently ignored when using the software renderer.
Egon, this isn't necessarily about this one thing (I don't really care about this one), but PLEASE don't leave the software renderer behind. It's really, really, useful. I know you've said in the past that you no longer care about it, but I, and no doubt lots of people, do.
-
No, don't worry...i won't leave it behind. It's just that with the software renderer, you can simply create a new FrameBuffer instead.
-
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.
-
It's no problem. I'll release this version when i find the time. It's a pretty stable beta.