next »

[Kinasin]

Looks awesome. 

[eigenbom]

Hey mate, you suggested vertex arrays as a fallback for older machines for terrain rendering. Does that mean you batch the arrays for each texture that contains the block sprites? (which I assume are spread over any number of images as Crea is fully moddable?)

[jmcmorris]

Hey mate, you suggested vertex arrays as a fallback for older machines for terrain rendering. Does that mean you batch the arrays for each texture that contains the block sprites? (which I assume are spread over any number of images as Crea is fully moddable?)

Eigenbom, that's right. All of my tiles have a unique id. I have a map<id, VertexArray> which means I have one VertexArray per tile. I add to the VertexArrays (position and texcoords) while going through all of the tiles on the screen. After that I then render each VertexArray. I have a few optimizations in there as well as some other stuff but that is the gist of it. Let me know if you have any other questions.

[eigenbom]

Oh right, so you rebuild the vertex arrays every frame? And then have up to N draw calls per frame for N block types, so I assume you're optimising to not have many different block types on screen at once?

[jmcmorris]

Oh right, so you rebuild the vertex arrays every frame? And then have up to N draw calls per frame for N block types, so I assume you're optimising to not have many different block types on screen at once?

Right. One optimization that I have planned is to add a tile buffer to the VertexArrays around the edge of the screen. Then keep the VertexArrays around as long as the player doesn't move out of the buffer (or if a tile changes that is currently being stored in the VertexArrays).

Another thing I am doing is drawing tile transitions above other tiles. This is done using tile priorities and the VertexArrays. You can see it between the dirt and stone in this image.

[eigenbom]

ok thx for the info! i got mm running on my old asus eeepc with intel gma gfx just by making the render textures a power of 2. unfortunately it runs slow as, but it works.

[jmcmorris]

Yeah, that is the problem I have had with the RenderTextures. They seem to be slow for me, which is why I decided to just go with the VertexArrays instead.

[eigenbom]

Oh, so you're not planning on doing any fancy composition?

[jmcmorris]

The VertexArrays are pretty fast. Right now there are several other places that need optimization more than the tile rendering. Like the water simulation (CA) and lighting.

[jmcmorris]

The last several days I have been working on getting the equipment implemented. It is now at a really good point.

It is very easy to change which equipment slots a character race has. Equipable items have a list of "attributes", which can be changed at anytime. Attributes are defined inside of the python scripts and can be anything as long as they have a few methods such as "onEquip", "onUnequip" and a few more. Each of these methods have full access to the game world; making it possible to create very unique and interesting equipment.

Characters in Crea are made up of several images instead of just one. This is thanks to Spriter. So a character has a head, hair, torso, forearm, and all the other expected body parts and on top of those is equipment. With the equipment it is possible to swap out any of the images on the character with other images.

Right now I'm just using placeholder equipment and UI so it is not much to see at the moment but all of the power is there.

Nothing Equipped


Body Armor Equipped

[jmcmorris]

Starting an art livestream at 4PM PST. Our artist will be drawing and animating a monster. Feel free to stop by and say hello.

[Nu-Type]

Saw the kickstarter on this. Glad to see a devlog. I find the game pretty interesting.

[Vovosunt]

Nice!
The art is amazing too!

So you're rebuilding all the vertexArrays?
Is it efficient enough?
I'm making a similar game and I have only one vertexArray. Tiles wrap around when the camera moves and obviously I can use only one tilemap (but that's not really a problem).
The problems I have are the overlaps (I can't really set in which order the tiles are rendered so don't have any tile order )

[jmcmorris]

Nice!
The art is amazing too!

So you're rebuilding all the vertexArrays?
Is it efficient enough?
I'm making a similar game and I have only one vertexArray. Tiles wrap around when the camera moves and obviously I can use only one tilemap (but that's not really a problem).
The problems I have are the overlaps (I can't really set in which order the tiles are rendered so don't have any tile order )

Thanks!

Right now my tile rendering is too slow. I actually need to optimize it but what I am currently doing is recalculating all of the VertexArrays every frame. Each tile type gets its own VertexArray (since each tile is on its own image). I also add the tile blinding to the appropriate VertexArray. Then at the end I draw each VertexArray according to the tile's priority, which is given along with the rest of the tile data.

When I profiled this I found that the slowest point is appending all of the Vertices. So I need to devise a way to keep the VertexArrays around and update them when tiles change and when the camera moves. The next slowest part is the actual rendering itself, which could be sped up by creating a composite RenderTexture of the tile images at runtime. I have to do this at runtime since mods can add new tiles.

[Vovosunt]

When I profiled this I found that the slowest point is appending all of the Vertices. So I need to devise a way to keep the VertexArrays around and update them when tiles change and when the camera moves.

I think most of the vertex arrays should stay more or less static. And I don't quite understand why you're recalculating every vertex? SFML views are faster and you can just leave all the stuff in one place and render what actually reaches the screen.

P.S.: I think that's the way I'm going to do it. My current method has almost identical number of vertexes rendered every frame, but the bg tiles are rendered first and them the fg tiles, which means I have many vertexes rendered that are overlapping and some that are not even seen (air is transparent, but still takes time to render ). I also have to move the vertexArray so meh... the only reason I chose that method is because I thought that more draw calls really take a lot more time to render, while in reality it barely adds anything (ran some tests yesterday, made me sad and happy at the same time ).

The next slowest part is the actual rendering itself, which could be sped up by creating a composite RenderTexture of the tile images at runtime. I have to do this at runtime since mods can add new tiles.

I think that's what I'm going to do too :D
Thought I don't think my game will be really modabble, rather I want people to be able to create content easily (using some sort of content creation app or smth).

Keep up the good work! 

[Connor]

please dont be dead...

[eigenbom]

check their blog for updates

[jmcmorris]

Yeah, I have been very quite here lately. I was planning to come back with a bang. I have been updating my blog at least once a week. I also do a coding livestream almost everyday for a few hours. It is not the most exciting thing but if you're interested then feel free to stop by.

Last time I posted on this I mentioned my tile rendering being too slow. Just yesterday I finally went ahead and optimized it. My debug build went from 7~fps to 45~fps. Huge win! For anyone interested...

I was already splitting my tiles up into chunks (16x16 tiles). So now I store a map of tileID to VertexArray for each chunk. I recalculate a chunk's map if a tile changes. I also have a map of tileId to VertexArray for the entire TileLayer. When a chunk needs to be drawn I add it to this map and track the chunks I've added to it in a set. To render the TileLayer I order the VertexArrays by the tile priority and then draw each one. (VertexArray is from SFML)

It is a little complicated and could likely be cleaned up some but given all of the requirements I'm pleased with it for the most part. It definitely gets the job done!

[jmcmorris]

I put this screenshot up on Screenshot Saturday. This is what Crea is shaping up to look like. Planning to start updating here much more frequently.

[jmcmorris]

It is about time I get this devlog caught up to speed. Over the past five months I have been working full time on Crea. I realized awhile back that a great deal of the features I had implemented needed to be rewritten for either performance or long term support reasons. Such as I moved from using libRocket for my UI to using Awesomium. We also redid our character animations and world generation. Things are starting to come along nicely now though.

We have pushed out 2 versions of our alpha and will be pushing out another major update today or tomorrow. Beta is not too far away...

We made a IndieDB page the other day and I finally put together a new video just now! It is a preview of the day/night cycle. Nothing too special but still pretty to look at.