Mini 3D FPS in an Applet Update 9

Yes I also agree with these comments about the unnatural controls.

I wouldn’t be surprised if the cause is that you don’t want to/ can’t (Robot permissions) lock the mouse into the applet which is what would be required to have traditional FPS mouse control.

If implemented using Robot you would have to press a button to regain access of your mouse which might be a little annoying in a non-fullscreen web browser game.

[quote]Unable to run it on my windows xp computer
[/quote]
I have absolutly no idea where that error come from :(, very strange stacktrace, does you JVM was already started, maybe by anther Applet ?

[quote]Yes I also agree with these comments about the unnatural controls.

I wouldn’t be surprised if the cause is that you don’t want to/ can’t (Robot permissions) lock the mouse into the applet which is what would be required to have traditional FPS mouse control.

If implemented using Robot you would have to press a button to regain access of your mouse which might be a little annoying in a non-fullscreen web browser game.
[/quote]
You are right Robot requiere a signed applet and Java above 1.3, I will add it but only as an option (same as hardware rendering), I agree wth the fact that control is disturbing, maybe playing the “futur” game drunk will help :slight_smile:

[quote]It’s MUCH better with the dead zone IMHO. It’s actually playable now, after you get used to it. Before that change, i felt like a drunk staggering around in the level. But what am i supposed to do? I saw one enemy right at the beginning, but it seemed to be stuck in the ground or something and i wasn’t able to kill it…
[/quote]
not really supposed to do anything :-, I wanted a feedback on the control stuff to see if I keep it like this, I will review the current code and make it more clean then I will add some enemy units, but dont really have a precise idea right now…

just a notice:
while making some memory improvment , I found some strange issue on Sun JVM VS MS :
memory used now on MS JVM : 12Mo
memory used now on Java 1.6(07) : 39 Mo :o

any idea ??

EDIT: ok, sry I found Ms seems to report a wrong value…

once again I have tried to improve player control, this is still different but after tuning and trying I found it become not so bad, but I have used it for so long that I dont really know…

the dead zone has been reduced (40*40) and the transition from dead zone to moving zone is smoother.

http://demo.dzzd.net/FPSSample6/

NB: once started run away, there is a bot that will kill you only after some seconds if you dont move.

I liked it more the way it was, because i don’t like the smoothing. It feels sluggish again now… :’(

ok, I finally found a name for this game : Spider Experiment

and here is the video preview :

[url=http://www.youtube.com/watch?v=9ARnWfc5TzU&fmt=18]

Click the screenshot to launch the Video
[/url]
hum does the name sounds ok ?

Update 7:

code review
first enemy unit

NB: sry but spiders cannot be killed yet

http://demo.dzzd.net/FPSSample7/

Update 8 :

if as me you are afraid by spiders and hate them, you will love this version :slight_smile:

http://demo.dzzd.net/FPSSample8/

tips: a spider is only dead when it dont move anymore

The display gets frozen when I start walking :frowning:

any console output ? browser is frosen ?? really strange can you give me anymore information ? it start fully software it should not froze anything :frowning:

The walk sound loops continuously and the game doesn’t respond. Nothing special in the console, no Java exception. I’m going to try again.

On a computer under Debian Etch with no sound, the bug is not reproducible.

hum… maybe that : if you click outside the applet while you press a key to move (one of th arrows) it may cause such problem, isn’it that ?

No sorry. I have just tested a few minutes ago. I can play with your game only if I don’t move or it gets frozen.

Soild performance here, although switching between soft/hard mode seems a little bit slow(took me about ~7 secs and the applet went black).

I noticed the phong’s specular hightlight on your moving models, they look very nice. I also noticed when you switched to hardware mode,
the models become guround shaded. Does open gl not let you do phong’s shading easily?

[quote]No sorry. I have just tested a few minutes ago. I can play with your game only if I don’t move or it gets frozen.
[/quote]
too bad… only if you dont press any key ? but you can move mouse ?

[quote]Soild performance here, although switching between soft/hard mode seems a little bit slow(took me about ~7 secs and the applet went black).
[/quote]
hardware switch requiere some native libraries download and is doing while the game is running so this is not surprising me, but if you switch back to soft (S) and then to hardware (H) it should be immediate or a lot faster

[quote]I noticed the phong’s specular hightlight on your moving models, they look very nice. I also noticed when you switched to hardware mode,
the models become guround shaded. Does open gl not let you do phong’s shading easily?
[/quote]
not really rather I did not try to implement it yet (in software you got a lot more as phong, reflective map, normal) in hardware I only implement few thing as it was/is intended to be a fallback for now but will be improved in the futur, the opengl renderer is a very little class for now.

[quote]Quote
No sorry. I have just tested a few minutes ago. I can play with your game only if I don’t move or it gets frozen.
too bad… only if you dont press any key ? but you can move mouse ?
[/quote]
I have updated the API, not sure it will help but maybe you can give it another try ? it run fine here :frowning: it pass the Microsoft 1.1 JVM test !

API updated for this one => http://demo.dzzd.net/FPSSample8/ (it is also a little faster)

NB:

Thijs is working on an extension to use the Robot class and than enable FPS control (same kind of extension than the jogl one)

I can only use the mouse to look around and to shoot, I can switch to hardware mode but I can’t go forward or backward.

I will test it when I’m back home at it is reproducible only on my home computer.

Not that average Joe would try to break the applet, but it seems to be very easy by reloading the page (outofmem, firefox, 1.6 update 10).
I think I managed to work around this in my own applet (yesterday! horay!) by:

  • doing nothing in init()
  • in start() I wait for the last thread (referenced by a static instance) to finish.

edit: forget what I wrote, my applet is still breakable (but it is difficult). shit.

yup… there is not any java plugin with a good applet life cycle … I used to do the following in some Applet (this give good results but not perfect ):
in destroy :

this.getParent().remove(this); => resursivly
System.gc();

this do a better clean of your applet but nothing for the other applets loaded before