hello,

first my aim: i want to port karga speech bubbles to GL renderer. they are currently blitted over awt.Graphics by using methods of graphics class. the bubbles has a popup effect, that is when they first appear they have an alpha value of 0 and alpha value increases in time giving a feeling of they appear from nothing.

how can i do that with GL renderer ? can i change alpha value of a texture when blitting it ? FrameBuffer.blit(..) method doesnt support it. Texture class itself also doesnt have any methods to change alpha.

Texture has an add method to mix two or more textures with some weight. adding bubble texure to an empty texture with an increasing weight may be an option, but that way colors will also change in time.

what else can i do ?

thanks,
r a f t

hello,

is it possible to change FrameBuffer's size without destroying it ? LWJGL allows changing display mode while running: Display.setDisplayMode(mode) jPCT continues to operate after change but it doesnt realize mode has changed. if we switch to a larger mode, jPCT renders only to a smaller area on screen, if we switch to a smaller mode, i guess it is over rendering.

is the only way to do this, disable GL renderer, dispose buffer and re-create with new size ? besides that popping efect, jPCT prints warnings below:
WARNING: ZBuffer depth of 24 not supported - trying something else now...!
WARNING: ZBuffer depth is now set to 16bpp!

if i dispose and re-create buffer again, it says:
WARNING: ZBuffer depth of 16 not supported - trying something else now...!
WARNING: ZBuffer depth is now set to 16bpp!

this goes on like this: 24 not supported, 16 not supported, 24 not supported...

and, just for wonder, the javadocs says first GL renderer should be enabled than sw will be disabled. is it really important ? cant we change the order ?

thanks
r a f t

i'm trying to map KeyState to awt.KeyEvent with the following code piece:

                int modifiers = 0;
                if (Keyboard.isKeyDown(Keyboard.KEY_LCONTROL) ||  Keyboard.isKeyDown(Keyboard.KEY_RCONTROL))
                    modifiers |= KeyEvent.CTRL_DOWN_MASK;
                if (Keyboard.isKeyDown(Keyboard.KEY_LSHIFT) ||  Keyboard.isKeyDown(Keyboard.KEY_RSHIFT))
                    modifiers |= KeyEvent.SHIFT_DOWN_MASK;

                final KeyEvent keyEvent;
                if (state.getState()) // pressed
                    keyEvent = new KeyEvent(EVENT_SOURCE, KeyEvent.KEY_PRESSED, 0, modifiers, state.getKeyCode(), KeyEvent.CHAR_UNDEFINED);
                else keyEvent = new KeyEvent(EVENT_SOURCE, KeyEvent.KEY_RELEASED, 0, modifiers, state.getKeyCode(), KeyEvent.CHAR_UNDEFINED);

but unfortunately Keyboard.isKeyDown(left-right control) never returns true. pressing/releasing control key never generates an event either. any ideas why this may happen ?

this is a fedora 4 linux laptop, with only left control key. awt itself properly generates control key events

btw, it may be handy to include modifiers in KeyState class.

r a f t

hello,

as Todd mentioned about unfulfilled promises to post code i felt guilty. here is the Animater class i use in karga to animate avatar movements. it coordinates animations deciding when to switch animation and during completion either rollback the animation or go till end. you cannot directly compile it but it will give an idea

say your avatar is walking forwards and you animate accordingly. then movement stopped but you're in the middle of walk animation, what will you do now ? leave the avatar as it is (one foot top) or play animation till end, or play it backwards ? what will you do when avatar decided to strafe left/right while he was walking forward ? how will you smootly switch between walk forward and strafe animation ? Animater class takes care of these. it does the low level dirty job..

the typical usage is as follows: this code piece is called every frame. seconds is passed seconds since last frame

// clamping mode is important here, as we dont want roundings at ends
Avatar.getAnimationSequence().setClampingMode(Animation.USE_CLAMPING);
if (moving) {
    Animater.Frame frame = animater.getNext(step, seconds);
    animate(frame.index, getSequenceNumber(frame.sequence));
} else {
    if (animater.hasNext()) {
        Animater.Frame frame = animater.getNext(seconds);
        animate(frame.index, getSequenceNumber(frame.sequence));
    }
}
Util3D.Step is an enum defining what step avatar makes during movement, one of:

NONE, FORWARD, BACKWARD,  JUMP_UP, JUMP_FALL, FALL_DOWN,
LEFT, RIGHT, // strafe
TURN_LEFT, TURN_RIGHT, // turn around
FAST_FORWARD; // run

AvatarInfo.Animation stores information about animation sequences of avatar. the only relevant part used here is period, how long the sequence lasts. the enum Interval is the segments of animation sequences. as forum settings doesnt allow to post such a long piece of code i placed it in karga site  here is the Animater class

hope this helps 
r a f t

welcome jKilavuz, a sister project of karga

for a couple of months i've been working on a pathfinding system for karga. i've read a lot, thought a lot and concluded in pathfinding is not that hard, hard part is collecting necessary data. i've barrowed the idea at the great article at gamasutra. now it is already shaped and i'm happy with the results. here is how it works in short:

starting a from a set of points on ground, floodfills to 4 cardinal directions until all map is explored. this is our massive raw grid data consists of cells. it's a kind of 2d grid in 3d space which can take us up or down slopes, across bridges and over and under overpasses.  we than analyze cells and collide them into freely traversable rectangular regions called sectors and portals between sectors. all the process is automized and quite time consuming. we have the option to intercept with sector creation and to create custom portals for elevators teleporters etc.

here is a demo for our old friend quake level of fps example. move camera freely with arrow keys, a, z, s, x. click anywhere around and the avatar will come. f to follow avatar and toggle free camera again. almost all places are reachable. although unlikely if stuck r to reset to start position. v to visualize path finding sectors. dont miss the elevator 

it takes about 15 minutes to generate pathfind data on my 1.86 ghz notebook. there are a total of 384 sectors and 1348 portals. although the grid takes 5-6mb the runtime pathfinding information is only ~207k uncompressed

here are some key features and design goals:
* the pathfind algorithm is A*. it's a generic one not limited to kilavuz sectors
* minimum JRE version is 1.5
* kilavuz is targeted to java users not especially jPCT users. flood filling is plugable. there is a default implementation which uses jPCT's collision detection capabilities but it is not mandatory. the runtime only requires SimpleVector and Matrix classes to work. so any non-jPCT user can use kilavuz by simply transforming coordinates into his space
* all calculations are done in grid space. when executing path, coordinates are transformed back into world space. elevations are calculated by interpolation. the demo doesnt use any kind of collision detection but avatar nicely fits on ground almost all times
* users may intercept both with sector/portal creation and path exectution. the runtime supllies a small and limited set of classes to iterate over paths (either linear or curved) over time but anyone can use his own path execution system. the methods for converting between grid and world space provided. for special portals (like the elevator), the runtime uses factory interfaces to create relevant path segments. for example, this way one can plug actions like going somehere and calling the elevator by pressing a button

here is a shot from demo. top view with sectors visualized


and this is how our grid looks like. notice how the found path goes upstairs passing over itself. you can see the cells (the small circles), transitions between cells and sectors and portals here


although not certain, kilavuz will most likely be a commercial api with a limited freeware version. sorry i'm really broke nowadays :/

i will soon make a site for it when polished and documented the api

just for reference, kilavuz means guide in turkish

cheers
r a f t

edit: added a link to home site and moved the demo link to home too

last thing i remember was Egon said there was some legal issues and game will not be available for a while. now it completely disappeared no forum topic, no entry in projects page  i felt sad about it

i wondered what that legal issue was resulting in such a demolish 

the problem below took me days to resolve, so i thought it may help others if it's documented in a thread.

-- o --

sometimes models arent loaded with 3dsLoader as they look in 3d max. i mean somehow their placement and rotation change when loaded into jPCT.

i first encountered this problem with the commercial village set i use in karga. the producer suggested to use XRef and it effectively solved the problem. this is done by either adding an XRef modifier to each object's stack or by using reset x-form utility in utilities panel (which indeed does the same for all selected objects)

however on some situations XRef doesnt solve the problem. the objects are still misplaced when loaded into jPCT. there seems to be a hidden translation or whatever which XRef doesnt clear, and which in turn confuses the jPCT's loader. here is the solution, it took me days to find it:

create a new object (say a box) and align its center by align tool with our object in question. convert the new object to editable mesh (or poly) and attach our object to it. now go to element sub object level, select new object and delete it. your object has now a brand new transform.

this is the document i found this workaround in: http://fosters.realmwarsgame.com/maxdts/section2.html

note: maybe you may wish to add to this thread in time to build a list of helpful 3d max tips. Egon, maybe you may wish to open a new forum category for this purpose

hope this helps
r a f t

hello,

this is what Egon said in an email:
Texture aliasing is an undersampling artifact that occurs, when only a few samples of a texture (due to the size of the polygon) are taken to draw the image.

Hardware is using mip mapping (i.e. smaller textures for smaller polygons in the distance) to work against this. The software renderer doesn't do this, because determining the correct mipmap level would be quite expensive. To prevent it (well, you can't really prevent it, just try to minimize the effect) use textures with less contrast and/or larger structures.

i guess, no matter how one selects a texture, he cannot avoid texture aliasing for objects like grass, trees etc due to the nature of thier texture.

so how to beat it when using software renderer ?

i thought of emulating mip mapping to some degree by re-assigning objects' textures based on distance, but i'm quite unsure if it worths a try. for trees it may help, but for large objects like ground it wont. (since camera is close to some part of object and far to other) this approach will also break 3DSLoader's multiple texture assignments to a single object. it requires an Object3D.recreateTextureCoords() each time the texture size changed (i dont know how expensive it is)

using PolygonManager to set textures per polygon instead of per object maybe an alternative but i guess doing that for every polygon will be a sure performance killer. also i dont know if there is a way of getting all polyon id's

so is there a nice solution for this ?
thx

r a f t