mIRC Home    About    Download    Register    News    Help

Print Thread
drawing pix from binvars #201079 18/06/08 09:37 PM
Joined: Aug 2007
Posts: 334
foshizzle Offline OP
Pan-dimensional mouse
OP Offline
Pan-dimensional mouse
Joined: Aug 2007
Posts: 334
I want to be able to draw pix from binvars
mainly, so i can read from a file and draw it without having to extract it as an image


This is not the signature you are looking for
Re: drawing pix from binvars [Re: foshizzle] #201081 18/06/08 09:53 PM
Joined: Jul 2006
Posts: 3,738
W
Wims Offline
Hoopy frood
Offline
Hoopy frood
W
Joined: Jul 2006
Posts: 3,738
What if the file is sent with multiple /sockread command ?
How mirc will know the extention of the file ?
What mirc will do is what you can do actually with /bwrite and /drawpic, but internally.Why the problem with this method ?


Looking for a good help channel about mIRC? Check #mircscripting @ irc.swiftirc.net
Re: drawing pix from binvars [Re: Wims] #201091 19/06/08 03:26 AM
Joined: Aug 2007
Posts: 334
foshizzle Offline OP
Pan-dimensional mouse
OP Offline
Pan-dimensional mouse
Joined: Aug 2007
Posts: 334
but i want the thing where u can like write a picture to a cache or buffer/ram without having the file(just raw data)


This is not the signature you are looking for
Re: drawing pix from binvars [Re: foshizzle] #201105 19/06/08 09:44 PM
Joined: Oct 2003
Posts: 3,918
A
argv0 Offline
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
This would indeed be useful, and easy to implement.


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
Re: drawing pix from binvars [Re: foshizzle] #201218 22/06/08 09:14 PM
Joined: Apr 2004
Posts: 759
M
Mpdreamz Offline
Hoopy frood
Offline
Hoopy frood
M
Joined: Apr 2004
Posts: 759
/drawpic -c already caches images for subsequent calls i don't think writing the raw data to a file and loading it into the cache with /drawpic -c ONCE is such an extra hit to performance that it warrants the ability to /drawpic from a binvar.


$maybe
Re: drawing pix from binvars [Re: Mpdreamz] #201219 22/06/08 09:34 PM
Joined: Oct 2003
Posts: 3,918
A
argv0 Offline
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
Maybe not, but writing 100 different images to disk just to read them back from the disk *would* be a significant performance hit. In any event, performance isn't the only thing that warrants new features in mIRC, convenience does as well. This suggestion is both convenient and more efficient than writing a file to disk to have mIRC load it.


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
Re: drawing pix from binvars [Re: argv0] #201229 23/06/08 08:29 AM
Joined: Apr 2004
Posts: 759
M
Mpdreamz Offline
Hoopy frood
Offline
Hoopy frood
M
Joined: Apr 2004
Posts: 759
Convenience is just as valid reason for improvements as performance. I still think even convenience doesn't apply to this situaton. Binvars are not permanent so they'd have to be saved and reloaded across sessions (closing the picwin or mIRC) in fact the only thing that would keep them alive is the timer doing the drawing (i can't test right now that a binvar keeps excisting while a timer is associated with a script, but let's pressume it does because if it wouldn't it'd be an even worse scenario). So you'd still have to revert to disk access.


$maybe
Re: drawing pix from binvars [Re: Mpdreamz] #201240 23/06/08 02:33 PM
Joined: Oct 2003
Posts: 3,918
A
argv0 Offline
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
You're making the assumption that the binvar would be containing static data and needs to be persisted through sessions in the first place. Binvars make it easy to do double buffering for any animation style drawing, something files would *not* be able to do efficiently. If you don't understand its usage, don't blindly claim it's not useful- there's no basis for shooting down an idea just for the sake of it. What exactly is there to lose here? The implementation is actually already there in /drawcopy- mIRC just needs to extend that functionality to read data from a binary var.


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
Re: drawing pix from binvars [Re: argv0] #201243 23/06/08 03:18 PM
Joined: Apr 2004
Posts: 759
M
Mpdreamz Offline
Hoopy frood
Offline
Hoopy frood
M
Joined: Apr 2004
Posts: 759
Likewise don't assume i don't understand the usage/usefulness of double buffering. The only real usage for this is for images recieved through sockets or files read with bread. The later offering no real benefit over drawpic -c which already caches from file and for which every subsequent call to the image will be loaded from memory and not from a file. So the only real beneficiary situation is where someone request new data from a socket a lot of times which doesn't offer performance gain either so what you have is a convenient feature for a situation that either doesn't happen often or when it does poses different hurdles.

I take offense in your assumption i just shoot down an idea for the heck of it because i put question marks over the improvements it will bring, talk about the pot blaming the kettle. Your blatant rudeness aside i am all for more binvar support throughout mIRC such as $encode allowing &binvar as param this suggestion however brings too few gains IMO to be any priority. Is it convenient ? yeah. Would i use it ? yeah. Do i think its an absolute showstopper? heck no.


$maybe
Re: drawing pix from binvars [Re: Mpdreamz] #201245 23/06/08 04:36 PM
Joined: Oct 2003
Posts: 3,918
A
argv0 Offline
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
Quote:
Likewise don't assume i don't understand the usage/usefulness of double buffering. The only real usage for this is for images recieved through sockets or files read with bread.


Again, you're assuming that the binary variable is set once and never changed. This is the exact opposite usage for binvar support. The benefit is the ability to change the image directly in memory many times.

I'll make it easy and just show you an example, and you tell me if my usage is not "real":

Code:
; Assuming /drawcopy is modified to accept binvars as the input arg
; Draws and moves a square programmatically with double buffering

alias drawanim_1 {
  bset &bvar 1  1 1 1 0 0
  bset &bvar 6  1 0 1 0 0 
  bset &bvar 11 1 1 1 0 0 
  hadd anim buffer &bvar
  .timerANIM 1 0 drawanim_2
}

alias drawanim_2 {
  bset &bvar 1  0 1 1 1 0
  bset &bvar 6  0 1 0 1 0
  bset &bvar 11 0 1 1 1 0
  hadd anim buffer &bvar
  .timerANIM 1 0 drawanim_3
}

alias drawanim_3 {
  bset &bvar 1  0 0 1 1 1
  bset &bvar 6  0 0 1 0 1
  bset &bvar 11 0 0 1 1 1 
  hadd anim buffer &bvar
  .timerANIM 1 0 drawanim_1
}

; Main call to buffer / draw
alias drawanim {
  drawanim_1 | ; Start buffering
  .timerANIMTIMER 0 0 drawanim_timer 
}

; Copy buffer to window
alias drawanim_timer {
  noop $hget(anim,buffer,&bvar)

  ; 0 0 5 3 represents the expected dimensions of the 
  ; contents in the binvar since there's no other 
  ; explicit way to specify it.
  drawcopy &bvar 0 0 5 3 @win 20 20 5 3 
}


Note that I can do anything with those bvars, I'm not limited to statically defined data like in my example. You could for instance draw spirals of user defined size, or plenty of other dynamic drawing operations.

The usage here is exactly similar to buffering to a hidden @window and /drawcopying it to the actual window-- but the benefit is that a) you need no second window and b) mIRC doesn't need to go through the entire GDI layer just to draw image data, which is silly.

Convenient? Yes. Far more efficient? Yes. Can it be done with anything else? Only /drawcopy (see efficiency). Easy to implement? It pretty much already is (see /drawcopy). Is there more use than just sockets and files? ..Just look up. Priority? Maybe not, but the fact that it's "pretty much already implemented" trumps any issue of priority imho- it would be about half a day's work. Instead of BitBlt'ing from a HWND you just take the data from the *already existing* memory space.. implementation done. I don't get what the issue is here.


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
Re: drawing pix from binvars [Re: argv0] #201253 23/06/08 06:08 PM
Joined: Apr 2004
Posts: 759
M
Mpdreamz Offline
Hoopy frood
Offline
Hoopy frood
M
Joined: Apr 2004
Posts: 759
Your proposition is a lot more interesting then what the original OP asked for. I doubt he was on about using binvars as a mapping utility like you're envisioning it, but rather was on about raw image data in a binvar (png/jpg/bmp).

The later imposes not much benefit other then the dubious convenience by drawing straight from sockets. The way you interpreted the OP's suggestion as using binvars as a 2d map is a lot more interesting and offers indeed a lot more then you can do so now. If you had been more clearer we could have saved yet another one of our squabbles smile


$maybe
Re: drawing pix from binvars [Re: Mpdreamz] #201509 29/06/08 06:41 PM
Joined: Aug 2007
Posts: 334
foshizzle Offline OP
Pan-dimensional mouse
OP Offline
Pan-dimensional mouse
Joined: Aug 2007
Posts: 334
wat i wanted originally is to read from a file with lots of raw data(multiple files) and draw the selected data....
but, i like arv0's suggestions a lot too smile


This is not the signature you are looking for
Re: drawing pix from binvars [Re: foshizzle] #201572 30/06/08 09:21 PM
Joined: Mar 2007
Posts: 40
S
silimon Offline
Ameglian cow
Offline
Ameglian cow
S
Joined: Mar 2007
Posts: 40
I've been working on a project as of late that would benefit greatly from this ability. As it is, there's a dedicated server script that has to save multiple files and then use drawpic to make the data useful again. The clients have to do the opposite in addition -- drawsave and then read the files. It would also be important to have the ability to save an image or load an image into/from a binvar and have it support all the normal mirc image parameters.. i.e. 1-bit bitmaps, jpeg compression adjustment.