| QUOTE (crobar @ Feb 24 2004, 09:48 AM) |
no real "dash problems" so far. this is a very solid release! the only issue ive had is with the virtual keyboard in the text editor...it feels like the dir pad should move the cursor around the keyboard rather than the thumb stick... other thant that i love thet we now have a text editor on the xbox! |
I was having a dilemma about this when I was designing it. Dpad moves very precisely as oppose to the thumbstick. I decided that the cursor placement in the text editor window needs to be more precise than the keyboard, so I made it that way. However, so as not to deprive the keyboard of the needed precision, there is a way to channel all input to the virtual keyboard by pressing the right thumbstick -so it behaves like the normal virtual keyboard.
I'd be revising it again so that an USB keyboard, when attached, gets the input priority so no mapping between it the the gamepad occurs. This means Enter will work as enter key and backspace will work as a backspace key, rather than mapped to A and B button presses.
@Hectobleezy,
It's all part of the optimization that I did. I deferred loading of icons so disk I/O is very minimal, but there was no check whether it was still doing its thing or not. I, again, modified it so that some icons load while rebuilding the menu, and put it in a worker thread so that it doesn't block the main process. This should prevent the music hiccups when going in and out of a submenu. Further, while it's in a separate thread, input is block so that it will have to finish creating the menu list before it respond to input. So as not to appear locked, a nice "Checking" with moving "..." is added. Now I just have to make sure that all processes that takes more than a few millisec to do is done on its own thread. Game information is done on the main thread, so this will also stop the music for a while.
Going into submenu appears to be little longer with this build, but, again, this is part of the optimization that I did. If you noticed, your boot up time is greatly reduced, because, I deferred scanning of submenu items, as opposed to doing it all on startup. This means that if you don't go to the applications submenu, it will never be scanned for required files. Again, doing it this way ensure that minimal disk I/O is performed.
I'm thinking of making this configurable, giving the user to scan files during boot up (slower boot up time), or scan when needed (slower going into submenu the first time). If you are using a skin that implements intro video, scanning on bootup may be better as it can mask the *perceived* delay.
@MetalZoic,
this should solve your problem as well. By adding a check, no preview, no input will be process until the list is done. This also ensures the the correct preview will be shown. I wasn't clearing the preview video when "B" is press (getting out of submenu).
I'm still very happy that there is no critical error being reported yet. Finally, all the test/research that I did paid off. I may release another quick update to solve those common problems/little annoyances that you are having.
Any thoughts on the file scanning? Deferred, or do it on startup like previous version (disk I/O intensive). Or perhaps, a balance between the two? Ideas would be great.