[TESTERS NEEDED] Another World

[__builtin]

Bugs:
All Targets:
CCW is borked, looks like the wrong stride, can be seen on the sim.

This should be fixed in the latest patch set.

Starting the plugin and choosing "quit" without starting a game and then starting the plugin again and choosing resume game causes a panic, this can be fixed by setting a bit to tells us if a game has been played first before saving, if not don't save

Hmm... what patch set?

1) I really hate the "quit" with the hidden extra save first then quit functionality, and even if it was changed to say "save and quit" I would much prefer just a "save" and "load" option with a "quit" that only quits.  Even with only one slot.  My beef being, when I'm past a difficult area, I'm forced to "quit" in order to save, and start up the plugin again and go set my settings again then resume my game.  Also when I want to load a save and I have to "quit without save" so I don't over write the old one and start it again to load my save then its back to settings so I can set my preferred options again before playing.  It's all very unnecessary and frustrating, I don't really see the appeal of it the way it is now.  If it's ok with you, I'd like to rework it.

I agree with your reasoning here. However, I think there should also be a "Save and Quit" option, so people don't accidentally quit and lose their game.

3) We need to set the lcd timeout to "off" so the screen stays awake, it is a cinematic experience after all, and then set it back when we exit.

This is really quite trivial, but I haven't gotten around to it yet.
DONE!

4) Even on a fast player, the game play feels sluggish if the fast mode is not on, and then most times that's to fast, maybe we can adjust the "normal" speed to say 10% faster. About 15-20 fps seems more suited to a natural game play feel.  I know players can do it, the "fast" mode is just to fast, if only it had a "medium speed" setting

I suppose this is possible. Perhaps dividing the delay between frames in half?

[BenBrown]

I have finished the keymaps for all targets with HAVE_LCD_COLOR except the ones not defined in the uisimulator, there's a few not in there.

Bugs:
mrobe500, is really messed up at least in the sim, someone needs to test it on real hardware.  It looks like the wrong stride again, but this time it happens across all orientations.

Is it possible to just run it at full speed, and limit it to 20fps on all targets?

[__builtin]

Weird. Really weird. Do other 640x480 devices have the same issue?
According to wodz, it's the LCD stride. Other devices have a horizontal stride (that is, the pixels are stored row-by-row in memory) while the mrobe500 stores them column-by-column (a vertical stride).
This complicates matters a bit because the internal format used by XWorld uses a horizontal stride.
However, the CPU on the mrobe500 is insanely powerful (875 MHz) and the plugin buffer is twice the normal size, so any overhead incurred converting between the two should be negligible.

[BenBrown]

 
I'd just like to call attention to Franklin Wei's tremendous work on this plugin, he works at a break neck pace.   Its hard to keep up with sometimes for a person like me, who prefers to work at a much slower pace because he's learning.  I'm a rockbox'er not because I'm a great programmer, but because I want to be one day.

 
But if Franklin doesn't stop clobbering Gerrit and if he doesn't start with the latest code, in the most recent task, every day before he starts working, and if he doesn't learn to wrangle git into keeping his local branches _some what_ resembling a source control managed repository of changes.  Then I give up!

 
But seriously dude thanks for all the hard work  It's almost "ready" but get the branch looked at it's clobbered 

[__builtin]

But if Franklin doesn't stop clobbering Gerrit and if he doesn't start with the latest code, in the most recent task, every day before he starts working, and if he doesn't learn to wrangle git into keeping his local branches _some what_ resembling a source control managed repository of changes.  Then I give up!

Hehe... yeah. Gerrit shouldn't let you push unless you pull first.

But seriously dude thanks for all the hard work  It's almost "ready" but get the branch looked at it's clobbered 

Nah... it needs sound!

So what'd I clobber? Is it fixed?

[__builtin]

Ok, it looks like grayscale/monochrome support won't be happening: http://www.rockbox.org/irc/log-20141127#00:00:43

However, with the addition of sound, the game is now largely feature-complete, as well as being mostly bug-free!

IMHO, the only thing left before it's committable is support for vertical stride LCDs, though it could certainly use some more performance.

[saanaito]

Unfortunately, the game is virtually unplayable on small-screen targets. I'm stuck at the code wheel screen on my Clip Zip and c250; with scaling, the text is unreadable; without scaling, the needed text is off the screen.

So it's probably best to simply not enable the plugin for such targets (unless their screen resolution is very close to the minimum).

Fast scaling:


Good scaling:

[BenBrown]

I had an idea, what if when scaling is off on small screen targets, we set the framebuffer to start at the corner of the x y position where the code lives on screen.  So it will be real BIG and visible.

[__builtin]

Apparently the strings embedded in the interpreter were copyrighted, so a workaround was devised. BenBrown provided an alternate set of strings () which ship with the plugin by default, but it's possible to load the "official" strings from /.rockbox/xworld/xworld.strings

EDIT:

I had an idea, what if when scaling is off on small screen targets, we set the framebuffer to start at the corner of the x y position where the code lives on screen.  So it will be real BIG and visible.

I'm working on that right now. It works only with rotation disabled for now, I'll commit when I figure out how to zoom with rotation.