endolf
|
 |
«
Reply #60 - Posted
2003-11-16 20:36:53 » |
|
Me again Having pointed out to me my mistake, I only thought it fair to point out kev's  , he forgot the flag in the jnlp file. It's now back in and working fine. Endolf
|
|
|
|
William Denniss
|
 |
«
Reply #61 - Posted
2003-11-16 21:05:56 » |
|
I know I proposed it a while back and was outvoted, but I still believe that until that issue is fixed in linux, XITH3D_USER_VERTEX_BUFFER_CACHING should be set to false.
People can always turn it on - and it can be overridden in the Java code as well (the developer can query an Option to see if the user wants to override it with the isDefaultSetByProperty method and then decide if they want to honour that or not).
Will.
|
|
|
|
|
Games published by our own members! Check 'em out!
|
|
Jeff
|
 |
«
Reply #63 - Posted
2003-11-29 17:37:42 » |
|
Good news. Old version worked on my OS X tiBook once I got my JDK path problem fixed. Bad news, new version fails to launch  If I can coax an error message out I'll post it.
|
|
|
|
Jens
|
 |
«
Reply #64 - Posted
2003-11-29 19:54:12 » |
|
The game is great.  One good hint: Do not create a usual directory in the home directory of a Linux user. It's better to put a point (".") in front of it to mark it as "hidden" (".MartianMadnessConfig"). Personally I'd delete every program which wants to have its own directory in my $HOME. 
|
|
|
|
kevglass
|
 |
«
Reply #65 - Posted
2003-11-29 20:20:03 » |
|
Bad news, new version fails to launch If I can coax an error message out I'll post it.
That'd be great if you could Jeff, I'm really keen on getting it running on a Mac as it seems like a great market atm. The game is great. One good hint: Do not create a usual directory in the home directory of a Linux user. It's better to put a point (".") in front of it to mark it as "hidden" (".MartianMadnessConfig"). Personally I'd delete every program which wants to have its own directory in my $HOME.
Thanks. Interesting thing about the config directory. In my last game attempt I put a "." infront and some Linux bods complained they didn't like the game creating a directory they didn't see straight away.. I prefer it hidden and was pandering to the masses I suppose. Back in the "." goes  Cheers for checking guys, Kev
|
|
|
|
William Denniss
|
 |
«
Reply #66 - Posted
2003-11-29 21:12:44 » |
|
Definitally have the "."
Almost all linux programs create such a directory in the users home dir - other than that there is no way for them to store settings (unless the user has write access the the programs directory which is unlikely and there is no such thing as a registry - thankfully).
I'm surprised people complained about that actually...
Will.
|
|
|
|
swpalmer
|
 |
«
Reply #67 - Posted
2003-11-30 02:07:55 » |
|
Once again my system works differntly than Jeff's.. go figure. It DID take a long time to show the game screen after the little setup/config thingy. BUT... No controls work on the main game screen. The music is happily playing away, I see a screen, the FPS counter is updating.. but nothing I press does anything.  Oh, and my game pad was not available to select as a controller, so I'm guessing the JInput stuff isn't working on Mac either.
|
|
|
|
swpalmer
|
 |
«
Reply #68 - Posted
2003-11-30 02:30:06 » |
|
Ack, I take it back.. I started it once with webstart, and once from the zip version (I ran update.jar first)...
Now it seems to deadlock after you press "start game"
|
|
|
|
kevglass
|
 |
«
Reply #69 - Posted
2003-11-30 07:44:49 » |
|
Fantastic!!  Ok, the jinput stuff is on windows only atm, but I'm about to change that. However, from a post I see from you in JInput, its unlikely to make any difference  Interesting about the controls, in now creates control configuration files so maybe I need to try wiping mine out and check if that prevents running first time. Incidently, the keyboard input doesn't use JInput so shoud always work. Now, to the dead lock.. Did the menu disappear? If so do you see the level with the alien and his yellow rings around him. If it stops there, could you just try running it again. I had an issue (which I thought I'd resolved) with that particular effect where it can stack overflow. Incidently.. any stack traces from the installable version? Kev PS. Thanks to all for continuing to try this out, real pain not having access to a whole suite of machines 
|
|
|
|
Games published by our own members! Check 'em out!
|
|
swpalmer
|
 |
«
Reply #70 - Posted
2003-11-30 20:06:44 » |
|
Time permitting I'm happy to test anyone's project on my Mac, so long as it isn't too much of a pain to start. Web Start or executable Jars preferred.
When it dead locks the menu does disappear. I couldn't get any stack traces or other useful information.
|
|
|
|
kevglass
|
 |
«
Reply #71 - Posted
2003-12-01 04:26:10 » |
|
If possible could you try turning sound and music off. Maybe they're some conflict with Java Sound on the Mac.
Kev
|
|
|
|
DjaZia
Senior Newbie 
Build once, run everywhere!
|
 |
«
Reply #72 - Posted
2003-12-01 07:02:19 » |
|
Brillant! Nice little game. Well done Kev 
|
DZ Ecrew member
|
|
|
Yuri Vl. Gushchin
Senior Devvie   
Speak Java!
|
 |
«
Reply #73 - Posted
2003-12-01 08:01:56 » |
|
Really nice! Works quite well!
Yuri
|
Yuri Vl. Gushchin JProof Group
|
|
|
swpalmer
|
 |
«
Reply #74 - Posted
2003-12-01 11:16:47 » |
|
Tried again (with no sound)...
After waiting for some time i saw the openGL extensions dump to the console.. and then the game screen appeared. It looked like it was stuck with no response from the keyboard as it was before...
But i left it going for a while this time.. And after lets say about a minute the selection moved down a line.. then a minute later it moved again.. I think at some point in there I actually saw the rings around the alien step to a new position, but I'm not sure.
It appears to be running but EXTREMELY slow. Even though the FPS indicator is updating frequently and shows around 100 fps.
Odd.
|
|
|
|
swpalmer
|
 |
«
Reply #75 - Posted
2003-12-01 11:26:42 » |
|
More info... I can tell when it is about to actually process a keystroke because the FPS indicator stops updating for several seconds... then when the FPS display resumes updating the selection steps to the next choice in the game menu. Earlier times of 1 minute are actually low. it takes a LONG time before a keystroke is recognized. I wonder if something is starving the AWT thread from processing events? Probably not... the process seems to take about 45% of my CPU.
|
|
|
|
kevglass
|
 |
«
Reply #76 - Posted
2003-12-01 11:35:38 » |
|
This is going to get painful, but did you actually get rid the menu and manage to start the game? If not, the rings wouldn't have moved (since the game doesn't start running until the menu disappears). If this is the case it may just be really really slow at updating textures. Could you try just hitting Escape which should remove the menu and allow you to "play" in the startup level. Or hit Enter straight away which shoudl start the game. If so, then hmmmmmmm.. Don't think I added anything significantly new. Did the last version you saw have a the health bar/face/coin counter etc ? When was the last version that worked for you. I'm even more worried that it takes such a long time to start up, its not actually doing much (initialising sound, xith etc..) I'll take a look at that part in more detail. Whats worrying me more is that it could be some oddity with the Apple VM atm and I could spend an age trying to figure it out  Still, atm getting the release to work on Win32, Linux and Mac is my top priority. Cheers for the continued testing, Kev
|
|
|
|
kevglass
|
 |
«
Reply #77 - Posted
2003-12-01 14:58:26 » |
|
I reakon this has something to do with generating the texture for the menu item. Are there any known bugs with buffered image performance on MacOS?
There's a new version posted with a smaller menu, since it was causing problems everywhere.. I've another idea so there may be an even newer version before you get there.
Oh, in addition I've added a bunch of logging as the game initialises. Hopefully this will help working out whats taking all the time. Should dump a log.txt in the config directory each run.
Cheers
Kev
|
|
|
|
kevglass
|
 |
«
Reply #78 - Posted
2003-12-01 15:06:26 » |
|
Okie dokie, yet a newer version. The menu might be quicker this means there might be performance issues the Xith GUI stuff on Mac generally...
Let me know how it goes,
Kev
|
|
|
|
swpalmer
|
 |
«
Reply #79 - Posted
2003-12-01 15:27:41 » |
|
Much better.. New version works normally. Menu speed is fine. However the menu doesn't go away when you start the game.
I completed that level (I think) and ended up sliding forever to the right. with no floor beneath me.
answering some other questions: the last version that worked prior to this did not have the health bar & stats. Mac platform IS sensitive to image format. Always use compatible formats.. other formats may render very slow. (I can't see why it would be so slow as to cause the massive slowdown I was seeing though!)
The log:
Scotts-Laptop:~/Desktop/Games/Java/mm-macos scottpalmer$ java -jar martian.jar 1070302602803 : Starting Martian Madness 1070302602809 : Initialising Keyboard Handler 1070302603767 : Attempting to read configuration from: /Users/scottpalmer/.MartianMadnessConfig/config.props 1070302614386 : Attempting to read configuration from: /Users/scottpalmer/.MartianMadnessConfig/config.props 1070302614409 : Attempting to establish controller 1070302614421 : Using default swing keyboard controller device 1070302614423 : Building rendering window 1070302615137 : Initialising visual frame 1070302616124 : Initialising music system, play? : false 1070302616950 : Initialising sound effects system, on? : false 1070302616962 : Building scoreboard 1070302617457 : Building menu system 1070302623187 : Creating score table class and the game logic 1070302623208 : Starting new level with map: maps/startup 1070302626702 : Starting Xith Renderer Init GL is net.java.games.jogl.impl.macosx.MacOSXGLImpl OpenGL Renderer = ATI Radeon 9000 OpenGL Engine OpenGL Version = 1.3 ATI-1.3.0 OpenGL Vendor = ATI Technologies Inc. OpenGL Extensions = GL_ARB_transpose_matrix GL_ARB_vertex_program GL_ARB_vertex_blend GL_ARB_window_pos GL_EXT_multi_draw_arrays GL_EXT_clip_volume_hint GL_EXT_rescale_normal GL_EXT_draw_range_elements GL_EXT_fog_coord GL_APPLE_client_storage GL_APPLE_specular_vector GL_APPLE_transform_hint GL_APPLE_packed_pixels GL_APPLE_fence GL_APPLE_vertex_array_object GL_APPLE_vertex_program_evaluators GL_APPLE_element_array GL_APPLE_flush_render GL_NV_texgen_reflection GL_NV_light_max_exponent GL_IBM_rasterpos_clip GL_SGIS_generate_mipmap GL_APPLE_texture_range GL_APPLE_vertex_array_range GL_APPLE_ycbcr_422 GL_ARB_imaging GL_ARB_multisample GL_ARB_multitexture GL_ARB_texture_border_clamp GL_ARB_texture_compression GL_ARB_texture_cube_map GL_ARB_texture_env_add GL_ARB_texture_env_combine GL_ARB_texture_env_crossbar GL_ARB_texture_env_dot3 GL_ARB_texture_mirrored_repeat GL_ATI_array_rev_comps_in_4_bytes GL_ATI_blend_equation_separate GL_ATI_blend_weighted_minmax GL_ATI_text_fragment_shader GL_ATI_texture_env_combine3 GL_ATI_texture_mirror_once GL_EXT_abgr GL_EXT_bgra GL_EXT_blend_func_separate GL_EXT_blend_minmax GL_EXT_blend_subtract GL_EXT_blend_color GL_EXT_compiled_vertex_array GL_EXT_secondary_color GL_EXT_stencil_wrap GL_EXT_texture_compression_s3tc GL_EXT_texture_env_add GL_EXT_texture_lod_bias GL_EXT_texture_rectangle GL_EXT_texture_filter_anisotropic GL_NV_blend_square GL_NV_fog_distance GL_SGIS_texture_edge_clamp GL_SGIS_texture_lod 1070302636171 : Starting new level with map: maps/test2 Scotts-Laptop:~/Desktop/Games/Java/mm-macos scottpalmer$
|
|
|
|
endolf
|
 |
«
Reply #80 - Posted
2003-12-01 15:33:29 » |
|
Mac platform IS sensitive to image format. Always use compatible formats.. other formats may render very slow. Hi Can you explain what you mean by compatable formats?, although I don't have a mac or access to one, if this is an issue it's something I want to consider early on. Cheers Endolf
|
|
|
|
kevglass
|
 |
«
Reply #81 - Posted
2003-12-01 15:36:02 » |
|
You're a star!  I've fixed the little menu oddity.. I'd be interested to see if Jeff could run this now. The level isn't finished yet (as you found out) and when you walk somewhere there isn't ground there is no friction to slow you down.. so you just keep on sliding  Anyway.. back to features.. Thanks again for the help, Kev
|
|
|
|
Jens
|
 |
«
Reply #82 - Posted
2003-12-01 15:59:00 » |
|
The fullscreen mode doesn't work for Linux. The app simply exits. For Linux the easy way to do "fullscreen" is to use the screen resolution as canvas size. I hope JRE 1.5 will support fullscreen mode for Linux.
|
|
|
|
kevglass
|
 |
«
Reply #83 - Posted
2003-12-01 16:55:52 » |
|
Yep, I didn't really want to support full screen that way. I guess I was hoping for the LWJGL port of Xith, which should do full screen nicely on Linux.
Kev
|
|
|
|
swpalmer
|
 |
«
Reply #84 - Posted
2003-12-02 01:04:14 » |
|
Can you explain what you mean by compatable formats? The images with the same format as those returned by createCompatibleImage for one. OS X only supports a few different byte packings natively... if you aren't using one off them horrible slow conversions will kill your performance. But more specifically... /me goes hunting for a message from some apple dude.... found this.. doesn't have what you want but is worth noting... From: gerard ziemski <****@apple.com> Subject: Re: drawing fast. Date: November 12, 2003 4:40:18 PM EST To: Java-Dev Java <java-dev@lists.apple.com
dude,
what exactly are you trying to draw? is it really just single pixels you're interested in drawing?
a few pointers:
1. if you draw into a buffer, make sure that image is created using createCompatibleImage 2. if you draw on-screen directly into Graphics object, never do that from a 3rd thread. for on-screen, only use the graphics objects that you are handed by the repaint mechanism. issuing "repaint" calls from 3rd thread is fine though. 3. if the color of pixels you're drawing is different each time, you should not use fillRect (CoreGraphics is very slow at switching colors). if that is the case you are best off setting the pixels directly in DataBuffer that you get from WritableRaster that you get from your BufferedImage (the pixel layout will be platform dependent). in this case it is critical that the image type is natively supported on Mac OS X. 4. clipping will help if the drawing area is really large and you know which part changed
if you give me the access to your test case, I will hopefully be able to help more.
cheers But what I'm really trying to find is... /me keeps looking... Can't find the exact message... Basically I think it said something along the lines of TYPE_INT_ARGB_PRE and TYPE_INT_ARGB are supported 'directly'... possibly others. (RGBA and RGB I think) The person to ask is Gerard Ziemski (author of quoted message above), I know he visits here... maybe send him a private message. Ah, I did find this Apple tech note: http://developer.apple.com/technotes/tn/tn2014.html#Section3
|
|
|
|
kevglass
|
 |
«
Reply #85 - Posted
2003-12-02 04:46:48 » |
|
We need to get Dave/Yuri to take a look at this in respect to texture loading and the GUI stuff..
Kev
|
|
|
|
Yuri Vl. Gushchin
Senior Devvie   
Speak Java!
|
 |
«
Reply #86 - Posted
2003-12-02 12:08:27 » |
|
Default texture loading mechanisms in TextureLoader use Texture.RGB + ImageComponent.FORMAT_RGB for RGB textures and Texture.RGBA + ImageComponent.FORMAT_RGBA for RGBA textures.
Internally, Texture.RGB and ImageComponent.FORMAT_RGB corresponds to GL_RGB format, Texture.RGBA and ImageComponent.FORMAT_RGBA corresponds to GL_RGBA format.
In UI code, only BufferedImage.TYPE_INT_ARGB and BufferedImage.TYPE_INT_RGB image types used, so it should be compatible.
Anyway, Xith3D UI code does no on-screen drawing and draws only in BufferedImage, which then loads as OpenGL texture. If there are significant performance slowdowns, more detalied investigation should be made to figure out what is happening there.
Yuri
P.S. Not much info from me for that - my Mac is still broken (power supply pbs) and I can not test this now.
|
Yuri Vl. Gushchin JProof Group
|
|
|
kevglass
|
 |
«
Reply #87 - Posted
2003-12-02 18:03:03 » |
|
On the off chance that anyone trys this on windows and has a game pad with rumblers.. I've just added the support from JInput Kev
|
|
|
|
Kevdog
|
 |
«
Reply #88 - Posted
2003-12-02 19:39:29 » |
|
Works good at about 25fps. Smooth and no artifacts here.
WinXp P4 2GHz Intel 84845G graphics (i.e. crap!) 512MB memory
|
There are only 10 types of people, those who understand binary and those who don't!
|
|
|
Jens
|
 |
«
Reply #89 - Posted
2003-12-02 20:08:33 » |
|
Looks like every Kev and his dog plays this game.  I found two "bugs": 1) If you jump up, you can jump through a wall. In my opinion this only makes sense if you are "pushed" through a wall by an elevator or something similar. The difference is, that in the latter case you have no option and must decide to either let the alien die or push it through the wall. In the first case you can simply block the jump. 2) If you jump at the end of the level you stay in the air which looks funny.
|
|
|
|
|