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).

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.

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.

Quote

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

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).

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

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.

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.

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.

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 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.

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....

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 createCompatibleImage2. 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.

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.

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.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org