beowulf03809
|
 |
«
Posted
2005-08-29 02:01:35 » |
|
Greetings, all. I've been out of circulation for several months but am trying to get going again here. I have worked thru a few of the tutorials ( need to revist a few though ) and am ready to start a basic game that I hope to build up in layers until it's something interresting. I've been a Linux advocate for many years and live as much of my e-life as possible behind X. However, I know M$ will continue to have the dominant share of target audiences for years to come. SO...I really want to be able to support both ( Mac support would be good, but not as critical to me at this time...personal reasons  ). I have been trying to catch back up on the last few months of topics here but haven't found much meat on a specific issue that's outstanding in my planning right now. Basically, if I want to support Linux & Windows in full screen mode ( with safe Alt-tab to other apps and back ), is either JOGL or LWJGL a better choice considering both OS targets? The game itself is a mostly-strategic game along the lines of Master of Orion, etc. As such it is pretty much "flat" screens and I'm not trying to push pixles to their limits. I do hope to use a 3d space map with the ability to zoom in and out, but that's not in the first-phase of release. It is starting off as two player + computer AI but I hope to expand it to up to a larger human player base in the mid-development time frame ( continued to be turn-based though with each player submitting thier turn's orders to the server for processing and results sent back ). Likewise, I may want to expand the game to have a semi-3d space combat ( ships generally stay flat but player can swing the camera around and perform some zooming ) but again that's candy that's going to wait until I have a functional and fun game ( and may depend heavily on how I want multi-players to interract ). I know this is a touchy subject that can easily kick off religious wars and I don't want to go down that route. It's just that right now I'm leaning to JOGL since I've had a little more reading experience with it and am "getting it" a little better right now, but if one is seriuosly better than the other for technical reasons I would appreciate the heads-up before I invest too much time. advTHANKSance!  -Lawrence
|
|
|
|
Jeff
|
 |
«
Reply #1 - Posted
2005-08-29 04:01:55 » |
|
I think both support Linux as a first class platform. If you use JOGL you'll also want to use JInput and JOAL. All support WIndows, Linux and Mac  If you use LWJGL I believe it has its own input and audio API, and it supports all 3 paltforms, so either way your covered.
|
|
|
|
Matzon
|
 |
«
Reply #2 - Posted
2005-08-29 06:02:31 » |
|
What Jeff said. However there is one technical reason - which may or may not be relevant for you - Jogl cannot do proper fullscreen on Linux, and (though not entirely sure about that) it cant do it completely reliable on Windows either. But if you're doing Windowed mode, that isn't an issue.
|
|
|
|
Games published by our own members! Check 'em out!
|
|
beowulf03809
|
 |
«
Reply #3 - Posted
2005-08-29 09:24:52 » |
|
Thanks for the pointers. "True" full screen on Linux may be an issue later, so I'll have to do some early tests to see what I can do with an undecorated window. Depending on how well I can keep that reflecting the theme of the game it may make my decision for me. At least now I have a better direction to focus the little bit of free time I have.  -Lawrence
|
|
|
|
erikd
|
 |
«
Reply #4 - Posted
2005-08-29 09:46:07 » |
|
May I ask what your reasons are not to support Mac as of yet? I found that it was basically effortless to get my emulator working on Mac using LWJGL. Chances are that if you include the mac binaries, it will 'just work'.
|
|
|
|
princec
|
 |
«
Reply #5 - Posted
2005-08-30 15:37:51 » |
|
Yep, it will just work.. I've never even seen Ultratron running on a Mac! I'd use whichever API suits your coding style better as they are functionally identical. LWJGL in most cases simplifies things for the common case of writing games though. Cas 
|
|
|
|
beowulf03809
|
 |
«
Reply #6 - Posted
2005-08-30 19:26:08 » |
|
I'm actually not planning on "excluding" Mac, but I just don't have access or any experience with them ( since Apple days ). Since this is just hobby level for me for a while at least I plan on getting things the way I want on the platforms I can personally test. Once I pull in external testers I'll try to find people w/ Mac to participate but it would really be based on who helps out and what kind of problems turn up. Sorry...didn't mean to give the impression I'm anti-Mac. I USED to be in the 80s, but those days are long gone.  -L
|
|
|
|
Jeff
|
 |
«
Reply #7 - Posted
2005-08-31 18:02:59 » |
|
Hmm.
Im not sure how much difference there is in fullscreen, honestly.
If you tell Java to create a FullScreen undecorated window it will look exactly the same as any other full screen display and I don't believe there is any performance penalty.
I've done this with Java3D, though not with JOGL, for JNWN at times and its been just fine.
JK
|
|
|
|
elias
|
 |
«
Reply #8 - Posted
2005-08-31 19:31:42 » |
|
Hmm.
Im not sure how much difference there is in fullscreen, honestly.
If you tell Java to create a FullScreen undecorated window it will look exactly the same as any other full screen display and I don't believe there is any performance penalty.
I've done this with Java3D, though not with JOGL, for JNWN at times and its been just fine.
JK
Yes, but will it actually _switch_ modes? AFAIK, java fullscreen support is limited to the current display mode, which is likely to be higher than what you want (if you have a resource-hungry game, you'd like to run it at 800x600 or 1024x768 on mediocre machines). Note: I'm aware of the fact that java 6 has fixed this issue, but then we can take the details; like the fact that LWJGL can alt-tab out of fullscreen modes on supported window managers, while the java implementation can't. - elias
|
|
|
|
Jeff
|
 |
«
Reply #9 - Posted
2005-08-31 20:33:25 » |
|
Hmm.
Im not sure how much difference there is in fullscreen, honestly.
If you tell Java to create a FullScreen undecorated window it will look exactly the same as any other full screen display and I don't believe there is any performance penalty.
I've done this with Java3D, though not with JOGL, for JNWN at times and its been just fine.
JK
Yes, but will it actually _switch_ modes? AFAIK, java fullscreen support is limited to the current display mode, Totally false. You can use the DeviceContext to chnage display modes at will. See this tutorial by Mike Martak http://java.sun.com/docs/books/tutorial/extra/fullscreen/
|
|
|
|
Games published by our own members! Check 'em out!
|
|
blahblahblahh
|
 |
«
Reply #10 - Posted
2005-08-31 21:25:32 » |
|
If you tell Java to create a FullScreen undecorated window it will look exactly the same as any other full screen display and I don't believe there is any performance penalty.
Yes, but will it actually _switch_ modes? AFAIK, java fullscreen support is limited to the current display mode, Totally false. I may be missing the point, but it's never looked teh same in linux, and last time I checked, there was no way to change the resolution at all in linux with the JVM (but then, I dont actively use 1.5, so forgive me for foolishness if 1.5 has finally fixed this bug)
|
malloc will be first against the wall when the revolution comes...
|
|
|
Jeff
|
 |
«
Reply #11 - Posted
2005-09-01 04:12:34 » |
|
If you tell Java to create a FullScreen undecorated window it will look exactly the same as any other full screen display and I don't believe there is any performance penalty.
Yes, but will it actually _switch_ modes? AFAIK, java fullscreen support is limited to the current display mode, Totally false. I may be missing the point, but it's never looked teh same in linux, and last time I checked, there was no way to change the resolution at all in linux with the JVM (but then, I dont actively use 1.5, so forgive me for foolishness if 1.5 has finally fixed this bug) The API hooks are certainly there.. Ill go grab one of Mike's old tests and run it on my linux box to see what it does 
|
|
|
|
Jeff
|
 |
«
Reply #12 - Posted
2005-09-01 06:45:20 » |
|
Okay, I decided its abotu time i starte dputting soime simple HUD stuff in JWNW so Im just going to use that as a test base. Im going to try to use Dave Yazel's J3D HUD stuff. It may take me a week or so to put the mode setting dialog in. After ist in il ltest it on Linux and see what it does
|
|
|
|
elias
|
 |
«
Reply #13 - Posted
2005-09-01 07:21:55 » |
|
Hmm.
Im not sure how much difference there is in fullscreen, honestly.
If you tell Java to create a FullScreen undecorated window it will look exactly the same as any other full screen display and I don't believe there is any performance penalty.
I've done this with Java3D, though not with JOGL, for JNWN at times and its been just fine.
JK
Yes, but will it actually _switch_ modes? AFAIK, java fullscreen support is limited to the current display mode, Totally false. You can use the DeviceContext to chnage display modes at will. See this tutorial by Mike Martak http://java.sun.com/docs/books/tutorial/extra/fullscreen/Check your facts: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4661156The API is there alright, but it is reported as not supported (isDisplayChangeSupported() returns false). It is marked as fixed in mustang, as I said. - elias
|
|
|
|
beowulf03809
|
 |
«
Reply #14 - Posted
2005-09-06 01:12:31 » |
|
So from the limited info I've posted about my basic needs it really boils down to LWJGL is the only option for true full-screen-exclusive mode under Linux. With JOGL the best I could do would be a "full-screen" undecorated window which is at the mercy of the user having their display set to the same as my game wants to use. If they are higher or lower then it will not look right and may, in fact, cause problems.
I thought I could live with the JOGL limitation, but the more I'm thinking about it the more I'm afraid to go down that path too far and find that full-screen really is as important to the visual of the game as I think it will be.
Follow-up question: Are there any concerns or gotcha's in LWJGL's behaviour under Linux?
-Lawrence
|
|
|
|
Jeff
|
 |
«
Reply #15 - Posted
2005-09-06 01:34:06 » |
|
So from the limited info I've posted about my basic needs it really boils down to LWJGL is the only option for true full-screen-exclusive mode under Linux. With JOGL the best I could do would be a "full-screen" undecorated window which is at the mercy of the user having their display set to the same as my game wants to use.
Thats falls into the rumor category. I do not believe it is true as the API celarly allows you to chnage mode. I havent had a chance to test it yet but if thats going to be the deciding poitn for you I suggest *you* test it. Write a simple full-screen exclusive mode program that opens a window and tries to chnage the settings. JK
|
|
|
|
Jeff
|
 |
«
Reply #16 - Posted
2005-09-06 01:49:38 » |
|
Okay, because I HATE rumors I did the tests myself on SUSE 1.3. The full screen display mode stuff as near as I can see is total nonsense. JOGL uses AWT. AWT goes fullscreen and sets the display mode just fine. Here's the test code: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242
|
import java.awt.*; import java.awt.event.*; import javax.swing.*; import javax.swing.event.*; import javax.swing.table.*;
class DisplayModeModel extends DefaultTableModel { private DisplayMode[] modes;
public DisplayModeModel(DisplayMode[] modes) { this.modes = modes; }
public DisplayMode getDisplayMode(int r) { return modes[r]; }
public String getColumnName(int c) { return DisplayModeTest.COLUMN_NAMES[c]; }
public int getColumnCount() { return DisplayModeTest.COLUMN_WIDTHS.length; }
public boolean isCellEditable(int r, int c) { return false; }
public int getRowCount() { if (modes == null) { return 0; } return modes.length; }
public Object getValueAt(int rowIndex, int colIndex) { DisplayMode dm = modes[rowIndex]; switch (colIndex) { case DisplayModeTest.INDEX_WIDTH : return Integer.toString(dm.getWidth()); case DisplayModeTest.INDEX_HEIGHT : return Integer.toString(dm.getHeight()); case DisplayModeTest.INDEX_BITDEPTH : { int bitDepth = dm.getBitDepth(); String ret; if (bitDepth == DisplayMode.BIT_DEPTH_MULTI) { ret = "Multi"; } else { ret = Integer.toString(bitDepth); } return ret; } case DisplayModeTest.INDEX_REFRESHRATE : { int refreshRate = dm.getRefreshRate(); String ret; if (refreshRate == DisplayMode.REFRESH_RATE_UNKNOWN) { ret = "Unknown"; } else { ret = Integer.toString(refreshRate); } return ret; } } throw new ArrayIndexOutOfBoundsException("Invalid column value"); }
}
public class DisplayModeTest extends JFrame implements ActionListener, ListSelectionListener {
private boolean waiting = false; private GraphicsDevice device; private DisplayMode originalDM; private JButton exit = new JButton("Exit"); private JButton changeDM = new JButton("Set Display"); private JLabel currentDM = new JLabel(); private JTable dmList = new JTable(); private JScrollPane dmPane = new JScrollPane(dmList); private boolean isFullScreen = false;
public static final int INDEX_WIDTH = 0; public static final int INDEX_HEIGHT = 1; public static final int INDEX_BITDEPTH = 2; public static final int INDEX_REFRESHRATE = 3;
public static final int[] COLUMN_WIDTHS = new int[] { 100, 100, 100, 100 }; public static final String[] COLUMN_NAMES = new String[] { "Width", "Height", "Bit Depth", "Refresh Rate" };
public DisplayModeTest(GraphicsDevice device) { super(device.getDefaultConfiguration()); this.device = device; setTitle("Display Mode Test"); originalDM = device.getDisplayMode(); setDMLabel(originalDM); setDefaultCloseOperation(EXIT_ON_CLOSE); exit.addActionListener(this); changeDM.addActionListener(this); changeDM.setEnabled(device.isDisplayChangeSupported()); }
public void actionPerformed(ActionEvent ev) { Object source = ev.getSource(); if (source == exit) { device.setDisplayMode(originalDM); System.exit(0); } else { int index = dmList.getSelectionModel().getAnchorSelectionIndex(); if (index >= 0) { DisplayModeModel model = (DisplayModeModel)dmList.getModel(); DisplayMode dm = model.getDisplayMode(index); device.setDisplayMode(dm); setDMLabel(dm); setSize(new Dimension(dm.getWidth(), dm.getHeight())); validate(); } } }
public void valueChanged(ListSelectionEvent ev) { changeDM.setEnabled(device.isDisplayChangeSupported()); }
private void initComponents(Container c) { setContentPane(c); c.setLayout(new BorderLayout()); JPanel currentPanel = new JPanel(new FlowLayout(FlowLayout.CENTER)); c.add(currentPanel, BorderLayout.NORTH); JLabel current = new JLabel("Current Display Mode : "); currentPanel.add(current); currentPanel.add(currentDM); JPanel modesPanel = new JPanel(new GridLayout(1, 2)); c.add(modesPanel, BorderLayout.CENTER); for (int i = 0; i < COLUMN_WIDTHS.length; i++) { TableColumn col = new TableColumn(i, COLUMN_WIDTHS[i]); col.setIdentifier(COLUMN_NAMES[i]); col.setHeaderValue(COLUMN_NAMES[i]); dmList.addColumn(col); } dmList.getSelectionModel().setSelectionMode( ListSelectionModel.SINGLE_SELECTION); dmList.getSelectionModel().addListSelectionListener(this); modesPanel.add(dmPane); JPanel controlsPanelA = new JPanel(new BorderLayout()); modesPanel.add(controlsPanelA); JPanel controlsPanelB = new JPanel(new GridLayout(2, 1)); controlsPanelA.add(controlsPanelB, BorderLayout.NORTH); JPanel exitPanel = new JPanel(new FlowLayout(FlowLayout.CENTER)); controlsPanelB.add(exitPanel); exitPanel.add(exit); JPanel changeDMPanel = new JPanel(new FlowLayout(FlowLayout.CENTER)); controlsPanelB.add(changeDMPanel); changeDMPanel.add(changeDM); controlsPanelA.add(new JPanel(), BorderLayout.CENTER); }
public void setVisible(boolean isVis) { super.setVisible(isVis); if (isVis) { dmList.setModel(new DisplayModeModel(device.getDisplayModes())); } }
public void setDMLabel(DisplayMode newMode) { int bitDepth = newMode.getBitDepth(); int refreshRate = newMode.getRefreshRate(); String bd, rr; if (bitDepth == DisplayMode.BIT_DEPTH_MULTI) { bd = "Multi"; } else { bd = Integer.toString(bitDepth); } if (refreshRate == DisplayMode.REFRESH_RATE_UNKNOWN) { rr = "Unknown"; } else { rr = Integer.toString(refreshRate); } currentDM.setText( COLUMN_NAMES[INDEX_WIDTH] + ": " + newMode.getWidth() + " " + COLUMN_NAMES[INDEX_HEIGHT] + ": " + newMode.getHeight() + " " + COLUMN_NAMES[INDEX_BITDEPTH] + ": " + bd + " " + COLUMN_NAMES[INDEX_REFRESHRATE] + ": " + rr ); }
public void begin() { isFullScreen = device.isFullScreenSupported(); setUndecorated(isFullScreen); setResizable(!isFullScreen); if (isFullScreen) { device.setFullScreenWindow(this); validate(); } else { pack(); setVisible(true); } }
public static void main(String[] args) { GraphicsEnvironment env = GraphicsEnvironment. getLocalGraphicsEnvironment(); GraphicsDevice[] devices = env.getScreenDevices(); for (int i = 0; i < 1 ; i++) { DisplayModeTest test = new DisplayModeTest(devices[i]); test.initComponents(test.getContentPane()); test.begin(); } } }
|
I don't believe that LWJGL handles this significantly differently then AWT/JOGL. At the end fo teh day both must go through X to get to OGL.
|
|
|
|
beowulf03809
|
 |
«
Reply #17 - Posted
2005-09-06 01:59:29 » |
|
You are a true prince among coders, Jeff.  Thanks for taking some of your time to help clearing some fud. I'm trying to get my head above water with some work issues right now but will duplicate your test with my own environments as soon as I can. -Lawrence
|
|
|
|
Jeff
|
 |
«
Reply #18 - Posted
2005-09-06 02:06:09 » |
|
Thanks, but the code actually is Mike Martak's, not mine. I started to write a test, went to Mike's excellent tutorial to remind myself of a few things and found it was already written for me in his examples 
|
|
|
|
Jeff
|
 |
«
Reply #19 - Posted
2005-09-06 02:10:52 » |
|
As an interesting side note, this may have bene the start of the rumor, from Mike's comments: 1
| * On UNIX, only a single display mode should be available, |
He was almost certainly referring to Solaris. This has to do with the weird ass way Solaris does X. (On older Solaris boxes, believe it or not, display mode is set per-pixel. This allows cool things like different windows in different modes on the same screen but really complicates the whole issue.)
|
|
|
|
elias
|
 |
«
Reply #20 - Posted
2005-09-06 11:05:08 » |
|
Eh? What am I missing, Jeff? On my SUSE 9.3 laptop with an ATI 9700 gfx card with the ATI drivers installed and with a 1.5.0_03 VM only one display mode is available according to the program you pasted (the current display mode, 1280x800). And the "Set Display" button is grayed out, indicating that isDisplayChangeSupported() returns false, as I said. And this machine does LWJGL display mode switching fine btw (since this is my main development machine).
- elias
|
|
|
|
Jeff
|
 |
«
Reply #21 - Posted
2005-09-07 02:31:18 » |
|
Thats odd.
I have an NVidia chip on my system and I get a full range of mode options.
I dont suppose you have an NVidia system with the same kernel version as your ATI system to compare to?
How recent are your drivers? NVidia has generaly had better OGL drivers then ATI on Linux. (Though why yo ushould get it from lwjgl and not AWT is odd. Id be curious to comapre where theya re getting their infor from... )
|
|
|
|
elias
|
 |
«
Reply #22 - Posted
2005-09-07 06:31:19 » |
|
I tried it on an NVIDIA system with upgraded drivers but the results were the same. LWJGL does switch mode correctly on that system, btw. Are you running a Mustang VM?
Display mode switching has nothing to do with OpenGL, so that's why jogl and lwjgl differ in this aspect. They share the opengl code (GLX interface), but jogl relies on the AWT abilities, while LWJGL implements its own direct interface to the Xlib API+extensions.
- elias
|
|
|
|
Jeff
|
 |
«
Reply #23 - Posted
2005-09-12 07:34:10 » |
|
I tried it on an NVIDIA system with upgraded drivers but the results were the same. LWJGL does switch mode correctly on that system, btw. Are you running a Mustang VM?
Yeah Iam, how about you? Display mode switching has nothing to do with OpenGL, so that's why jogl and lwjgl differ in this aspect. They share the opengl code (GLX interface), but jogl relies on the AWT abilities, while LWJGL implements its own direct interface to the Xlib API+extensions.
- elias
Im wondering if it has to do with display managers. Im running KDE. I can try spinning up gnome and do the same experiment.... JK
|
|
|
|
ryanm
|
 |
«
Reply #24 - Posted
2005-09-12 09:08:46 » |
|
Are you running a Mustang VM? Yeah Iam, how about you? Isn't it more likely to be that then? From earlier in the thread: So, mode switching is unavailable on linux on anything but pre-release JREs?
|
|
|
|
Jeff
|
 |
«
Reply #25 - Posted
2005-09-12 21:53:52 » |
|
Missed the post.
So its a bug. and a bug thats fixed in Mustang.
That solves the question and gives the final answer: If you need it for older VMs, then due to the bug it looks like you need to go around (either with LWJGL's native code or your own.) If you dont need to support older VMs then Mustang is out there now and AFAIHS works fine even if its pre-release. And I woudl guess it will be release by next J1 if not before.
|
|
|
|
elias
|
 |
«
Reply #26 - Posted
2005-09-13 10:28:54 » |
|
But keep in mind that "older" VMs (<= 1.5.0) are the only ones you can distribute to your customers. So unless you're a researcher, Mustang is not an option until it is released (of course, you can develop on mustang and hope it is released when your application is done).
- elias
|
|
|
|
Orangy Tang
|
 |
«
Reply #27 - Posted
2005-09-13 11:39:46 » |
|
If you dont need to support older VMs then Mustang is out there now and AFAIHS works fine even if its pre-release.
Yes, because we all know how good Sun's track record is with new major versions of the VM. 1.5.0 was a particularly sucessful release. 
|
|
|
|
princec
|
 |
«
Reply #28 - Posted
2005-09-13 12:54:09 » |
|
They're not the only ones that cock up... I just for my iMac last night and the Java 5.0 download from Apple is actually corrupted. Anyone know where I can get it from, and why it's not fixed? Cas 
|
|
|
|
beowulf03809
|
 |
«
Reply #29 - Posted
2005-09-13 16:00:14 » |
|
If I'm following this trail correctly, JOGL should be able to handle resolution swapping on Linux as well as it does on Windows if running a 1.5+ JVM, but is crippled on 1.4, correctl? Hmmm....
My only "anti-LWGL" concern is that it is hardware-only rendering. About 75% - 90% of my game is being designed really as just a standard 2D strategy game with only a couple parts that may take advantage of 3D capabilities. I know that most machines in the public hands now do perform accelerated 3D as hardware rendering and that by early next year it will be an even higher percentage, but, for example, the laptop I'm working on now does it's 3D for Linux in software. Since 3D is not even the biggest feature of the game I hate to limit a target audience by requiring that. If this was a fast-paced shooter that's an understandable target, but a trun-based simulation is very different story.
-Lawrence
|
|
|
|
|