mIRC Home    About    Download    Register    News    Help

Print Thread
#260318 29/03/17 12:26 PM
Joined: Apr 2010
Posts: 969
F
Hoopy frood
OP Offline
Hoopy frood
F
Joined: Apr 2010
Posts: 969
When using /drawrot, the image seems to be rotated around an ambiguous center point related to window size.

For instance, if the window's display area is large enough to house the entire image it works fine; but if the window is NOT large enough, the drawrot fails:

Code:
;; compare
;;     /drawrotbug 100
;;
;; to an input that, when doubled, is larger than your display area; example:
;;     /drawrotbut 1000
alias DrawRotBug {
  close -@ @DrawRotBug

  var %CellSize = $iif($1, $1, 1000)
  var %File = $qt($scriptdirDrawRotBug $+ $ticks $+ .bmp)

  ;; Create the picwin
  window -pBfz @DrawRotBug -1 -1 $calc(%CellSize *2) $calc(%CellSize * 2)

  ;; Draw a 'filling' rectangle to:
  ;;     1. set the background color for the image
  ;;     2. extend the internal bitmap to the correct size
  drawrect -fr @DrawRotBug 16777215 1 0 0 $calc(%CellSize *2) $calc(%CellSize * 2)

  ;; Draw something to have a visual representation
  drawrect -fr @DrawRotBug 0 1 0 0 %CellSize 20
  drawrect -fr @DrawRotBug 0 1 0 0 20 %CellSize
  drawrect -fr @DrawRotBug 255 1 0 $calc(%CellSize - 20) 20 20
  drawrect -fr @DrawRotBug 65280 1 $calc(%CellSize - 20) 0 20 20 

  ;; Copy & paste the top-left cell to the top-right
  drawcopy @DrawRotBug 0 0 %CellSize %CellSize @DrawRotBug %CellSize 0

  ;; rotate top-left 90 degrees
  drawrot @DrawRotBug 90 %CellSize 0 %CellSize %CellSize

  ;; copy & paste top-half to bottom-half
  drawcopy @DrawRotBug 0 0 $calc(%CellSize *2) %CellSize @DrawRotBug 0 %CellSize

  ;; rotate bottom-half 180 degrees
  drawrot @DrawRotBug 180 0 %CellSize $calc(%CellSize *2) %CellSize

  /*
  ;; uncomment if you want to see the result with external picture editor
  drawsave @DrawRotBug %file
  run %file
  */
}


I am SReject
My Stuff
Joined: Dec 2002
Posts: 5,411
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,411
Thanks for your bug report. I inserted a few /drawsaves at different points and it looks like the issue is due to /drawrect not drawing beyond the size of the bitmap. I cannot remember the exact design decisions involved with the /draw-related features, as they were implemented so long ago, however most of them do not expand the bitmap beyond the window size. I think, at the time, the worry was that even small errors in x/y/w/h would result in an enormous bitmap that would consume all memory.

Joined: Jul 2006
Posts: 4,145
W
Hoopy frood
Offline
Hoopy frood
W
Joined: Jul 2006
Posts: 4,145
What about a new switch on /draw* command, forcing the draw beyond the size of the bitmap?


#mircscripting @ irc.swiftirc.net == the best mIRC help channel
Joined: Apr 2004
Posts: 871
Sat Offline
Hoopy frood
Offline
Hoopy frood
Joined: Apr 2004
Posts: 871
Alternatively or in addition, I for one would like to see a /window switch that forces the canvas size to be of the given size, no matter the size of the resulting window. The reason for this is that the latter may be restricted by the screen resolution or (if the window is maximized) the mIRC window size, which I'd argue is often undesirable, in particular for cases where the result is to be written to a file or otherwise not shown directly to the user in that window. As Ouims has pointed out (Note 1) on IRC, it is already possible to force this now, but I would say that method is very, very far from obvious. It does resolve the original issue here though.


Saturn, QuakeNet staff
Joined: Apr 2010
Posts: 969
F
Hoopy frood
OP Offline
Hoopy frood
F
Joined: Apr 2010
Posts: 969
Khaled:
I feel that mIRC shouldn't attempt to predict and prevent scripted errors. For example, /bread can fill memory, looping + opening coms can fill memory, etc; typos in scripts happen, at most the scripter kills mIRC and restarts it after removing the offending script. To take preventative measures against such would end with mIRC being 99% of 'this *might* happen'.

--

Wims:
How is this any different than removing the limitation? you are simply aliasing what Khaled was attempting to prevent

--

I agree with Saturn though that at the very least, when a picwin's width and height are specified with the -f switch, the internal canvas should be increased to the specified size:
Code:
;; This should force the canvas to be 2000 x 2000.
;;
;; If the window is pre-existing, the canvas should
;; be extended to cover at least this space if it does
;; not currently do so.
window -pf @ -1 -1 2000 2000


--

My suggestion would be to remove the limitation that stops the internal bitmap/canvas from being extended with /draw*. We've seen quite a few bug reports over the years in which the poster thought it was an issue with a specific /draw* command and it turned out to be how mIRC handles the canvas.



Last edited by FroggieDaFrog; 30/03/17 04:25 PM.

I am SReject
My Stuff
Joined: Jul 2006
Posts: 4,145
W
Hoopy frood
Offline
Hoopy frood
W
Joined: Jul 2006
Posts: 4,145
it would preserve backward comp


#mircscripting @ irc.swiftirc.net == the best mIRC help channel
Joined: Dec 2002
Posts: 5,411
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,411
Quote:
I feel that mIRC shouldn't attempt to predict and prevent scripted errors.

The binary commands were originally limited for the same reason ie. memory usage. However, they needed to be less limited to make them remotely useful, so they had to be changed. The /draw commands have been used ever since they were created with only an occasional request to change them - and there is a way around their limitation by using /window.

Quote:
How is this any different than removing the limitation?

I have to say, I like that /window needs to be used because it is more likely to use explicit values. On the other hand, /draw commands used with variables in loops are more likely to result in unintended values. All it takes is one wrong x/y/w/h value to result in an enormous bitmap that uses all memory and causes other applications to fail, corrupt files, or shut down windows.

Update: adding a specific command, like /drawsize, that sets the bitmap size would probably be better than depending on /window. This should be in the next beta.

Last edited by Khaled; 30/03/17 06:55 PM.
Joined: Dec 2002
Posts: 5,411
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,411
I have added a /drawsize @ width height command. I have limited the width and height to a maximum of 32768. Also, /drawsize will not allow you to resize below the largest point that a /draw command has drawn to within the bitmap.

On my system, with 4GB free, /drawsize fails with 32768 x 32768. In paint.net, a bitmap of 32768 x 32768 just crashes paint.net. When it has managed to create it, paint.net uses up 2GB+ of memory. So it is still possible for /drawsize to cause issues, however I am assuming that most scripters will use it immediately after /window to set the maximum reasonable size that a scripter expects to use for that bitmap.

Joined: Apr 2010
Posts: 969
F
Hoopy frood
OP Offline
Hoopy frood
F
Joined: Apr 2010
Posts: 969
I think /drawsize is a good start, or rather the limit of ~32k x ~32k.

I ask you to consider including functionality to change the window's draw state so that /draw* commands would freely (without the need of extra switches or commands to be called directly prior) increase the size of the bitmap when applicable up to the established ~32k x ~32k size limit.

I understand that with the addition of /drawsize this functionality could be scripted, but internal checks would be far faster than mSL $calc followed by if-then-else checks to know if the bitmap needs to be extended. Given the context of what picwins are generally used for -- interactive interfaces -- speed is something that I feel should be considered.

Last edited by FroggieDaFrog; 31/03/17 04:28 PM.

I am SReject
My Stuff
Joined: Dec 2002
Posts: 5,411
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,411
In that case, 32768 x 32768 may be too large a maximum. If a scripter is going to repeatedly call /drawsize with every /draw to arbitrarily increase the bitmap size up to a possible maximum of 32768 x 32768, that will cause problems for users.

The purpose of /drawsize is to allow a scripter to set a reasonable bitmap size at the start of a script ie. what they know they will need. An arbitrary bitmap size is not practical or realistic as it can have a drastic effect on resources.

In your experience, what size of bitmap is generally needed?

Apart from that, resizing a bitmap is a slow process. If a script, instead of setting a realistic bitmap size at the start, chose to /drawsize repeatedly as needed, it would slow down significantly. The same would apply if mIRC did this automatically.

Last edited by Khaled; 01/04/17 03:19 PM.
Joined: Apr 2010
Posts: 969
F
Hoopy frood
OP Offline
Hoopy frood
F
Joined: Apr 2010
Posts: 969
Originally Posted By: Khaled
If a scripter is going to repeatedly call /drawsize with every /draw ...
I wasn't meaning to infer that the /drawsize would be called with each /draw, but rather the checks to see if it needed to be called may need to be performed.

In my current use case I have an operation where the script is creating a single sprite sheet from all images stored in /sprites/. This is done via looping and /drawpic where with each /drawpic I'm checking to see if the bitmap needs to be vertically resized and using various 'hacks' to resize the bitmap when needed. Its not that I wish to call /drawsize with every drawpic, but rather I still have to perform checks to see if such is needed.

This operation could be sped up if the "does the bitmap need to be resized?" checks were to be performed internally with the /drawpic commands, and the '/drawsize' operation done as needed.

Originally Posted By: Khaled
In your experience, what size of bitmap is generally needed?

For the current use case above I'm working with a 3200px x ~640px. I personally don't see myself using anything more than 4k x 4k but I could see larger sizes being applicable for such things as Mario level clones or similar. If you are worried about ~32k being too high, I would not oppose reduction to ~16k

After thoughts:
My level map is 2k x 2k, and I know both Wims and Talon use internal maps of similar sizing if not slightly larger at times

Last edited by FroggieDaFrog; 02/04/17 02:19 AM.

I am SReject
My Stuff
Joined: Dec 2002
Posts: 5,411
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,411
Thanks for the feedback. I decided to set the maximum to 8192 x 8192 pixels in the new beta which sounds like it should be more than enough for the majority of use cases. It also limits memory usage to 200MB per maximum size bitmap. As for automatic resizing of bitmaps, that would be more complicated to implement and might require rewrites of existing routines. I have added it to my to-do list though. Thanks for your comments everyone.


Link Copied to Clipboard