ArenaWars is a small strategy game for two players playing in a duel. This project started out as a school project. Each player gets to choose his army, and each fighter got it’s own special abilities. You got four different fighters to pick from, the soldier, the archer, the medic and the engineer(wich builds walls by right-clicking). The boards are random generated, and depending on the layout of the board, the different fighters will have different advantages. For instance a wall will let archers shoot the soldies on the other side, while the soldiers would need to brake down the wall.
The game runs through Java Web Start, and uses lwjgl. To play the game, enter the ArenaWars.org website, click play, select the server closest to your location, and then select if you want to play the game with or without audio.
org.lwjgl.opengl.OpenGLException: Invalid value (1281)
at org.lwjgl.opengl.Util.checkGLError(Util.java:54)
at org.lwjgl.opengl.Display.swapBuffers(Display.java:640)
at org.lwjgl.opengl.Display.update(Display.java:660)
at spel.Game.mainLoop(Game.java:677)
at spel.Game.execute(Game.java:602)
at spel.Game.main(Game.java:2257)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.javaws.Launcher.executeApplication(Launcher.java:1188)
at com.sun.javaws.Launcher.executeMainClass(Launcher.java:1134)
at com.sun.javaws.Launcher.doLaunchApp(Launcher.java:983)
at com.sun.javaws.Launcher.run(Launcher.java:121)
at java.lang.Thread.run(Thread.java:619)
What are the minimal requirements? I have an ATI Radeon 9250 Pro only
Also, I had to quit both games I played because of a bug. If the archer stands in a way that it cannot move and cannt shoot (stuck between an enemy and a wall for example) the only thing you can do is quit the game seeing as archers can’t defend and you can’t skip your turn in any other way.
Cero:
I know there is a very similar name, that’s why I said the name was not my decision. Though, the game name is not registered. The other members of the group didn’t manage to google it, and when I finally god to know the porhect had a name, they didn’t want to change it. Anyway, this game is just for fun.
I was called in to put this game together, the concept and design was done by others.
gouessej:
Your OS, your CPU, your amount of ram please.
I know the game has problems on certain Intel GMA-chips, but ATI should work. The requirements are not high, OpenGL 1.1 with updated Java(1.6.0_14). The game is tested on 800x600 -screens and up to 1920x1200, but any other resolution should work.
Back to the problem on your computer: According to the debug information, the game crashes when it tries to swap buffers, so it seems the game fails to initialize double buffering (wich I thought all modern gpus supported). Wich ATI driver do you use?
I use an open source driver and it works fine with a lot of games using OpenGL, it is not a driver bug. You don’t understand how LWJGL reports errors, it performs this task only when swapping buffers, it means than the error might have happened earlier, it will be reported only at this moment, it is more efficient as it avoids to check errors after each OpenGL call but it drives debugging harder. You can activate a property to help debugging in LWJGL but I have forgotten its name, I’m sorry, I usually use JOGL rather than LWJGL :persecutioncomplex: On my view, you try to use an OpenGL enum that is unknown on my graphics card whereas you should check if it is supported before using it. I’m going to test on another machine with an ATI Radeon XPress 200 under Linux too.
OpenGL in Java is a real pain in the ass, I usually do it in languages like C/C++, wich is much simplier.
I haven’t testet the game on the free ATI driver, just the proprietary one, and the game worked well on several computers running GNU/Linux.
The game uses only OpenGL 1.1 calls and enums, except for LWJGL calls.
I’ll look into it.
When creating the window, the game asks LWJGL to ask the drivers if the requested resolution is valid (default is 1280x1024), if not, it will use the desktop resolution. If LWJGL reports that 1280x1024 is a valid resolution on your computer but your actual max. resolution is lower, then there is a bug in either LWGJL or your driver.
You’ll probably have to scatter calls to Util.checkGLError around your gl calls to narrow down which one is failing, which unfortunately can be a pain when you can’t reproduce it yourself.
At a guess some kind of initialisation will be failing and not being caught but instead handed down to opengl. Eg. an image failing to load and resulting in you passing -1 as a width/height to a texture call.
No it is totally wrong on my view, I used C++ with OpenGL in 2006, I was quite good in C/C++ at the university, I was famous thanks to this but some very weird replacements done by the preprocessor broke the game that should have become TUER. When you get only a segmentation fault, it does not help a lot. Debuggers for C/C++ are less easy to use than Eclipse and Netbeans debuggers. C++ allows to do more things but more dangerous things above all. Java allows to write cross-platform applications using OpenGL without using the buggy GLUT, without depending on platform-dependent libraries, it is far better for me and JOGL is particularly robust.
In my humble opinion, your problem would be very easy to solve if you could force LWJGL to check errors for each OpenGL call, maybe princec knows which option to use. I had the same kind of errors when I used JMonkeyEngine 2 for the first time with JOGL, finding a fix required only several minutes. Which version of LWJGL do you use?
once again… could you explain how did you decide to use opengl rather than Java2d or any other stable/compatible existing 2d library (slicks / pulpcore / other ) for this game ? (I was unable to see the game but if it look like the screenshot above you would probably get less trouble using a simple software api)
result for the 2.8MB version (11.5Mb version never finish load) :
3 min to start
monitor make some strange noise on changing resolution… and finally game start minimized
once maximised the intro animation run at 1 frame every two second
the mouse cursor did not move or rather it move every 5 seconds (on the gui screen)
then unable to go farther…
First of all, LWJGL is not very stable. But I tried JOGL at first, texture loading etc. were simple, but making a runnable jar file were difficult.
The problem with Java and OpenGL is the need of additional packages (JOGL, LWJGL, etc.), and problems linking these. I know it is possible to do it in java, but it’s far more effort than doing it in C/C++. In C/C++ you just need to link OpenGL, OpenAL, keyboard events etc. to the running system (Windows, GNU/Linux…) and the remaining code is mostly platform neutral. If you don’t like GLUT (like most of us), you can use the highly usable SDL, wich is very quick.
I do not want to start a “flamewar”, java is ok for simple stuff, but when you need something a little more advanced, it often results in extra efforts (compared to C++). And for a 2.5 week school project with a deadline, there is limited possibilities to test for the best solution. I was basically pulled in to this project without beeing allowed to participate in any of the design and concept details. The team consisted of five students, three artists (one of them a skilled cartoon drawer), another coder and myself. I myself has been using OpenGL in C/C++ and pascal for over 6 years, and has 11 years of programming experience, wich includes java, but not games in java. The other programmer basically worked out the pathfinding, while I got the dirty job of putting the artists’ plans and codebase to something called a “game”, the worst codebase ever. This is what happens when three people wich never has seen a game engine plans their own game. And since they had submitted the plans to the school before I was called in, we needed to follow them.
The designers(artists) of this game think it’s quite fun to play, so I hoped some of you would enjoy it. This is not a serious game, it’s just for fun. But I was considering not to put my name on it, due to the quality (or lack of quality) of the work done. I’m fully aware that this game does not work on all computers, I apologise inconvenience.
If you got an idea how to fix it, feel free to let me know.
By tracing the dump it fails at swapping the buffers, but it might occur earlier. If anyone get the same message with other drivers please let me know (if you want if fixed ).
I’ll try to test the free ATI drivers within the next days, and see if it fails.
BTW: by some quick googling I found others wich got exactly the same message caused by a driver.
The general consensus seems to be that Java is better suited for general programming problems,. Individually it will be affected to a large degree by how well you know each language and the libraries available for it. Java is less suited to low-level programming… with it’s signed bytes and no pointer manipulation tricks. But generally better for everyday object-oriented programming. I suppose it all depends on what you mean by “advanced” - perhaps you mean something like low-level. If by “advanced” you mean more complex algorithms and such, Java is probably the better choice all else being equal. (If you count the quality of the tools, Java is way ahead.)
Anyway… how about including the LWJGL Solaris binaries?
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.javaws.Launcher.executeApplication(Launcher.java:1321)
at com.sun.javaws.Launcher.executeMainClass(Launcher.java:1267)
at com.sun.javaws.Launcher.doLaunchApp(Launcher.java:1066)
at com.sun.javaws.Launcher.run(Launcher.java:116)
at java.lang.Thread.run(Thread.java:619)
Caused by: java.lang.UnsatisfiedLinkError: no lwjgl in java.library.path
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1709)
at java.lang.Runtime.loadLibrary0(Runtime.java:823)
at java.lang.System.loadLibrary(System.java:1030)
at org.lwjgl.Sys$1.run(Sys.java:72)
at java.security.AccessController.doPrivileged(Native Method)
at org.lwjgl.Sys.doLoadLibrary(Sys.java:65)
at org.lwjgl.Sys.loadLibrary(Sys.java:81)
at org.lwjgl.Sys.(Sys.java:98)
at org.lwjgl.opengl.Display.(Display.java:129)
at spel.Game.initialize(Game.java:636)
at spel.Game.execute(Game.java:162)
at spel.Game.main(Game.java:2257)
… 9 more
Sorry, I forgot to add Solaris support. Solaris binaries are now added to the europe primary server. (the US server is maintained by another member, and will be updated within a couple of days)
I don’t use Solaris myself, so it’s not tested. (neither is Mac OS X)
its like jester said OrangeTang said earlier. you need to place Util.checkGLError() calls around your GL functions, in order to determain which openGL is causing the error.
I did not write it :persecutioncomplex: but I agree.
It is not difficult and you use Java Webstart. For each OpenGL binding, you only have to add a single line in the JNLP file to load the JARs and the natives of the library, it is very simple. You only need to make a JAR with the resource of your own application, there is no need of doing a single JAR containing all.
He explained it on the website, you should have read it. OpenGL is quite table in my humble opinion.
Lol it is not a driver bug, it is the excuse that some unfortunate programmers give. Use this to debug (a LWJGL programmer should confirm if it is the good option) :
).