Re: [Fenfire-dev] Yet another libvob API: LWJGL

[Tuukka Hastrup]

On Sat, 14 Jan 2006, Matti Katila wrote:
> On Fri, 13 Jan 2006, Tuukka Hastrup wrote:
> Ok what we can do with this information? Let's say that we use lobs to
> fill the scene with text. If we can put 600 words per (academic text) page
> (http://www.writersservices.com/edres/p_word_count.htm)
> and one word has aproximately length of five. Every character takes 2
> trids to render into rectangular texture. 8200/2 / (600*5) ~= 1 page with
> more than 50 fps in my machine. Well it's not good but not the worst
> case either. If we put just a few images instead we get much better
> results of course.

So you would say this is acceptable and the test used a comparable amount
of jni calls per frame to what fenfire would?

> > Perhaps a "Fenfire demo" that builds a
> > scene like we would in reality and then animates it to see how
> > much resources it takes.
>
> Well, go ahead :-)

Well, you can go straight ahead and implement lwjgl libvob, I don't want
to be slowing you down. Just (bad?) ideas ;-)

> > Right, was one of the requirements to have as few JNI calls per frame as
> > possible?
>
> Then we come back to the start point, that's the system we have now.
> There still are the same issues.

Not really, there was this idea of moving the opengl data over in one jni
call, independent of using native libvob?

> > And was this a reason why none of the wrappers would do, as
> > they concentrate on games?
>
> Well, we haven't ever been there. When architecture is constructed it has
> needs to fulfill, i.e., requirements. I think speed was one of those
> requirements and Tuomas though that one jni call per frame would do
> that. We don't know whether a more than one jni call per
> frame is acceptable. This mode, where you have a freedom to draw anything
> on frame, is called as intermediate mode in game scenes.

I thought he'd found out more jni calls wouldn't be acceptable, but who
knows.  Requirements have changed too.

(What mode now exactly is intermediate mode? What are the alternatives?)

> > Perhaps that part of Fenfire could find its way
> > to one of the other wrappers.
>
> Not really. Native libvob is not a wrapper anymore. It does 3/4 of the
> work of libvob and has basically the libvob architecture and requirements.

Here again, I didn't mean libvob but a part that makes several opengl
calls into one jni call. Perhaps there wasn't such a part in fenfire but I
certainly thought there was =) And about Benja wondering if parsing would
be even slower that jni, I didn't mean a proper language with a difficult
grammar, just some way to quickly transfer data from Java side to native
side. I can't look into code now, but I hopefully can later.


Tuukka

-- 
-- Trying to catch me? Just follow up my Electric Fingerprints
-- To help you: address@hidden
                http://www.iki.fi/Tuukka.Hastrup/
                IRCNet: tuukkah/Stugge @#pii,#fenfire,#toys
                Jabber ID: address@hidden, ICQ #11321669