Main Menu
Menu

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.

Show posts Menu

Messages - Cowbox

#1
Projects / Re: VoxRaiders
December 01, 2012, 07:56:34 PM
Updated to v0.04!

Comes with the launcher to allocate memory now.

Has fluids! (Gas/water/lava are dangerous)

Made the menu less... temporary. xD
#2
Support / Re: Window icon?
December 01, 2012, 02:17:12 PM
Oh! xD

I didn't realise it was in AWT. :D

I just didn't have AWT imported where I tried it.

I shall give it another shot in a bit. :)
#3
Support / Re: Window icon?
December 01, 2012, 12:07:52 AM
I found that snippet already and can't do anything with it. (I don't have a pixelgrabber, or some of the other things it's after.)
#4
Projects / Re: VoxRaiders
December 01, 2012, 12:06:17 AM
Yeah, with graphics on high, it will be rendering:
7 layers per voxel slice, each with a texture of 1024x1024 ARGB.
There are 20 voxel slices.

So this is 140 1024x1024 ARGB textures, 20 of which, have a 2nd texture blended with them.

That's essentially all it's rendering, and I can get about 500FPS on a relatively good computer. (My laptop gets like 100FPS.)

The map generation just takes time because it's manipulating each of the 1024x1024x20 voxels, and assigning them a colour. (It also saves each voxel slice as a .png for map loading/saving as well.)
#5
Support / Window icon?
November 30, 2012, 11:14:55 PM
Ok, this seems ridiculous. xD

There has to be a better way to get one tiny little picture, into the top left of the window.

I mean, that one with the 4 keys, and the blue circle got up there somehow.

Surely there's some quick trick I'm missing where I just put icon.ico or something next to the .jar and it goes "Aha! - I'll just use that!"

Or a method somewhere in a class for "setIcon". xD

I've searched high and low for icons, lwjgl, bytebuffers etc. - and none of it seems to help a great deal.

I got to the point where I had:
org.lwjgl.opengl.Display.setIcon(bufs);

And thought, "Ah! All I have to do, is load an image in as a bytebuffer!"

But that seems a monster of a task as well. xD

What can I do?

Surely there's a way to get an icon on the jPCT window, I mean, it's already gotten one from somewhere. :(

Either that, or some kind of handler for the window, that can then be manipulated?

D: <Stuck>
#6
Projects / VoxRaiders
November 30, 2012, 09:48:33 PM

I thought it was time we announced our project!

VoxRaiders is essentially a mining game in development by Soharix.
We're using Voxeng5, a voxel engine built right on top of the jPCT engine. (Thanks to EgonOlsen for all his help with that.) :D

And yes, the game is inspired by LEGO® RockRaiders™.

There is no real objective yet, as this is only our 3rd release of alpha, but already many of the core game mechanics are in place:
* You can place miners, who will run about mining random walls.
* You can place barriers, to stop the miners running into trouble (lava).
* You can access all 1024x1024x20 voxels in the randomly generated world.
* Flowing fluids (water, noxious gas and lava are all hazards at the moment)

Features yet to come include:
* Vehicles
* Buildings
* Dangerous AI entities
* 2 additional AI algorithms (for waypoints and rudimentary pathfinding)

The current version, Alpha v0.04 can be downloaded here:


And here are some screenshots:

(The first one was taken before we made a more suitable bitmap font.)

Anyone having difficulty running it successfully is probably facing memory problems with Java.
#7
Support / Re: Blitting transparency troubles
November 23, 2012, 08:27:16 PM
Ah yes!

I knew I was being a retard xD

I had them saved as .png images already, I just wasn't loading with the transparency flag turned on.

Now everything works nice and awesomely. :D
#8
Support / Blitting transparency troubles
November 23, 2012, 03:59:20 PM
:D Me again,

I've got a HUD on my game at the moment that uses blitting of bitmap images as textures to put images on the display.

I'm slightly confused as to the behavior I'm seeing though.

The documentation (and just, the way the methods seem to suggest they work) implies that something like this:
buffer.blit(btn1,0,0,0,0,32,32,32,32,[b]0[/b],false);
would render the image with all areas of 0,0,0 as transparent.

However, it renders all areas with colours values less than 16,16,16 (so 15,15,15; 14,14,14; 13,13,13; etc.) as transparent. D:

Is there a way to stop this? (I've checked what colour depth I've been using, and switched variables around: none of it seems to make any difference.)

The other thing in conjunction with this is that it'd be nice if there was a way to set a particular colour to be used as transparent rather than 0,0,0 -> 16,16,16 - I mean, if I used 255,0,255 (a colour I'm not using) for transparency , then all black values would be available.

I keep looking through the documentation for a method along the lines of:
setTransparentColor(int r,int g,int b)
or something. :(

Please enlighten me :D! There has to be something I'm doing wrong. xD
#9
But the problem lies in the fact that when someone says "take a 32x32 image from 16,16 on this 400x300" image, you expect to get  a picture with dimensions 32x32 at the very least. xD
And most would expect the top left pixel of the image to have the same colour as 16,16 on the 400x300 image.

The documentation is just misleading and doesn't hint that this might be a problem some encounter with these particular methods. :(
#10
Hmm, well I suppose that makes sense.

I've just sucked it up and I'm using a 512x512 image for the sake of speed of conversion.

But the documentation on the blit commands is misleading therefore.

Because, in other libraries (AWT and Slick2D), whenever I use the 8 integers for source(x/y/x2/y2) dest(x/y/x2/y2) they all work in true pixels values, and this is what the documentation seemed to suggest to me. :(

Perhaps just a note to say something like "Make sure your image complies with powers of 2" or change the wording so it doesn't sound like destination pixel from/to and source pixel from/to.
#11
Ok this time I'm sure I've found a bug.

I just converted an old bitmap font decoder from Slick2D into jPCT. The principles are basically exactly the same.

The code I would want to use would be something like this: (for numbers)
public static void drawString(FrameBuffer b,int x,int y,String string)
{
if(string.length()>0)
{
for(int c=0;c<string.length();c++)
{
int ascii=(int)string.charAt(c);
if(ascii>47&&ascii<58)
{
b.blit(bmpFont,(ascii-48)*letterSize,letterSize*2,x+(c*letterSize),y,letterSize,letterSize,letterSize,letterSize,5,false);
}
}
}
}


This should theoretically work on this image:


But it displays a seemingly random jumbled subset of the image.

The only way I could get it to display the right numbers (or letters in other parts of the whole code) was to do something like this:
b.blit(bmpFont,(ascii-48)*letterSize,64*2,x+(c*letterSize),y,letterSize,64,letterSize,letterSize,5,false);
But I mean, why 64? How am I to use this usefully?

If I resize the image to 260x260, the original works, but has artifacts around the edges of characters and wastes space.

:(
#12
I'd probably just remove the other parameters for http://www.jpct.net/doc/com/threed/jpct/TextureInfo.html#add(int, float, float, float, float, float, float, int) because giving it those 6 floats makes you think you can change the UV data for the texture just added. (Exactly what I was thinking.)

So there should only really be the constructor (where the UV values can be set) and an add method that just adds a layer, but doesn't allow any manipulation. That's where one would use set. :)
#13
Ah, right, I understand now.
xD

Phew, I'm GLaD that's over. D:

You can see why you made this engine and not me. xD
#14
Ahh, I'm thoroughly confused then. :(

I don't understand how you meant for me to access the other layers:
QuoteSimply by not changing the coordinates for layer 0, i.e. get the u/vs, create a new TextureInfo with the original u/vs on the first layer and the modified ones on the second.
D:?
#15
Ohhhhhhhhhhhh

I'm a complete idiot.

I didn't realise the 6 parameters for the UV mapping were for 3 layers with 2 per layer. xD

Ok, so I've tried that, but now it's screwing up.

I'd have thought if I did something like this:
tileTexture(testObject,1,4,1);
It would loop the 2nd layer 4 times.

It instead just messes up all the texturing, like so:

I've also tried calcTextureWrap and calcTextureWrapSpherical, neither of which fix it. :(

(I can't help but notice when I do this as well it no longer combines the textures, it's actually just messing up layer1 and ignoring layer2.)

(For completeness, here is the method after editing it to support 3 scales:
public static void tileTexture(Object3D obj,float tileFactor0,float tileFactor1,float tileFactor2)
{
PolygonManager pm=obj.getPolygonManager();
int lastPoly=pm.getMaxPolygonID();
for(int i=0;i<lastPoly;i++)
{
SimpleVector uv0=pm.getTextureUV(i,0);
SimpleVector uv1=pm.getTextureUV(i,1);
SimpleVector uv2=pm.getTextureUV(i,2);
uv0.scalarMul(tileFactor0);
uv1.scalarMul(tileFactor1);
uv2.scalarMul(tileFactor2);
int id=pm.getPolygonTexture(i);
TextureInfo ti=new TextureInfo(id,uv0.x,uv0.y,uv1.x,uv1.y,uv2.x,uv2.y);
pm.setPolygonTexture(i,ti);
}
}

)