I'm going to test it at home. I spoke about your engine recently to the author of JavaGL and TESSERACT, I advised him to use your engine because he is writing a 3D software engine for applets :s I'm impatient to see the improvement in the controls

java.lang.IllegalArgumentException: Width (0) and height (0) cannot be <= 0 at java.awt.image.DirectColorModel.createCompatibleWritableRaster(Unknown Source) at sun.awt.Win32GraphicsConfig.createAcceleratedImage(Unknown Source) at sun.awt.windows.WComponentPeer.createImage(Unknown Source) at java.awt.Component.createImage(Unknown Source) at FPSSample.startOnce(FPSSample.java:219) at FPSSample.start(FPSSample.java:208) at sun.plugin2.applet.Plugin2Manager$AppletExecutionRunnable.run(Unknown Source) at java.lang.Thread.run(Unknown Source)

hum seems that this is this line :

1

this.bgi=this.createImage(this.getWidth(),this.getHeight());

It means that the start method of the applet has been called before applet has been sized, this is strange, I am not sur that it is a normal case in the applet life cycle ?? I will try to cach such case

Quote

I'm going to test it at home. I spoke about your engine recently to the author of JavaGL and TESSERACT, I advised him to use your engine because he is writing a 3D software engine for applets :s I'm impatient to see the improvement in the controls

thanks, I am still working to improve the control and the 3DzzD API , this sample is a piece of the current work I am doing to implement lightmapping , in this one there is only the light map, in next one I will add diffuse texture.

NB: I have realised that a cupple of people think that 3DzzD work with GC and is not software even if it is compatible with Java 1.1 as TESSERACT author who dont want to trust that 3DzzD is software .... that's finally pretty cool

NB: I have realised that a cupple of people think that 3DzzD work with GC and is not software even if it is compatible with Java 1.1 as TESSERACT author who dont want to trust that 3DzzD is software .... that's finally pretty cool

I told him to look at your source code, he didn't answer about this point. I explained to him that he was not alone to write such kind of engine, I explained to him that there were already some technologies to write 3D games on mobile phones (M3G 1.0, JOGL-ES, Mascot Capsule) and he denied the obvious. The problem is that he was trying to convince people that there is no light cross-platform technology to write FPS on PC and mobile phone in Java. He denied these accusations. However, if some newbies read that, they could believe he said the truth and then they could begin reinventing the wheel... It would be fine if you could come to the forum of "Games Creators Network" at least to defend your own engine :http://forum.games-creators.org/showthread.php?p=59488If people believe that your engine works in hardware rendering when it works in software rendering, it means that you have made an excellent job

I have tested your latest update. It is very good, maybe a bit too dark. It is playable. I haven't reproduced the problem I had with the previous update

I guess it's possible to get used to it. I'd like a "dead zone" in the middle though, where the view is totally still. Like, for example, as long as the mouse is within a 32 pixel radius of the center of the screen.

I have added a dead zone of 50px, your feedbacks on this one are welcome

Quote

If you were planning to develop it further, I would say that a few more damage particles would be nice

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

Looks great!What I find a little disconcerting between this and a traditional FPS is that the targeting reticle moves around the screen rather than staying fixed in the center. Since the mouse is controlling where you look and where you aim, the center of the screen should always be where I am looking and I should always be aiming where I am looking.The "drunk" feeling comes from the disconnect between and absolute mouse move for aiming and a relative mouse move for looking.

What I find a little disconcerting between this and a traditional FPS is that the targeting reticle moves around the screen rather than staying fixed in the center. Since the mouse is controlling where you look and where you aim, the center of the screen should always be where I am looking and I should always be aiming where I am looking.The "drunk" feeling comes from the disconnect between and absolute mouse move for aiming and a relative mouse move for looking.

You have found the good words to explain to the author what I think, it is the same feeling.

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.

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

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

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

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?

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

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

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?

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.

I have updated the API, not sure it will help but maybe you can give it another try ? it run fine here it pass the Microsoft 1.1 JVM test !API updated for this one => http://demo.dzzd.net/FPSSample8/ (it is also a little faster)

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.

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); => resursivlySystem.gc();

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