thanks 👍

is it possible to make custom window borders

you have to make them yourself of a borderless window

im not sure how to make regions that move the window around with lime though

youll need that to actually be able to move the window around by dragging the titlebar

Transparent windows tests. Built a simple flixel app with a couple of sprite blocks moving around. The SDL window opacity change results in both the window background and the content becoming less opaque. It doesn't just affect the window itself. The colorkey approach affects only the window background but not the content. So flixel shapes in my text remained opaque. But if the color appears in your foreground it will be transparent. Rather amusingly though if such a sprite moves across another one that you can see you will see a portion of that opaque sprite become invisible. No doubt because the one with the colorkey color rendered in front of it and then Windows WM decided it should be transparent. If you make the window borderless the colorkey version will make the window entirely invisible with just the content showing. Setting the opacity to 0.0 in the opacity change will cause everything to disappear. I do not know how to do the colorkey thing in a portable way.

@bulky-angle-28618 I found some comp errors and warnings in TransparentWindow.hx. Basically all the externs should have no return statements and just terminate in a semi-colon after the return types. The setColorKey function is Void so all the

return false

cases need to be removed.

> I do not know how to do the colorkey thing in a portable way. You can't. The specific "replace a color with the things behind the window" is not possible on Linux (and macOS?). I'll test it in the afternoon (don't feel like rebooting into windows right now) but I think you might not need the colorKey thing, just not clearing (or clearing to a transparent color) might also do the trick, just like it does on Linux.

> I'll test it in the afternoon (don't feel like rebooting into windows right now) but I think you might not need the colorKey thing, just not clearing (or clearing to a transparent color) might also do the trick, just like it does on Linux. I just had to know, so I tested it, and unless I overlooked something you do need the colorKey thing.

Ok thanx for trying it out. So this basically means there is currently no portable invisible window with visible content. A job for the SDL team to figure out. Even the color key thing is an imperfect implementation of it. I really don't know the graphics APIs on any of these platforms so I don't know what is possible without research.

On Wayland and X11 (ie Linux) it's very easy. Just don't clear with an opaque background (and make sure the EGL surface or X11 visual actually have an alpha channel). I suspect that approach also works on macOS. Windows is the only one were you need weird things.

> Even the color key thing is an imperfect implementation of it. Actually, if you use

0x0

as the color key and then clear the background to

0x0

instead of black it should work just fine.

transparent black - Let me try that

What is wayland by the way ? - is it some linux wm ?

Wayland is a new display protocol, the replacement for X11.

oh ok - I should read up on that

thanx - I'll have to play with a more practical example on the transparency thing. Flixel/OpenFL put other layers in the way - but setting the camera bgcolor to 0 and clearing to color in the colorkey does work.

so that is probably enough for what I need

but it would be really nice if the SDL team added an API over these different impls

getting this error with no context:

Error: Invalid field access : length

Try with

-verbose

, it might give more information as to where it's failing.

I'm trying to rebuild lime 7.9.0 from source all the way down in all deps with debug symbols. I recursively cloned the repo and reset to the commit 2b04782 which is the one listed against the 7.9.0 tag. Then when I run

haxelib run lime rebuild windows -debug

I get

../src/lime/_internal/graphics/ImageDataUtil.hx:89: characters 6-8 : Local variable s1 used without being initialized

. I've looked at change history for that file and it should have initialized the s* vars from some time in Feb 2021 and 2b04782 is in March 2021. I assume I'm doing something wrong. Any ideas ?

ah ... checking the v7 branch I see that at that commit this error was still there. That makes me wonder how it built - perhaps an older version of Haxe ?

nvm - figured it out - looks like it was fixed for the 4.2 update of Haxe

when I do a

lime build ...

I see various cpp files go by some with [haxe, release] or [haxe, gc] or such. What do these annotations mean ? they are only on some files

was lime rebuild give you the debugging msg you really was need ?

(into that dirty environment i am mean you told me last time of [sry about my first stupid

stereotyping

;:)

@hallowed-ocean-84954 chat is

allways

-> dirty dust (for me .)

any<way ... if something gets wrong we should

remember

!