Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - EgonOlsen

Pages: 1 ... 789 790 [791] 792 793 ... 796
News / LWJGL 0.6 is out!
« on: May 07, 2003, 08:45:34 pm »
FYI: A new version of LWJGL (the lib jPCT uses for the OpenGL binding) is out, but jPCT 0.88 won't work with this version. 0.89 will.

If you are interested in LWJGL, grab it here:

Support / A few questions...
« on: April 28, 2003, 05:57:52 pm »
Update on the sidebar problem: I've uploaded a pre-release of 0.89 which has an option included to apply an offset to the viewport and it hopefully works in software as well as in OpenGL. There are two new configuration options in Config called viewportOffsetX and viewportOffsetY. The offset is in fact a factor and independent of the resolution...have a look at the docs for futher detail about these settings.
This should also help to reduce the amount of polygons overdrawn by the sidebar anyway, so it should be a little faster too.
The version can (only) be download here: *removed*...the normal distribution contains this option now.
Let me know, if it helps.

Edit: Fixed the link...

Support / A few questions...
« on: April 26, 2003, 04:10:17 pm »
Before the days of the OpenGL renderer, this would have been rather simple. You can access the Image-instance that holds the pixels generated by the software renderer and blit it into whatever and whereever you want. But though it's possible, it's not very convenient. Therefor, i once added an option to jPCT (that isn't available via the API at the moment) that "shifts" the projected 2D coordinates in any direction, because this is, what's actually needed to avoid the problem: If your sidebar is for example 100 pixels, you would like to start the rendering not at x=0 but at x=100. This is no problem with the software renderer, because i have full access to every pixel and can do whatever i want to. However, i didn't find a working way to tell OpenGL not to start rendering at (0,0) but somewhere else. That's why the option to do this is not publicly available.
Manipulating the matrices doesn't help btw, because what you want is basically a 2D operation...just tell the stupid polygon to start at (x+a,y+b) instead of (x,y) on screen (the position in 3D wouldn't change). I just don't know how to achieve this in OpenGL ATM...maybe i'll have a closer look again one day (glViewport comes to mind...but i tried that once and it failed somehow...well, maybe i'll give it a shot again...). For now, i suggest to take it as feature. Maybe you want to make the sidebar removable... :wink:

Edit: About the filtering: Maybe it hurts performance on PowerPC's and their VMs more than it does on Intel...can't wait to see what happens when LWJGL comes out for Mac (byteorder anyone... :roll: ?).

Edit2: I forgot to mention this in the docs of 0.88: The coords the projectCenter...stuff returns are backbuffer coords, i.e. if you are using 1.5 or 2 times oversampling, you have to divide them by 1.5 (or 2) to get the actual coords of the frontbuffer (for blitting and stuff). 0.89's docs will mention this.

Support / A few questions...
« on: April 24, 2003, 10:27:58 pm »
Make sure to use software rendering in MODE_OPENGL to ensure that soft- and hardware will almost look the same. The reason is, that jPCT's default rendering mode is software legacy which uses a different lighting model that OpenGL doesn't support (and that's sad because i think that it, may it be realistic or not, produces better results than the standard lighting OpenGL supports). Have a look at the terrain example's sources to see what i mean. Or, if you are already doing this, ignore my post... :wink:

BTW: Texel filtering shouldn't be much slower than not using it...if it's noticable at all. I've put a lot of affords into optimizing the software renderer may it be with or without filtering.

Support / A few questions...
« on: April 24, 2003, 07:52:07 pm »
Two things i've forgotten to mention:

1.) Don't use textures with a height other than a power of 2 when doing OpenGL (not for blitting either). OpenGL doesn't support this and jPCT has to do a conversion run on every texture. This is very slow, because it's just a naively implemented better-than-an-exception-method. In addition, the converted textures are not very pretty...

2.) I'll try to speed up texture upload performance a little bit for 0.89. The problem is, that i can't do much about it because most of the time is wasted inside OpenGL and the video card's driver, not in jPCT. I already tried some things and got a 50% increase (but we are talking about 2fps compared to 3fps after the optimization)....anyway, i'll add it to the next release.

Support / A few questions...
« on: April 23, 2003, 07:21:39 pm »
0.88 has been released. The projection-methods you requested can be found in Interact2D. Please let me know, if this helps you.

News / Version 0.88 has been released!
« on: April 23, 2003, 07:19:49 pm »
Optimized OcTree generation and added some methods to Interact2D. Fixed a bug in getWorldTransformation() when using lazy transformations, modified some small parts of the documentation...that's it for now... :wink:

Support / A few questions...
« on: April 22, 2003, 09:54:06 pm »
Quote from: "GP"
Well, let's say I have a unit of 20 warriors. In my game they will just be 20 boxes with textures on their front and back faces on 20 bases (just like old tabletop games like D&D, but I'm getting off-topic). I want the player to be able, holding Shift or Caps Lock, for example, to display information over the units, under the form of 2D icons (I could do it with 3D objects hovering on the unit, but they wouldn't be well visible from every angle), for example an icon if the unit is fleeing.

I see...instead of doing 2D blitting, it is also possible to use billboarded 3d objects. But that may be overkill. Doing it the 2D way should be a fine solution.

Quote from: "GP"
So what I need is a method like : public Point get2DPosition(Camera c, 3DObject targetObject), (with -1 or something representing offscreen positions), for determining object center in the scene. Alternatively, any point in the world could be fine...
I think i'll head for the "center"-way of doing it. It's easier to understand for "non-3ders".

Quote from: "GP"
I'm moving objects with only "rotate" and "translate" and not by "setOrigin", does that mean I can treat object- and world-coordinates as the same thing?
No, the object-space never changes (unless you are using the unfamous rotateMesh() and translateMesh() methods). However, a center of (0,0,0) will be virtually translated to (0+xt,0+yt,0+zt) if you translate the object by (xt,yt,zt) if your object's center is at the origin (in object-space) and you are doing translations only (or the rotation pivot is at the origin too), then your approach should work, but i like the idea of directly projecting the center more.

Quote from: "GP"
Ah, I was forgetting! A simple, non-vital thing this time  :) I'm implementing the sidebar blitting it from texture. It covers a quarter of the screen, wasting quite a lot of processing time... I remember that in OpenGL you can specify a subset of the frame buffer for rendering (i.e. a smaller rectangle), this way one can display a static image without performance loss. Is that possible to specify, at least in the OpenGL hardware renderer?
I'm not sure about that...blitting in OpenGL is actually done using textured quads, so limiting the output for rendering would kill your blitted bitmap too. For the software renderer, it may be possible. I'll think about it later.

I hope to release a version featuring the projection-thingy within the next few days.

Support / A few questions...
« on: April 22, 2003, 05:59:13 pm »
Quote from: "GP"
If such a method does not exist, I think I'll have to do the math myself using tan's and sin's... would you have any suggestions?
That won't work (and especially not by using trigonometric functions), because you would need some internal Camera-stuff for doing it. It shouldn't be a problem to add such a method for you to jPCT but the question is: What should it project into 2d? I can imagine the center of an Object3D, the rotation pivot (less likely to be usefull) or any point you throw at the method. But this would have to be a point in world-space, while the center is in object-space. Or in other words: Using the center takes the objects' transformations into account while using a point in world-space can't. I may add both methods as well. What do you want to use the method for exactly?

Support / A few questions...
« on: April 19, 2003, 06:25:20 pm »
The int[]-method is only slower when using OpenGL. When using software rendering, both methods should perform the same. Another way to do it, is to use the "texture-method" and implement your output-code using ITextureEffect. By implementing this interface in a class of your own, you have direct access to the texture's binary data. Problem with this is, that for OpenGL, a texture upload has to take place everytime the texture-effect has been applied. The good thing with this is, that the upload takes place only after the texture has been changed and not for every blit. Another way would be to use the int[]-method and set "glUseIgnorantBlits" in Config to "true"...but be carefull with this, because it prevents any texture-upload from any int[] until you set it back to false.
I suggest to go with the ITextureEffect-approach and see how it performs.
Anyway, i suggest to precompute as much as possible to avoid costly conversions at runtime.

Support / Deployment Problem
« on: April 09, 2003, 04:00:25 pm »
Quote from: "Neoteric"
Are the LWJGL-team working on problem 1?
They mentioned it some time ago, but i think the priority is not very high. They seem to favour Java WebStart instead.

Support / Deployment Problem
« on: April 07, 2003, 06:35:45 pm »

Does the openGL version offer any speed up yet? Last I remember it didn't.
:shock: ...?? should... :wink: The hardware support via LWJGL is way faster than the software modes. If it isn't, OpenGL may run in software emulation (done by the OpenGL implementation, not by jPCT) for some reason but i doubt that this will even work. There are three rendering modes in jPCT: software legacy (default), software OpenGL-look-a-like (a bit slower than legacy but using OpenGL's lighting model) and finally the hardware OpenGL renderer itself. Try the terrain example in OpenGL. It should be much faster (around 10 times on my machine) than the software rendered version.
Two problems with LWJGL though:

1.) It doesn't work in an applet (a security problem which has to fixed by the LWJGL-team...nothing i can about it)
2.) No support for AWT/Swing stuff in the OpenGL window (a design decision of LWJGL)

Does this answer your question somehow?

News / Version 0.87 has been released
« on: April 06, 2003, 06:25:01 pm »
Not much has changed in this version...anyway: The culling may be a little faster now (in some situations), the accuracy of some SimpleVector methods is higher now as well as the accuracy of the Camera's lookAt()-method (has much improved...the "shaking" should be gone now).
Oh, and a method to query an object about collisions that took place is in.
Have fun!

Support / Deployment Problem
« on: April 06, 2003, 04:59:36 pm »
Are the textures/models part of the JAR? If so, you may have to use the "InputStream"-methods/contructors  to access them. Or, if they aren't part of the JAR, the methods/contructors with "URL" are what you need. Either that or try adjusting the applet-params like setting codebase="." or something.

Edit: Another thing that may fool you: Windows in not case-sensitive, so loading "HuRz.Jpg" will work even if the file is named "hurz.jpg" on the HD. On a webserver, this won't work though. Just a thought...

Edit2: OT: A new version (0.87) is out which major improvement is a much more accurate lookAt()-method. If you're using (or plan to use) this method, you should get the update.

Support / Deployment Problem
« on: April 05, 2003, 01:19:36 pm »
Quote from: "Neoteric"

Your classes but I think the problem is my end, everything is included in the archive fine, it can find the classes, but on frame buffer instantiation it throws the exception. I think it's a packgage problem.

Are you sure that you've included BufferedImageBuffer and MemoryImageBuffer into the JAR? jPCT doesn't do very much in the instantiation of a FrameBuffer that may cause this exception but it dynamically loads one of these classes depending on the VM (Memory... for 1.1 and Buffered...for 1.2+). Maybe this fails because the classes are not there? Does it output some blah before it crashes? Like "java version is:"??

Pages: 1 ... 789 790 [791] 792 793 ... 796