next »

[eigenbom]

Update: Subchunks now get rendered to textures and only re-render if they are modified. This results in a HUGE speed-up. For instance, I can now zoom all the way out (where moonman is 8 pixels wide) and have a 1800x1000 window and experience no noticeable slow down. Jenqui!

Disregard the buggy background renderer for now.

[peous]

nice ! What world size does this allows you to handle ?

[Franklins Ghost]

That's really impressive and interesting to hear how you are handling it all.

[eigenbom]

@peous I discussed the world size a few pages back I think... But it's big. I plan to have the texture caching limited, probably around 20 chunks cached at a time = 256 mg vram..

[wademcgillis]

RenderTextures don't work on Intel graphics cards!

[harkme]

Yeah, I was going to mention that RenderTextures do not work on Intel GPUs, but it seems I was beaten to it. I have heard that the later Intel GPUs support them through updated drivers, though.

I love how your world looks zoomed out. When I saw it zoomed in, I didn't think much of it, but zoomed out it strikes me as beautiful, probably because I can appreciate the structure more.

[happymonster]

There are copy to texture functions that work on Intel graphics cards. I used them for Neon Wars and they are fast enough for real time in most cases.

[harkme]

There are copy to texture functions that work on Intel graphics cards. I used them for Neon Wars and they are fast enough for real time in most cases.

Yes, but the method used by SFML 2.0 isn't supported by most Intel GPUs:
https://github.com/LaurentGomila/SFML/issues/101

The creator of SFML says he should be able to fix it by SFML 2.1.

[eigenbom]

Interesting, thx for the heads up. Actually I was already using RenderTextures to do the AO shading compositing too, though I've always had a 'plain graphics' fallback in mind so it would still run on older machines. ATM this'll have to go in the TODO bin.

[BlueSweatshirt]

More game!!! So people can do this ----> 

[eigenbom]

Yes Mr Sanders. I'll be bring the game soon enough.

Update: Added an edit mode where you can control the camera, used for debugging. Did some minor refactoring, and cleaned up the chunk renderer.

Currently I'm working on a more flexible collision system for the blocks. The plan is for blocks to register as one of four collision types:

Code:

enum CollisionType {
  kNoCollisionType = 0,
  kFullCollisionType = 1,
  kPlatformCollisionType = 2,
  kStackableCollisionType = 3
} collisionType;

The first two are what I've currently got. Platform collision type will allow the creation of platforms which can be jumped up onto from below, and only register as a collision when landing on from above. The stackable  collision type will be like the platform type, except if there is a stack of stackable blocks of the same type, then you can only land on the top-most one. This is for things like background columns which you can walk through, but also can land on top of. (gah does that make sense? who knows.. but i know what i mean. :D )

Image is of mega zoom.

[SolarLune]

Mega zoom looks pretty sweet. Also sounds like you know what you're looking for when it comes to block types. Keep going with it!

[eigenbom]

thx for the encouragement dudes

Update: Got the first two collision types (none and full) working in the new system. The tombstone, for instance, has collision type NoCollisionType which means that, although it's a foreground block, you can't collide with it. So it appears to be a background block, but .. erm .. isn't. Technicalities people!

Also had a few minutes to pixelise a couple of concepts for the tree monsters. Some trees will be made of tree monsters, just waiting to wake up if you try to chop them down.

[Belimoth]

That is the best thing I've ever read.

[namragog]

Those are the greatest tree monsters I have ever seen.