Charmed Quark Systems, Ltd. - Support Forums and Community

Full Version: Official RIVA thread
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39
I updated the beta website docs and added a RIVA User Guide technical document, to just discuss the general RIVA system and how it works from a non-developer point of view. It's not quite as coherent as it could be in this first cut, but it's a start.

I have some questions about the StartDraw and EndDraw commands. More important is the EndDraw question. I think I may be misunderstanding how to process it. The message indicates the portion of the screen to be updated. Straightforward enough. But then what do I do with my offscreen buffer. Am I supposed to dump it completely? When the next drawing cycle begins, will the server start from the ground up and tell me everything I need to know again?

I had been assuming that I needed to keep the offscreen buffer around, and then apply the new drawing commands on top of the existing buffer, but I'm seeing glitches in the rendering, and I think maybe it's because my assumption is wrong. Let me know if I'm not explaining myself properly.

Regarding StartDraw, I have noticed that sometimes I get some drawing commands, then StartDraw, then more drawing commands, then EndDraw. In other words, the StartDraw is not the first message in a new packet of updates. Is that to be expected? The documentation implies that I would get StartDraw first, but maybe that's not always the case. Right now I ignore StartDraw, so it doesn't matter, but if I have to rework my logic for EndDraw, the StartDraw may become important.

You should always get start draw first. Are you always checking the packet sequence numbers to insure you aren't missing packets? If not, you may be missing some which could explain the gitches.

There's generally nothing particular you need to do on StartDraw. It's just to tell the client that if it has anything it needs to reset for a new drawing cycle, it should do so.

On the EndDraw, you just need to blit from the memory buffer to the screen. Whether you keep the memory buffer around or not platform specific. Windows requires that I redraw the screen any time something is uncovered, so I have to keep around what's been drawn in order to update the screen. You may not need that if your platform maintains the window contents for you.

BTW, if you aren't up to .36, and you have any OnTimeout events set in any templates, then you could get intermixed start/end cycles. There was an error that was not serializing those events into the larger stream of stuff, so you could get one starting in the middle of another cycle. So that might explain some issues.
I was thinking about doing some persistent image caching. Are the serial numbers sent by the Riva server persistent? If the CQC environment is stopped and restarted, or even reinstalled and restarted, will the serial numbers be reset, or do they persist? If a user removes an images, then adds a new one with the same path, will the serial number be reset?
The serial numbers are transient. They are just for runtime purposes. You could always make it an option, where they can indicate that they only want to you get new images if they force it, if they know the images will not be changing. You can provide a menu option to clear the cache.
Can't you provide a mechanism to indicate if an image timestamp or something? So clients automatically know if an image has changed and can download the updated image.

Given the requirements for this type of app, you really need to put in some of these featuresj to accomodate high latency and transient connection. But I am glad Brian is considering persistent images.

I was just demoing my screen to a guy at work and it went like this...

Ok this screen... wait for it... it takes a little while over 3g, ok there this is my flooplan, now if you click here.... ok wait for it... here is my security keypad, and I can control my thermostat... wait.... (you get the idea).
We can look into something like this after 3.1. It would be way too big a change to do before then.
dumb question but i was up until 1:30am putzing with my S70 screens and didn't have the energy to check:

Do fonts have to be natively installed on the device with this? If so, sergio, any clue on how to install new fonts on the S70?
Something that would be nice for the iPhone at least, on which the user can't add any new fonts, would be a way for the client to request font data though the existing image cache, or even a new 'font cache'...
I have a question about an aspect of RIVA that I haven't quite figured out how to handle. As far as I can tell, there is never an indication of how large the template is, nor when a new template is loaded. So what I have done is set the initial size of the scrollable content area equal to the screen size, increasing it whenever I get an EndDraw whose rectangle includes additional real estate. This works pretty well to size the content size automatically. Then, if the content size is larger than the screen, the user can scroll around as needed.

When the user loads a new template with a smaller size, the content size ought in theory to shrink down to that area. But my client doesn't realize that a template switch has taken place, so what happens instead is that the full size of the old template sticks around in the client's understanding, messing up the size of the scrolling area.

For instance, on the iPhone, you can rotate the device. What Rob has done is create a 320x480 portrait template and a 480x320 landscape template, switching between them when the client signals that the device has changed its orientation. But since the client doesn't realize that the template has changed, I wind up with a 480x480 content size, with unnecessary extra scrolling area either below or to the right of the real template.

I thought about resetting the content area size when the device is rotated, but that has its own problems, and wouldn't help in the simple case of a smaller template replacing a larger one. And I'm planning to allow the user to disable scrolling altogether, which will help Rob, but won't help in any situation where the template is bigger than the screen size, and some scrolling is required.

Is there in fact a way to detect, either officially or via heuristic examination of the RIVA command flow, that the template size has changed? If not, do you have any suggestions on how I should attack this problem?
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39