Anyone have time to test...

endolf · December 1, 2003, 3:33pm

[quote]Mac platform IS sensitive to image format. Always use compatible formats… other formats may render very slow.
[/quote]
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 · December 1, 2003, 3:36pm

You’re a star! ;D

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

joo · December 1, 2003, 3:59pm

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 · December 1, 2003, 4:55pm

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 · December 2, 2003, 1:04am

[quote]Can you explain what you mean by compatable formats?
[/quote]
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…

[quote] 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:

if you draw into a buffer, make sure that image is created using createCompatibleImage
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.
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.
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
[/quote]
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 · December 2, 2003, 4:46am

We need to get Dave/Yuri to take a look at this in respect to texture loading and the GUI stuff…

Kev

yvg · December 2, 2003, 12:08pm

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.

kevglass · December 2, 2003, 6:03pm

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 · December 2, 2003, 7:39pm

Works good at about 25fps. Smooth and no artifacts here.

WinXp
P4 2GHz
Intel 84845G graphics (i.e. crap!)
512MB memory

joo · December 2, 2003, 8:08pm

Looks like every Kev and his dog plays this game. ;D

I found two “bugs”:

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.
If you jump at the end of the level you stay in the air which looks funny.

swpalmer · December 3, 2003, 2:53am

[quote]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
[/quote]
Just tried with my Macally iShock … It’s a Mac controller but it appears to be supported on Windows (Windows knew how to use it without me needing to go find drivers).

The Web Start version chrashed the VM when I went to select the controller… I’m guessing the JInput plugin wasn’t quite right with the Web Start install.

The Zip version worked fine (ran update first and noticed it grabbed new files - only seconds after I got the Zip. Were you in the process of updating things maybe?
Teh controller worked fine to play the game - Setup of the buttons was a bit strange, I seemed to need to click the mouse on the button GUI twice for it to take my button press from the controller.

No rumbler activity at all. Do you know where I can get a Windows program that definately works with rumblers? It may just be that this controllers rumblers are not supported on windows. Do you typically need custom drivers for rumbler support? It appeared that Windows jsut recognised this thing as a HID and new what to do. Perhpas it is using generic drivers that don’t do force feedback?

kevglass · December 3, 2003, 4:50am

Erg, all I can say is it works happily for me. When you say crashed, was it a Java crash or a Windows crash. I’ve had it crashing windows now and again but just running webstart again seems to clear it up.

Fraid not, its a limitation of my updating system. Since it kinda morphs the webstart install into the zip install the native libraries get a bit screwed up and end up getting replaced straight away. I’ll fix it some day

Coo, thats a new one… when you clicked once did the label appear at the top of the table saying press the button… ? I’ll have a look at this tonight. I’m glad it worked in game

The rumbler should be very soft when you push blocks around. However, it could be a driver thing. I thought that directx drivers support rumblers by default but maybe not. I’ll add some debug tonight to dump out what rumblers JInput thinks it found.

Kev

EDIT: Coo, 1000 posts

swpalmer · December 3, 2003, 12:21pm

[quote]Erg, all I can say is it works happily for me. When you say crashed, was it a Java crash or a Windows crash. I’ve had it crashing windows now and again but just running webstart again seems to clear it up.
[/quote]
I tried it only once, it was a Windows crash.

[quote]Coo, thats a new one… when you clicked once did the label appear at the top of the table saying press the button… ? I’ll have a look at this tonight. I’m glad it worked in game
[/quote]
Yes the label appeared but it seemed to go away before I pressed the controller button, then the second mouse click brought the “press button” label back and when I pressed the controller button it worked.

[quote]The rumbler should be very soft when you push blocks around. However, it could be a driver thing. I thought that directx drivers support rumblers by default but maybe not. I’ll add some debug tonight to dump out what rumblers JInput thinks it found.
[/quote]
Ok, the plastic the houses the controller is translucent, so I can see that there was no motion on the rumblers… it’s not just me not feeling it. I kept bumping into the chicken, I figured it throws the player a bit so that might ‘rumble’. I will pay special attention when pushing blocks.

Orangy_Tang · December 3, 2003, 12:55pm

Seems to be a tad tricky to force the second movable block into place, the aliens forehead stop you pushing it the last milimeter without lots of trial and error

But thats just a gameplay bug, like me moonwalking into thin air at the end of the level Other than that works nice and smooth.

kevglass · December 3, 2003, 2:06pm

Do you know, I was really worried about that bug cropping up… but then it didn’t!

And now it does, git!

I’ll probably update the level design rather than the code. Current plans are to create a full level and “map screen” relatively soon… which reminds me… I was going to start another thread…

Kev

swpalmer · December 3, 2003, 3:41pm

[quote]Seems to be a tad tricky to force the second movable block into place, the aliens forehead stop you pushing it the last milimeter without lots of trial and error

But thats just a gameplay bug, like me moonwalking into thin air at the end of the level Other than that works nice and smooth.
[/quote]
I’ve never had a problem with the block, it worked every time (only 3 times I tried though )

I agree, the game in general is pretty smooth. There was some glitching in the earlier versions that seems to have mostly gone away.
’
This looks like it will be a great, fun game. I can’t wait to see how it evolves.

kevglass · December 3, 2003, 6:00pm

Well, thanks for the positive feedback! As to evolution, I haven’t got a fixed direction to go with the game at the moment… but I have got pages of ideas.

Kev

endolf · December 3, 2003, 6:57pm

[quote]I kept bumping into the chicken, I figured it throws the player a bit so that might ‘rumble’. I will pay special attention when pushing blocks.
[/quote]
Last time I checked pushing blocks was the only thing that triggered the rumblers, and then gently, which feels good, if you report back more on it not working I’ll update the webstart demo of jinput so we can do some testing that is just jinput.

Cheers

Endolf

swpalmer · December 4, 2003, 3:20am

I can confirm that there was no detectable movement in the rumblers at all when pushing blocks or anything else. It could be that the iShock FFB simply doesn’t work on windows, since I have no specific drivers and it is sold as a Mac controller.

If you know of some other code I can use to test that theory let me know.

endolf · December 4, 2003, 5:00am

Hi
I suspect that, unlike the rest of a HID controller, force feedback protocols differ from vendor to vendor in which case you will need the right drivers, I know that my gamepad only works undler linux with the logitech drivers installed (ok, it doesn’t even work then yet, but it should do). If you want while I was learning the ff stuff I wrote a little app that went through every game controller searching for ff axes that I can mail/post, but it’s a windows .exe. I’ll update the jinput webstart test tonight and you can try that, although if MM doesn’t work odds are jinput isn’t finding any rumblers.

Cheers

Endolf