isometric tiles in Java2D w/ scrolling

Shared Code
#1

Here is a little isometric tiling app i wrote, which scrolls a set of tiles. it doesn’t work as well as i had hoped, getting only about 100 FPS (Windowed)

it uses transparent GIFs in an array (256x256), and BufferStrategy.

the main classes have comments so anyone can hopefully follow what’s going on in it. you can get the source by unzipping the .jar:

http://www.adam.com.au/kellyjones/javagaming/isostuff.jar

-Judd

edit: if anyone knows a more efficient or better way to do this type of tiling (aside from switching to LWJGL or something like that) i’d really like to know about it.

#2

This looks pretty nice! I wonder how hard it would be to extend it to non-level terrain?

#3

im getting 216FPS on a pretty naff Gfx (ATI radeon 9200).

The thing that really got to me about this is that the outside tiles are being culled, i would prefer it if the outside’s outside are culled instead, so you get a feeling of your still in the terrain, and not isolated…

Its not v. good looking to see the culling happening to speed things up! :slight_smile:

DP

#4

I suggest performance by balancing:

two things you have to weight up against each other:

-time to convert data
-time to copy data

when you draw more surface than actually seen (and you do, as rectified tiles overlap here) maybe a backbuffer-and-copy strategy would be better. i experienced that in my game. the reason is that your images (paletted gifs for example) need to be converted to screen mode which is 24/32bpp mostly and can have several different alignments of data (bitmap type; eg INT_RGB, BYTE etc…)

so there are three different ways to use:

-draw directly to a flip-buffer (as you do, if it is available)
pro: less to draw
con: every tile, and so more then actually visible surface is converted every time drawn

-draw to a backbuffer that exactly matches image-bitmap-mode (eg. paletted mode with global palette for gifs)
pro: conversion is only done once for exact the whole visible surface
con: whole surface will be converted even if less is drawn (eg. no scrolling but moving sprites), for gif’s a global palette is needed

-convert all images first
pro: no conversion at runtime at all
con: heavy memory footprint

for me the last worked best
in fact i copy every loaded image to a same-sized bitmap with the exact properties of the output-screen, and use this new duplicates for drawing. if all works, no conversen is done then.
this even accelarates alpha-channel blits i used a lot, but these are allways many times slower than direct blit.

hopes that helps
Paul