LÖVE

It's cool looking , but the performance is, like you say, completely awful. I'll experiment a little with your tiles and get back to you ...

Ethnar wrote:I must admit I got confused by you, qubodup, as well. Guess you just found it funny that my post has letter-like structure.

Not funny. Elegant rather. Nice job on getting something done. I hope you don't have Nethack #4932 planned though

You made those nice sprites and tiles? (where's the 'impressed'-smiley?)

Thanks.

It's not going to be nethack - more like a Drawf Fortress, but with players instead of AI-scripts for dwarfs.

And no, no. The sprites are part of Battle for Wesnoth, those are GPL'ed. I'm going to use them as a base (cut a leg here, sew an arm from there... ).
As for tiles - there's a lot of work, I might even use completely different tiles than those presented in this ultra-pre-alpha-version.

It may be that you already implemented this, and your performance loss is due to something else, but if that is the case, then I'm not sure I can help you ...

This example shows how you can quickly display selective parts of a huge map. This map has one million tiles, but only tiles within a certain interval are drawn. Use the arrow keys to move around. I didn't implement smooth scrolling, nor do I do any fancy z-ordering or scene rotation or anything like that.

I'm sorry that I can't "heal" your code directly, but there are limits as to what I have time for.

For reference: GEE.love averaged on about ~90 FPS on the same computer. Oh, and vsync is disabled in the conf, so CPUs beware.

Thanks for help with this one!

Well, to get the numbers straight: That data confuses me a lot, I can't put my finger on it...
Just for the record: I have ATI Mobility X1300, 1.6GHz Core 2 Duo, 2GB RAM
Also - on your test there were only 100 tiles drawn, in my test (2 z-layers by the way) there were almost 600 blocks drawn (empty and hidden are completely omitted)
Two things have drawn my attention however:
You are using single-indexed array. Is it much faster than 3D array of the same size? As far as I know in C it doesn't make a difference, how is it working in lua?
And second thing: I know there's an option to zoom, rotate images, skew, etc., but I've also read, somewhere on this forum, that if those things were disabled, LOVE could work faster. Is this a viable option? If so, how much work would that require and what would be your estimates regarding performance increase?

Once again, thanks for help, it's much appreciated.

Kind regards,
Ethnar

600 blocks? That many? What is the dimensions of the map? And what do you mean by completely omitted? Not even iterated?

That FPS is a little low, then again, FPS is a really poor metric for game performance.

I just did a basic performance test now, and I'm a little surprised. On my main machine (2ghz AMD, nvidia 7950GTX), LOVE could draw 4000+ rotated/scaled tiles @ 60 FPS.

On my laptop (2ghz AMD, ATI X1250), which is similar to your machine, the same code ran at just below ~60 FPS for only 100 rotated/scaled tiles! Seems more GPU-bound than I expected. I guess Lua is pretty badass. If this is similar to the performance of your computer, though, it's no wonder you get 30 FPS when drawing 600 tiles.

You can't up performance further until we have vertex buffers in LÖVE, or some specialized map object written in C. And I wouldn't wait on that. That will take a while.

Single indexed array: I don't really know about this. You only have to create one table this way, but you still need nested loops, so I guess it only matters memory wise.

Disabling scaling/rotation will not change performance much, and is not possible anyway.

rude wrote:600 blocks? That many? What is the dimensions of the map? And what do you mean by completely omitted? Not even iterated?

So..

Yes, 593 blocks are displayed (depends on angle a little). Map is a diamond: of size 63 in diameter. However, only a diamond of 31 in diameter is displayed. The reason that map is bigger than displayed area is that when displaying different z-levels, I need different portions of the map (not the middle). Now, for each level only blocks that would be visible inside that brown border are displayed and only those that won't be covered by other tiles. This means that those blocks are still iterated, but the draw() method isn't called
that often. I believe I've done what I could on this field.

That FPS is a little low, then again, FPS is a really poor metric for game performance.

Interesting lecture, it's nice to learn something that is both, new and obvious.

I just did a basic performance test now, and I'm a little surprised. On my main machine (2ghz AMD, nvidia 7950GTX), LOVE could draw 4000+ rotated/scaled tiles @ 60 FPS.

On my laptop (2ghz AMD, ATI X1250), which is similar to your machine, the same code ran at just below ~60 FPS for only 100 rotated/scaled tiles! Seems more GPU-bound than I expected. I guess Lua is pretty badass. If this is similar to the performance of your computer, though, it's no wonder you get 30 FPS when drawing 600 tiles.

You can't up performance further until we have vertex buffers in LÖVE, or some specialized map object written in C. And I wouldn't wait on that. That will take a while.

Yup, LÖVE is pretty baddass. And sadly, even thou I just love the simplicity and structure of this engine, I have to give it up. Guess my project isn't that little and I'm having pretty big expectations. But it was really interesting experience and I know what platform I'll use if I ever need to quickly write something smaller.

Single indexed array: I don't really know about this. You only have to create one table this way, but you still need nested loops, so I guess it only matters memory wise.

Disabling scaling/rotation will not change performance much, and is not possible anyway.

Thanks for info.

So, I guess my and LÖVE roads part... at least for now. It was a pleasure to meet so kind folks on this forum, thanks again for help.

In unlikely (I'm just one of millions, right? ) case anyone need to contact me, you can catch me via PM, I'm also watching this topic for replies so I'll visit it if something new springs.

Good look guys and keep up the good work!

Let us know what you try next and how it goes!