Hi guys,

I am quite new to jPCT-AE and my question is, can it be used for 2D games as well? (displaying sprites, transformation, collision detection etc.)  I am currently developing a 2D game for Android but it becomes laggy on standard SurfaceView when several thousand objects are shown (FPS drops below 10) and I would like to avoid to call OpenGL methods directly (it's quite a mess to me), so a good engine that encapsulates them would be handy.

Or is it possible to make a 3D scene and set a camera to simulate a 2D view? (cubes would be projected to squares etc.)

Thanks for any help.
Filip

Thank you Egon, I will make some experiments with it. :-)

Another question: What would be the best approach to create a "continuous terrain"? I mean a situation when the world terrain grid would be too big to make a simple Object3D object out of it (because it would probably cause an OutOfMemoryError issue), which means that some kind of loading and replacing on the fly (depending on the camera position) would be necessary. I am not sure if the given sample code would be the best option for it, regarding the note "this is why building objects this way isn't blazing fast".

I never created an application of this kind, so this is just a theoretical speculation. How about to generate a set of terrain maps, convert them to Object3D, save to disk (serialize?) and load only the visible ones when the camera is close enough?

Is there a simple way how to create a terrain based on a heightmap, using jPCT API? Ideally something that would take an int[][] grid (or similar) containing height values and generate a terrain with some kind of interpolation (to make it smooth) and using provided textures and/or alpha maps to make it look nice?

I hope my request is not too confusing. :-)  But I would like to make a simple "run and fight" game and it would be great if a broken terrain makes it more strategic etc.

Thanks for any tips.

Quote from: EgonOlsen on May 02, 2008, 09:35:54 AM
No, it's fine to discuss this here. Thanks for voting...

Very well, since it is fine, I have another dilemma to solve:

My applet game is using hundreds of small-sized sprites to draw on every frame and I am currently doing it with the standard Graphics.drawImage method. However, I am not sure how the drawImage method works under the hood, and since I've been observing some kind of slowdown when the number of sprites is high, I am thinking about a better performing way to do it.

So the question is, which of the following approaches is better?

1) Convert all sprites (which are loaded as png images at the applet start) to pixel arrays and simply copy them to the proper positions of the offscreen pixel array (obtained from BufferedImage or ImageProducer etc.). Since I want to do some particle using effects after all sprites are drawn (smokes, fires etc.), I would need to modify the target image pixels anyway.

2) Keep the current code, i.e. draw all sprites using drawImage methods, then get the resulting pixel array and do all required pixel modification stuff.

I don't want to rewrite what doesn't have to be rewritten. On the other hand, I need the best possible performance, and I am afraid that any kind of hardware acceleration cannot be used here (or am I wrong?).

Thanks for any tips.
Filip

No problem. I have read the java.net thread about this topic (http://forums.java.net/jive/thread.jspa?threadID=35484&tstart=0) and the problem seems to be more complex than I ever thought.

For instance, I am developing an applet game which is displayed in 618x406 area and when I measure FPS value, it gives me 50-60 on my laptop with Intel Core 2, Nvidia GeForce Go 7400 and Windows Vista (I should add that I am not using any pixel manipulation yet, I just create a BufferedImage as a back buffer, draw all sprites there using Graphics.drawImage and then blit it to applet canvas).

What I don't get is that when I try to add this param to the applet code

    <param name="java_arguments" value="-Dsun.java2d.d3d=false -Dsun.java2d.opengl=true">

it does nothing in most cases but sometimes it increases FPS to 190-200. I am using Java Plugin 1.6 update 5, not the mentioned update 10.

As far as I know, it should make no effect to pass the java_arguments to applet prior to update 10 plugin, which makes me even more confused. Can it be a Vista-specific behavior? I have tried it with Firefox 2, Internet Explorer 7 and Opera 9, all of them show the same results.

I've just voted. 
By the way, I hope it's not too off-topic to discuss these issues here.

Thanks, that's what I thought.
I guess that one of BufferedImage benefits is that it can be hardware accelerated but it is probably not applicable when the image is fully rendered 100 times a second.

I have noticed that jPCT takes advantage of BufferedImage (if available), otherwise is uses a MemoryImageSource for software rendering (in Java 1.1, right?).

This point caught my attention because I would like to know which method is the best (fastest) one to make a software rendering with an ability to manipulate pixels directly. I read many articles about this topic, some of them say that a MemoryImageSource with an ImageProducer is still the fastest one, some of them claim that BufferedImage is preferred on Java 1.4+, etc. The conclusion is that I am just confused and I am not sure about anything.

Would someone know the answer to this issue?

Quote from: "EgonOlsen"Try this: http://www.jpct.net/forum/rss.php

Thanks Egon, works fine.  

Hello,
is it possible to read the jPCT forums via a RSS reader?
It is not too convenient to visit the index page just to find out there is nothing new in the topics I am interested in.

Thanks,
Filip

Quote from: "EgonOlsen"If the LWJGL packages are signed now, it's up to you to use it. jPCT works fine with all the recent LWJGL versions. Just find the correct way to embed it into an applet and you are done. I've stopped researching this topic with  the modified car example, but i'm sure that it's possible somehow. jPCT itself doesn't require signing.

Thank you. I am new to all these things, so I better ask instead of spending days to develop what is already developed.

Filip

Quote from: "EgonOlsen"The signing is required because the applet uses native libs. You can't work around this unless you are not using them. The example is not meant to be a general applet example but as a starting point for OpenGL implementations in an applet. A more generic example (using the software renderer) can be found in this (german) thread: http://www.jpct.net/forum/viewtopic.php?t=474

Thank you Egon, I'll try the German thread. Fortunatelly the code is in English.  
Just out of curiosity, this page says the upcoming release of LWJGL 1.0 would contain signed packages, in order to allow users to create signed applets (using native libraries) without purchasing their own certificate. It sounds great because that's exactly what I need.
Do you plan to add this functionality to jPCT after the LWJGL 1.0 is out?

Filip

Quote from: "EgonOlsen"It's already there due to popular demand (but well hidden... :wink: ):http://www.jpct.net/download/beta/AppletCarTest.java

I guess it requires a signed applet due to accessing local resources, right?
I would like to try it without signing but I hope it won't be a big modification.

Filip

Quote from: "EgonOlsen"It's already there due to popular demand (but well hidden... :wink: ):http://www.jpct.net/download/beta/AppletCarTest.java

Thank you very much, you saved me.  

Filip

I would like to use the Car Demo as a classic applet (because I've seen it in this thread) but when I try to convert the existing example to the applet, it doesn't work. Actually, the Java console says all resources have been loaded correctly but the applet window shows nothing, only a black screen.

Since the full code is too long to post it here, would it be possible to download the car demo applet source code? I just want to learn how to use jPCT features in an applet context and working examples are always the best way.

Thank you.
Filip