Wow, amazing job of getting a C=64 onto a Palm! I'm amazed how well it works... Speed seems good. It does start up with gibberish on screen, but switching to 'Buffered 256' seems to bring everything in line.
Wizball works OK (few sprite multiplexing issues it seems), sound is brilliant, and I could even run a few of my old demos!
Let me know if you need a beta tester.
Thanks, thanks!
-James.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Oops, I forgot to mention. The program doesn't save your settings at the moment. Is that right? I have to set the graphics mode everytime I go in, as I do for the joystick, sound, etc.
FYI.
-James.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
One to the 16 color modes and direct 256 should work on most any device. Buffered 256 is a last resort, as well as "forward compability" since it should scale on future 480x480, 640x640 devices.
The problem with the UX-50 is that it seems to LIE about its screen width. I'll probably make a work-around at some point.
Prefs is (supposed to be) saved every time that app quits, along with the auto snapshot. Does auto-snapshot work? Ie. try starting a game, then quit and restart Frodo. Does the game reappear?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, the autosnapshot works fine. The emulator always starts off where I left it.
The Buffered 256 is the only mode that works for me. Direct 256 actually fills the whole screen across (going over the virtual grafiti), but it's still corrupted.
With Buffered256, I take it you are drawing to an offscreen window and copying that to the display once you've finished drawing? The other modes directly write to the screen?
-James.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, all modes except buffered 256 write directly to screen memory. Now, of course I query the device for it's display width and compensate if the width is larger than 320 pixels, *but* the UX-50 and every other landscape device replies "320" rather than the actual 480.
I guess that would make the device more compatible with most programs, but it also causes any direct screen accesses to fail horribly. I'm going to add some patches to solve this. Essentialy, if I detect that the device has a "soft" graffiti area, I'll expand to full-screen, measure, then shrink back to normal mode.
Then direct 256 and one of the 16 modes should work fine for you, and your graffiti area won't be overdrawn either. Priority ~2.5. Next beta or the one after.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
MOST likely, I stupidly store the prefs in a resource in the main .prc (which would be on the stick). I really must change that. Still, it's nice to hear that AppShelf works since I made no effort at all to be compatible with it.
Johan
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The only caveat is that for pre-PalmOS 5 hi-res Sony models using the Sony HR lib you have to double the returned values. But they won't run Frodo anyway...
WinGetDisplayExtent() and WinScreenGetAttribute() won't give you what you want.
When you find 480x320 a landscape display but only want to use the 320x320 "client" area things can get kinda tricky. It all works until someone (like me) sets his PalmOS prefs to be left-handed, and suddenly that square isn't at the left hand side of the screen.
Hopefully there's some trivial way to figure out where the client rect is and I just haven't found it...
I guess you can check the "handedness" system pref (prefHandednessChoice) and if it's 'left' measure back from the right hand side of the screen? Sounds lame - there must be a better way.
- jim berry
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Wow, amazing job of getting a C=64 onto a Palm! I'm amazed how well it works... Speed seems good. It does start up with gibberish on screen, but switching to 'Buffered 256' seems to bring everything in line.
Wizball works OK (few sprite multiplexing issues it seems), sound is brilliant, and I could even run a few of my old demos!
Let me know if you need a beta tester.
Thanks, thanks!
-James.
Oops, I forgot to mention. The program doesn't save your settings at the moment. Is that right? I have to set the graphics mode everytime I go in, as I do for the joystick, sound, etc.
FYI.
-James.
One to the 16 color modes and direct 256 should work on most any device. Buffered 256 is a last resort, as well as "forward compability" since it should scale on future 480x480, 640x640 devices.
The problem with the UX-50 is that it seems to LIE about its screen width. I'll probably make a work-around at some point.
Prefs is (supposed to be) saved every time that app quits, along with the auto snapshot. Does auto-snapshot work? Ie. try starting a game, then quit and restart Frodo. Does the game reappear?
Hi Johan,
Yes, the autosnapshot works fine. The emulator always starts off where I left it.
The Buffered 256 is the only mode that works for me. Direct 256 actually fills the whole screen across (going over the virtual grafiti), but it's still corrupted.
With Buffered256, I take it you are drawing to an offscreen window and copying that to the display once you've finished drawing? The other modes directly write to the screen?
-James.
Yes, all modes except buffered 256 write directly to screen memory. Now, of course I query the device for it's display width and compensate if the width is larger than 320 pixels, *but* the UX-50 and every other landscape device replies "320" rather than the actual 480.
I guess that would make the device more compatible with most programs, but it also causes any direct screen accesses to fail horribly. I'm going to add some patches to solve this. Essentialy, if I detect that the device has a "soft" graffiti area, I'll expand to full-screen, measure, then shrink back to normal mode.
Then direct 256 and one of the 16 modes should work fine for you, and your graffiti area won't be overdrawn either. Priority ~2.5. Next beta or the one after.
I just remembered I am running Frodo from my Memory Stick, and luanching it with AppShelf. I bet that is causing the problem with the prefs saving...?
-James.
MOST likely, I stupidly store the prefs in a resource in the main .prc (which would be on the stick). I really must change that. Still, it's nice to hear that AppShelf works since I made no effort at all to be compatible with it.
Johan
As for real screen size, this works for me:
BitmapType* pDispBmp;
Coord pixW, pixH;
Int16 rowBytes;
pDispBmp = WinGetBitmap(WinGetDisplayWindow());
BmpGetDimensions(pDispBmp, &pixW, &pixH, rowBytes);
The only caveat is that for pre-PalmOS 5 hi-res Sony models using the Sony HR lib you have to double the returned values. But they won't run Frodo anyway...
WinGetDisplayExtent() and WinScreenGetAttribute() won't give you what you want.
When you find 480x320 a landscape display but only want to use the 320x320 "client" area things can get kinda tricky. It all works until someone (like me) sets his PalmOS prefs to be left-handed, and suddenly that square isn't at the left hand side of the screen.
Hopefully there's some trivial way to figure out where the client rect is and I just haven't found it...
I guess you can check the "handedness" system pref (prefHandednessChoice) and if it's 'left' measure back from the right hand side of the screen? Sounds lame - there must be a better way.
- jim berry