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
SamVimes2 Wrote:Dean, do you mean web widgets or web image widgets? Based on this post and some other discussions I'd been looking forward to web image widgets in the advanced RIVA protocol.

Oh, sorry, I thought he meant web browser widgets. Yeh, for web image widgets, that's doable. It just needs a V2 of the protocol. The problem of course is that I don't want to dribble out V2, V3, V4, etc... by adding a thing at a time and having all these backwards versions to deal with. So I need the time to sit down and deal with a substantial chunk of the stuff that has been discussed and do a serious V2.
We need some less confusing names for the pair! Looking forward to V2.
If I go ahead and use templates with web image widgets will they just load with the widget missing?
potts.mike Wrote:If I go ahead and use templates with web image widgets will they just load with the widget missing?

Yeh, you just won't see them. Though the iPhone client may get a draw request with an empty URL, which hopefully won't confuse it.
I think I need more information about the bitmap modes used in the DrawBitmap message. In the version of cqc.h I have, modes 1 through 7 are defined. Most of the time the server sends me mode 5 (SrcCopy), which makes sense. But I also get mode 1 (DstInvert) sometimes. What am I supposed to do in that case?

Also, I occasionally see modes 0, 53, 97, 101, 102, 105 and 114. Maybe there's a bug in my code, but as far as I can tell that's what the server is sending me. Are those defined modes? Or am I supposed to be applying some sort of mask to the bitmap mode byte?
Oh, maybe there's an issue. The DrawBitmapMasked operation is being passed as a regular DrawBitmap command, but the mode doesn't get set, nor does the transparency color get passed along. I think that we need a new DrawBitmapMasked command to support that. You will have to mask the image using the passed transparent color and display the masked image (the standard sprite type of masked bitmap draw.)

Do any of these problematic ones have images with color based transparency, as apposed to alpha type transparency?
I will have to let Mr. Vimes answer that. Rob, what are the file formats of your images of the monitors, speakers, printer and so on?

Dean, What is the meaning of the DstInvert bitmap mode? What am I supposed to do when I receive this mode? Maybe in this case I should be receiving it at all, but at least I'd like my client to do the correct thing when I get it.

Also, what happens when the .Net RIVA client gets such invalid modes? I would have expected that the .Net client would show Rob's template in a messed-up way as well, since it would also get the crazy mode values (Rob, have you tried that?). But maybe it does something special.
On another topic, my client is apparently displaying some of the characters taken from the GuiFX Transports font using the wrong color. In one example, Rob intends the transport controls to be white, but they show up as black. In the debugger, it does appear that the last text foreground color sent by the CQC server was black, which explains why I draw it that way. But I wonder if maybe my text color logic is wrong. All I do currently is rememember the most recently specified foreground and background colors, and use those when drawing text. Is it more complicated than that? Do other commands such as setting the font, drawing text (or non-text), or pushing and popping the graphics state need to be taken into account? Is there a stack of text color settings in any way?
The pushing and popping of the state should definitely include those colors. All graphics state stuff should be included in the overall state push/pop, including clipping areas and such. DstInvert does a XOR of the colors of the destination area. I don't think that you should be legitimately getting that. I'm hoping that it's the thing above, where you are actually getting some random stuff there. That would certainly explain why some folks are having problems and most aren't. Most folks probably aren't using any color based transparency.
Is there a parameter that determines the amount of blur applied to the text in the DrawTextFX message? I saw a field called passes or something like that, but I wasn't sure. If there is a parameter, what values does it take on, and how much blur results from the various settings?
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