masvea
Posts: 2
Joined: Fri Feb 08, 2013 9:26 am

Re: Not Minecraft, but Blocky

Fri Feb 08, 2013 6:24 pm

Awesome. Thanks for the update! I can't wait to get home and try it out...

zproc
Posts: 31
Joined: Mon Sep 03, 2012 12:05 pm

Re: Not Minecraft, but Blocky

Sat Feb 09, 2013 2:51 pm

Hello,

i'm trying to build the PC version from GitHub, as I'm using a Mac so after importing the projects in Eclipse, i changed in the buildpath of ge.base and ge.framework the path ot the natives for using the Mac ones, but when I try to build and run i get this error in the console (and of course does not run/the game window closes immediately)

Code: Select all

Info Log of Shader Object: 1
--------------------------java.lang.RuntimeException: A compilation error occured in a shader.
	at ge.framework.shader.GL20Shader.createFromSource(GL20Shader.java:82)
	at ge.framework.shader.GL20Shader.<init>(GL20Shader.java:24)
	at ge.framework.shader.GL20Program.<init>(GL20Program.java:21)
	at ge.framework.shader.BasicProgram.<init>(BasicProgram.java:29)
	at ge.demo.game.Blocky.start(Blocky.java:238)
	at ge.demo.game.Blocky.main(Blocky.java:2526)

ERROR: 0:1: 'mat4' : syntax error syntax error

Looks like a shader error, and I know nothing about shaders... but i guess this should compile/run without errors as i can see there has a been a single commit of the PC/dev version recently... Maybe it tries to use GL ES 2.0 instead or GL shaders? I'm gonna look at the source and google, but if anyone has a clue about this, let me know. :)

User avatar
spsn
Posts: 72
Joined: Wed Nov 07, 2012 6:33 pm

Re: Not Minecraft, but Blocky

Sun Feb 10, 2013 7:53 pm

krishnak wrote: Can you give me a pointer as what is needed to get LWJGL compile with out X? I can give it a try.

Jogamp code can run with out X on the Pi
I do not actually know precisely because I have not spent much time looking. It could be as simple as compiling out everything that refers to Xlib and/or AWT, but there is probably more to it. Mouse and keyboard input may also be affected if LWJGL currently depends on events coming from X.

xranby may be able to provide input since he is heavily involved with Jogamp and will likely know what was required to make it happen with Jogamp.

Otherwise, I guess the only way to find out is to jump into the code and start compiling things out. That's what I did to get LWJGL working for RasPi, after a bit of research.

User avatar
spsn
Posts: 72
Joined: Wed Nov 07, 2012 6:33 pm

Re: Not Minecraft, but Blocky

Sun Feb 10, 2013 8:44 pm

Jens1970 wrote:May I asked where you learned this? The coding? I am really interested in coding, but haven't got any time to dive into it or to find any good tutorial.
When I started with the project in October 2011, I knew nothing about 3D programming or LWJGL or how a Minecraft type game would even work.

I started out with the LWJGL tutorials here:
http://www.lwjgl.org/wiki/index.php?tit ... ng_started

And then found the NeHe tutorials to be very helpful, here, just click on the Legacy Tutorials links (the tutorials show the C code, but there are LWJGL ports at the end of the tutorials):
http://nehe.gamedev.net/

There are many tutorials about OpenGL, most of them in C, but a common theme is that most of them teach the old OpenGL (direct programming) way instead of the more modern OpenGL (VBOs, shaders, etc.) way, and the two are very different for someone who is just starting out.

Just when I had figured out how to get some blocks to display on the screen using the old OpenGL way, I discovered that performance was so poor that it would be impossible to get anything like Minecraft to ever work that way.

I had to do a lot of research into OpenGL performance until I learnt about VBOs, texture atlases and shaders, etc. But like I mentioned above, most OpenGL tutorials do not teach you this.

I also had to learn how to use the OpenGL state machine more optimally. Switching between shaders and textures are often more expensive than actual draw calls, so one has to design the code in such a way that this switching is minimised, e.g. perform all the draw calls that need a specific shader and texture before switching to another shader and/or texture.

There was a forum post here not too long ago about a MIT course in 3D programming, that will be useful too for those who are staring out. There are probably many more similar courses available now that when I started.

The most useful site I found for learning how to put together a Minecraft like project is this one (the code examples are for the Unity engine, but the information and techniques discussed are very useful):
http://forum.unity3d.com/threads/63149- ... necraft...

I have learnt a lot in the almost 16 months since I started, but there is still a lot more on the TODO list: lighting, shadows, reflections, bump/parallax mapping, and a lot of other things related to 3D programming that I have not even discovered yet. Oh, and I still have to delve into sound too. That is not far down the list now.

People may ask, would it not have been easier to use a mature 3D engine instead of trying to write your own? Possibly, but I wanted to learn all about 3D programming, the same way the developers of those mature 3D engines must have.

And now I can teach my son. That is the best part.

User avatar
spsn
Posts: 72
Joined: Wed Nov 07, 2012 6:33 pm

Re: Not Minecraft, but Blocky

Sun Feb 10, 2013 9:02 pm

@zproc Sorry. The GLSL code for the shaders contains qualifiers that are specific to OpenGL ES and are not recognised by all the OpenGL desktop implementations.

xranby was kind enough to point this out to me before, but I forgot to change the GLSL code in the update.

Have a look at the file ge.framework.shader.BasicProgram.java, and remove all the "highp" and "lowp". That should sort it out for you.

m1n1m3
Posts: 5
Joined: Mon Jan 21, 2013 7:19 pm

Re: Not Minecraft, but Blocky

Thu Feb 14, 2013 3:50 am

is something wrong with

Code: Select all

./blocky-jamvm block=play
because its not causing blocks to do anything but slightly move no matter what perameters i give it

User avatar
spsn
Posts: 72
Joined: Wed Nov 07, 2012 6:33 pm

Re: Not Minecraft, but Blocky

Fri Feb 15, 2013 1:27 pm

@m1n1m3 Woops. I seem to have overwritten the "blocky" and "blocky-jamvm" scripts with older versions when I prepared the new .tgz files.

As a quick fix, please edit the "blocky" and "blocky-jamvm" scripts and replace the "$1" at the end of the line with a "$*". The scripts will then pass all your command line parameters on to blocky and the "play" option will work as expected.

I will prepare new .tgz files in just a bit.

krishnak
Posts: 17
Joined: Mon Feb 04, 2013 2:28 am

Re: Not Minecraft, but Blocky

Sat Feb 23, 2013 4:05 pm

I am trying to get some graphics done using JOGL/Jmonkey on the PI - Could you please tell me what is the format of the texture that you created for Blocky.

I keep getting a warning- Your graphics card does not support non-power-of-2 textures when I use JMonkek - the screen appears as a black box.

User avatar
spsn
Posts: 72
Joined: Wed Nov 07, 2012 6:33 pm

Re: Not Minecraft, but Blocky

Sat Feb 23, 2013 8:37 pm

Some GPUs expect the dimensions of the textures to be a power of 2, e.g. a width of 256 or a height of 32, etc.

Blocky uses multiple textures (12 if I remember correctly), some with power of 2 dimensions and some without. So how does Blocky make it work? Blocky uses SlickUtil library to load textures, which automatically pads the texture data up to power of 2 dimensions.

From the error you encountered it would appear that JME does not do the same by default. The simplest solution would probably be to create your textures with power of 2 dimensions, that is if JME does not already have functionality to do the padding

krishnak
Posts: 17
Joined: Mon Feb 04, 2013 2:28 am

Re: Not Minecraft, but Blocky

Sun Feb 24, 2013 2:26 am

I have tried that i.e made my texture images 16x16 pixel PNG - I still get the same warning. I am told on JOGL forum that it may be due to JMonkey using a different texture format to that of slick util.
http://forum.jogamp.org/JOGL-2-0-OpenGL ... 28332.html

I basically want to run some graphics with out X - I have tested jogamp samples -which run with out X. I thought it will be easier to develop some basic graphics with the game engine rather than doing the hardway :)

NathanBookham
Posts: 64
Joined: Sat Dec 15, 2012 9:18 am

Re: Not Minecraft, but Blocky

Sun Feb 24, 2013 12:35 pm

I cannot run Blocky, every time I try to run it I get this error:

Code: Select all

Exception in thread "main" java.lang.UnsatisfiedLinkError: /home/pi/Games/blocky/lwjgl/native/linux/liblwjgl.so: libEGL.so: cannot open shared object file: No such file or directory
	at java.lang.ClassLoader$NativeLibrary.load(Native Method)
	at java.lang.ClassLoader.loadLibrary1(ClassLoader.java:1935)
	at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1860)
	at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1850)
	at java.lang.Runtime.loadLibrary0(Runtime.java:845)
	at java.lang.System.loadLibrary(System.java:1084)
	at org.lwjgl.Sys$1.run(Sys.java:73)
	at java.security.AccessController.doPrivileged(Native Method)
	at org.lwjgl.Sys.doLoadLibrary(Sys.java:66)
	at org.lwjgl.Sys.loadLibrary(Sys.java:95)
	at org.lwjgl.Sys.<clinit>(Sys.java:112)
	at org.lwjgl.opengl.Display.<clinit>(Display.java:132)
	at ge.framework.render.GLES20Renderer.createDisplay(GLES20Renderer.java:117)
	at ge.demo.game.Blocky.start(Blocky.java:199)
	at ge.demo.game.Blocky.main(Blocky.java:2510)
It's a bit weird why it doesn't work, I have Zero installed, the .so file can be seen in PCManFM.

Can someone help!
This account is now inactive.
I am now known as 'InverseSandwich'

User avatar
spsn
Posts: 72
Joined: Wed Nov 07, 2012 6:33 pm

Re: Not Minecraft, but Blocky

Sun Feb 24, 2013 6:33 pm

@krishnak Blocky uses the default settings with Slick Util, which then produces 32-bit (8888) RGBA textures for the GPU. Slick Util can load both 32-bit and 24-bit textures, and produces 32-bit RGBA textures from both, but I have not tried using 24-bit textures on the RaspPi. Slick Util can also produce 16-bit RGB565 textures (by setting a flag), but I have not tried that either.

At the very least I know that 32-bit RGBA is supported by the RaspPi.

krishnak
Posts: 17
Joined: Mon Feb 04, 2013 2:28 am

Re: Not Minecraft, but Blocky

Mon Feb 25, 2013 3:16 pm

Thanks for the information, I will see whether I can get the JMonkey code sorted with some help from JOGL team.

On a side note, I have managed to get libgdx code run on Pi, with out X.

NathanBookham
Posts: 64
Joined: Sat Dec 15, 2012 9:18 am

Re: Not Minecraft, but Blocky

Mon Feb 25, 2013 6:15 pm

It turns out that I can't run OpenArena or Iridum Rising. I might need to reflash Raspbian.
This account is now inactive.
I am now known as 'InverseSandwich'

User avatar
mrpi64
Posts: 931
Joined: Sat Feb 16, 2013 5:13 pm

Re: Not Minecraft, but Blocky

Wed Feb 27, 2013 11:02 am

Wow... And you and your son made it... Amazing!!!
I'm happy to help.
https://www.raspberrypi.org/forums/viewtopic.php?f=78&t=51794 - List of games that work on the Pi.

User avatar
mrpi64
Posts: 931
Joined: Sat Feb 16, 2013 5:13 pm

Re: Not Minecraft, but Blocky

Wed Feb 27, 2013 11:10 am

Just like real Minecraft!!! :D :) ;) :( :o :shock: :? 8-) :lol: :x :P :oops: :cry: :evil: :twisted: :roll: :!: :?: :idea: :arrow: :| :mrgreen: :geek: :ugeek: lol!

This is the answer to life!
:( :?: :arrow: :idea: :arrow: :!: :D
I'm happy to help.
https://www.raspberrypi.org/forums/viewtopic.php?f=78&t=51794 - List of games that work on the Pi.

krishnak
Posts: 17
Joined: Mon Feb 04, 2013 2:28 am

Re: Not Minecraft, but Blocky

Wed Feb 27, 2013 2:44 pm

Just to let you know that I have managed to get Jmonkey render graphics on the Pi with out X. I think it is still work in progress to get Keyboard/Mouse to work.
spsn wrote:@krishnak Blocky uses the default settings with Slick Util, which then produces 32-bit (8888) RGBA textures for the GPU. Slick Util can load both 32-bit and 24-bit textures, and produces 32-bit RGBA textures from both, but I have not tried using 24-bit textures on the RaspPi. Slick Util can also produce 16-bit RGB565 textures (by setting a flag), but I have not tried that either.

At the very least I know that 32-bit RGBA is supported by the RaspPi.

User avatar
xranby
Posts: 539
Joined: Sat Mar 03, 2012 10:02 pm
Contact: Website

Re: Not Minecraft, but Blocky

Thu Feb 28, 2013 2:55 pm

krishnak wrote:Just to let you know that I have managed to get Jmonkey render graphics on the Pi with out X. I think it is still work in progress to get Keyboard/Mouse to work.
Raspberry PI Console Keyboard and Mouse input got improved during Jan 2013 and is included with the the latest JOGL auto-test-builds.
So in a nutshell, while this it is still work in progress, it will be better in the next JOGL release.
Xerxes Rånby @xranby I once had two, then I gave one away. Now both are in use every day!
twitter.com/xranby

jonnyred
Posts: 1
Joined: Sat Mar 02, 2013 3:08 pm

Re: Not Minecraft, but Blocky

Thu Mar 07, 2013 11:06 am

Just wanted to say a big thank you for creating Blocky, my kids really enjoy messing around with it, including creating new blocks. For example we created some alphabet blocks so that we could write out words (I used them to make a big birthday cake with ‘happy birthday’ across the top).
Just a couple of quick questions:

Whenever I try to create any new blocks with any form of transparency in them, like new water blocks etc the transparency is just rendered as opaque, do I need to add any other code or add the blocks to a list? (if I just amend any blocks that are transparent already then the transparency works). This also goes for creating deco blocks which do not draw properly, any block you place it on you can see right through it or it looks a bit like a mirror. (again if I amend old deco blocks then they draw as they should)?

This might be connected; I would like to create some glowing blocks a bit like the torch, could you point me in the direction of the code that lights up the torch? Thanks

Thanks once again for creating Blocky, it really is great fun messing around with, not just playing the game, but messing around with the code and seeing the results in the game.

User avatar
spsn
Posts: 72
Joined: Wed Nov 07, 2012 6:33 pm

Re: Not Minecraft, but Blocky

Thu Mar 07, 2013 5:22 pm

@jonnyred In the file Generator.java in the following method:

Code: Select all

	public void generateMeshes(
		final Region region,
		final FloatBuffer vertexBuffer1,
		final FloatBuffer vertexBuffer2,
		final ShortBuffer indexBuffer1,
		final ShortBuffer indexBuffer2)
you will find code that looks like the following:

Code: Select all

	if ((space_x_y_z == 6) || (space_x_y_z == 14) || (space_x_y_z == 26) || (space_x_y_z == 27) 
		|| (space_x_y_z == 28) || (space_x_y_z == 55) || (space_x_y_z == 56) || (space_x_y_z == 57) 
		|| (space_x_y_z == 58) || (space_x_y_z == 59) || (space_x_y_z == 60))
	{
		mesh = mesh2;
	}
	else
	{
		mesh = mesh1;
	}
This is where transparent blocks are distinguished from opaque blocks. For each region Blocky creates one mesh for the opaque blocks and another separate mesh for the transparent blocks. This way all the meshes for the opaque blocks can be rendered first and then the meshes for the transparent blocks can be rendered on top so that the transparency works.

I was thinking of adding attributes to the blocks so that characteristics of the blocks (like transparency, glowing etc.) may be set in the same place where the blocks are defined, but we have not done that yet.

The method where we define whether or not neighboring blocks should have faces, is the following:

Code: Select all

	private boolean hasFace(
		final byte block,
		final byte other)
The top part of the method body is where inner faces for the transparent blocks are disabled, so that transparent areas appear as continuous without visible inner faces.

The bottom part of the method body is where neighboring faces are enabled for non-solid blocks like deco blocks and transparent blocks, so that we see actual block faces around deco blocks and transparent blocks instead of seeing through the world.

In the following method:

Code: Select all

	public void updateBlock(
		final Vector3f position,
		final byte newBlock,
		final boolean ownBlock,
		final byte worldLight)
The code block that starts with:

Code: Select all

if (newBlock == 30)
is where we made our first attempt at lighting the torches. It is very simple, but was effective enough as a demonstration. With some refinement of the algorithm, the effect can be greatly improved.

It was important to me son that we share Blocky so that others may share the fun we have. So we are pleased that you are enjoying it. :D

dan3008
Posts: 1172
Joined: Wed Aug 15, 2012 1:05 pm

Re: Not Minecraft, but Blocky

Tue Mar 12, 2013 5:17 pm

Hay spsn.

I've been trying to make my own game in java like this for ages... And i keep hitting brick walls lol.

I've just got to the point where i can render blocks anywhere i like, and detect the players location ect, and ive got to start again from the ground up lol

the thing i'm really intrested in asking, is about lighting? I've not worked out how you did that one yet? any hits?

thanks

Daniel
dan3008 wrote:Pays your money, takes your choice

miicchhii
Posts: 3
Joined: Fri Aug 03, 2012 11:57 am
Contact: Website

Re: Not Minecraft, but Blocky

Wed Mar 13, 2013 12:03 pm

It looks really nice!

Sorry, but is there some other place to download it?
I appear to be unable to download it from 4shared.com

Would really like to try the game!

Greetings

ghans
Posts: 7878
Joined: Mon Dec 12, 2011 8:30 pm
Location: Germany

Re: Not Minecraft, but Blocky

Wed Mar 13, 2013 1:21 pm

• Don't like the board ? Missing features ? Change to the prosilver theme ! You can find it in your settings.
• Don't like to search the forum BEFORE posting 'cos it's useless ? Try googling : yoursearchtermshere site:raspberrypi.org

miicchhii
Posts: 3
Joined: Fri Aug 03, 2012 11:57 am
Contact: Website

Re: Not Minecraft, but Blocky

Wed Mar 13, 2013 1:32 pm

Thank you very much!

User avatar
spsn
Posts: 72
Joined: Wed Nov 07, 2012 6:33 pm

Re: Not Minecraft, but Blocky

Thu Mar 14, 2013 9:37 am

@dan3008 I wished to have more interesting shadows in Blocky, somewhat like we observe in real life where clouds cast shadows, more dense trees cast darker shadows than less dense trees, shadows can be cast over water, etc.

So the "lighting" in Blocky is based on a light absorbing model where cloud blocks, leaf blocks and water blocks absorb different amounts of light and leave shadows under them.

In the file Generator.java, the following method is where the light values are set for each block in the world:

Code: Select all

	public void setLighting(
		final int x,
		final int y,
		final int z,
		final byte topLight,
		final boolean stopWhenSolid)
To keep it simple, the sun light is assumed to always shine straight down onto the world. Blocky has 127 integer levels of light, starting with the maximum value at the top of the world. As you move down each column of blocks in the world the light level is decreased by a specific value whenever you hit a cloud block, a leaf block, a water block etc., making all the blocks underneath darker than the ones above, effectively casting a shadow. Whenever you hit a solid block then the light level is set to the minimum level (representing the ambient light level) since no more direct light can pass to lower blocks.

When the light level has been set for all the blocks in the world, then the "lighting" is smoothed as part of the process of generating the meshes for the regions. For each of the 8 corners of each block, you take the average of the light values of the 8 blocks (4 above the corner and 4 below the corner) that share that same corner. Each block then ends up with 8 smoothed floating point light values that are used to "light" the block faces that are drawn into the mesh.

This seems to work well enough and provide a pleasing effect. There is one case though that I still need to address; when digging out a cave, you will notice that the cave ceiling is lit up when it should not be. Probably have to consider a different set of light values to smooth over in this case.

Return to “Gaming”