Technopolies

[rolz]

a couple of new shots
*Removed*

[Uija]

erm, alittle offtopic, but how do you manage to be 2 days ahead of me? Your titlebar sais: 2006.01.29 We here have Friday 2006-01-27 Wrong clock?

[rolz]

nope, that's the build/date string for upcoming version.
I increase version number just after the previous release - a reminder for keeping up to the schedule

EDIT:
that is, the next public version is 2 days away.

[rolz]

The build is postponed till the next week.

[rolz]

I am going on vacations and will be out of computer for a week. The build is postponed till feb, 15.


New features for today

- switched from AWT GL to GL renderer. Lost most of 2D functionality, but i hope to recover it in a couple of weeks
- started reworking 2d to be based on opengl
- added GLComponent, GLTextArea, and GLButton base classes

Simple UI with a couple of semi-transparent panels and lots of small buttons in the background:
*Removed*

[raft]

brave decision !

why ? what went wrong ? talk about details please.. i really wonder as (i guess) many others do

[rolz]

The main reason i beleive is just too many people coplaining about problems making the game to run at all. ;(

I had this decision in mind for a long time, but was unsure if it is worth switching from AWTGL to OpenGL renderer. ;(

I liked AWTGL renderer for being able to mix AWT and GL seamlessly, but i see now it has drawbacks. I would not throw it out completelly, it is still used by map viewer and animation editor (with AWT UI), but the game now uses GLRenderer.

[EgonOlsen]

...but the game now uses GLRenderer.

I somehow saw that coming... :wink: That's one reason why the upcoming 1.10 offers a multi-threaded GLRenderer to make better use of dual core cpus...
Is that new GUI based on LWJGL directly or on jPCT's blitting stuff combined with alpha blending?

[rolz]

Yes, I got new GL renderer performing much better on my system.

In average, I get 133-135 fps with new renderer and 75-85 with 1.10_pre3.


Regarding 2D - i would like to stick with JPCT's blitting unless you recomend to do otherwise.


BTW, I need your thoughts regarding blitting text.

After doing some UI benchmarks it appears that in general the UI works just fine except for text rendering - it is rather slow.

For example, the UI with 5 semi-transparent windows with a dozen of buttons
displays at 250-260 FPS.

If i add10 lines of text, 30-symbols per line, fps drops to 160. With 20 lines of text, FPS drops to 85-90.  

I assume that the reason of poor performance is my current text blitting implementation. I load the whole alphabet as a single texture and blit chars as regions of this texture, every char is blitted separatelly as a single polygon.

What are your suggestions on improving text blitting ?

I had ideas of creating a texture effect that would change UI component's texture when UI component's text changes - do you think is it worth trying ?
Let's say if the texture is 256x256 and text changes every 1-2 sec - will generating/uploading a texture be faster than blitting text as separate chars ?

[EgonOlsen]

Yes, blitting can be slow if used a lot, because every blit results in 2 polygons being rendered in OpenGL's immediate mode. Blitting larger parts as dynamically generated textures is an option, but i'm not sure if it's faster. Texture loading is a performance killer too. I'll have a look at the state of the current blitting code...could very well be, that there is some room for improvements. I can't remember that i've worked on it since i've written it... :wink:

[EgonOlsen]

Here is a version with improved blitting speed. I doubt that it'll get much faster than that without changing the way how blitting currently works at all. Well, give it a try and let me know: http://www.jpct.net/download/beta/jpctapi110_pre4.zip

[rolz]

Wow, MUCH faster now,

old version: 117 FPS
pre_4: 243 FPS

What did you change that influenced performance so much ?

[EgonOlsen]

Wow, MUCH faster now,

old version: 117 FPS
pre_4: 243 FPS

What did you change that influenced performance so much ?

Cool...
Blitting was quite "dumb", because it has never been a performance problem before. When calling blit, i had simply set up the OpenGL pipeline to a clean state, did the blitting, set it back to the former state. Now, this process is a bit more clever and i've removed some obviously unnecessary state changes.

[EgonOlsen]

I've updated the zip with a newer version that fixes a bug in blitting int[]-arrays that i had introduced in the last version. In addition, this version improves state management and should be even faster when blitting (well, not much but anyway...).

[rolz]

finally got some time to work on ui. Ported small part of older UI to GL, this time inventory screen:
*Removed*