Hi !
Featured games (91)
games approved by the League of Dukes
Games in Showcase (799)
Games in Android Showcase (237)
games submitted by our members
Games in WIP (865)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
   Home   Help   Search   Login   Register   
  Show Posts
Pages: [1] 2
1  Game Development / Performance Tuning / Re: Alternatives for instanceof on: 2004-11-13 13:34:04
So what would you do if your Fruit types were dynamic? Suppose a run-time plugin added Grape, which the Monkey wasn't designed to receive. Grape would somehow have to determine that the target animal does/doesn't have an eatGrape() function. You'd end up with something like "is Monkey instanceof GrapeEater", and then each animal implements a set of xxEater interfaces.

It's a shame that polymorphism doesn't automatically do this for us... that is, if the object is of type Grape, then it could automatically call .eat(Grape g) instead of .eat(Fruit f). Just pick the most specific type and work your way up until you find a matching function.

Our system has both run-time dynamic plugin message generators and run-time dynamic plugin message receivers. We use a type combined with the source of the message; that is,

if (obj.Source == FruitTree && obj.type == FruitTree.APPLE)

mostly because we didn't want to try to define a unique ID to each type of message (ie, didn't want to create a global message ID namespace). So our message types are only unique within their own source, and we check both.

However, this is little more than a fancy instanceof, and I'm curious what the "proper" solution is supposed to be.
2  Game Development / Networking & Multiplayer / Re: java 1.1 compatiable 3d engine? on: 2004-11-10 21:42:57
I'd have to agree with the undesirable state of Java on the average machine. We've been distributing a Java-based 3D engine (our own using LWJGL 0.7) and, in the process of doing tech support, we've discovered many, many, many people either don't have Java, don't have Java 1.4, don't have a video driver besides their default (non-hardware accelerated) driver... don't be so quick to put down a statement until you've been in the trenches dealing with the typical public vs Java 1.4 and modern video drivers.
3  Java Game APIs & Engines / Xith3D Forums / Re: ui xith3d on: 2004-11-09 14:47:04
We too are working on a GUI system for our application. What we've done is made a hierarchy of Shape3D's, under a FG node with a scaling matrix that translates 3D FG coords into the exact matching 2D screen pixels, and vice versa.  The different widget flavors (Buttons, Text, etc) are responsive to our application's custom event notification of cursor positioning, but naturally that's assuming the widget is flat-on to the camera, etc.

We had a real problem with the Text and clipping. We determined that due to UV floating, the only way a Text texture map would render correctly was if the texture AND the Shape3D was a power-of-2 size. However, that left a dilemma about how to clip the text when the window itself wasn't a power-of-2 sized. We ended up discovering the Graphics2D.setClip() function... now we create power-of-2 sized textures and quads, but call Graphics2D.setClip() with the actual window size, such that the text drawn onto the texture doesn't go outside of the bounds of the actual window. The rest of the texture is filled in with a 100% transparent color, and nobody ever knows...

Click to Play

The System window can be moved and resized correctly. The buttons work correctly. The Text windows can be dynamically modified during runtime, and they can be resized correctly. The red box indicates the actual size of the Shape3D and texture on the bottom window, although the drawing of the text onto the texture is clipped to within the widget boundary. If the text widget is resized to the point of needing a different power-of-2 size, it automatically recreates the texture/quad.

The hierarchy for this example looks like this. Note that "quads" are Shape3Ds, while "widgets" are our own custom objects that extend BranchGroup (thereby containing quads or more widgets):

System widget
- Background quad (purple)
- Title quad (light blue)
- Menu button widget
--- Button image quad
- Maximize button widget
--- Button image quad
- Minimize button widget
--- Button image quad
- Close button widget
--- Button image quad
- Title text widget
--- Text quad
- Content widget
--- Background quad (grey)
--- Chat buffer text widget
------ Text quad
--- Chat input text widget
------ Text quad

Note that isn't a Swing window. It's a stack of Shape3Ds that's simply designed to look like one.

We don't use layout managers at all. We define the top, bottom, left, and right of each widget as being measured from the parent top/left, parent bottom/right, as a distance from the parent middle (vertical or horizonal), or as a position/size combo. It makes for a radically cleaner and more predictable design, avoids the headache of layout manager implementation and usage, and does everything we need to do.
4  Java Game APIs & Engines / Xith3D Forums / Re: Animation, loaders, bones, weights and morphin on: 2004-11-05 12:26:43
Well, our company's previous engine was 100% propreitary (ie, we were making it up as we went along) and we've just started the Xith translation from scratch... so it could be a long while until we're caught back up to the skeletal avatar stage again.  Don't hold your breath on us, hopefully somebody else will add this functionality long before we reach that stage ourselves again... if not, I'll see what we can do about donating the code.
5  Java Game APIs & Engines / Xith3D Forums / Re: Controlling lighting on: 2004-11-05 10:51:22
So, in Java 3D you can place a light node anywhere in the graph (for example in the hand of a creature) and it will influence all things inside its influencal bounds
I want to place light nodes in their natural place in the scene graph (for example, the hand of a creature), but I want to explicitly specify to Xith3D which graph nodes this light influences

I think this hits the nail on the head exactly. Of course you could always make a new type of light that provides this capability without breaking the existing lighting system.

Also, please don't tell me that Xith uses OpenGL lights... because last I heard, OpenGL had some unreasonably low limit to the number of lights available (like 8 or something) and my scene may have hundreds... how many are dependent on performance, of course, but I'd rather be limited by performance than by some artificial tiny limit.
6  Java Game APIs & Engines / Xith3D Forums / Re: Controlling lighting on: 2004-11-05 08:26:55
I'm not sure I understand. I thought I read that lighting is supposed to affect everything in the scene graph under it... but the scene graph hierarchy is how the light is positioned in the first place... ie, World -> Player -> RightArm -> Torch -> LightSource. But how is the LightSource at the end of the arm simutaneously be able to light the World node... unless, I guess, you kept a matching twin... like a placeholder object at the end of the torch, calculated its world position, and then updated a real light in the World node to match or something... but that sounds pretty ineffecient.
7  Java Game APIs & Engines / Xith3D Forums / Re: Animation, loaders, bones, weights and morphin on: 2004-11-03 19:49:10
Well, our devs don't have access to any of the high end modelling packages, so we use TrueSpace (for environments) and Milkshape (for avatars). Milkshape is simple, cheap, and the file format is pretty trivial. We've had some of our people figure out how to do full imports from something like MAX into Milkshape, I think by first exporting to Unreal PSK and then into Milkshape. I'll have to ask our people how they did it.

What we're talking about is a fully custom posable internal skeleton that deforms the single mesh skin attached to it. We match pre-recorded joint animations to specific skeletons, and then we match specific skeletons to mesh skins... so one skeletal animation can be used for thousands of mesh skins, as long as they both use the same skeleton. Although we use pre-recorded skeletal animations, it's just as possible to do runtime skeleton movement calculations... it's just something that we personally don't need to do.

Now just to figure out how to do it in Xith...
8  Java Game APIs & Engines / Xith3D Forums / Re: Animation, loaders, bones, weights and morphin on: 2004-11-03 02:22:39
You're talking about a standard skeletal single-mesh model. Being that it's probably the most common means of animating characters now, I don't know why people seem to be unclear on what you're talking about.

We do exactly this in our custom in-house 3D engine, using the Milkshape format (Milkshape is cheap and the file format is pretty trivial). We're in the process of recoding for Xith, and will be tackling this exact same issue for our Xith application in the near future. However, if it requires any Xith modifications (ie, can't be done on the application level) I doubt we'll be able to do it.
9  Java Game APIs & Engines / Xith3D Forums / GUI->Foreground Transform3D solution on: 2004-10-25 19:55:26
Just wanted to give ya'll food for thought, since it took me a couple days to work this out.

I'm designing a GUI system that works on a Foreground node at a distance of -0.6f from the camera.

First, using the screenToFG() function I previously figured out:

Point3f screenToFG (Point screen, float depth)
float xfrac = (float)((screen.x / canvasWidth) - 0.5f) * -2.0f;
float yfrac = (float)((screen.y / canvasHeight) - 0.5f) * 2.0f;
float heightA = canvasTanFOV * depth;
return new Point3f(xfrac * heightA * canvasAspect, yfrac * heightA, depth);

where canvasTanFOV = Math.tan(canvasFOV)

Using this, I determined that at a depth of -0.6f, a quad that exactly covers the entire screen is of the following 3D coords in the Foreground node:

Pixel -> Foreground 3D coords
(0,0) -> (-0.559797, 0.41984773, -0.6)
(800,600) -> (0.559797, -0.41984773, -0.6)
Size: 1.119594 x 0.83969546

Then, to get even fancier, I figured rather than making custom fuctions to do all this math for me, why don't I just figure out a transformation matrix to do all this work for me. So I ended up with this:

float xscale = 1.119594f / canvasWidth;
float yscale = 0.83969546f / canvasHeight;

TransformGroup foregroundTG = new TransformGroup();

// This transform scales pixels to 3D size, and flips the Y coord    
Transform3D tmp = new Transform3D();
tmp.setScale(new Vector3f(xscale,-yscale,1));

// This transform recenters 0,0 from the middle of the
// screen (from 3D style) to the upper left (to screen
// style). It also drops everything back -0.6f to the GUI plate.

// Note that after the previous scaling, the X and Y
// coords are now in pixels!
Transform3D tmp2 = new Transform3D();
tmp2.setTranslation(new Vector3f(-canvasWidth/2,-canvasHeight/2,-0.6f));

Foreground fg = new Foreground(foregroundBG, View.VIEW_FIXED);

Now you can create quads with vertices in X, Y pixel coords (with Z=0) and it should map into the Foreground 3D coords automatically. Just make sure to add your quads to foregroundTG.

Another cool benefit is that with the entire GUI system based on a single TransformGroup, you can reposition the entire GUI in one step... like scrolling it off the screen, shaking it, etc.

Maybe a new ScreenGUI node (extends Foreground node) that does all this automatically? I couldn't even begin to put that into Xith, just an idea. I got my code working with the above anyway, so I'm good to go already.

Possible issues to be debugged... I might have one too many negative signs in there, flipping (and reflipping) things too many times but coming out correctly in the end. Also, the Foreground stack looks like this:

ForegroundBG -> ForegroundTG -> user quads

I dunno if the ForegroundBG is really necessary. The Foreground node only seems to accept BranchGroups, maybe it can be made to accept just Nodes and then we can skip the extraneous ForegroundBG? I don't know how to do any of this, I just know the code above works for my needs Smiley
10  Java Game APIs & Engines / Xith3D Forums / Re: Creating textures during runtime on: 2004-10-24 04:38:40
Solution... the geom object requires the following appearance component:
11  Java Game APIs & Engines / Xith3D Forums / Re: Creating textures during runtime on: 2004-10-24 01:57:34
Well, no matter what I do, I cannot get the texture background to be transparent. I can even set every pixel to a 100% transparent color, but when drawn in Xith, it comes out black.


BufferedImage bi = new BufferedImage(width, height, BufferedImage.TYPE_INT_ARGB);
Graphics2D g2 = (Graphics2D) bi.createGraphics();

Texture2D stringTex = (Texture2D), "RGBA",
         false, Texture.BASE_LEVEL, Texture.BASE_LEVEL_LINEAR,
          Texture.WRAP, false, TextureLoader.SCALE_DRAW_BEST);

Any thoughts? I've done a dozen different things, it all comes out the same... no matter what I do, the texture simply will not render transparent. Is there some sort of switch on the texture, the scenegraph object, or something involving using the Foreground node that indicates it has transparency or something? Testing the default pixel of the freshly-created texture, it's 100% transparent black already (ARGB=0).

Note that I don't want to set a transparency level on the entire texture... just on the background pixels so the text doesn't have a background color.
12  Java Game APIs & Engines / Xith3D Forums / Re: Merge Java3D and Xith3D? on: 2004-10-23 18:53:51
Actually we just have a pre-loaded model as a placeholder for delayed models in transit, and we just use a flat grey texture for delayed textures in transit. No framerate impact... generally speaking, the placeholder content has a better framerate than the actual content. The entire delayed process works in less than a second or so, and we find that people accept the streaming nature of the system very readily... much more readily than waiting for a 2GB pre-game download to finish, for instance. They'd rather be up and playing, and then only download content as they first encounter it, than needing to install 2GB (ie, EverQuest) all at once for content they may never encounter in their playing experience. I tell ya, dialup people really really appreciate that. Not to mention that we can dynamically modify the universe on serverside and not incur a per-player patch penalty on the next login.

The only reason I asked the Xith devs first is because they already know the Xith source... and when it's the difference between one person doing it in 5 minutes, versus me taking 5 days just to understand the Xith code enough not to screw it up, I figure I could at least ask first.

As far as Aviatrix3D, it's not as advanced as our own in-house 3D engine, and like was said earlier, doesn't seem to have the ongoing development speed of Xith. I guess just any issue not directly related to making Quake games I'll just have to shut up about.
13  Java Game APIs & Engines / Xith3D Forums / Re: Creating textures during runtime on: 2004-10-23 18:14:07
Well, I have a textured-quad creator function. I just pass a boolean whether to create the vertices in rightside-up or upside-down order, and then use that whenever I know I'm going to be either using file-loaded textures (rightside-up vertices) or generated/runtime-modified textures (upside-down vertices).  True, you could do the same to the UV instead of the vertices, but I didn't think of that at the time.

You definately don't want to be flipping a runtime-modified texture every time you do an update to it.

I'm stuck right now though... I'm using some code I found for Text2D, which basically uses a generated texture to have AWT draw font text onto it. But I can't get the background to be transparent, because I think it starts as opaque black when created, and nothing you do (including painting with a fully alpha color, which I think goes on transparent over the existing opaque black, not replacing it) seems to work. I recall seeing the per-pixel byte array available somewhere, I'll probably just go replace that here next, and see if that works. But that's another one you gotta keep upside-down, since it's runtime generated.
14  Java Game APIs & Engines / Xith3D Forums / Re: ui xith3d on: 2004-10-23 07:01:46
Yeah, each tile has it's own quad, and the depth is 0.6f. I'm using the Maze3D code, with has a near clip of 0.5f, any I found that the avatar collider they used tends to keep the world 3D objects at least 0.7f from the camera. So I get a 0.5 to 0.7 range to put a GUI that won't be clipped by the near plane, nor have world geometry cutting into it.

I'm also experimenting with making a GUI entirely of 3D objects (ie, colored quads and text stacked on each other, instead of a tiled texture plate with the GUI painted onto it). It's really going to boil down to how many 3D objects can be handled per frame, versus how much texture region gets invalidated and must be reuploaded per frame...
15  Java Game APIs & Engines / Xith3D Forums / Re: ui xith3d on: 2004-10-22 17:08:03

o  Since full screen is not in 2^n dimensions how should/would I size a base texture

Can you simply have a pow2 texture bigger than needed which you just cut off the bits you don't need?

I ran my own experiments, and found that a full-screen 800x600 texture (blown up to 1024x1024 internally) suffered from sufficient "UV float fuzziness" that it was only about 80% pixel accurate. The closer the base image got to 1024x1024, the closer to pixel-accurate it became.

In other words, there was enough UV float fuzziness that texture pixels were not being rended, because their neighboring pixels were often chosen to be rendered instead, making it look like the drawn image was a poor copy-of-a-copy type image.

My GUI system currently uses a tiled texture process, where each texture tile is exactly a power of 2, and its base polygon is sized to match exactly a 1:1 screen pixel size. It works perfectly and is pixel-accurate, using tiles that are 64 or 128 square. I haven't yet decided if I'm going to use the tiled textures for each GUI window, or just a single full-screen collection to draw the entire GUI system on a single surface.

The trick is that the texture must be a power of 2 so UV is texel accurate, and the base polygon must be 1:1 screen pixel sized, so it's screen pixel accurate as well.
16  Java Game APIs & Engines / Xith3D Forums / Re: Creating textures during runtime on: 2004-10-22 11:08:01
Hmm, this works almost perfectly...


ImageComponent2D tmp = (ImageComponent2D)texture2.getImage(0);
BufferedImage tmp2 = tmp.getImage();
Graphics2D tmp3 = tmp2.createGraphics();

... except it's upside-down, compared to drawing onto the BufferedImage before creating the texture. But doing it this way, you can modify the texture after it has been created, and the changes go into effect immediately.
17  Java Game APIs & Engines / Xith3D Forums / Re: Creating textures during runtime on: 2004-10-22 10:56:19
Okay, figured out the first two... but the texture doesn't seem to update if I draw on it after creation.


BufferedImage BI = new BufferedImage(Xsize,Ysize,BufferedImage.TYPE_4BYTE_ABGR);
Graphics2D tmp = BI.createGraphics();
Texture2D texture2 = (Texture2D), "RGBA", false, 0, 0, 0, false, Texture.NICEST);  

If I want to draw on the texture with the Graphics2D after the texture has been created, does anyone know how to push/flag it back to Xith for update? Texture2D.setDirty(true) doesn't do it.
18  Java Game APIs & Engines / Xith3D Forums / Re: Foreground node + picking = exception on: 2004-10-22 02:19:59
I dunno, it works for me at 800 x 600 at least Smiley
19  Java Game APIs & Engines / Xith3D Forums / Creating textures during runtime on: 2004-10-21 21:17:55
I'm working on our GUI and need to create a blank texture of size X, Y with alpha, that we can later draw into manually.

What's the correct way to...

1) Create this blank texture. I tried TextureLoader.constructTexture, but none of the parameters are documented and I have no idea what they are. I tried just new Texture2D(), but it crashed with a null pointer. I couldn't find any demos that created textures at runtime.

2) Draw into the texture on a per-pixel level. I'm assuming you somehow get a Graphics2D object for drawing into the texture... but if we gotta poke pixels into an image byte array, that works too.

3) Update the texture back to Xith/OpenGL

Much obliged.
20  Java Game APIs & Engines / Xith3D Forums / Re: Foreground node + picking = exception on: 2004-10-21 10:51:22
Figured it out...


Point3f screenToFG (Point screen, float depth)
float xfrac = (float)((screen.x / canvasWidth) - 0.5f) * -2.0f;
float yfrac = (float)((screen.y / canvasHeight) - 0.5f) * -2.0f;
float heightA = canvasTanFOV * depth;
return new Point3f(xfrac * heightA * canvasAspect, yfrac * heightA, depth);

Where canvasTanFOV is equal to Math.tan(canvas.getFOV()), but I only calculate that once Smiley

tan(f)=opp / adj, where we know the f=FOV, adj = depth, and calculate O. Then it's scaled by the screen coords.
21  Java Game APIs & Engines / Xith3D Forums / Re: Foreground node + picking = exception on: 2004-10-21 08:43:45
I wouldn't even need to use the official Xith picking if I could just figure out a screen coords -> Foreground coords equation, for a given depth from the camera. But my numbers just aren't coming out right yet, and I've been working 4 days on it.
22  Java Game APIs & Engines / Xith3D Forums / Re: Foreground node + picking = exception on: 2004-10-20 15:58:48
Here's the relevant code from jogl/
public void renderDone()
      if (pickMode)
        pickRenderResults = convertSelectBuffer(gl.glRenderMode(GL.GL_RENDER));

private PickRenderResult[] convertSelectBuffer(int count)
      PickRenderResult[] results = new PickRenderResult[count];

It appears the gl.glRenderMode(GL.GL_RENDER) call is returning a negative value. It's that value being passed to convertSelectBuffer() as the size of the array to be created.
23  Java Game APIs & Engines / Xith3D Forums / Foreground node + picking = exception on: 2004-10-20 08:55:29
Trying to use view.pick() to pick a quad drawn on a Foreground node. When I do, I get the following exception only when the coordinates are within the quad (ie, successful pick):

       at com.xith3d.render.jogl.CanvasPeerImpl.convertSelectBuffer(
       at com.xith3d.render.jogl.CanvasPeerImpl.renderDone(
       at com.xith3d.render.jogl.CanvasPeerImpl.display(
       at com.xith3d.render.jogl.CanvasPeerImpl.render(
       at com.xith3d.scenegraph.View.pick(
       at CRG_World3D.getPickRenderResult(
       at CRG_GUI.Message(
       at CRG_Manager.Broadcast(
       at CRG_Keyboard.update(
       at CRG_Manager.runCycle(
       at CRG_VXI.go(
       at CRG_VXI.main(

Any thoughts? It only seems to happen on what would have been a successful pick otherwise.
24  Java Game APIs & Engines / Xith3D Forums / Re: ui xith3d on: 2004-10-20 00:29:01
I'm highly interested. I was starting to work on porting our own in-house GUI system to texture -> Foreground, but I'm currently hung on coming up with a way to guarantee a quad drawn in a Foreground node exactly matches the screen size down to the pixel. I was going to make a tiled texture system, because the float UV is too coarse to work with a single screen-sized texture with per-pixel accuracy, but I was getting stumped with screen coords -> Foreground coords conversion.

What I was planning on doing was casting screen coords to Foreground coords at a distance of -0.5f, which would be the GUI plate.  Then doing 32x32 screen-pixel tiles, which doing the same pickray would give me what size quads to put on the GUI plate, with individual 32x32 textures.  Then just a matter of wrapping a single Graphics interface around the tile mosaic, so that it appears as a singular drawing surface. I figure the smaller the tiles, the better update resolution when only a small region is dirtied.

If somebody could give me a hint on screen coords -> Foreground coords, I could churn all that out. Would give him a singular drawing surface that covers the entire screen, but with per-pixel accuracy.
25  Java Game APIs & Engines / Xith3D Forums / Re: Merge Java3D and Xith3D? on: 2004-10-19 21:06:39
Last check, jME supported mac just as much as LWJGL does.  There were problems with loading image formats with awt, but there are ways around that.  If you posted your problem and your fix on the forums, I'm sure it would be well recieved

I already did, months ago. I said you had to disable the opening options dialog box, because any usage of AWT/Swing completely screws up the JVM for any usage of LWJGL later on. I wrote a custom TGA loader and used it to recode one of the basic demos, avoiding the AWT-based loader. I uploaded it all to the devs and said, "Here's your problem, here's your fix, and here's one of your examples recoded to work on the Mac". And here, months later, nothing's been changed and even the recoded example wasn't updated to work.

I don't know what you're refering to about the ""Why in the world would you EVER need that in a GAME?" but usually if many people are questioning your design they have a valid point.

Well, the first thing I need is for model loaders to notify me whenever they require a texture, because I have to download or generate the texture in realtime with a delayed provider mechanism. The first retort is, why wouldn't you ever not have a texture immediately available for loading? That's no good when you have a constant streaming content system being provided from a remote server. I made suggestions like model and texture loaders being able to load from streams, but it was why would a game ever be loading resources from anywhere other than from disk? I asked about per-poly texturing, because our Mars game uses real Mars MOLA data where each polygon is almost half a mile in size, but was shot down that my needs were too specialized.

but usually if many people are questioning your design they have a valid point

Or maybe they're just not doing what we're trying to do. Is it a valid point to say that it's utterly unimaginable that your textures wouldn't be immediately available, on disk, at the time of model loading? Or that it's a bad design if that's the case?

Point being that unless you're making a Quake with Xith, or making a CAVE with Java3D, you're basically screwed for Java in terms of what's available.  

For the record, I think these guys do a hell of a job, because I know they're doing it for free, and I can't really ask for much. It just annoys me when people harp Java as the best thing since sliced bread and it's critically missing various options as such, and particularly when I make meager suggestions and then am told that I must being doing something wrong if I could ever think I would have a need like that... like who in the world would ever need something like that? Well, I do... just because people don't see why you'd ever need it in a Quake game, suddenly means that I must be doing it horribly wrong somehow...
26  Java Game APIs & Engines / Xith3D Forums / Re: Merge Java3D and Xith3D? on: 2004-10-19 18:39:34
Not so good when people look at 3D in Java and only see it for making games, and those of us doing serious stuff move on to something else instead. Hardly the ultimate programming platform evangelized by some, if that's the best Java can offer.

Funny how some will say that 3D Java will never be taken seriously until somebody makes a good game, but on the other hand, 3D Java will never be taken seriously if it can only make games.
27  Java Game APIs & Engines / Xith3D Forums / Re: Merge Java3D and Xith3D? on: 2004-10-19 17:53:54
And jME just needs more press

jME needs to work on the Macintosh. I figured out to fix it, uploaded example code on how to fix it, came back 6 months later and it was still completely broken.

LWJGL and jME have fundamental design problems that prevent them being used anywhere other than niche gaming markets

The biggest problem I've been having in this regard is anytime I suggest or ask a question involving my project, the first retort is always "Why in the world would you EVER need that in a GAME?" Answers to questions are usually in the context of "Well, you don't use that code anywhere except when you shoot your sniper rifle, so it's not important". So people's interest, and therefore willingness to answer questions or add engine support, for anything non-game related is virtually zero.

Which basically means if you're not making a game, your choice is either Java3D or you're on your own to figure it out.
28  Java Game APIs & Engines / Xith3D Forums / Re: Foreground and screen-size texture on: 2004-10-19 01:20:44
It appears that it is, indeed, a "fuzzy float" UV issue. I've noticed that the distortion is more pronounced whenever the image is farther from the next power of 2 (ie, 800x600 -> 1024x1024), and the distortion is more pronounced on the axis furthest from it (ie, 800 is closer to 1024 than 600, so the X axis is less distorted than the Y axis).

I was looking through the UIOverlay code, and I see David coded up a tiled texture process, which is what we used in our own in-house 3D engine. That's just as well though, I'd rather the full-screen image be broken into very small tiles, to help keep the "dirty texture needs updating" resolution as high as possible. Nothing worse than updating one pixel on a 1024x1024 texture and requiring the entire thing be pushed up again...

29  Java Game APIs & Engines / Xith3D Forums / Re: Foreground and screen-size texture on: 2004-10-18 16:07:48
I did a high-quality rescale of the 800x600 GUI example screenshot and made a 1024x768 version. When I load that into my client and draw it at 800x600, it comes out with about 98% accuracy. A much better improvement, but I'd hate to think of coding a GUI system that works on an 800x600 display only by writing to a 1024x768 texture, heh.

Is there some sort of "quality vs speed" switch somewhere that I could set to do more accurate texturing?
30  Java Game APIs & Engines / Xith3D Forums / Re: Foreground and screen-size texture on: 2004-10-18 15:44:05
As far as I thought, OpenGL required power-of-2 sized textures that were a maximum size of 256 x 256. However, already thinking of that, I rescaled the texture in a graphics editor to get a feel for how much it had been rescaled down... and the quality I'm seeing appears consistent with only having been scaled down a few pixels (800x600 -> 512x512 looks far worse, with much more data lost).

I was wondering if maybe the canvas had been scaled up to 1024x1024 (next power of 2), and then using floats to UV back down to 800x600 was responsible for missing a pixel here or there.

I mean, the quality is pretty good, I'd say 90%, but to be the basis of a GUI I gotta have per-pixel accuracy. And I'd understand if I was stretching or shrinking the on-screen drawing of the texture to a size that was not the original, but I just can't seem to figure out how it's seemed to have lost like 10% of the image. I think it's probably more like it's trying to grab a pixel, and the UV float fuzziness means that it's occasionally grabbing a pixel that's just 1 pixel too high or low...
Pages: [1] 2
Riven (208 views)
2019-09-04 15:33:17

hadezbladez (4950 views)
2018-11-16 13:46:03

hadezbladez (1828 views)
2018-11-16 13:41:33

hadezbladez (5228 views)
2018-11-16 13:35:35

hadezbladez (1033 views)
2018-11-16 13:32:03

EgonOlsen (4419 views)
2018-06-10 19:43:48

EgonOlsen (5251 views)
2018-06-10 19:43:44

EgonOlsen (2989 views)
2018-06-10 19:43:20

DesertCoockie (3883 views)
2018-05-13 18:23:11

nelsongames (4314 views)
2018-04-24 18:15:36
Java Gaming Resources
by philfrei
2019-05-14 16:15:13

Deployment and Packaging
by philfrei
2019-05-08 15:15:36

Deployment and Packaging
by philfrei
2019-05-08 15:13:34

Deployment and Packaging
by philfrei
2019-02-17 20:25:53

Deployment and Packaging
by mudlee
2018-08-22 18:09:50

Java Gaming Resources
by gouessej
2018-08-22 08:19:41

Deployment and Packaging
by gouessej
2018-08-22 08:04:08

Deployment and Packaging
by gouessej
2018-08-22 08:03:45 is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!