Isotröma (Tesseract 2)

WIP games, tools & toy projects
#41

Hello,

I walk back out of my coffin again (hin hin) to give a few news of this project abandoned for numerous mounthes.

To calmly take it up again, i tried to take advantage of the code functionalities to start a cubes sceneries system (it would be cool to provide this possibility, and it fits well to the game vectorial design :wink: ).

A few screens ?

1024×768 850 KB

1024×768 949 KB

So here is the result of my debuts (a little map generator), after a week (cubes really simplify a lot of things !), that i submit to your merciless judgement :smiley: :

http://tesseract-fps.sourceforge.net/isotroma/isotroma_exp.jnlp
(Keys : E, S, D, F, Space | Mouse : Direction | Left click : Destruct | Right click : Construct)

Requirements :

  • Support 1024 MB heap size
  • Support GLSL

Warnings :

  • Huge maps + several octaves = awfully slow generating time !
  • Don’t choose 1024x1024 cubes map, it can cause weird memory behaviors (EDIT : Yeah, fixed !)

About this last point i’m puzzled : each cube takes 1 byte in RAM so hugest maps in the demo (1024x1024x256 cubes) must take 256 MB, how can it cause problems with 1024 MB of heap (i don’t think the rest of the app takes 768…) ? Have you an idea :frowning: ?

#42

Wow, looks awesome! Although, I really liked your previous design with the randomized shapes. There are already so many voxel games, your other design was unique!

#43

What makes you think each cube is only 1 byte?

Also, looking pretty good, I like the sky texture. :smiley:
Would be cool if the clouds had some vertical depth to them, though.

#44

@opiop65
Thanks a lot !
Actually it’s not the most innovative idea of the year ;D , i consider it most as an ingredient we could use among others, maybe it would be fun to mix these different styles of scenery in same maps :wink: …

@BurntPizza
Thanks !
Well, the cubes are stocked in a simple bytes array :

private byte[][][] types;

There’s also a 2D array of vertical chunks that read this bytes array to build geometry and send it to chipset as VBOs.
Each chunk only stores 6 floats for frustum and its VBO id.
Is there a trap somewhere that i don’t see :-\ ?

#45

Well each array is an object and thus has an object header and etc, according to this article, about 12 bytes. And then there is padding bytes to align the objects to the 8-byte granularity. So each byte[][][] is actually ~16 bytes I believe. Don’t quote me on any actual numbers, but my point is that a byte[ x][y][z] takes up a lot more space then xyz bytes.

You could probably do a lot to help with this by collapsing it to a one-dimensional array (a byte[xyz]), so as to not have so many sub-array objects.

#46

Hello,

I walk back out of my coffin again (hin hin) to give a few news of this project abandoned for numerous mounthes.

To calmly take it up again, i tried to take advantage of the code functionalities to start a cubes sceneries system (it would be cool to provide this possibility, and it fits well to the game vectorial design :wink: ).

A few screens ?

1024×768 850 KB

1024×768 949 KB

So here is the result of my debuts (a little map generator), after a week (cubes really simplify a lot of things !), that i submit to your merciless judgement :smiley: :

http://tesseract-fps.sourceforge.net/isotroma/isotroma_exp.jnlp
(Keys : E, S, D, F, Space | Mouse : Direction | Left click : Destruct | Right click : Construct)

Requirements :

  • Support 1024 MB heap size
  • Support GLSL

Warnings :

  • Huge maps + several octaves = awfully slow generating time !
  • Don’t choose 1024x1024 cubes map, it can cause weird memory behaviors (EDIT : Yeah, fixed !)

About this last point i’m puzzled : each cube takes 1 byte in RAM so hugest maps in the demo (1024x1024x256 cubes) must take 256 MB, how can it cause problems with 1024 MB of heap (i don’t think the rest of the app takes 768…) ? Have you an idea :frowning: ?

#47

Thank you very much !!
Actually i didn’t consider a n-dimensionnal array is an array of pointers on some other objects (didn’t know, shame on me it’s rather important !) .
I’ll implement 1 dimension arrays quick ;D !

#48

Wow, looks awesome! Although, I really liked your previous design with the randomized shapes. There are already so many voxel games, your other design was unique!

#49

What makes you think each cube is only 1 byte?

Also, looking pretty good, I like the sky texture. :smiley:
Would be cool if the clouds had some vertical depth to them, though.

#50

@opiop65
Thanks a lot !
Actually it’s not the most innovative idea of the year ;D , i consider it most as an ingredient we could use among others, maybe it would be fun to mix these different styles of scenery in same maps :wink: …

@BurntPizza
Thanks !
Well, the cubes are stocked in a simple bytes array :

private byte[][][] types;

There’s also a 2D array of vertical chunks that read this bytes array to build geometry and send it to chipset as VBOs.
Each chunk only stores 6 floats for frustum and its VBO id.
Is there a trap somewhere that i don’t see :-\ ?

#51

You’re welcome! ;D

Tell me how the memory efficiency goes. :point:

#52

Well each array is an object and thus has an object header and etc, according to this article, about 12 bytes. And then there is padding bytes to align the objects to the 8-byte granularity. So each byte[][][] is actually ~16 bytes I believe. Don’t quote me on any actual numbers, but my point is that a byte[ x][y][z] takes up a lot more space then xyz bytes.

You could probably do a lot to help with this by collapsing it to a one-dimensional array (a byte[xyz]), so as to not have so many sub-array objects.

#53

Thank you very much !!
Actually i didn’t consider a n-dimensionnal array is an array of pointers on some other objects (didn’t know, shame on me it’s rather important !) .
I’ll implement 1 dimension arrays quick ;D !

#54

You’re welcome! ;D

Tell me how the memory efficiency goes. :point:

#55

Hey, i just uploaded the 1 dimension arrays version, it works fine now :slight_smile: .
Actually, the memory now increases of about 300 MB at a 1024x1024 map instanciation,
Thanks again 8) !

#56

Hey, i just uploaded the 1 dimension arrays version, it works fine now :slight_smile: .
Actually, the memory now increases of about 300 MB at a 1024x1024 map instanciation,
Thanks again 8) !

#57

You can implement a cache-friendly version with Riven’s awesome 1D to 3D array mapping techneque:


:slight_smile:
#58

You can implement a cache-friendly version with Riven’s awesome 1D to 3D array mapping techneque:


:slight_smile:
#59

Hey, thanks !
Unfortunately this code seems to work only for power of 2 sizes and i have to support any size :frowning: .
I guess i have no choice but a “regular” mapping :


private byte getType(int i, int j, int k) {
	return types[(k * width_x_depth) + (j * width) + i];
}

But this code is actually pretty clever, i’ll remember it, thank you :slight_smile: !

#60

Hey, thanks !
Unfortunately this code seems to work only for power of 2 sizes and i have to support any size :frowning: .
I guess i have no choice but a “regular” mapping :


private byte getType(int i, int j, int k) {
	return types[(k * width_x_depth) + (j * width) + i];
}

But this code is actually pretty clever, i’ll remember it, thank you :slight_smile: !