Keyboard auto repeat and other issues about vamigaweb HOT 77 CLOSED

Yes yes yes ! :)

from vamigaweb.

Hi Vincent

Very nice web-based C64 and Amiga emulators, congrats ! They work quite well on my Samsung Z 3 fold (Android).

cool a fold !! I want to see picture 🤤 of it running vAmigaWeb ...

One major issue is that on both emulators, the virtual keyboard does not allow key auto repeat when pressed long. This is a show stopper, for instance for flight simulators, like Fighter Pilot on C64 and F/A 18 Interceptor on Amiga...

Yes I know the virtual keyboard does currently only work on with the click event ... so there is a fix auto key release after a couple of milliseconds .... I have to adapt it to mouse_down/mouse_up touch_start/touch_end ...
But here is the thing !! the virtual keyboard was never meant to be used for power playing ... for a nice play experience there are customizable action buttons which will do the job much better than the virtual keyboard

1. start to create a new ActionButton 😎 by pressing the + from the menu
   

2. give it a label (emojis are also allowed)

3. give it an action script
   for example when we want to simulate the pressing and releasing of the key q then we write this
   pressq=>3000ms=>releaseq

when we touch the action button it will press q wait 3000ms and after this it will release q

4. save the action button
   

in the middle of the screen there is now your self defined action button which you can drag around to a position suitable for the game.
If you just click or touch the button then the q key press will be executed. To change actionscript again just do a long press on the action button which brings you back to the configuration screen...

with action buttons you can program your own autofire and many more too ... possibilities are endless 😎

If you do not want a fix duration but you want a key to be pressed as long as you hold your defined action button then this apparently will conflict with the long-press "take me to the action buttons edit mode" gesture...

to do this (and effectively loose the long-press-to-edit mode)
rewrite your action script to

pressq=>await_action_button_released=>releaseq

and go to settings and disable the actionbuttons long-press-edit-gesture

now your actionbuttons will be no longer movable and editable ... they are locked... and the key q is pressed on touchstart and it will be released only when you lift your finger from the actionbutton...

Also, none of the proposed screen sizes for the Amiga is satisfying (the C64 is fine): narrow has good proportions but cut the top line and some space on left and right. The others are too compressed vertically...

We should make a separate issue to this ... (I have already a solution which will nicely and automatically solve this on the hd branch but still unreleased)
The point is that there is already an auto viewport tracking feature in the current version but it only tracks the coordinates of the viewports which the game opens in amiga hardware... some games e.g. F18 just open a vertically maximal viewport and write just to a portion of it ... so this auto strategy is not working then as it thinks the viewport is very large ...
I have implemented another strategy which analyses the borders for same pixel colors and eliminates the borders this way which is always effective ... I plan to release in the next couple of days😄

from vamigaweb.

Hi,

Many thanks for your kind, quick and detailed answer, much appreciated !

Here is a picture of the Z3 running Gravity Force :)

Thanks for the tip, although I will really prefer to have a virtual keyboard behaving just like the original, for nostalgia purposes :) so I understand a fix for autorepeat is on the way ? That would be great !

Best regards,

Vincent

from vamigaweb.

One more thing: the customized buttons work very well with Interceptor (I tried a "down" button to keep pressing the bottom arrow to take off).
But for Fighter Pilot for C64, the problem is deeper: this game requires keys being pressed quite long, just to register. So you can't even press space to continue, or any of the 1...8 menu entries numbers. And you are not going to create buttons for all this ! I think the auto repeat feature on the virtual keyboard is really a must... Not sure if the problem is purely in C64 and not Amiga, I think it must depend of the software that is loaded...

Many thanks and best regards,

Vincent

from vamigaweb.

Here is a picture of the Z3 running Gravity Force :)

actually I meant a picture from the Z3 device running vAmigaWeb ;-) ... must be very cool as it has plenty of screen space compared to a non foldable phone...

so I understand a fix for autorepeat is on the way ?

I had it in mind already months ago ... as it is very simple to upgrade the virtual keyboard to this ... so yes ... I will do it within the coming weeks

So you can't even press space to continue, or any of the 1...8 menu entries numbers.

the custom keys are persistent and game specific and stored to your local browser storage... so you do it only once ... but I see 8 custom buttons do already occupy a lot of screen space ...

from vamigaweb.

Also, none of the proposed screen sizes for the Amiga is satisfying (the C64 is fine): narrow has good proportions but cut the top line and some space on left and right. The others are too compressed vertically...

new beta4 version is out ... there is now a new display area calibration strategy called borderless ...

it should be fine now ... @Vweber73 could you please test ?

from vamigaweb.

Hi,

Oops, doesn't really look fine on my Z3 !

Thanks for your previous answer, I'll try to take a picture of the Z3 running Gravity Force with another phone later.

Cheers

from vamigaweb.

that is supposed to look like this 🤓 ... because it cuts off all same color pixels from the borders ... (in case of the hand disk logo we probably should set some minimum values so that there is still a very small border) but don't worry ... try it on games and you will see that it will selfcalibrate ... very nicely ... I tried it on monkey island, archon and some others...

borderless strategy goes like this:
it examines the screen every 500ms by detecting the borders by same color pixels from the edges onwards... when it (during the calibration process) detects some bigger larger screens then it will retain these larger viewport ... until the game resets the viewport sizes in amiga hardware ... in other words it always looks for the largest pixel screen and will stick to this largest display area size ... since you started with the hand disk screen it has set a very small screen size ...

from vamigaweb.

Oops, you're right, I jumped to conclusions too fast, now my ultimate
favorite (Interceptor, my dream flight simulator when I was 15) looks even better than on RetroArch / PUAE ! congrats and thanks !!

Cheers

from vamigaweb.

As promised, here is a picture of the Z3 playing Gravity Force :)

2 others issues:
-(major): All my .adf files are listed as ".bin" files in the file selector. Loading them has no effect. I can only load them from .zip files !
-(minor): the controls (mouse, joystick,..) settings are not saved, I need to set them every time...

Cheers

from vamigaweb.

As promised, here is a picture of the Z3 playing Gravity Force :)

that one looks so good... the screen dimensions of this z3 thing are nearly perfect for vAmigaWeb ... as you can leave the virtual keyboard open while not hiding the Amiga Screen. ... but wait ... why is there this white border at the bottom ? That does not come from vAmigaWeb right? (I don't have an android device). BTW have you installed the vAmigaWeb to your homescreen... as it is a PWA maybe it this white bottom bar will be removed then ?

All my .adf files are listed as ".bin" files in the file selector. Loading them has no effect. I can only load them from .zip files !

I don't understand this ... can you make a screenshot ?

the controls (mouse, joystick,..) settings are not saved, I need to set them every time...

would you like to make a new issue for this? Or should I ? Then we can discuss this there ...

from vamigaweb.

Hi,

Yes, this looks so good indeed ! :)

Yes, I have installed it as a PWA on my home screen. The bottom bar is generated by Android. There are was to remove it in a native app, but I have no idea on how to do this with a PWA...

Here is a screenshot of the file selector. You can see that all my adf files are refered to as "fichier .bin" (.bin file in french) and trying to load them does nothing. Only within a zip file can I load a adf file... No idea why ?!

Ok, I'll make a separate issue for the control settings :)

Cheer,

Vincent

from vamigaweb.

fichier .bin

Je peux parle francais un peu ... donc pas du probleme ... But easier for me en anglais ...

Can you get the javascript logs somehow ? If not enable live debug ...

we are looking for the following lines ... I inserted a Workbench ADF file...

load file=A500 WB noninterlace.adf len=901120, header bytes= 44, 4f, 53
A500 WB noninterlace.adf - Loading ADF file
**** State change RUNNING -> SUSPENDED
**** State change SUSPENDED -> SUSPENDED
vAmiga message=DISK_INSERT, data=0
**** State change SUSPENDED -> RUNNING
**** State RUNNING
**** State RUNNING

definitly a problem of the OS in your case android ... maybe you can configure file extensions mapping in android ? I do not see this problem in iOS, MacOS or Windows11.

what would be interesting is the file name in your logs ... when you insert the ADF. Have you tried DMS, Exe or HDF files ?

try to drag this exe file in this zip file into vAmigaWeb it is an Amiga shareware version of astroids
Asteroids.exe.zip

so we can see whether your OS has only a problem with adf ...

The bottom bar is generated by Android. There are was to remove it in a native app, but I have no idea on how to do this with a PWA...

I did a quick search on internet here is what I have found ... maybe this works?

How do I get rid of the bottom Navigation bar on Android?
Touch “Settings” -> “Display” -> “Navigation bar” -> “Buttons” -> “Button layout”. 
Choose the pattern in “Hide navigation bar” -> When the app opens, the navigation bar will be automatically hidden
and you can swipe up from the bottom corner of the screen to show it.

from vamigaweb.

Hi,
I have enabled live debug, and tried to load gravity force adf.
It says something like (hard to see since the debug window keeps filling) "error loading file - the file type does not match its contents". This file and the others work perfectly well as they are in RetroArch/PUAE, and work perfectly fine in vAmigaWeb when I directly select the zip file containing them...
In the Files Android app they appear as .adf file, not .bin files. The only problem is that if I click on them, even with "open with", they are directly opened (with no app choice) by CpcEmu, an Amstrad CPC emulator (which of course can't deal with them). I have tried everything to remove the file association with CpcEmu with no success, even removing all app's permissions, this still happens. It seems that bloody Android 12 makes it impossible to deal manually with file associations. I don't know what to do !

Regarding the bottom bar, yes I know that it can be globally removed, what I meant is more that apps can do that directly, only for themselves, not as a global setting. Maybe there is a way to ask for this behavior on a PWA when the OS is Android ? No idea...

Thanks and cheers,

Vincent

from vamigaweb.

Maybe there is a way to ask for this behavior on a PWA when the OS is Android ? No idea...

just published a new manifest file which should repair it ... see follow up issue #72

(hard to see since the debug window keeps filling)

regarding the bin file problem ... I dont know how you can access the logs in android but what about to try live debug again and make a slowmo video with another phone ... then you can catch the line where it says load file=

we must know the filename ... I bet this android thing somehow changes the filename from .adf to .bin or .adf.bin ... lets clarify this ...

from vamigaweb.

I entered the live debug mode again, and although I cannot prove it since it fills fast, I swear after careful looking several times, that there is nothing wrong with the file name as listed in the log. It ends with ".adf", which is correct...

from vamigaweb.

strange ... what about the exe file ?

from vamigaweb.

I'm not sure what exe files are exactly ? I have tried an hdf file, and it works fine...

from vamigaweb.

I'm not sure what exe files are exactly ?

these are amiga exe files like I posted above ... when dragged into vAmigaWeb then it creates a bootable disk and puts the exe file onto it and starts the amiga executable

BTW: you can mount a floppy e.g. workbench in df0 and a hdf into dh0 at the same time... some hdfs from planet emu are not coming with workbench ... then you need a workbench disk in df0

can you post a adf which is not working ... just to be sure that it is not a thing with vAmigaWeb... I would like to try it here on my side

from vamigaweb.

Wait, I think it is my bad and I got it wrong, sorry. Even though there are also labelled ".bin", many files run fine ! I was focused on a few of them that i have been transferring on April 23rd, I guess I had some file corruption on those... It is not linked to the .bin naming. Sorry to have you waste time on that !

from vamigaweb.

very good one strange problem less 🤓 then we can start with the auto repeat keyboard now I guess

from vamigaweb.

😎I have got it running here locally on my computer ... when I short press q in notepad on the vkboard it prints one q and if I long press q then there are loads of q .... so auto repeat works... that was what you want right ?

I have to refactor the code a bit more... it has become a bit messy ... and also do more tests with modifiers keys (Shift, Amiga, CapsLock ...)

from vamigaweb.

Yes absolutely ! Wonderful, thanks ! Can't wait to test it ! ;)

Cheers

from vamigaweb.

I just published the new virtual keyboard ... keys should be sensitive to the click/touch duration now 😎

EDIT:
problems ... when touching not only touchstart/end event is fired ... also mousedown/up ... resulting in two key presses ... I think they (browser developer) want to simulate a mouse when touching ... I have to find a way to detect this ...

from vamigaweb.

Many thanks !

Just tested it with my favorite - Interceptor.
It works... partially:
-down and right arrows long presses work fine;
-up and left arrows don't work, same as before;
-pressing "G" to toggle landing gear up/down is strange: if you just press normally as before, you get 2 toggles, ending up doing nothing (with an alarm since you are not supposed to put in down while flying). If you long press it, it works as per normal. Strange !

Besides, the bug in "narrow" display is back ! (First line of interceptor is cut). How come ?

Will you update vC64 as well ?

Thanks and cheers

from vamigaweb.

I had a problem with the double keypresses ... should be resolved now ... please retry

I found a new problem that for one keypress I have to touch very short 🙄 or it presses to long and generates two keys

Will you update vC64 as well ?

when vAmigaWebs keyboard works well then we do it also in vc64web ...

from vamigaweb.

Thanks. I have tried again, the "G" double press is corrected and works fine !
But the up and left arrows still don't work...

Also, one minor cosmetics, the up arrow is not aligned with the down one.

Btw to you intend to go for haptic feedback on the keys as well as visual ?

from vamigaweb.

Btw to you intend to go for haptic feedback on the keys as well as visual ?

we could do this...

first lets look after the up and left... is right and down working?

from vamigaweb.

Yes they are !

from vamigaweb.

ok found the problem ... and fixed it

from vamigaweb.

It works absolutely fine now ! Congrats and thanks ! :)

from vamigaweb.

I think typing regular text is a bit awkward no? It seems my left thumb is too slow in lifting off fast enough. Sometimes it stays too long on the touch button generating two characters. Left thumb is ok.

Do you see this too? I could delay the press when touchstart event comes in. This way it would shorten the duration of the amiga key press. But at the cost of a slight minimal delay maybe 20ms?

from vamigaweb.

I tried extensively in a shell window, and I didn't have such problems. Everthing is fine, no miss keystroke, no too fast repeats...
It seems that behaviour may differ depending on the device. You defined the delay manually, shouldn't this be left to the keyboard emulation at electrical level ?

Only strange thing I have is that the '#' key does not seem to work, is it normal ? Don't think so...

Also, the keyboard key size and position change when you press caps lock or shift... A bit strange but minor, like the arrows alignment :)

Any explanation for the "first line cut in narrow mode" bug that reappeared ?

Cheers

from vamigaweb.

Sometimes long pressing the keyboard interferes with a "cut,copy, paste" pop-up menu... I understand this is a web application and not a native one, but anyway to disable this behaviour ?

from vamigaweb.

Yes just did this ... it also solved my double character problem ...

I just disabled on touchstart and touchend any other default behaviour (which delayed in my case on iOS the touchend and in your case the popup menu)

So glad that it types now fine on iOS ... hoping your Android is doing fine too with the preventDefault on both events

from vamigaweb.

It seems to work fine ! Only thing is that now you don't have visual feedback at all when pressing a key...

from vamigaweb.

Only thing is that now you don't have visual feedback at all when pressing a key...

later... tomorrow ... we must sleep now ..😂

what about the narrow problem ... as I understand narrow is fixed size not like borderless where we adapt the screen size... so the line which is missing is maybe missing due to a too small fixed top position ... when using borderless then the line should be there right?

from vamigaweb.

Yes we must sleep ! :)
There is still the issue of the # key not registering in a shell window...
Yes borderless has no problem... But it thought narrow was fixed last time...

What about the "high accuracy" settings you mentioned for Fire Power ? I only have "blitter accuracy" and I always leave it a 2... Lowering it doesn't change anything to the flickering...

from vamigaweb.

you don't have visual feedback at all when pressing a key...

last pressed key is slightly darker ...

from vamigaweb.

No, this doesn't work well on my phone. Very randomdly, the last key pressed becomes darker, but this only happens once in a while...

from vamigaweb.

What about the "high accuracy" settings

The Blitter setting is the most important one in this case. Level 2 means highest accuracy. There are some more settings available in the Desktop version, but most of them should be on by default in the web version (@mithrendal, can you confirm?)

from vamigaweb.

Regarding my earlier comment about the # key not working... I checked with a picture of a real Amiga and noticed that this is a key that does not exist ! So it is normal it does nothing, but... Why is it there in the first place on the virtual keyboard ? :)

from vamigaweb.

Regarding the "narrow" setting, one thing I fail to understand (besides the resurrected bug of the top being cut, obvious in Workbench and Interceptor), is that it is the only setting with correct proportions. All the others are too compressed vertically. Save for "borderless", which is ok but keeps being re-zommed to the current used area - a bit ennoying, especially in demos where the screen setup can change a lot from one section to the next...

from vamigaweb.

No, this doesn't work well on my phone. Very randomdly, the last key pressed becomes darker, but this only happens once in a while...

are the modifier keys tinted in green when pressed ? CapsLock Shift Amiga... they normally becoming green ... on your z3 too?

All the others are too compressed vertically.

then we should change it to better values right ?

here is the method which sets the coordinates ...

any suggestions for correcting the values ? maybe we should make narrrow a bit larger too?

Regarding my earlier comment about the # key not working... I checked with a picture of a real Amiga and noticed that this is a key that does not exist ! So it is normal it does nothing, but... Why is it there in the first place on the virtual keyboard ? :)

because it is on my real A1000 ... when unboxing in 1986 there were commodore stickers which I put onto some keys ... I don't dare to remove them 😬

according to the AmigaTestKit the key gets pressed here
AmigaTestKit.adf.zip could you try too ?

Maybe you have a Workbench with a french keyboard mapping? But how did you enter # back then in the days ... because it was important for programming e.g.moveq.w #0, d0 which was some cycles faster than clr.w d0 when I remember correctly

The Blitter setting is the most important one in this case. Level 2 means highest accuracy. There are some more settings available in the Desktop version, but most of them should be on by default in the web version

yes except what is settable in the setting all other values are default ... I will check the desktop mac version again to see the graphic anomalies bug

from vamigaweb.

For the modifier keys: yes, they become green with no problem. But the other become darker only very randomly.

For the screen size values, oops, I don't think I have an idea... I just would like the screen to look like the real thing, filling the screen as much as possible as long as the correct screen aspect ratio is kept (I'm not too interested in zomming if it's to loose the ratio).

For the keyboard I see, you must have a German one, the English one is different even though it is QWERTY... I'm not using a french workbench, I believe it is an English one. # is easily accessed by shift + 3, as per your virtual keyboard ! :)
I tried the test disk and yes, the key works properly even though it does not output a character in the workbench...

Regarding Fire Power, many thanks if you could solve this as it seems to be something else then the accuracy settings, I'm most interested !

Many thanks and best regards

from vamigaweb.

For the modifier keys: yes, they become green with no problem. But the other become darker only very randomly.

fixed it ... and reworked the behaviour a bit ... now while pressing we see a white glow around the key ... don't know yet if I still will like it tomorrow we will see ...

I'm not too interested in zomming if it's to loose the ratio

ok ... understand ... will do later

Regarding Fire Power, many thanks if you could solve this as it seems to be something else then the accuracy settings, I'm most interested !

ok I did the following ... played it

• on vAmigaMac
• vAmigaWeb on a powerful windows laptop

I dont saw any shearing or flickering

• on the 2007 mac book pro ... flickers and shears often, it looks as if the screenbuffer copying to the canvas is not in sync ... i.e. browser updates the canvas screen and while new data is coming in or something like that...

so I checked all the relevant code ... and finally found one missing Sync in the renderer

before was this

    renderer = SDL_CreateRenderer(window,
          -1, 
          SDL_RENDERER_SOFTWARE
          );

now I changed it to

    renderer = SDL_CreateRenderer(window,
          -1, 
          SDL_RENDERER_SOFTWARE|SDL_RENDERER_PRESENTVSYNC
          );

now flickering seems to be gone ... when using software renderer... (or maybe I played not long enough... 😬)

I pushed new version ...

from vamigaweb.

Many thanks !
I love the visual feedback on the keyboard.
Fire Power flickers a bit less now. Still some, but it is similar to RetroArch /PUE. It seems that it is a flickering game in the first place !
Cheers

from vamigaweb.

I cannot scroll the keyboard anymore ...🙈 ... something did broke it ... at least on iOS ... I will rollback some changes to see what it was

from vamigaweb.

I can still scroll the keyboard perfectly on Android !!

from vamigaweb.

I can still scroll the keyboard perfectly on Android !!

yeah but iOS is not 😩 ...

I found it ... scrolling is prevented by the touchstart event

the_key_element.addEventListener("touchstart", ()=>{/*event.preventDefault();*/ key_down_handler()});

but we need the preventDefault() ... otherwise I will see two characters on iOS if my left thumb is too slow and you will see a popup asking you copy cut paste as you yesterday reported

maybe we trigger the prevent a bit delayed lets say 20ms ? I will try

from vamigaweb.

I have tried it on my ipod and got no problem scrolling the keyboard. Did you fix it ?

from vamigaweb.

I reverted it partial back...

the problem is gestures...

our infrastructure

when touching a button and we do nothing special then the following happens

1. it fires a touchstart / touchend events and afterwards mousedown /mouseup events and finally click event

2. when pressing very long then keyboard comes up with a "cut,copy, paste" pop-up menu (android only)

3. time between touch_start and touch_end seems to be a bit longer than the finger really is on the surface of the touch screen (iOS only)

4. when between touchstart and touchend there is a touch move then it scrolls...

our goal

we don't want 1. 2. 3. but we want 4.

solutions

to disable 1. we have to call event.preventDefault() in touch_end

to disable 2. and 3. we have to call event.preventDefault() in touch_start but !! this also disables 4.

sort of a dilemma ... when we want it autorepeat and super exact and without gesture interference then dragging/swiping with the finger over a key on the keyboard does not scroll the keyboard anymore

in general problem is that gestures implementation/recognition on android/iOS are conflicting / interfering with a super exact and virtual keyboard

solutions which comes to my mind:

A. an extra switch on the virtual keyboard (lock Position/unlock position) when unlocked i.e. scrollable then no auto repeat vs. auto repeat then not scrollable

B. make a special slider area as it still slides when swiping over background

C. on touch move calculate the movement and slide manually i.e. programmatically interprete the swipe gesture

D. some other solution which I am not aware of yet ...

from vamigaweb.

going for solution C now... stay tuned

EDIT:
solution C is working now ... goal reached: remember we don't want 1. 2. 3. but we want 4.

but some new points... because we disabled gestures completely on key buttons and start manually replace the wanted stuff with own code

• first scrolling when scrolling on a Amiga key it is not the inertial scrolling (because we do it by our own and I simply coded linear scrolling)

• when doing our own homebrew scrolling on a key it gets pressed (the original gesture detection did not fire a touch start when it thinks it did detected the swipe gesture)
  to solve this we can write our own detection by delaying the keypress a bit (20ms) and when touch moves don't fire the amiga key press

or should we try a complete different solution ... lets say solution A ?

from vamigaweb.

Hi,

Sorry I didn't get notifications for the edition of the same comment, so I thought I was still supposed to stay tuned :)

Yes, why not A ? Sounds simple and less possibilities of conflicting gestures !

Cheers

from vamigaweb.

Ok soultion A. 🤓

should we better move this into the settings ? because the keyboard gets too messed up otherwise? What options should we offer ?

• exact timing
  autorepeat and simultaneous keycap presses (disables default scroll gestures on keycaps, scroll gesture possible only on gaps around the keys)

• smartphone like
  native scroll gestures on keycaps (press starts after finger is lifted from keycap for a duration of 100ms)

• mix of both
  (i.e. solution C)

do we really need mix of both ? what should be the default value ? smartphone like maybe ?

from vamigaweb.

Yes, I'm all for options :) these 3 sound reasonable !
Any news on the agnus subtile differences ?
Cheers

from vamigaweb.

Excellent, thanks !

from vamigaweb.

new version published with solution A, C and also with no automatic reset when a zip file contains only one mountable file.

@Vweber73 could you test it on z3 android ?

from vamigaweb.

Hi,
I have just tested it on the Z3 and it works great ! All 3 modes worked as intended, at least on Interceptor. I guess I'm not gonna use mode B, for the lack of autorepeat. Mode A is my favorite, but mode C is interesting to.

So this could be ported to the C64 as well, can't wait to try Fighter Pilot ! :)
Talking about the C64, I have launched GEOS, it works great, except for the lack of support of the 1351 mouse, so no way to move the cursor ! Do you plan to do it ? Also 1581 support, no only 1541, would be great for GEOS, as well as REU for Ram disk... :) And of course, the C128 would be great ! Any plans in this direction ?

Back to the Amiga, any progress on the screen sizes front ?

Thanks a lot and cheers

from vamigaweb.

virtual keyboard settings also for vc64web ... lets plan it ... do you open an issue on vc64web for this ?

Mouse support should be easy too ... do you also open an extra issue on vc64web for this ?

1581 + REU .. do you open a issue on dirks repo https://github.com/dirkwhoffmann/virtualc64 when he implements this we will merge the emulation core lib into vc64web

Back to the Amiga, any progress on the screen sizes front ?

lets open an extra issue for this here at vAmigaWeb

I think we close this issue now, no?

from vamigaweb.

Ok, I do this, thanks !

from vamigaweb.

great !! and thanks for testing 😍

plans for C128 I don't know ... maybe too much effort to do ? Don't know whether dirk is interested in it...

from vamigaweb.

Thanks for developing ! My pleasure to test anything in the Commodore/Atari/Amstrad/Sinclair/Oric/Tandy/Apple 2/Acorn/Thomson retrocomputing worlds... :)

from vamigaweb.

It seems that in "exact timing" mode, all the gestures are not disabled.
I just got this...

from vamigaweb.

confirmed when long pressing on the gaps (i.e. not on the keycaps) default gestures are still working for scrolling and yeah for this traduir copy and paste thing...

what we could do for exact mode ... disable gestures on the gap space too and implement our own scroll handler like we did in mixed mode... what do you think? Or investigate to find a way to disable the "traduir copy selection thing" without disabling scroll native gesture

from vamigaweb.

Whatever makes sense and is simpler for you will suit me ;)

These web apps are so powerful and flexible that often you forget you actually juste are on a web page. It's cruel to be reminded of it ;)

Another reminder is that when you press a top menu item, like "settings", the help text sticks to the screen, whereas it should disappear. This is an hindrance, it hides part of the menu !

But it's so great that with these PWA you can completely and legally bypass Apple's hostility towards emulators ! As an emulation fan I always hated iOS for this...

Cheers

from vamigaweb.

But it's so great that with these PWA you can completely and legally bypass Apple's hostility towards emulators ! As an emulation fan I always hated iOS for this...

that was one of my main motivations ;-) to create the PWA versions of vAmiga and virtualC64 😎

from vamigaweb.

It seems that in "exact timing" mode, all the gestures are not disabled.
I just got this...

I am just playing around to get rid of the "traduire, copy, ..." popup when long pressing in the gap space ..

is it working on android ? chrome is working ... but iOS seems to ignore the extra prevent ...

from vamigaweb.

I've just:
-updated the app manually to latest version;
-played with the keyboard. The "traduire..." thing is still there when long touching the gap...
Cheers

from vamigaweb.

I tried it differently now ... by putting a extra eventhandler for "contextmenu" and calling preventDefault() in it ... but still does not work on iOS ... android maybe?

from vamigaweb.

No more "traduire", but strange, a replication of the row below, some blue marks, and a message related to vc64... Here are some pictures.

from vamigaweb.

Ah ok ... it disabled the contextmenu traduir thing ... but now the drag and drop event fires ... has also to be disabled ... will do tomorrow...

PS: there is still a lot of things from vc64web not replaced in vAmigaWeb🙄

from vamigaweb.

alltogether I had to prevented text-selection dragging and contextmenu 😎

works now on iOS ... what about the Z3 flagship?

from vamigaweb.

Hi,
Thanks ! It now works as intended: now if I press outside a key nothing happens... Well, almost... I still have the haptic feedback !
Cheers

from vamigaweb.

we can search how to prevent this ...

in a quick search I found how to add haptic feedback

http://diagramcenter.org/adding-haptic-feedback-to-html.html

maybe there is also something how to disable it ...

I will later look into it

from vamigaweb.

Excellent thanks ! No so important compared to the screen sizes and ratio :)

from vamigaweb.

from vamigaweb.