bitmap draw bug

aliasant · 4 Apr 2009

Lol 🙂

Go Girl!

sunsynth · 4 Apr 2009

Hmmm, even without a MGUI and no Front Panel?

oddson · 4 Apr 2009

You need to use the other size primitive. The Bitmap Size primitive gives those values. The View Size needs to be connected to a View (as an enabled front panel or an MGUI primitive). The View Size should output the size of the connected view and not the size of any bitmap content within it.

It think the real issue is that this is one of those areas in SynthMaker with the directionality of program data become confusing. Defined graphic components on the right hand side of the Bitmap Create primitive seem like an input but arrive on the output side. Normally V connectors only appear as output on the right-hand-side when the primitive is passing V content from one side to the other with or without transformation (as with the Rotate primitive). Bitmap Create and Draw to Bitmap are the only exceptions.

(FYI to noobs - the Bitmap Create primitive is used to take graphic content generated within S|M and store it as a bitmap that can then be used as output within the program or to save as file output.)

MyCo · 4 Apr 2009

As I understand S|M, every View has it's parameters which are width and height. Each front panel generates this values by its size. So a component that generates a View has to pass width and height with it for following components. And this particular primitive doesn't do this. It's nearly the same bug as yu can see here: selector bug

The trigger (which is part of the green data type) is not passing through a primitive.

@oddson: what other "size" primitive? None of the View-Size primitives work, because in the generated View are no parameters stored (that's the bug).

sunsynth · 4 Apr 2009

you overlooked:

The Bitmap Size primitive gives those values

which outputs 80 x 80...

Tzarls · 4 Apr 2009

I don´t get this..... why should it output 10 * 10, when you are specifying a size of 80*80? If you use a Bitmap size, it outputs 80*80, which are the right values. And the V on the right side of the Bitmap Create primitive is actually an input, I think.

And maybe I´m wrong, but I think the only way to create a view is with the GUI primitive. The V connectors on the other primitives are to attach them to an existing view, not for creating views.

MyCo · 5 Apr 2009

first, when I work "on" the view I have the grid size set on the "bitmap create", it can be different and I can't use a lot of the draw primitves without recalculating EVERY size-value. I can't use "grid to pixel" or "pixel to grid" at all.

second, when I work on a view, I don't understand why I have to use variables from a bitmap at all. I don't have to use external "height" or "width" input when I draw normaly on a View, so why do I have to do it here? --> inconsistency and I still believe that's just a bug (missing parameter assignment)

third, 80x80 is in pixel, Views operate in grid size, the grid size is by default 8 pixel per grid square but you can change it when you use "bitmap create"

oddson · 5 Apr 2009

I guess it could be considered a missing feature of the View Size primitive that it won't give the obvious output for the two primitives that generate V outputs without views being created... but personally I wouldn't have expected them too (and yes I forgot about pixel versus grid units -- something I was once quite careful about while doing the primitive survey).

mwvdlee · 29 Dec 2009

From: Make "Bitmap Create" have an area

I agree with the poster that the width and height should be set for views generated by Bitmap Create.

Thing is; why would it be so difficult to include that information for those people who want it? I assume it's already reserved in the View data structure internally but simply not set.

Besides, do modules like Rotate and Smooth work on view generated by Bitmap Create? If so, then the information must already be in there somewhere, if not then... well... shouldn't they?

Acrobat · 16 Feb 2010

MyCo wrote: So a component that generates a View has to pass width and height with it for following components. And this particular primitive doesn't do this. It's nearly the same bug as yu can see here:

Probably the reason why it doesn't work like others is because it is NOT like others. It's just a bitmap primitive against vector primitives. 🙂

mwvdlee · 16 Feb 2010

Acrobat wrote: Probably the reason why it doesn't work like others is because it is NOT like others. It's just a bitmap primitive against vector primitives. 🙂

So basically its exactly like the others. The only difference between the screen and a bitmap is that... well... technically there really is no significant difference.