Closed GoogleCodeExporter closed 8 years ago
Thanks for reporting this. I'm not currently working on Frotz updates, but I
will look into this when next I do. Speed/performance issues may be more
difficult to resolve than incorrect behavior, because an iPad/iPhone is MUCH
slower than a Mac or PC, and I'm already using the fastest glulx implementation
I could find. But I'll see what I can do.
Original comment by spath...@gmail.com
on 7 Mar 2011 at 12:28
Thanks very much for supporting this. BTW, as an aside, do you know if any of
the Glulx games will display graphics (PNG/JPEG) on iOS devices under Frotz
1.5? I am just wondering if it's something I did that is causing the images not
to display...
Original comment by mountsha...@gmail.com
on 7 Mar 2011 at 12:57
The games I tested with when I was working on glulx graphics support are
Alabaster and Beyond, both of which work okay. Alabaster is the only glulx
game actually bundled with Frotz, so you won't need to manually transfer it.
Original comment by spath...@gmail.com
on 7 Mar 2011 at 1:07
One component in the performance issues may be the way graphics are drawn to
the screen. As I understand it, most Glk implementations only draw to the
screen when the game is waiting for input (with drawing commands drawing to a
buffer beforehand). The attached video (taken by the original poster) clearly
shows the individual images being drawn directly to the screen.
Also, I am seeing exactly the same performance on iPad 2 as is shown in the
video from an iPad 1, which suggests that processor speed may not be the
limiting factor here...?
Original comment by Ek.Temple@gmail.com
on 30 Apr 2011 at 11:59
Attachments:
Just an update:
I've got glk graphics working a lot better and hope to release an update in the
next couple of weeks.
It no longer flashes or shows each individual image drawing, and is much faster.
It's definitely still slower than it would be on a computer, but I think it's
reasonably performant now.
Original comment by spath...@gmail.com
on 13 May 2011 at 5:53
Perhaps I spoke too soon, It's reasonably performant on an iPad 2 (map updates
1-2 secs). On an iPhone 4, redrawing the map takes 4-5 times longer than this.
Older devices would probably be completely intolerable.
And I'm already caching all the drawing in an offscreen graphics context and
rendering the image at glk_select().
I'm not sure what I can do to make it faster.
(I'm hoping there's room for optimization in the game mapping routines as well;
I notice it redraws the whole map, based on dozens of composite images, if you
just 'look'. It could be much faster if it only redrew what's changed.)
Original comment by spath...@gmail.com
on 14 May 2011 at 7:39
Not sure if anyone is following this, but the mystery is solved, the problem
is image scaling. The Zork I background image is actually pretty large
(3200x1304), way larger then it needs to be. I'm caching the original images,
but not caching them at every size they might be drawn at, so scaling this
3200x1304 image happens every time the map is drawn and that's pretty expensive.
I'm going to consider this an issue in the game file and not in Frotz and not
worry about further opts for now.
Original comment by spath...@gmail.com
on 15 May 2011 at 7:23
Thanks, I'm still following. I had no idea the graphic was that size, I'll try
some testing with smaller sizes and hopefully that will make it tolerable to
include as a feature in a game intended for ipads. Thanks again for your help.
Original comment by mountsha...@gmail.com
on 15 May 2011 at 3:03
I've made it so the first time Frotz draws an image from the blorb file, if it
is bigger than screen resolution, it scales it down to screen resolution before
caching it; subsequent draws scale from this image instead of the original.
This helped a lot, and the iPhone 4 is now as fast as the iPad 2 was before the
optimization.
By the way, I noticed that Lovecraft Project.gblorb has another issue; if you
click on a room in the map, it prints to the main textbuffer window without
first canceling the line input request for that window, which is a Glk no-no.
Apparently this is a common enough mistake that Gargoyle has an option to allow
it anyway ("safeclicks"). I think I'll make Frotz do the same thing by
default, but just thought you should know.
Original comment by spath...@gmail.com
on 15 May 2011 at 8:48
Thanks for that additional note. Mainly I wrote the Lovecraft demo to test out
how IF with some graphics elements will work out on iPads. It's very much a WIP
to demo some concepts, and not meant to see release in this current iteration.
Thanks for looking into some of those issues. With the way I've set it up,
playing it on anything other than an iPad isn't really feasible, because of the
size of the graphics window and automapping display.
I believe I also tried Mark Tilford's Automap extension, which creates a Beyond
Zork style text automap as you play, but didn't have any luck running it in
iFrotz. But that's a separate issue I'll submit on another day if I ever return
to it. At present I was mainly interested in the iPad version.
Original comment by mountsha...@gmail.com
on 16 May 2011 at 12:52
This has been addressed in 1.5.3.
Graphics windows are faster and images can be displayed in text buffer windows
now.
Mouse input (taps) in graphics window now work.
Original comment by spath...@gmail.com
on 9 Jun 2011 at 11:33
Original comment by spath...@gmail.com
on 9 Jun 2011 at 11:33
Thanks for all your work on this! Looking forward to 1.5.3!
Original comment by Ek.Temple@gmail.com
on 10 Jun 2011 at 12:13
Original issue reported on code.google.com by
mountsha...@gmail.com
on 7 Mar 2011 at 12:08Attachments: