Welcome, Guest. Please login or register.

Login with username, password and session length

 
Advanced search

1411489 Posts in 69371 Topics- by 58428 Members - Latest Member: shelton786

April 24, 2024, 03:58:43 PM

Need hosting? Check out Digital Ocean
(more details in this thread)
TIGSource ForumsDeveloperTechnical (Moderator: ThemsAllTook)Will LibGdx be my saviour?
Pages: [1]
Print
Author Topic: Will LibGdx be my saviour?  (Read 1053 times)
PetSkull
Level 2
**


View Profile
« on: December 18, 2017, 04:44:14 AM »

Hi,

I'm using JavaFX as my framework when making small 2D games and it has worked "ok" so far. But this time I'm facing some challenges, which has made me look for other frameworks/engines as a solution.

My problem is, that I want to create a 2D top down map, consisting of layers (from 8 to 12 layers) drawn from tiles in size 32x32.

The way I have solved this so far is, that I generate a layer with new tiles, that are merged from the previous layers, giving me a lot of unique tiles but only 1 layer. This actually works quite fine. The problem is, that this process takes 6-10 seconds to generate.

I also want zooming out from this map, zooming from 32 pixels to 4 pixels in steps of 4. This I have solved in 2 steps:
1. For 4x4 zoom I create yet another layer, consisting of unique tiles 2x2 and viewed as 8x8. This keeps the frame rate up. But again this takes 4 seconds to generate.
2. For zooming 8x8 up to 32x32 I can do it in my renderer without framerate drops.

My fears are that the player needs a hardcore PC in order to play this game without frame rate issues and long waiting times (when generating maps).

Will LibGdx be able to save me some hassles?

1. Is LibGdx able to draw 8 layers of 4x4 tiles full screen without frame rate issues? Or will I still need to make a merged layer/map so tiles are at least 8x8 pixels?
2. Is my approach with layers even the right one?

I hope my question in understandable - English is not my native, so I have some trouble descriping my challenge the way I see it.
Logged

ThemsAllTook
Administrator
Level 10
******



View Profile WWW
« Reply #1 on: December 18, 2017, 07:26:08 AM »

Seems likely. Based on this libGDX demo reel, the games being shown are clearly using hardware acceleration. If your current framework is taking 6-10 seconds to merge 8 tile map layers, it sounds like it's not taking advantage of graphics hardware to do so, and probably has some incredible inefficiencies on top of that - unless we're talking about millions of tiles at once, that should be a trivial task for any reasonably modern computer.

Merging your tile map layers might not be necessary at all, but the first step is to get them rendering with hardware acceleration, so you can measure the performance of that to understand where the inefficiencies are.
Logged

PetSkull
Level 2
**


View Profile
« Reply #2 on: December 18, 2017, 07:56:56 AM »

My screen resolution right now is 1680x1050 and this means drawing

For 8 layers rendering in JavaFX

32x32 pixel : 54x32 tiles - Takes 1ms
16x16 pixel : 107x63 tiles - Takes 4ms
8x8 pixel : 212x125 tiles - Takes 14ms (well, framerate drops to 33-35 Sad )

And if players play in 2560x1440 I'm doomed...

Think I'll look into LibGdx as a solution. Thanks Smiley



Logged

ALourenco
Level 0
***


View Profile WWW
« Reply #3 on: December 27, 2017, 05:37:16 PM »

I'm not familiar with JavaFX. Although, I've used libGDX and it works pretty well. At the end it always depends on how you implement stuff, but I think libGDX even has asset management using miltithreading and stuff like that.

Your rendering problem doesn't seem complex at all. When you mean merging, you refer in case of some tiles having transparency and letting through the one bellow? If you do, the graphics API should take care of that with depth and you are not using acceleration at all, or doing something wrong.
Logged

GameDev Master Student.
Game Engines and Computer Graphics in free time.

@CodinGree
PetSkull
Level 2
**


View Profile
« Reply #4 on: December 28, 2017, 12:10:24 AM »

I made a small test program using LibGdx and it suffers from the same problem. Drawing 26500 tiles (sized 8x8 pixels) 8 times (for 8 layers) makes it use too many cycles.

But I overcame my problem with the layer merging. I can now merge 8-12 layers into a single tile layer within 1-2 seconds which is nothing the player will notice, as I do it in a background thread, while the player "travels" to the new location.
Logged

ThemsAllTook
Administrator
Level 10
******



View Profile WWW
« Reply #5 on: December 28, 2017, 06:26:15 AM »

I can now merge 8-12 layers into a single tile layer within 1-2 seconds which is nothing the player will notice, as I do it in a background thread, while the player "travels" to the new location.

That still seems like a lot to me. I'll bet it could be further optimized to get it down to a few milliseconds. If you're interested, feel free to post some code here, and we might be able to figure out where the inefficiencies are.
Logged

PetSkull
Level 2
**


View Profile
« Reply #6 on: December 28, 2017, 03:29:02 PM »

I can tell you how I made it.

I have a height map of some 1200x1200 values. The heightmap is then divided into x number of layers (usually 8-12 layers) where only 1 value is in one layer.
I then autotile the each layer to convert it into a 47 tiles tileset (the Wang tileset http://www.cr31.co.uk/stagecast/art/grid/blob/wang.png). I use different tilesets for some of the layers (grassy, dirt(s), water etc.)
Then I go through each position in each layer, figuring out which tiles goes into the combined layer (like drawing the tile for each layer on top of each other, but ignoring tiles which are completely hidden in lower layers)
All new combinations of tiles is saved to a new combined tileset (actually a lot of tilesets, as I can't hold all tiles in one tileset without hitting the max on a texture) and a new map is created consisting of values for the new combined tiles. This will look something like this:



BUT I am also able to zoom in and out of this map by redrawing the tiles in new sizes. Original is 32x32 pixels, but I can zoom all the way down to 4x4 and at 4x4 pixels, there's too much tiles that needs to be drawn (and I cant keep my 60fps), so I run another function on the merged map:

For each position in the merged map I look at the 2x2 neighbors and creates a new tile graphics sized 8x8 pixels. This I do for the entire map (skipping every other tile) and creates a lot of new 2x2 tiles (one of my maps creates 371 combined tiles and 2433 2x2 unique tiles), but this makes it possible for me to draw the entire map at 8x8 when I zoom to 4x4 and thus leaving me enough time to do all the other stuff in the frame (16ms).
Logged

BorisTheBrave
Level 10
*****


View Profile WWW
« Reply #7 on: December 29, 2017, 03:51:02 AM »

That sounds like lot of effort. You say you are already pruning completely hidden tiles (and fully transparent ones)? I expect it's a rare tile that actually has more than two layers visible on it, so you should be barely drawing more sprites than there are tiles on the screen, even without pre-combining the layers in any way. IOW the number of distinct layers shouldn't really impact your performance at all.

Though I do agree with ThemsAllTook, once you've got HW acceleration working properly even the completely naive way wouldn't be too bad.
Logged
PetSkull
Level 2
**


View Profile
« Reply #8 on: December 30, 2017, 01:36:35 AM »

By doing it the way I do, I can actually have 32 or 64 layers giving a more rocky/mountainous look to my maps, and still only draw one layer, keeping the fps at 60. This I like.
Logged

Pages: [1]
Print
Jump to:  

Theme orange-lt created by panic