The jar (patched or otherwise) just hangs my machine. Is it an old version of the jar that you zipped? The menu and logo look different to the exe.
[quote]He PM’d me some kind of sys report which claims that it should handle 1024x1024 - but I don’t believe it for a minute 
I bet that means 1024x1024x8bit, or 256x256x32bit.
[/quote]
I didn’t know whether to believe this either, but I’ve just run the Blending example program with a 1024x1024 image of the Earth. It took a few seconds to appear, but it did run, and looked right. So I don’t think it is the size per se.
AndrewNo, all that .jar is is a set of new sprites and a resources file - shouldn’t have any effect whatsoever on the rest of it. Sure you’re running it right? Maybe you could try and unzip the original jar and then unzip the patch over the top of it and just try running it from there.
CharlieI’m all strawed out. We’d get an instant Hotspot VM crash if I tried to call a nonexistent function. OpenGL allows as much texture memory as you like - whether it fits on the card is another matter, but I think you can tell from the size of the .exe that I don’t have 8MB of graphics anyway - because it dynamically uploads textures when they’re required, and if you repeatedly use more texture memory that there is on the card, you get “texture thrashing” which slows performance to a crawl.
Got any newer drivers?
Cas
First time I ran the Jar (without patch) I got a Microsoft VM crash (this is the latest, recently released MS VM which seems to handle sun 1.4.1-compiled java - i.e. it’s a proper, fully working jvm). All subsequent times have been fine…
However, when my spinning orbiting thingy killed the last blob on level 1 for me:
Resetting feature: jelly_incursion
java.lang.NullPointerException
at com.shavenpuppy.jglib.opengl.nvidia.GLFence.finish(GLFence.java:77)
at com.shavenpuppy.jglib.sprites.SpriteRenderer.preRender(SpriteRendere
.java:359)
at com.shavenpuppy.jglib.sprites.SpriteEngine.render(SpriteEngine.java:
42)
at xap.EndOfLevel.renderSelf(EndOfLevel.java:562)
at xap.gui.Component.render(Component.java:1293)
at xap.gui.Interface.render(Interface.java:556)
at xap.Game.main(Game.java:265)
This is on windows XP, geforce 4(00?) MX, Athlon 2000+ w/256Mb.
At the moment, the graphics give the impression the playing area extends onwards, but it
doesn’t.
Suddenly getting “stuck” at the edge of the level, without any warning, so that you die (because you can’t move any more, and the aliens are charging at you) is dumb. At least have some graphical indication of where the playing area ends; personally, I’d vote for toroidal board instead, but that’s a significant change in gameplay, so perhaps not what you want.
[quote]AndrewNo, all that .jar is is a set of new sprites and a resources file - shouldn’t have any effect whatsoever on the rest of it. Sure you’re running it right? Maybe you could try and unzip the original jar and then unzip the patch over the top of it and just try running it from there.
[/quote]
Sorry, I meant that the AlienFlux.jar seems old, not the patch.
There’s some tweaked versions up at the usual place. (Patch is gone now, not needed any more).
blahblahblah - found that NPE bug just too late to put it in the patch - it occurs on screen resolution changes, thanks to me using a static variable accidentally on purpose. I originally wanted a toroidal world but couldn’t figure out how to do it easily. The current “edge-of-the-world” does indeed suck and we’re still thinking about the nicest way to handle it. I was thinking of fading the background out suddenly at the edge, or drawing a big glowing circle around it or something.
Andrew - just give the latest one a go, in its entirety (no patch) and see if that works.
I’ve discovered a general bug as well if you only have one mouse button - you’ll get an ArrayIndexOutOfBounds exception over and over. Or if DirectX reckons you’ve only got one button, at any rate.
Cas
Well it works, with the same result as the exe - no sprites. I see a few pink blobs initially, but after the level 1 message has scrolled up, I see no more except for an occasional shadow. 
[quote]the latest, recently released MS VM which seems to handle sun 1.4.1-compiled java - i.e. it’s a proper, fully working jvm
[/quote]
Huh?? :o
I found that hard to believe. At the Microsoft site I can only find statements about the Microsoft VM being phased out and I believe they’re not allowed to update their current VM because of a court order.
Andrew - try and find some new drivers! Yours just don’t work right.
(A.F. alpha 8 is now uploading… it’s got a new 30Hz mode and low-res graphics mode too, and a thingy to redefine the keys)
Cas
[quote]Andrew - try and find some new drivers! Yours just don’t work right.
Cas
[/quote]
Well I’ve just updated my video driver (which was a rather fraught process that involved rebooting in 16 color mode after it refused to install first time). And now it doesn’t even run. ??? I’ll try the next release.
An unexpected exception has been detected in native code outside the VM.
Unexpected Signal : EXCEPTION_ACCESS_VIOLATION occurred at PC=0x1
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 org.lwjgl.opengl.CoreGL.clientActiveTexture(Native Method)
at xap.background.PlainPassState.preRender(PlainPassState.java:37)
at com.shavenpuppy.jglib.renderer.Renderer$StateList.render(Renderer.java:135)
at com.shavenpuppy.jglib.renderer.Renderer.draw(Renderer.java:373)
at com.shavenpuppy.jglib.renderer.Renderer.render(Renderer.java:256)
at xap.features.BackgroundFeature.render(BackgroundFeature.java:483)
at xap.BattleZone.render(BattleZone.java:78)
at xap.GamePanel.renderBackground(GamePanel.java:439)
at xap.gui.Component.render(Component.java:1277)
at xap.gui.Component.renderChildren(Component.java:1337)
at xap.gui.Component.render(Component.java:1285)
at xap.gui.Interface.render(Interface.java:559)
at xap.Game.main(Game.java:282)
Dynamic libraries:
0x7CC00000 - 0x7CC1D000 C:\WINDOWS\SYSTEM\IMAGEHLP.DLL
Local Time = Mon Apr 07 17:56:08 2003
Elapsed Time = 64
#
# The exception above was detected in native code outside the VM
#
# Java VM: Java HotSpot(TM) Client VM (1.4.1_02-b06 mixed mode)
#
Me too; it may be that I’m crediting them too much and all they’ve fixed is the classloader problems (I think I’ve found some 1.3-only classes that are running OK with it, but this may be a sleep-deprivation induced hallucination ;)). But I was working on a project for someone a couple of weeks ago, and ran into the problem that my 1.4.1-compiled code wouldn’t run on the XP machines they had. I was desperately looking for anything that might avoid me having to faff with compiling specifically for old VM’s, and noticed that a new 5-10Mb (can’t remember exactly) “Microsoft Java VM update” was showing up in windows update. Downloaded it, and now MSIE is happily loading all my class files on all the machines (there and at home here).
(note: I haven’t done a full test yet on which classes are present, so can’t verify where it lies between 1.2, 1.3 and 1.4, but at least all the ClassLoader errors in com.ms.xxxxxx have now disappeared).
My suspicion is that this might be a reasonably good VM that slipped out just before the court order? There seemed to be a bit of whining about something like “look, we were doing what we promised, and a new court order came through stopping us dead” on the java area of the MS website yesterday/today. But I’ve not looked closely yet (not enough spare time…).
PS Had to fix a project for someone today where they were using J++ - and still using a 1.1 VM. ARGGHHHH!!! The pain of using pure AWT, and going without the benefit of any bugfixes and function-enhancements since about 1998!
[quote]There’s some tweaked versions up at the usual place. (Patch is gone now, not needed any more).
blahblahblah - found that NPE bug just too late to put it in the patch - it occurs on screen resolution changes, thanks to me using a static variable accidentally on purpose. I originally wanted a toroidal world but couldn’t figure out how to do it easily. The current “edge-of-the-world” does indeed suck and we’re still thinking about the nicest way to handle it. I was thinking of fading the background out suddenly at the edge, or drawing a big glowing circle around it or something.
[/quote]
Suggestions:
-
Float a white (possibly throbbing/pulsating) tube/pipe above the surface, that casts an obvious shadow (or is in some way clearly marked as floating - this makes it more obvious as a barrier); my mental image is that it’s a continuous tube, forming a rectangle with curved corners.
-
Global navigation is quite hard at the moment, since there’s no “minimap” or similar, so it’s easy to forget quite where you are (technically speaking, I think the phrase is that there’s no “static frame of reference” at present.) Another solution to this (other than e.g. an inset transparent minimap, which is a bit overused these days ;)) is the “offscreen arrows” - i.e. arrows on the edge of the screen which point towards certain objects.
It would be quite cool to have one of these for each fluffy thing (can’t remember your name for them, sorry :)), so you could keep track of where you are relative to the things you’re protecting. The arrows themselves also tend to be an excellent frame of reference for general navigation, since the fluffy creatures themselves don’t move much/fast.
I have to say that if it weren’t for the zooming-in horizontal and vertical lines every time a fluffy was attacked, I’d probably stop playing really quickly just because I don’t like being so unaware of where the heck I am! The zooming-in cursor is an excellent nav-guide; screw the fluffy, I just need to remember where I am :P.
My original plan was to put a decal black & white texture in the centre of the battlezone, but I think I might abandon that idea entirely through fillrate concerns on older cards (on a card without multitexture the whole screen would effectively be painted three times over and I can’t see a card that old coping at all).
How about a radar circle in the centre of the screen, about 1/3rd the height, and around the edge of the circle I’ll draw up to 8 arrows pointing to where the 8 fluffies are if they’re not visible?
With that radar you’re unlikely to go whizzing off the edge of the game (it’s circular btw).
Cas
Sounds cool, the least we can do is try it :).
About the circular thing: doh! I had no idea. This might also partially explain why I had SO much trouble evading once I got to the edge. Rectangular-screen made me think rectangular playing area (even once I’d sussed that I’d hit the boundary, and was starting to panic, I was still dismal at evasion :().
Hmm. Also explains why you said you were “thining of putting a big circle round the playing area”; I though that sounded a bit strange ;).
Wow! The game r0x! Bang-Bang-Bang! I’m so glad to see a nice Java game.