798 replies to this topic

[SquidDev]

I was bored:


For reference, this is an 8x8x8 chunk of blocks being rendered - there are about 2600 polygons here which are being drawn in 0.025 seconds, and blitted in 0.038. There are some pretty serious bugs with this: as you can see random lines are being drawn off the edge of triangles: I have no idea why Fixed! Also, when the z coordinate is close to 0, all sorts of things go wrong due to x and y technically being infinite. I'm going to try to fix these, but don't know how it will go.

On a positive note, these textures were rendered with about 20 lines of code which I think is pretty cool, and shows how powerful code generation can be.

Lets be honest though, this isn't ever going to be playable (though it is not too bad running in Love).

Update:
Fixing the additional line bug makes the alpha-blending look much better (though it easy too see that I'm not sorting faces correctly (green is opaque).

Edited by SquidDev, 16 November 2015 - 04:37 PM.

[Creator]

Wow, this is extremely sweet.

[oeed]

SquidDev, on 16 November 2015 - 04:14 PM, said:

Lets be honest though, this isn't ever going to be playable (though it is not too bad running in Love).

As I mentioned in the Silica Gitter chat, I think it should be quite playable.

Texture-wise, Minecraft textures actually don't look too bad with a palette of 16 colours. (Note: the screenshot below doesn't use the CC colours, but 16 selected colours to best match the textures).



Speed-wise, the rendering is running at 40 FPS (without blitting). Presuming you're using the implementation of blit I used, it is intentionally poorly written to make performance issues more noticeable in Silica and could be quicker.

However, we're not sure what Dan actually has in the GFX API for us to render directly to the screen, but I'm realllllllllllly hoping that it has a good way to send all the changed pixels in one function call. (Honestly, bliting for 200 lines takes quite a while.) demhydraz on the Gitter chat suggested a blit method that used a string, did the entire screen and ignored a certain character (e.g. spaces) for buffering. A multidimensional table would also work, but it'd be slower.

[SquidDev]

oeed, on 16 November 2015 - 11:23 PM, said:

However, we're not sure what Dan actually has in the GFX API for us to render directly to the screen, but I'm realllllllllllly hoping that it has a good way to send all the changed pixels in one function call. (Honestly, bliting for 200 lines takes quite a while.) demhydraz on the Gitter chat suggested a blit method that used a string, did the entire screen and ignored a certain character (e.g. spaces) for buffering. A multidimensional table would also work, but it'd be slower.

On the latest screenshot/GIF/whatever, I noticed a gpu.drawMap function, judging by the argument list looks something like gpu.drawMap(x, y, map, no clue...). It is also using gpu.setCol, which is either setColour or setColourPallet. If someone has the time, it might be worth going through the pacman video, and see if we can find more exact function signatures - probably not worth it though.

[LeDark Lua]

SquidDev, on 16 November 2015 - 04:14 PM, said:

I was bored:


For reference, this is an 8x8x8 chunk of blocks being rendered - there are about 2600 polygons here which are being drawn in 0.025 seconds, and blitted in 0.038. There are some pretty serious bugs with this: as you can see random lines are being drawn off the edge of triangles: I have no idea why Fixed! Also, when the z coordinate is close to 0, all sorts of things go wrong due to x and y technically being infinite. I'm going to try to fix these, but don't know how it will go.

On a positive note, these textures were rendered with about 20 lines of code which I think is pretty cool, and shows how powerful code generation can be.

Lets be honest though, this isn't ever going to be playable (though it is not too bad running in Love).

Update:
Fixing the additional line bug makes the alpha-blending look much better (though it easy too see that I'm not sorting faces correctly (green is opaque).

Simple fix with z coordinates:

for i=1, #world do
for pol, _ in pairs(world[i]) {
  if pol.z>0 then
   --Draw polygons
  end
}
end

Edited by LeDark Lua, 17 November 2015 - 12:46 PM.

[ardera]

SquidDev, on 16 November 2015 - 04:14 PM, said:

Also, when the z coordinate is close to 0, all sorts of things go wrong due to x and y technically being infinite. I'm going to try to fix these, but don't know how it will go.

There's Frustum Culling, that not only fixes this, but also excludes things that are not in your Field of View, alias "View Frustum". This will improve performance, but it takes some time to implement. Minecraft uses Frustum Culling too.

Are you using a Z-Buffer? I got some ideas on how to implement partly transparent polygons. (Transparency is not possible with standard Z-Buffers)

Also, there's another performance improvement I have, if you're not already using it: Since most polygons in the world space share some vectors, you can give vectors with exactly the same position an index, and apply the transformations for every index. This way you don't transform the same point more than one time.

Edited by ardera, 17 November 2015 - 12:46 PM.

[SquidDev]

LeDark Lua, on 17 November 2015 - 12:35 PM, said:

Simple fix with z coordinates:

for i=1, #world do
for pol, _ in pairs(world[i]) {
  if pol.z>0 then
   --Draw polygons
  end
}
end

I do cull triangles that are outside the render region, but I was under the impression that the z coordinate was between -1 and 1 - though I might be mistaken - everything does break when z reaches 0. I'm kinda stuck on this, because if z > 0, then you are dividing the x and y coordinates by a negative number, so the image is going to flip. This doesn't matter if the entire polygon is outside, but if one point's z > 0 and the other points aren't, then everything blows up.

ardera, on 17 November 2015 - 12:44 PM, said:

There's Frustum Culling, that not only fixes this, but also excludes things that are not in your Field of View, alias "View Frustum". This will improve performance, but it takes some time to implement. Minecraft uses Frustum Culling too.

The code I'm currently is a mixture of GlesCraft and my own Minecraft clone. The both implement some form of frustum culling, as does this, its just commented out at the moment because I think it is broken.

ardera, on 17 November 2015 - 12:44 PM, said:

Are you using a Z-Buffer? I got some ideas on how to implement partly transparent polygons. (Transparency is not possible with standard Z-Buffers)

That would be awesome! Transparency does work, you just have to sort the polygons which is a pain. I did some reading on order independent transparency but got confused.

ardera, on 17 November 2015 - 12:44 PM, said:

Also, there's another performance improvement I have, if you're not already using it: Since most polygons in the world space share some vectors, you can give vectors with exactly the same position an index, and apply the transformations for every index. This way you don't transform the same point more than one time.

Already doing this - though the matrix transformations are pretty minimal, I guess it would add up.

Edited by SquidDev, 17 November 2015 - 01:20 PM.

[ardera]

Also, SquidDev, there is Backface Culling; it'd improve the performance a lot I think, but it's not that easy to implement.

ardera, on 17 November 2015 - 12:44 PM, said:

I got some ideas on how to implement partly transparent polygons.

Nevermind, I had this idea 1 or 2 years ago and just checked if it really works, but it turned out it doesn't. Sorry :/

[SquidDev]

ardera, on 17 November 2015 - 01:35 PM, said:

Also, SquidDev, there is Backface Culling; it'd improve the performance a lot I think, but it's not that easy to implement.

Backface Culling is one of those things I need to implement - also want to look into implementing a stencil buffer, as well as controlling which buffers are written to - because then we can have Portal!

Edited by SquidDev, 17 November 2015 - 01:48 PM.

[MKlegoman357]

SquidDev, on 17 November 2015 - 08:01 AM, said:

On the latest screenshot/GIF/whatever, I noticed a gpu.drawMap function, judging by the argument list looks something like gpu.drawMap(x, y, map, no clue...). It is also using gpu.setCol, which is either setColour or setColourPallet. If someone has the time, it might be worth going through the pacman video, and see if we can find more exact function signatures - probably not worth it though.

I've already covered some things that I saw in the pacman video here. gpu.drawMap() draws a tile map. The tiles are loaded from a simple .image file.

[Creeper9207]

How is that requiring so many polygons when StarFox required about 100-300 (or, at least i was told)

[oeed]

Creeper9207, on 18 November 2015 - 12:15 AM, said:

How is that requiring so many polygons when StarFox required about 100-300 (or, at least i was told)

Actually that's a very good point... I presume the 2600 means that every block has 2 per face and 6 faces. Now, it probably doesn't matter for a demo, but you might want to look in to removing shared edges.

You probably know what it is, in fact you might've already mentioned it somewhere and I missed it, but this page explains it a bit. http://0fps.net/2012...minecraft-game/

Edited by oeed, 18 November 2015 - 09:32 AM.

[Lignum]

oeed, on 18 November 2015 - 09:30 AM, said:

Actually that's a very good point... I presume the 2600 means that every block has 2 per face and 6 faces. Now, it probably doesn't matter for a demo, but you might want to look in to removing shared edges.

Index buffers could help cut down the amount of vertices. Though, I'm not sure how that would improve performance (if at all).

[SquidDev]

oeed, on 18 November 2015 - 09:30 AM, said:

Actually that's a very good point... I presume the 2600 means that every block has 2 per face and 6 faces. Now, it probably doesn't matter for a demo, but you might want to look in to removing shared edges.

You probably know what it is, in fact you might've already mentioned it somewhere and I missed it, but this page explains it a bit. http://0fps.net/2012...minecraft-game/

I already cull inside faces. I originally implemented "the greedy method" as mentioned in 0fps, and I guess I could look into poly2tri as mentioned here. One thing I need to think about though is how to handle textures - otherwise textures will be stretched over the polygon.

Lignum, on 18 November 2015 - 12:37 PM, said:

Index buffers could help cut down the amount of vertices. Though, I'm not sure how that would improve performance (if at all).

As mentioned in this post, I already do do this. The matrix transformations are pretty minimal, but I guess it adds up.

My biggest problem at the moment is culling near the z-plane - I still haven't made any progress on it . If people feel like helping out, I have a todo list on the GitHub.

Edited by SquidDev, 18 November 2015 - 01:59 PM.

[Creator]

Lignum, on 18 November 2015 - 12:37 PM, said:

oeed, on 18 November 2015 - 09:30 AM, said:

Actually that's a very good point... I presume the 2600 means that every block has 2 per face and 6 faces. Now, it probably doesn't matter for a demo, but you might want to look in to removing shared edges.

Index buffers could help cut down the amount of vertices. Though, I'm not sure how that would improve performance (if at all).

You have to transform less coordinates.

[CraftedCart]

There's controller support now

https://twitter.com/...9688104961?s=09

[oeed]

Private demos now apparently too...

Edited by oeed, 19 November 2015 - 12:47 PM.

[Waitdev_]

CraftedCart, on 19 November 2015 - 07:51 AM, said:

There's controller support now

https://twitter.com/...9688104961?s=09

hmm... i wonder why? and it was fullscreen?

[oeed]

Wait_, on 19 November 2015 - 08:16 AM, said:

and it was fullscreen?

Actually that's a good point, surprised we overlooked that. It's hard to tell whether it is dynamic resolution or it just scales as both his screen (a MacBook screen) and the CraftOS 2.0 screen both have a 1.6:1 ratio.

[Bomb Bloke]

320x200 is certainly 16:10, and I gather most Macbooks these days are as well. Which was a little surprising to learn: I'd've thought Macbooks would be 16:9.