This is my last post on this thread... here it goes:This function should draw on the regular screen in 160x160:
void draw() { WinPaintLine(10,10,150,150); }
This one, if run on a high res machine will do the same thing, but in
high res (this doesn't check to make sure the device you're on has
high-res, and will crash if run on, say, a m515):
But, if I'm drawing to a native screen (instead of standard), will that line consist of 2x2 pixels on a hi-res screen, or will it automatically resolve itself and draw twice as many 1x1 pixels? In other words, if I were to draw a point at 10,10 on a standard screen, I don't need the ability to, on a hi-res display, change that to 20,21. I will only EVER use the standard resolution in terms of where to draw. I only want the hi-resolution rendering of those drawings.
Yes, you only need to worry about 160x160 coords. All the high-res drawing is done automatically for you by the Palm OS. This is all explained in the palm os companion under the "high resolution display" section. Basically, you don't have to worry about high-density coordinates if you don't want to. Just do all your drawing in standard coords, and everything will look fine on a high-res device. If you want pixel-level precision in your drawing, you can switch into the native coordinate system on OS5+ devices, but that's your preference, it's not a requirement.
Look, if you don't believe the stuff I'm telling you, which it seems you don't: Verify it yourself. Just write some test code, try it. See what happens. Hell, I've written quick test code myself just to verify what I say in this forum before I say it. There's no substitute for experience. This is your journey, so don't be afraid to walk a bit yourself.
I tried to help you initially since I *just* went through much of this stuff myself in writing my game. I'm writing based on my own experiences, which come chiefly from (1) reading through the SDK docs, and (2) trying stuff in pose, the simulator, and on actual OS-4/5 devices (an M130 and Tungsten T, specifically).
Yes, I was that other person, and yes, just call WinCreateOffscreenWindow with 160,160, nativeFormat, &error). A high-density offscreen window will be created automatically on devices that support it.Ah, but another person said that if I use nativeFormat and leave it as 160x160, then it will, underneath, create a 320x320 window. This seems to contradict what you just said.If you want to draw in high res to an off-screen buffer, and then display that, you have to make sure to allocate your offscreen buffer in nativeFormat, not screenFormat:
// in screen setup code
WinHandle wh=WinCreateOffscreenWindow(320,320,nativeFormat,&error);
This is all confusing me more, actually. I don't care about working in 320x320 resolution. I just want my lines and text to render in hi-resolution if available. So, I don't know if I have to surround EACH and EVERY drawing command with code that checks if hi-res is supported, and if it is, change the coordinate system and double all of the x,y values accordingly. It would be a lot of work if this is necessary. But, based on what you are writing, it makes it sound like it is. Based on what Eron wrote earlier, it sounds like you don't.You don't.
Again, I implore you: If you don't know what to believe, then believe nothing. don't go on faith. Just try it yourself and see...
Of course, another question I have is how you determine what resolution the device actually supports. There is, for example, a call to get the supported densities of the device. But the documentation says that this isn't necessarily what you can actually draw to...only what the blitter supports (whatever a blitter is!). So, while this may report some desities, you might not actually be able to render to this. YOu can use the GetCoordinateSystem, because that only gets the CURRENT coordinate system. If I set the CoordinateSystem, it uses a different type (though, similarly defined) for coordinate systems versus densities.The section in the reference guide in which you must have read this, (WinGetSupportedDensity, p1165) actually tells you what to do, in exactly the next sentence. Here's a direct quote:
"NOTE: The densities reported by this function are those that are supported by the blitter. These densities are not necessarily supported by the underlying hardware. A handheld with a low-density screen that is able to scale high-density bitmaps will report that it can handle both high and low density bitmaps. Use WinScreenGetAttribute to determine the density of the handheld's screen."
There you go. Call WinScreenGetAttribute to get the actual width, height of the screen in native coordinates. If you want the width, height of the screen in standard coordinates, use WinScreenMode (which is linked to by WinScreenGetAttribute in the docs).
There is another call about getting the screen attributes, but that SOUNDS like it is getting the actual pixels that the display supports. That's no good, either. Some devices support 320x240, others 320x320, and others still 320x480. My code would have to be able to know the difference. For example, is 320x240 mean that one direction is 1 1/2 times versus 2x density...or does it mean that the device is actually 240x240 plus an extended 80 pixels for a virtual graffiti area?Why isn't it good? On devices that support a virtual graffiti area, you can still draw over that portion of the screen (hence, the "virtual" rather than "silk-screened" graffiti area).
So, for now, I will only try to detect double density if necessary and automatically just double all values. But, I'm not sure I even need to do that! It may be as simple (perhaps???) as creating a native format off-screen window, and setting the coordinate system when I do the CopyRectangle. I don't know, though. That's why I'm hoping people here can help! :-)Don't double all values unless you've switched into using high-density coordinates yourself, otherwise you'll draw off the screen. ;)
-- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
