Engine and loading of 32bpp graphics is now in trunk!

[zombie]

Hi.

The 32bpp inclusion is a very nice feature of OpenTTD. I found some 32bpp images, set the x_offs and y_offs settings to reasonable values for the sprites and they really look great. But there seems to be a performance problem when the 32bpp blitter is enabled. OpenTTD consumes up to 90% cpu capacity (45% on HT enabled system) while showing main screen. More frightening is the fact that the task manager shows a value of more then 1 GB of data being read (I/O bytes (read)) after about 5 minutes.

After starting a game it gets even worse. You have to be very patient when you zoom out or zoom in and the mouse movement es a bit rocky.

What's going on there? I don't think that my computer is the reason for the performance problem. My P4 3.0 GHz with 2 GB DDR400 dual channel memory should be adequate for every version of OpenTTD. The performance problems even exists, when there are no 32bpp sprites in the data subdirectory.

Kind regards

Zombie

[Rubidium]

What happens when you set the value for sprite_cache_size in openttd.cfg to something higher, like 32 or 64?

[zombie]

Wow. I'd call that an instant reply. The game now runs smoothly with 32bpp graphics. Thank you very much.

Kind regards

Zombie

[athanasios]

I wish I could say same about my ancient P3 Still it helped me a lot. Before 32bpp was practically unusable in my PC. Now I can run it better but it is still slow.

Note for those in similar state with me: Disable animation.

Thanks a lot Rubidium.

[TrueBrain]

I wish I could say same about my ancient P3 Still it helped me a lot. Before 32bpp was practically unusable in my PC. Now I can run it better but it is still slow.

Note for those in similar state with me: Disable animation.

Thanks a lot Rubidium.

Or just run 32bpp-simple

[Octopussy]

Where can I found a 32bpp toolbar which would run with the last nightlies ?

[GeekToo]

AFAIK at the moment you can't directly.
You can pickup the 149 tar from this thread. Untar it, rename and PNGcodec the png and put them in the correct directory for the 32bpp sprites.
I think I will create a new tar for the 32bpp-trunk version soon, or maybe Dannys9 already has it covered, since he was busy with an auto-resize for the toolbar.

[dannys9]

I still *am* busy with it
I have only the 28x28 versions of the images. They look ugly when used with the nightlies.

[GeekToo]

dannys9: I didn't mean to imply you stopped it ( english is not my native language ).

For Octopussy ( and everybody that wants to use it ), I've created a tar with the png's of JOED, with the correct names and png-codec'd.

You have to untar it in the bin/data/sprites/trg1r directory (at least on Linux, don't know if it's the same on Windows).
On Windows I guess a program like Winrar is able to do the un-tarring, on Linux use a simple tar xvf command in the trg1r dir.

[athanasios]

I noticed you omitted the cursor. Was this done intentionally because it is no part of the toolbar? I suppose the aim is to change all the GUI, so we 'd better gather all the sprites under the name 'GUI' and not 'toolbar'.'Toolbar' was the first step.


Fast Forward doesn't work again.
To DEVELOPERS:
32bpp replacements, unlike 32bpp branch, work only for original grfs?
If not, can you, please, provide us a way to get the sprite numbers of extra grfs like openttd.grf 'cause seems they change over time (Peter, DaleStan we had a discussion about it before. Any way to get it from the code?).

[DaleStan]

What happens if you put things in bin/data/sprites/openttd/ ?

[dannys9]

Fastforward is defined in openttd.grf, so you need to place the file 57.png into data/sprites/openttd.

[edit]Beaten by seconds[/edit]

[GeekToo]

@dannys9 / DaleStan: thanks for the addition, it works.

@athanasios: there's no special reason for omitting the cursor, just started to make it a little easier to use 32bpp. By creating the tar, there's no need for everybody to do the same pngcodecing and renaming again: so more time's available to do other useful things.
We can name and order the tars anyway we want, or what is requested. There probably will be some discussion about it in the future.

@developers: the performance of the 32bpp was mentioned above, and increasing the spritecache size did help a little, but for me the generating of the world was incredibly slow( 256x256 tile world took over 8 minutes). So I took a little peek into the code, and made a dirty hack in genworldgui.cpp version version 10276 lines 905-911:

Code: Select all

//	MarkWholeScreenDirty();
//	SetGeneratingWorldPaintStatus(true);

	/* We wait here till the paint is done, so we don't read and write
	 *  on the same tile at the same moment. Nasty hack, but that happens
	 *  if you implement threading afterwards */
//	while (IsGeneratingWorldReadyForPaint()) { CSleep(10); }

This is certainly not a final solution: the progress window is not shown anymore during generating, but what's more important, the complete screen is not updated for every tree etc that is planted.
But it reduced the generation of the world to ~20 seconds!
It's just a suggestion, but maybe you can look into this.

[osai]

I tried this with MacOSX (10.4.10 + PPCG5),

untared to /data/sprites/trg1r/

And I started OpenTTD (r10295) with ./openttd -b 32bpp-anim
but it aborts with the following Message:

Code: Select all

/compile_farm/openttd/nightly/compile_dir/src/gfx.cpp:612: failed assertion `sprite->width > 0'
Abort trap

Any Idea,
Greetz Osai

[Rubidium]

But it reduced the generation of the world to ~20 seconds!
It's just a suggestion, but maybe you can look into this.

Generation of a 256x256 map takes 20 seconds? Even a full debug build on my computer at the lowest possible CPU speed takes way way less. What hardware are we talking about here?

[athanasios]

Thanks DaleStan, thanks dannys9.
I didn't know it used number of grf in belongs too, because I already tried to use openttd with several numbers but I didn't use 57. I though it was an addition to original sprites like in branch. It is cool like that because all new grfs can have their 32 bpp sprites without much effort. Thanks developers.

GeekToo: It is very odd. I tried 2048x2048 and it took me 12min with high industries and towns, low sea, on my ancient PIII .933 GHz hardware. 256x256 took only 12 sec. Nevertheless those 12 mins are too much. I'd appreciate such a patch for big maps.

osai: As you can understand, with what I 've stated, there was no problem with Win32 binary under WindowsXP. Please don't ask to check under Linux, I am lazy to reboot ... MAC: impossible, I don't have one

[DaleStan]

It is cool like that because all new grfs can have their 32 bpp sprites without much effort.

Indeed. It makes great sense. Until you add a sprite to somewhere other than the end of a GRF file. Then it suddenly becomes most horribly and violently wrong.

[bobingabout]

so... these PNG files go loose in a directory?

this means it is impossable for me to continue running OTTD on my USB drive, i have to keep the FAT as small as possable, else my DivX player won't read the drive.

it already struggles to read it with a FAT of 100 files, the windows "System Restore" snapshots are a total nightmare, as are the "Thumbs.db" files... i've turned those features off for the drive on my home PCs, but when i use it on someone elses PC, it creates them all over again, which slows it down even more. i delete them all regularly...

can't you have something like a GRF, where it is all stored in a single file? maybe some kind of zip or rar file? and how does NFO type coding work for 32bpp sprites?

[Zephyris]

The current intention is to (eventually) allow packaging into one .tar per .grf, as was done in the 32bpp branch. Hence less files...

[athanasios]

"Until you add a sprite to somewhere other than the end of a GRF file."

So let us add it in the begining of the GRF file!