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
Restarting the service fixed the issue. Thanks!
brianmount Wrote:If it's alright, I'm moving this whole debugging-the-missing-highlight-image thing back to the RIVA thread, because it seems like it belongs here. It might be of interest to other RIVA developers, but won't be of any interest to end users of the iPhone (or any other) client.

Thanks for your debug log, Dean; that's very helpful. First of all, I see that I'm not sending the right protocol version. That's why I didn't see the new template message; you weren't sending it to me, because I was still using protoVer = 1. Am I supposed to set it to 2 now, or some other number?

Also, I see that, when you connect to Rob's server, you are getting AlphaBlits in the initial screen paint (serial numbers 26, 45, 78 and 97). I think these have alpha 0, and so have no effect, which is the right behavior. But you didn't receive those messages when you connected to your own server. So something must be different about Sam Vimes' template configuration, highlight images, or something. Do you know what that could be?

Of course, that still doesn't answer the question of why you are receiving a DrawBitmap as message serial number 144, whereas I get an AlphaBlit in the same position in the message stream coming from the same server. I remain stumped on that. Is it possible I'm sending something different at login time -- some flags detailing my screen resolution or capabilities -- that result in different server behavior? What values does your client send in the LoginRequest message?

I am relaunching this discussion. I have confirmed that the problem is also exhibited on the Android RIVA client, so I have to (continue to) assume that the problem is somewhere in the RIVA server or RIVA client documentation.

To recap:
"Assign a 'pressed' image to a button. The first time that button is pressed, it will not display the image."

Dean, can we nail this down once and for all?
Yeh, we can look at that. It clearly has to be something to do with a confusion between the two ends, since the C++ RIVA client doesn't have this issue. So that, in theory, should provide a big clue, but the big clue isn't coming to me as it should. Let me take care of a couple other things today, and I'll look at it.

Can you verify that you do get a drawing operation for that button's area when it's pressed? I.e. it's not something related to the first click from the RIVA client not getting recognized? If it recognizes the click, you should get a redraw for that area, and of course the activity requested should occur.

If that's the case, it has to be image related somehow, but not sure how. It cant' be something liek the first image download, since lots of images will have been downloaded already.

I can add some more verbose mode logging and then you could put the RIVA server into verbose mode and be able to see what's being logged as you interact with it. I'll work on that tomorrow.
I'm pretty sure it's not an overall first click problem because if you make a template with two buttons with pressed images, they both display the issue, and it recurds:

Load template
Press button1 (no image displayed)
Press button1 (image displayed)
Press button2 (no image displayed)
Press button2 (image displayed)
Press button1 (no image displayed)
Are you perhaps not responding to incoming messages while the user has the button pressed? Are you seeing other widgets not show pressed emphasis?
Dean Roddey Wrote:Are you perhaps not responding to incoming messages while the user has the button pressed?
I seem to remember that the pressed image was not sent, so it's not about not displaying it... The older messages should have the details of the investigation we did back then...
It has to send it or the C++ client wouldn't display them, right? So, if it's not sending them, it has to be due to something different between the C++ client and the others. Are you sure that the initial click has the right coordinates?
Unless the question is being asked differently, or there's some other state the C client sets that the others don't. Smile
There's not any questions being asked per se. The RIVA server is just spitting out stuff at the RIVA client. So it wouldn't change depending on who its talking to. It's sort of dominating the discussion. The only input from the RIVA client is the click.

And in terms of state stuff in the RIVA client, if it happened just on the first press after the RIVA client connected only, period, then I'd believe it easier that it's some sort of state thing in the RIVA client that doesn't get set until after some interaction occurs. But he was saying it happened on the first press of every button. But there's no state in the RIVA clients that have anything to do with widgets at all.

So really, the only thing that I can see that would be kind of likely is not responding to drawing commands while the mouse/finger is being tracked or something. That would be a reasonable explanation, though it might not be the right one.

Oh wait, looking at what he was saying above, it sounds more like any time you move to a new button, it fails. That almost sounds like an incorrect click position being sent or something, but the release is correct. Otherwise, there's nothing in the RIVA client at all that would know it had moved to a new widget. And certainly there's nothing in the RIVA server that would continue to operate one way while you clicked on one button, then changed when you clicked another. At least nothing I could remotely conceive of, though of course that doesn't mean it couldn't happen.
Well, from what I had tested with a Media browser, clicking the same arrow, the first time resulted in no "pressed animation", but the command was executed, while the following had both the animation and execution... I think the initial "pressed animation" was just redrawing the non-pressed state or such.
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