Feature parity for win32 version

keszegh · February 2023

keszegh said:
i think the only thing i miss from win32 is the openhand cursor, are you realy sure it cannot be added?
https://learn.microsoft.com/en-us/windows/win32/uxguide/inter-mouse
in this page it is in the same slot as the 4-way arrow, which is included, so i guessed that perhaps openhand can be added too?

on the link i refer to the second icon in the "Compound mouse interactions" section, called 'pan' there.

hgy29 · February 2023

Really ? I mapped the OCR_ constants defined here: https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-setsystemcursor to those defined by QT, that way:https://github.com/gideros/gideros/blob/master/libgid/src/win32/platform-win32.cpp#L269

MoKaLux · February 2023

one more thing please, now that we have win32 64 bits !!! what is it actually?

Imho win32 export doesn't sound good for promoting Gideros, what could we call win32 export? Windows without Qt? Windows64? ...

keszegh · March 2023

@hgy29 there is some issue with screen, i open one and it is immediately fullscreen even though i call
s:setSize(800,480)
self.screen:setState(Screen.STATE_NORMAL)

keszegh · March 2023

also application:set("cursor","cross") etc does not seem to work for me at all now for some reason.

MoKaLux · March 2023

keszegh said:
also application:set("cursor","cross") etc does not seem to work for me at all now for some reason.

application:set("cursor", "cross") is working for me on win32 64 exported app

keszegh · March 2023

MoKaLux said:

keszegh said:
also application:set("cursor","cross") etc does not seem to work for me at all now for some reason.
application:set("cursor", "cross") is working for me on win32 64 exported app

ok, more precisely:
1. it updates only if i move the mouse a bit.
2. it does not update at all if i'm using a pen (to press a button which would trigger a change in the cursor).

MoKaLux · March 2023

keszegh said:
@hgy29 there is some issue with screen, i open one and it is immediately fullscreen even though i call
s:setSize(800,480)
self.screen:setState(Screen.STATE_NORMAL)

I have the correct? behavior when doing this:

	local sss = Sprite.new()
	local img = Bitmap.new(Texture.new("gfx/ui/rpgpp_lt_models_vgood.png"))
	local ss = Screen.new(0)
	sss:addChild(img)
	ss:setPosition(128, 128)
	ss:setSize(128, 128)
--	ss:setState(Screen.STATE_ACTIVE|Screen.STATE_MAXIMIZED|Screen.STATE_FULLSCREEN)
	ss:setTitle("test")
	print("ss", ss:getState())
	ss:setContent(sss)

one issue though is when you resize the Screen it goes blank!

(the Screen is the one at the left of the player, 128*128px)

keszegh · March 2023

try going full-screen with setState and then back? perhaps that's when it got stuck for me (even after restart).

MoKaLux · March 2023

keszegh said:
try going full-screen with setState and then back? perhaps that's when it got stuck for me (even after restart).

MoKaLux said:

one issue though is when you resize the Screen it goes blank!

Yes can confirm that when going full screen (maximized) and then back the screen is blank for me.
One more thing about adding Screen states, when I do this

ss:setState(0+8) -- ss:setState(Screen.STATE_NORMAL + Screen.STATE_ACTIVE)
print("ss", ss:getState()) --> 48!

I though that these would be the values but I may be wrong (taken from c++):
Screen.STATE_NORMAL 0
Screen.STATE_MINIMIZED 1
Screen.STATE_MAXIMIZED 2
Screen.STATE_FULLSCREEN 4
Screen.STATE_ACTIVE 8
Screen.STATE_HIDDEN 16
Screen.STATE_CLOSED 32

Plus also a bug? when you close the Screen the app closes too!

Plus a question: how do you set states? Like this ss:setState(Screen.STATE_NORMAL | Screen.STATE_ACTIVE) or like this ss:setState(Screen.STATE_NORMAL + Screen.STATE_ACTIVE)

MoKaLux · June 2023

moved to https://forum.gideros.rocks/discussion/comment/68302/#Comment_68302

MoKaLux · August 2023

It seems Event.KEY_DOWN and Event.KEY_UP don't behave the same on win32 and Qt/html5/android

In my game I implemented a jump input buffer (http://kpulv.com/106/Jump_Input_Buffering/) which works very well on all platforms but win32

html5 demo https://mokatunprod.itch.io/gideros-tests?secret=ht8e7uTPJgGUApRozoooCCEE

It seems win32 doesn't release the key (deleteKeyEvent) on Event.KEY_UP?

I had a look at the source code and found this extra code which isn't present in Qt, winRT, ...:

        if (keyCode == 0)
            return;

https://github.com/gideros/gideros/blob/2f3e098af176a6d3c9461464bcb6d88871b482d7/libgid/src/win32/ginput-win32.cpp#L548

~~Could you confirm that this could be the issue please~~

~~I am on my way on testing on my side by building gideros~~

BUILT AND TESTED DONE, ISSUE NOT FIXED

Thank you

EDIT: I built Gideros with my modifications (that is only commenting the above quoted code) but unfortunately that doesn't solve the issue

EDIT2: the issue happens when you quickly press and release (in my case the up arrow key) multiple times (it seems Gideros doesn't register the key up event?)
EDIT3: I attach a stripped project file if you want to compile for win32 and see the issue

MoKaLux · August 2023

EDIT4: the "faulty" code is in Files/systems/splayer1 line 155 and 178

hgy29 · August 2023

I can't reproduce the issue, or I don't know what to look for. I always get a KEY_UP when I release a key, although on windows there is an autorepeat feture that causes multiple KEY_DOWN to be sent for a single key if you press the key more than half a second or so.

I will disable auto repeat stuff , since Gideros doesn't expect it.

MoKaLux · August 2023

...although on windows there is an autorepeat feture that causes multiple KEY_DOWN to be sent for a single key if you press the key more than half a second or so.

I will disable auto repeat stuff , since Gideros doesn't expect it.

that was it, thank you captain

MoKaLux · June 10

I have a weird bug with MOUSE_MOVE and ALT key but not sure how to fix

	self:addEventListener(Event.MOUSE_MOVE, function(e)
			offsetx = e.rx - pointerstartx
			offsety = e.ry - pointerstarty
			if self.isgrabchild then
				if e.modifiers == KeyCode.MODIFIER_ALT then
					offsetx *= 5
				elseif e.modifiers == KeyCode.MODIFIER_CTRL then
					offsetx *= 2
				elseif e.modifiers == KeyCode.MODIFIER_SHIFT then
					offsetx = 1
				end

This work for SHIFT and CTRL but not ALT

The weird thing is that SHIFT CTRL and ALT work just fine when used for any keys on the keyboard.

On the c++ side I see:
libgid\src\win32\ginput-win32.cpp

	keyMap_[VK_SHIFT] = GINPUT_KEY_SHIFT;
	keyMap_[VK_SPACE] = GINPUT_KEY_SPACE;
	keyMap_[VK_BACK] = GINPUT_KEY_BACKSPACE;
 
	keyMap_[VK_CONTROL] = GINPUT_KEY_CTRL;
	keyMap_[VK_MENU] = GINPUT_KEY_ALT;
	keyMap_[VK_ESCAPE] = GINPUT_KEY_ESC;
	keyMap_[VK_TAB] = GINPUT_KEY_TAB;

versus libgid\src\winrt\ginput-winrt.cpp

		keyMap_[GINPUT_KEY_SHIFT] = GINPUT_KEY_SHIFT;
		keyMap_[GINPUT_KEY_SPACE] = GINPUT_KEY_SPACE;
		keyMap_[GINPUT_KEY_BACKSPACE] = GINPUT_KEY_BACKSPACE;
 
		keyMap_[GINPUT_KEY_CTRL] = GINPUT_KEY_CTRL;
		keyMap_[GINPUT_KEY_ALT] = GINPUT_KEY_ALT;
		keyMap_[GINPUT_KEY_ESC] = GINPUT_KEY_ESC;
		keyMap_[GINPUT_KEY_TAB] = GINPUT_KEY_TAB;

I am trying to compile win32 exporter to test on my side but something is wrong with my setup (mysis, qt, vs community are all installed):

$ make -f scripts/Makefile.gid win32.install
mkdir -p ./Sdk/lib/win32
#BUILDING gvfs
make[1]: Entering directory '/c/dev/gideros_dev202406'
#LINK gvfs.dll
cp win32_example/build/gvfs.dll ./Sdk/lib/win32
make[1]: Leaving directory '/c/dev/gideros_dev202406'
#BUILDING pystring
make[1]: Entering directory '/c/dev/gideros_dev202406'
#LINK pystring.dll
cp win32_example/build/pystring.dll ./Sdk/lib/win32
make[1]: Leaving directory '/c/dev/gideros_dev202406'
#BUILDING lua
make[1]: Entering directory '/c/dev/gideros_dev202406'
#C+ StringUtils
luau/Ast/src/StringUtils.cpp: In function 'bool Luau::equalsLower(std::string_view, std::string_view)':
luau/Ast/src/StringUtils.cpp:208:21: error: 'uint8_t' was not declared in this scope
  208 |         if (tolower(uint8_t(lhs[i])) != tolower(uint8_t(rhs[i])))
      |                     ^~~~~~~
luau/Ast/src/StringUtils.cpp:10:1: note: 'uint8_t' is defined in header ''; this is probably fixable by adding '#include '
    9 | #include 
  +++ |+#include 
   10 |
luau/Ast/src/StringUtils.cpp: In function 'size_t Luau::hashRange(const char*, size_t)':
luau/Ast/src/StringUtils.cpp:217:5: error: 'uint32_t' was not declared in this scope
  217 |     uint32_t hash = 2166136261;
      |     ^~~~~~~~

hgy29 · June 10

Hi @MoKaLux,

On win32 the ALT modifier is determined from the WM_MOUSEMOVE event here: https://github.com/gideros/gideros/blob/master/win32_example/win32.cpp#L619

But I notice that VK_MENU is used on the line of code, where it should have been one of the MK_xxx constants. Unfortunately, there is no MK_ALT/MK_MENU defined: https://learn.microsoft.com/en-us/windows/win32/inputdev/wm-mousemove

hgy29 · June 10

Googling a bit, it looks like it should have been written

	  if (GetKeyState(VK_MENU) & 0x8000) m|=GINPUT_ALT_MODIFIER;

instead.

MoKaLux · June 10

Excellent, that is what I was trying to understand. So it's not a bug in Gideros

Thank you hgy29. I also noticed there is no defined key for the ENTER key on the numpad. MS said that not all keys on the keyboard are mapped for win32

https://github.com/microsoft/DirectXTK/issues/319

I will have to do with it

One more question please: while searching for the above I tried to export win32 template on my windows 11 but it is not working (something about Luau). Have you tried it?

Thank you kind sir

MoKaLux · June 10

I found something interesting but unfortunately cannot test it

https://learn.microsoft.com/en-us/windows/win32/inputdev/virtual-key-codes

VK_MENU 0x12 ALT key
VK_LMENU 0xA4 Left ALT key
VK_RMENU 0xA5 Right ALT key

FI: NUMPAD ENTER key: https://learn.microsoft.com/en-us/windows/win32/api/winuser/ns-winuser-kbdllhookstruct, https://github.com/microsoft/PowerToys/issues/5703

MoKaLux · June 11

Hope you are all doing well

I am trying to build win32 export template with latest Gideros 2024.6 but failing

first I had this error (on both windows10 & 11):

#BUILDING lua
make[1]: Entering directory '/c/dev/gideros_dev202406'
#C+ StringUtils
luau/Ast/src/StringUtils.cpp: In function 'bool Luau::equalsLower(std::string_view, std::string_view)':
luau/Ast/src/StringUtils.cpp:208:21: error: 'uint8_t' was not declared in this scope
  208 |         if (tolower(uint8_t(lhs[i])) != tolower(uint8_t(rhs[i])))
      |                     ^~~~~~~

I added this in StringUtils.h and it seems to work:

// This file is part of the Luau programming language and is licensed under MIT License; see LICENSE.txt for details
#pragma once
...
#include stdarg.h
 
#include stdint.h // new 20240611
 
namespace Luau

Now this error pops up

:

...
#C+ winmm
#LINK openal.dll
cp win32_example/build/openal.dll ./Sdk/lib/win32
make[1]: Leaving directory '/c/dev/gideros_dev202406'
#BUILDING gid
make[1]: Entering directory '/c/dev/gideros_dev202406'
#C+ gaudio-loader-mp3
...
#CC mixer
#CC mix_all
#CC load_helpers
#CC load
libgid/external/libxmp-4.3/src/load.c: In function 'xmp_load_module_from_file':
libgid/external/libxmp-4.3/src/load.c:530:33: error: passing argument 1 of 'fileno' from incompatible pointer type [-Wincompatible-pointer-types]
  530 |         FILE *f = fdopen(fileno((FILE *)file), "rb");
      |                                 ^~~~~~~~~~~~
      |                                 |
      |                                 G_FILE * {aka struct g__sFILE *}
In file included from libgvfs/gstdio.h:8,
                 from libgid/external/libxmp-4.3/src/stdio2.h:4,
                 from libgid/external/libxmp-4.3/src/load.c:23:
C:/msys64/mingw64/include/stdio.h:1510:28: note: expected 'FILE *' {aka 'struct _iobuf *'} but argument is of type 'G_FILE *' {aka 'struct g__sFILE *'}
 1510 |   int __cdecl fileno(FILE *_File) __MINGW_ATTRIB_DEPRECATED_MSVC2005;
      |                      ~~~~~~^~~~~
libgid/external/libxmp-4.3/src/load.c:530:19: error: initialization of 'G_FILE *' {aka 'struct g__sFILE *'} from incompatible pointer type 'FILE *' {aka 'struct _iobuf *'} [-Wincompatible-pointer-types]
  530 |         FILE *f = fdopen(fileno((FILE *)file), "rb");
      |                   ^~~~~~
make[1]: *** [/c/dev/gideros_dev202406/scripts//GidWin32.mk:92: win32_example/build/libgid/external/libxmp-4.3/src/load.o] Error 1
make[1]: Leaving directory '/c/dev/gideros_dev202406'
make: *** [/c/dev/gideros_dev202406/scripts//GidWin32.mk:66: gid.win32.libs] Error 2
 
HP PC@XXX MSYS /c/dev/gideros_dev202406
$

Am I having all those troubles because I have a SPACE in my username directory HP PC???

I know when you install Android Studio they tell you not to have ANY SPACES in the path!!!

That may be the reason but I wanted to ask before formating my HD

Or maybe when I installed VS Community I forgot to install win10 SDK (I installed only win11 SDK). I will try to install win10 SDK and see what I get

. Nope didn't work, I guess VS is not needed here

I will try on my windows 10 laptop.

Thank you

hgy29 · June 11

@MoKaLux, it seems to me that you have an issue with your msys installation, like incomplete or bad compiler installed. Not sure of what happened, exactly but can you double check your installed packages ?

MoKaLux · June 11

thank you hgy29, I did the msys from scratch:

pacman -Sy pacman
pacman -Syu
pacman -Su
...

Checked my paths for the scripts files.

I can compile Gideros Studio and the Player.

The same errors as above appear when trying to build win32 export template

. Sadly, I don't know what I am missing.

Thank you for the help anyway, much appreciated

MoKaLux · June 21

I may have found why I can't build win32 export

luau makefile:
https://github.com/gideros/luau/blob/master/Makefile#L9C1-L28C1

MAKEFILE      = Makefile
 
QMAKE         = C:/Applications/Qt514/6.3.0/mingw_64/bin/qmake.exe
...
QINSTALL      = C:/Applications/Qt514/6.3.0/mingw_64/bin/qmake.exe -install qinstall
QINSTALL_PROGRAM = C:/Applications/Qt514/6.3.0/mingw_64/bin/qmake.exe -install qinstall -exe
...

I hope updating to Qt 6.3.0 will fix it, let's go

EDIT: Gideros Studio build success but still no luck with win32 export (still same errors as above post)

, I will investigate more

EDIT2: when I try to compile Luau.pro with Qt I have these errors:

linking debug/lua.dll 
C:/Qt/Tools/mingw1120_64/bin/../lib/gcc/x86_64-w64-mingw32/11.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lgvfs
collect2.exe: error: ld returned 1 exit status
mingw32-make[1]: *** [Makefile.Debug:212: debug/lua.dll] Error 1
mingw32-make[1]: Leaving directory 'C:/dev/gideros_dev202406/luau/build/Desktop_Qt_6_3_0_MinGW_64_bit-Debug'
mingw32-make: *** [Makefile:45: debug] Error 2
17:12:10: The process "C:\Qt\Tools\mingw1120_64\bin\mingw32-make.exe" exited with code 2.
Error while building/deploying project luau (kit: Desktop Qt 6.3.0 MinGW 64-bit)
When executing step "Make"
17:12:10: Elapsed time: 00:11.

MoKaLux · June 30

hello guys,

Do you know why there is such a lag when using MOUSE_MOVE on win32 compared to winQt?

I have checked the ginput-win32.cpp file and it is the same as the Qt one when it comes to GINPUT_MOUSE_MOVE_EVENT

Win32, when I drag a sprite on a 256*256 canvas everything is fine, above 512*512 it starts lagging a bit and beyond 1024*1024 a lot of lags. That is when I drag the sprite, it doesn't move at all for a couple of frames and after a while it jumps to the new location and it "freezes" again, ...

On Qt I can go up to 2048*2048 and then notice only little lags.

Is win32 that "weak" compared to Qt

?

keszegh · November 4

@hgy29 it seems that win32 exported lua files are encrypted even if encryption is set to off.

hgy29 · November 5

@keszegh, I just tested and they are not encrypted for me, but they are compiled anyway (VM bytecode) so you won't find your original source code

keszegh · November 5

hgy29 said:
@keszegh, I just tested and they are not encrypted for me, but they are compiled anyway (VM bytecode) so you won't find your original source code

i only noticed that it is not human readable (the lua file), as it was in the past. what platforms have this bytecode thingy?
overall it's fine then and thanks for checking.

hgy29 · November 5

Gideros always precompile lua code to bytecode during export, except for the files marked 'no execute', on all platforms, as long as I recall.

Howdy, Stranger!

Categories

In this Discussion

Top Posters

Feature parity for win32 version

Comments

Howdy, Stranger!

Quick Links

Categories

In this Discussion

Top Posters

Feature parity for win32 version

Comments