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
Seems reasonable to me, if the modes actually do what the names would seem to imply.
Dean Roddey Wrote:Seems reasonable to me, if the modes actually do what the names would seem to imply.
I was afraid of that too, as it means I have to hunt for the bug(s) somewhere else... Wink
Fonceur Wrote:c1ClipMode_And = 0; --> INTERSECT
Actually, this one didn't seem to work, I switched to UNION instead and so far it seems OK. Of course none of the test templates are loading a popup or really have any overlapping regions, so the ClipArea usage hasn't really been representative...
Dean Roddey Wrote:- There is a new Ping command which simple clients can use if they want a persistent image download connection. There's a chance in certain simple templates that there will be no changes for over a minute, and the image server could time out. So if you've made no snapshot requests in around 45 seconds or so, send a ping to keep the connection alive.
On page 17 of the doc it says 20 seconds, but the .NET RIVA client seems fine with the 45 seconds... Wink
I'll have to look at it, but it's probably suggesting that you don't go longer than that, because you don't want to let it drop and there can be delays. So it's always best to allow for that.
So for an image download, I am supposed to send:

THeader hdrInfo;
TCard1 c1Flags;
TCard1 ac1SessCookie[16];
TCard4 c4SerialNum;
TCard4 c4PathSize;
UTF8 Path;

Or am I missing something?
Oh, no, you send the TReqImgDownload outward from your side. That's what you get back as the start of the download process.
Dean Roddey Wrote:Oh, no, you send the TReqImgDownload outward from your side. That's what you get back as the start of the download process.
I am not following you... Based on the documentation:

- Connect to port 13517.
- Send TReqImgDownload (containing what I mentioned).
- Receive TReqImgStart (containing the image).

But it seems to just times out with my TReqImgDownload...
Oh, I was looking at the others as actual members of the structure. Sorry. Anyway, are you sending it to the image download port? There are two separate ports involved, one is for normal traffic and the other is for image downloads.
Dean Roddey Wrote:Oh, I was looking at the others as actual members of the structure.
Well, it's like the other messages where the "text length" + "utf8 text" is included in the load, but not part of the "official" structure, no (which I've already complained about)?

Quote:Anyway, are you sending it to the image download port?
Yes, I was sending the request to 13517, but I guess I need to send it to 13516 and 13517 is for the download only... While that does make sense, it wasn't exactly obvious... Wink
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