[java] Java3D vs. GL4Java
Sounds like you are not using Sun''s JDK1.4. The java.nio packages that your VM can''t find were introduced in JDK1.4. Try writing ''java -version'' to see the version of your runtime environment.
Now with 1.4 got another error, a BIG ONE this time:
D:\Work\Terrain>java -cp demo.jar demo.client.Demo
GL: Loading native library...
DLL process attach
GL: Loaded native library. Initialising...
GL: initialised.
Creating display: size 640x480x32...
Pixel format is 3
Created display
DLL thread attach
Powersolve OpenGL interface v2.0
Available extensions:
GL_ARB_multitexture GL_ARB_texture_border_clamp GL_ARB_texture_compression GL_AR
B_texture_cube_map GL_ARB_texture_env_add GL_ARB_texture_env_combine GL_ARB_text
ure_env_crossbar GL_ARB_texture_env_dot3 GL_ARB_transpose_matrix GL_ARB_vertex_b
lend GL_ARB_window_pos GL_S3_s3tc GL_ATI_envmap_bumpmap GL_ATI_map_object_buffer
GL_ATI_texture_mirror_once GL_ATI_vertex_array_object GL_ATI_vertex_streams GL_
ATIX_texture_env_combine3 GL_ATIX_texture_env_route GL_ATIX_vertex_shader_output
_point_size GL_EXT_abgr GL_EXT_bgra GL_EXT_clip_volume_hint GL_EXT_compiled_vert
ex_array GL_EXT_draw_range_elements GL_EXT_fog_coord GL_EXT_packed_pixels GL_EXT
_point_parameters GL_EXT_rescale_normal GL_EXT_secondary_color GL_EXT_separate_s
pecular_color GL_EXT_stencil_wrap GL_EXT_texgen_reflection GL_EXT_texture_env_ad
d GL_EXT_texture3D GL_EXT_texture_compression_s3tc GL_EXT_texture_cube_map GL_EX
T_texture_edge_clamp GL_EXT_texture_env_combine GL_EXT_texture_env_dot3 GL_EXT_t
exture_lod_bias GL_EXT_texture_filter_anisotropic GL_EXT_texture_object GL_EXT_v
ertex_array GL_KTX_buffer_region GL_NV_texgen_reflection GL_NV_blend_square GL_S
GI_texture_edge_clamp GL_SGIS_texture_border_clamp GL_SGIS_texture_lod GL_SGIS_g
enerate_mipmap GL_SGIS_multitexture GL_WIN_swap_hint WGL_EXT_extensions_string W
GL_EXT_swap_control
ARB Multitexture: 1
ARB Texture cube map: 1
Failed to get pointer to GL_EXT_blend_color
EXT Blend color: 0
Failed to get pointer to GL_EXT_blend_minmax
EXT Blend minmax: 0
EXT Compiled vertex arrays: 1
EXT Fog coord: 1
Failed to get pointer to GL_EXT_paletted_texture
EXT Paletted texture: 0
EXT Point paramters: 1
EXT Texture env dot3: 1
EXT Secondary color: 1
Failed to get pointer to GL_EXT_vertex_weighting
EXT vertex weighting: 0
Failed to get pointer to GL_NV_register_combiners
NV Register combiners: 0
WGL_EXT_swap_control_available: 1
Failed to get pointer to GL_NV_vertex_array_range
NV_vertex_array: 0
Failed to get pointer to GL_NV_fence
NV_fence_available: 0
Failed to get pointer to GL_EXT_multi_draw_arrays
EXT_multi_draw_arrays_available: 0
An unexpected exception has been detected in native code outside the VM.
Unexpected Signal : EXCEPTION_ACCESS_VIOLATION occurred at PC=0x0
Function=[Unknown.]
Library=(N/A)
NOTE: We are unable to locate the function name symbol for the error
just occurred. Please refer to release documentation for possible
reason and solutions.
Current Java thread:
at com.powersolve.opengl.GL.wglAllocateMemoryNV(Native Method)
at com.powersolve.jglib.AGPMemory.reserve(AGPMemory.java:101)
at com.powersolve.opengl.GLClient.run(GLClient.java:104)
at demo.client.Demo.main(Demo.java:275)
Dynamic libraries:
0x00400000 - 0x00406000 C:\WINNT\system32\java.exe
0x77F80000 - 0x77FFB000 C:\WINNT\System32\ntdll.dll
0x77DB0000 - 0x77E0C000 C:\WINNT\system32\ADVAPI32.dll
0x77E80000 - 0x77F35000 C:\WINNT\system32\KERNEL32.DLL
0x77D40000 - 0x77DAD000 C:\WINNT\system32\RPCRT4.DLL
0x78000000 - 0x78046000 C:\WINNT\system32\MSVCRT.dll
0x6D330000 - 0x6D442000 D:\Java\j2re\bin\client\jvm.dll
0x77E10000 - 0x77E74000 C:\WINNT\system32\USER32.dll
0x77F40000 - 0x77F7C000 C:\WINNT\system32\GDI32.DLL
0x77570000 - 0x775A0000 C:\WINNT\system32\WINMM.dll
0x6D1D0000 - 0x6D1D7000 D:\Java\j2re\bin\hpi.dll
0x6D300000 - 0x6D30D000 D:\Java\j2re\bin\verify.dll
0x6D210000 - 0x6D228000 D:\Java\j2re\bin\java.dll
0x6D320000 - 0x6D32D000 D:\Java\j2re\bin\zip.dll
0x10000000 - 0x10023000 D:\Work\Terrain\jglib.dll
0x5F580000 - 0x5F620000 C:\WINNT\system32\DINPUT.dll
0x69510000 - 0x695D7000 C:\WINNT\system32\OPENGL32.dll
0x6FAC0000 - 0x6FADF000 C:\WINNT\system32\GLU32.dll
0x51000000 - 0x5104B000 C:\WINNT\system32\DDRAW.dll
0x728A0000 - 0x728A6000 C:\WINNT\system32\DCIMAN32.dll
0x0CE80000 - 0x0CE8B000 D:\PROGRA~1\Grisoft\AVG6\avgoerun.dll
0x69000000 - 0x6927E000 C:\WINNT\system32\atioglxx.dll
0x6F9A0000 - 0x6F9A8000 C:\WINNT\system32\HID.DLL
0x77880000 - 0x7790D000 C:\WINNT\system32\SETUPAPI.DLL
0x77C10000 - 0x77C6E000 C:\WINNT\system32\USERENV.DLL
0x716F0000 - 0x7177A000 C:\WINNT\system32\COMCTL32.dll
0x77920000 - 0x77943000 C:\WINNT\system32\imagehlp.dll
0x72A00000 - 0x72A2D000 C:\WINNT\system32\DBGHELP.dll
0x0BB20000 - 0x0BB2B000 C:\WINNT\system32\PSAPI.DLL
Local Time = Wed Aug 28 21:18:50 2002
Elapsed Time = 1
#
# The exception above was detected in native code outside the VM
#
# Java VM: Java HotSpot(TM) Client VM (1.4.0-b92 mixed mode)
#
# An error report file has been saved as hs_err_pid2316.log.
# Please refer to the file for further information.
#
DLL process detach
Destroying display...
****************
Another exception has been detected while we were handling last error.
Dumping information about last error:
ERROR REPORT FILE = hs_err_pid2316.log
PC = 0x00000000
SIGNAL = -1073741819
FUNCTION NAME = (N/A)
OFFSET = 0xFFFFFFFF
LIBRARY NAME = (N/A)
Please check ERROR REPORT FILE for further information, if there is any.
Good bye.
D:\Work\Terrain>
D:\Work\Terrain>java -cp demo.jar demo.client.Demo
GL: Loading native library...
DLL process attach
GL: Loaded native library. Initialising...
GL: initialised.
Creating display: size 640x480x32...
Pixel format is 3
Created display
DLL thread attach
Powersolve OpenGL interface v2.0
Available extensions:
GL_ARB_multitexture GL_ARB_texture_border_clamp GL_ARB_texture_compression GL_AR
B_texture_cube_map GL_ARB_texture_env_add GL_ARB_texture_env_combine GL_ARB_text
ure_env_crossbar GL_ARB_texture_env_dot3 GL_ARB_transpose_matrix GL_ARB_vertex_b
lend GL_ARB_window_pos GL_S3_s3tc GL_ATI_envmap_bumpmap GL_ATI_map_object_buffer
GL_ATI_texture_mirror_once GL_ATI_vertex_array_object GL_ATI_vertex_streams GL_
ATIX_texture_env_combine3 GL_ATIX_texture_env_route GL_ATIX_vertex_shader_output
_point_size GL_EXT_abgr GL_EXT_bgra GL_EXT_clip_volume_hint GL_EXT_compiled_vert
ex_array GL_EXT_draw_range_elements GL_EXT_fog_coord GL_EXT_packed_pixels GL_EXT
_point_parameters GL_EXT_rescale_normal GL_EXT_secondary_color GL_EXT_separate_s
pecular_color GL_EXT_stencil_wrap GL_EXT_texgen_reflection GL_EXT_texture_env_ad
d GL_EXT_texture3D GL_EXT_texture_compression_s3tc GL_EXT_texture_cube_map GL_EX
T_texture_edge_clamp GL_EXT_texture_env_combine GL_EXT_texture_env_dot3 GL_EXT_t
exture_lod_bias GL_EXT_texture_filter_anisotropic GL_EXT_texture_object GL_EXT_v
ertex_array GL_KTX_buffer_region GL_NV_texgen_reflection GL_NV_blend_square GL_S
GI_texture_edge_clamp GL_SGIS_texture_border_clamp GL_SGIS_texture_lod GL_SGIS_g
enerate_mipmap GL_SGIS_multitexture GL_WIN_swap_hint WGL_EXT_extensions_string W
GL_EXT_swap_control
ARB Multitexture: 1
ARB Texture cube map: 1
Failed to get pointer to GL_EXT_blend_color
EXT Blend color: 0
Failed to get pointer to GL_EXT_blend_minmax
EXT Blend minmax: 0
EXT Compiled vertex arrays: 1
EXT Fog coord: 1
Failed to get pointer to GL_EXT_paletted_texture
EXT Paletted texture: 0
EXT Point paramters: 1
EXT Texture env dot3: 1
EXT Secondary color: 1
Failed to get pointer to GL_EXT_vertex_weighting
EXT vertex weighting: 0
Failed to get pointer to GL_NV_register_combiners
NV Register combiners: 0
WGL_EXT_swap_control_available: 1
Failed to get pointer to GL_NV_vertex_array_range
NV_vertex_array: 0
Failed to get pointer to GL_NV_fence
NV_fence_available: 0
Failed to get pointer to GL_EXT_multi_draw_arrays
EXT_multi_draw_arrays_available: 0
An unexpected exception has been detected in native code outside the VM.
Unexpected Signal : EXCEPTION_ACCESS_VIOLATION occurred at PC=0x0
Function=[Unknown.]
Library=(N/A)
NOTE: We are unable to locate the function name symbol for the error
just occurred. Please refer to release documentation for possible
reason and solutions.
Current Java thread:
at com.powersolve.opengl.GL.wglAllocateMemoryNV(Native Method)
at com.powersolve.jglib.AGPMemory.reserve(AGPMemory.java:101)
at com.powersolve.opengl.GLClient.run(GLClient.java:104)
at demo.client.Demo.main(Demo.java:275)
Dynamic libraries:
0x00400000 - 0x00406000 C:\WINNT\system32\java.exe
0x77F80000 - 0x77FFB000 C:\WINNT\System32\ntdll.dll
0x77DB0000 - 0x77E0C000 C:\WINNT\system32\ADVAPI32.dll
0x77E80000 - 0x77F35000 C:\WINNT\system32\KERNEL32.DLL
0x77D40000 - 0x77DAD000 C:\WINNT\system32\RPCRT4.DLL
0x78000000 - 0x78046000 C:\WINNT\system32\MSVCRT.dll
0x6D330000 - 0x6D442000 D:\Java\j2re\bin\client\jvm.dll
0x77E10000 - 0x77E74000 C:\WINNT\system32\USER32.dll
0x77F40000 - 0x77F7C000 C:\WINNT\system32\GDI32.DLL
0x77570000 - 0x775A0000 C:\WINNT\system32\WINMM.dll
0x6D1D0000 - 0x6D1D7000 D:\Java\j2re\bin\hpi.dll
0x6D300000 - 0x6D30D000 D:\Java\j2re\bin\verify.dll
0x6D210000 - 0x6D228000 D:\Java\j2re\bin\java.dll
0x6D320000 - 0x6D32D000 D:\Java\j2re\bin\zip.dll
0x10000000 - 0x10023000 D:\Work\Terrain\jglib.dll
0x5F580000 - 0x5F620000 C:\WINNT\system32\DINPUT.dll
0x69510000 - 0x695D7000 C:\WINNT\system32\OPENGL32.dll
0x6FAC0000 - 0x6FADF000 C:\WINNT\system32\GLU32.dll
0x51000000 - 0x5104B000 C:\WINNT\system32\DDRAW.dll
0x728A0000 - 0x728A6000 C:\WINNT\system32\DCIMAN32.dll
0x0CE80000 - 0x0CE8B000 D:\PROGRA~1\Grisoft\AVG6\avgoerun.dll
0x69000000 - 0x6927E000 C:\WINNT\system32\atioglxx.dll
0x6F9A0000 - 0x6F9A8000 C:\WINNT\system32\HID.DLL
0x77880000 - 0x7790D000 C:\WINNT\system32\SETUPAPI.DLL
0x77C10000 - 0x77C6E000 C:\WINNT\system32\USERENV.DLL
0x716F0000 - 0x7177A000 C:\WINNT\system32\COMCTL32.dll
0x77920000 - 0x77943000 C:\WINNT\system32\imagehlp.dll
0x72A00000 - 0x72A2D000 C:\WINNT\system32\DBGHELP.dll
0x0BB20000 - 0x0BB2B000 C:\WINNT\system32\PSAPI.DLL
Local Time = Wed Aug 28 21:18:50 2002
Elapsed Time = 1
#
# The exception above was detected in native code outside the VM
#
# Java VM: Java HotSpot(TM) Client VM (1.4.0-b92 mixed mode)
#
# An error report file has been saved as hs_err_pid2316.log.
# Please refer to the file for further information.
#
DLL process detach
Destroying display...
****************
Another exception has been detected while we were handling last error.
Dumping information about last error:
ERROR REPORT FILE = hs_err_pid2316.log
PC = 0x00000000
SIGNAL = -1073741819
FUNCTION NAME = (N/A)
OFFSET = 0xFFFFFFFF
LIBRARY NAME = (N/A)
Please check ERROR REPORT FILE for further information, if there is any.
Good bye.
D:\Work\Terrain>
Er, um, whoops yes, sorry, in the long lost archaic readme that used to accompany the demo (got lost when JGO put it up on their site) it mentioned that it was for Nvidia cards only... (you'll notice it says it can't find a bunch of things in that printout, and I, er, well, ignore that fact and carry on regardless).
I haven't got an ATI dev machine to hand right now and I'm busy writing a game so no plans to make it work just yet. Maybe when all this pixel shader stuff comes to GL2.0 I'll port it.
Cas
[edited by - princec on September 1, 2002 2:14:02 PM]
I haven't got an ATI dev machine to hand right now and I'm busy writing a game so no plans to make it work just yet. Maybe when all this pixel shader stuff comes to GL2.0 I'll port it.
Cas
[edited by - princec on September 1, 2002 2:14:02 PM]
Okay, I''m not trying to start a war or flame anyone here, but all these kinds of issues are why I ended up switching away from Java game programming. Granted, I was only trying to do a 2D side-scrolling game, but there were enough issues to turn me off.
I started reading through this thread because I like keeping up with the current state of Java game programming (2D and 3D) and see what things come along. When I started my Java game, I liked the fact that it would run on many systems, run in a browser, and is in general a nice and clean language. I wasn''t so concerned with blazing speed, since it was just a 2D game. But once I started coding it, I came across more and more issues that just frustrated me. First was the system resource problem (granted, my machine at the time was only a 366 MHz and 128Meg RAM). I was getting decent framerates, but you could not have anything else running, since the game and JRE were taking up all the resources.
Once I got some sprites flying around, I found that I had compatibility problems with the browser plug-ins for 1.2 and 1.3. It annoyed me that I felt that I had to jump through hoops to get things working. And if I got one browser working, it wouldn''t work in another. And I new this was a potential frustration point for my game players. And most of the game tutorials I''ve read are for C or C++, and so I had to come up with equivalents in Java.
Once I got a little demo finished, I informed the world, and asked for feedback. I gave the option to download a zip with or without the JRE included. Pretty much the only responses I got were about how it was too big a download for a little game, compatibility issues, and from those few who actually took the time to download it and get it running, that it took everything their system had just to run it. I don''t know what people believe, but the Java JRE is by no means widespread on the average joe''s computer. So this is a reality you will have to deal with when distributing your game.
I reached a point where I asked myself why I was I programming my game in Java in the first place? I started out that way because I was learning Java in school and liked it. I liked the thought of having my game running on many platforms. It was a good way to learn different aspects of Java. And all of these are good reasons IMHO. But after a while I realized that there were going to be compatibility issues on different OS''s and browsers. Getting people to get a big download was going to be hard. And there were other issues that made me look at why Java was my language choice. A lot of the "solutions" seemed like hacks. In the end, I decided to take the plunge and move my game to DirectX and C++. At first this was intimidating, since I didn''t know anything about DirectX, and was still learning C++ (although I did know C). But as it turned out, it was a worthwhile switch for me. My game is well on it''s way, and I have learned a ton (thanks in no small part to gamedev.net). I don''t feel like I''m making any sacrifices (which I sometimes felt with Java), and I''ve gotten to a point where I am programming game logic faster than I originally thought I would when I switched.
Granted, most of my Java experience was a little while ago (1.3), and I''m sure things have improved. I don''t mean to knock Java, because I like it a lot, and it has many powerful features. So while have I popped into this thread and rambled on like this? Well, reading some of these posts brings back many of the feelings I had when I was programming games in Java. Compatibility problems and trade-offs and things of that sort. When I read about using GNI to access a DirectX or OpenGL engine, I ask myself, why aren''t they just using C++ or something and use them directly? What do you gain by using Java and GNI? I really don''t know the answer because I haven''t used, and know little about, GNI. I could be wrong, but aren''t you going to lose the cross-platform advantage of Java by doing it this way? Like I''ve said, I''m using DirectX, and it has run with no problems on all my friends'' machines. I found this kind of ironic, since my DirectX/C++ game had much less distribution and compatibility problems than my Java games. I guess it just strikes a cord when I read about people who are having the same kind of problems and issues I had.
My only advice (which I know you didn''t ask for) would be that make sure that you have some good reasons (and there are) to use Java to solve the problems you are having. As yourself if it is easier than using the engines, resources, or whatever in the manner they were originally designed for. You might save yourself some headaches and disappointments in the long run.
Sorry for this lengthy post.
Cheers.
I started reading through this thread because I like keeping up with the current state of Java game programming (2D and 3D) and see what things come along. When I started my Java game, I liked the fact that it would run on many systems, run in a browser, and is in general a nice and clean language. I wasn''t so concerned with blazing speed, since it was just a 2D game. But once I started coding it, I came across more and more issues that just frustrated me. First was the system resource problem (granted, my machine at the time was only a 366 MHz and 128Meg RAM). I was getting decent framerates, but you could not have anything else running, since the game and JRE were taking up all the resources.
Once I got some sprites flying around, I found that I had compatibility problems with the browser plug-ins for 1.2 and 1.3. It annoyed me that I felt that I had to jump through hoops to get things working. And if I got one browser working, it wouldn''t work in another. And I new this was a potential frustration point for my game players. And most of the game tutorials I''ve read are for C or C++, and so I had to come up with equivalents in Java.
Once I got a little demo finished, I informed the world, and asked for feedback. I gave the option to download a zip with or without the JRE included. Pretty much the only responses I got were about how it was too big a download for a little game, compatibility issues, and from those few who actually took the time to download it and get it running, that it took everything their system had just to run it. I don''t know what people believe, but the Java JRE is by no means widespread on the average joe''s computer. So this is a reality you will have to deal with when distributing your game.
I reached a point where I asked myself why I was I programming my game in Java in the first place? I started out that way because I was learning Java in school and liked it. I liked the thought of having my game running on many platforms. It was a good way to learn different aspects of Java. And all of these are good reasons IMHO. But after a while I realized that there were going to be compatibility issues on different OS''s and browsers. Getting people to get a big download was going to be hard. And there were other issues that made me look at why Java was my language choice. A lot of the "solutions" seemed like hacks. In the end, I decided to take the plunge and move my game to DirectX and C++. At first this was intimidating, since I didn''t know anything about DirectX, and was still learning C++ (although I did know C). But as it turned out, it was a worthwhile switch for me. My game is well on it''s way, and I have learned a ton (thanks in no small part to gamedev.net). I don''t feel like I''m making any sacrifices (which I sometimes felt with Java), and I''ve gotten to a point where I am programming game logic faster than I originally thought I would when I switched.
Granted, most of my Java experience was a little while ago (1.3), and I''m sure things have improved. I don''t mean to knock Java, because I like it a lot, and it has many powerful features. So while have I popped into this thread and rambled on like this? Well, reading some of these posts brings back many of the feelings I had when I was programming games in Java. Compatibility problems and trade-offs and things of that sort. When I read about using GNI to access a DirectX or OpenGL engine, I ask myself, why aren''t they just using C++ or something and use them directly? What do you gain by using Java and GNI? I really don''t know the answer because I haven''t used, and know little about, GNI. I could be wrong, but aren''t you going to lose the cross-platform advantage of Java by doing it this way? Like I''ve said, I''m using DirectX, and it has run with no problems on all my friends'' machines. I found this kind of ironic, since my DirectX/C++ game had much less distribution and compatibility problems than my Java games. I guess it just strikes a cord when I read about people who are having the same kind of problems and issues I had.
My only advice (which I know you didn''t ask for) would be that make sure that you have some good reasons (and there are) to use Java to solve the problems you are having. As yourself if it is easier than using the engines, resources, or whatever in the manner they were originally designed for. You might save yourself some headaches and disappointments in the long run.
Sorry for this lengthy post.
Cheers.
quote:I guess it just strikes a cord when I read about people who are having the same kind of problems and issues I had.
You need to remember that Cas''s terrain engine is an experimental hack, tailored for one specific graphics chip manufacturer. It should not be used in mainstream products and its problems have nothing to do with general Java compatability or even compatability in mainstream libraries such as GL4Java.
quote:When I read about using GNI to access a DirectX or OpenGL engine, I ask myself, why aren''t they just using C++ or something and use them directly?
If only tiny parts of your application, such as calls to graphics APIs, require native code, then it makes sense to use JNI for just those calls and keep all the benefits from Java for the rest of your application. That is especially true if you are using a library such as GL4Java where someone else has already wrapped all the native calls inside Java methods, letting you develop your application completely in Java. I guess it is similar to how C++ programmers occasionally use assembly language in their applications but do not switch completely from C++ to assembly.
quote:I could be wrong, but aren''t you going to lose the cross-platform advantage of Java by doing it this way?
That depends on how many platforms that the native library is implemented on. The GL4Java library is available on PC, Mac, Linux and Solaris, so you do not really lose the cross-platform advantage unless you plan on porting your application to other platforms than those. Even then it is much quicker to just port a small native library rather than your whole application.
Primus, I couldn''t give 2 poos about Java cross-platform capability As it is you more or less have to write to specific cards anyway if you want to do anything clever.
No, I just use Java because once you know the (few, but crucial) hoops that you have to jump through, it''s just loads bloody easier than arsing around debugging C++ code.
I fully intend to compile my Java games down to Win32 .exes anyway because of the ridiculously large runtime download requirement. And you can''t really do serious games programming with Java out-of-the-box because it''s... well, shite. That''s why we''ve gone and made the Lightweight Java Game Library which just gives Java direct access to graphics, sound, and input hardware. And it''s really working a treat right now! I keep reading forum messages about how to achieve smooth animation or reasonable performance or scrolling without juddering and the plain truth of it is, you can''t really do it in Java, because you need to get closer to the metal. Hence LWJGL, which does exactly what it says on the tin.
I reckon you might enjoy having another go at it. We''d be grateful if you had a quick go with LWJGL and let us know your thoughts. I must say that because it''s a reasonably pure and simple wrapper round the native stuff that it really needs you to write a nice layer over the top of it to make it even easier - like a sprite lib or something. Which is just what I''ve done for my game
Cas
As it is you more or less have to write to specific cards anyway if you want to do anything clever.No, I just use Java because once you know the (few, but crucial) hoops that you have to jump through, it''s just loads bloody easier than arsing around debugging C++ code.
I fully intend to compile my Java games down to Win32 .exes anyway because of the ridiculously large runtime download requirement. And you can''t really do serious games programming with Java out-of-the-box because it''s... well, shite. That''s why we''ve gone and made the Lightweight Java Game Library which just gives Java direct access to graphics, sound, and input hardware. And it''s really working a treat right now! I keep reading forum messages about how to achieve smooth animation or reasonable performance or scrolling without juddering and the plain truth of it is, you can''t really do it in Java, because you need to get closer to the metal. Hence LWJGL, which does exactly what it says on the tin.
I reckon you might enjoy having another go at it. We''d be grateful if you had a quick go with LWJGL and let us know your thoughts. I must say that because it''s a reasonably pure and simple wrapper round the native stuff that it really needs you to write a nice layer over the top of it to make it even easier - like a sprite lib or something. Which is just what I''ve done for my game
Cas
People who are considering Java game development might also want to look out for the public specification of the Java Game Profile that should be released around this month I think.
Your Lightweight Java Game Library sounds quite cool. I''d like to get around to trying it out before too long. But where is the time to do all these things I want to do? And your C++ debugging point is well taken.
And your C++ debugging point is well taken.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement