GDR Forum Index
Podcast Podcast
Dev Dev Logs
Search Search
RSS RSS
Register Register
Log in Log in
Reply to topic GDR Forum Index -> Game Developer's Refuge -> Development Log - This And That (unfocused randomness) Page Previous  1, 2, 3, 4, 5, 6, 7, 8  Next
View previous topic :: View next topic  
Author Message
0xDB
Developer

Joined: 26 Dec 2005
Posts: 1666
Location: Your consciousness.
PostPosted: Thu Sep 04, 2014 12:56 pm    Post subject: Reply with quote

Got distracted again and implemented another fancy feature first (a boot loader) before I will get back to the data manager and the engine... but before that I want to also extend the script shrink and make a page/tool which uses it to combine several files(locally selected or from online URLs) and shrink and save them to a single script. Jumping between features is fun but I have to make sure, not to lose track. Eventually I should try porting an old game to HTML5/JS and just make the lib grow along the way to see what features I really need, instead of just implementing "every" feature I can think of which might be useful first (which is fun too but then the lib will never hit a first usable version with certain core features any time soon).
  • changed rlEngine and rlG.createCanvas (inserts canvas elements into an existing container now, instead of writing directly to the current position in the document stream)
  • wrote rlBoot (loader which checks for needed browser/system features and loads all other parts/scripts of the library while displaying fancy progress and/or error messages)
  • started rlTemplate_HelloWorld.html page template for Refugee Lib based pages
  • levelled up DIII Crusader to 70 finally getting the Dream Team achievement
  • watched Johnny Cash bio "Walk The Line"
Test 5: rlBoot demonstration

Test 5b: rlBoot loaded from self-expanding script(shrunk by rlScriptShrink)

rlTemplate_HelloWorld.html (using rlBoot) (your connection and machine will likely be way too fast for you to read the boot messages)
_________________
0xDB
View user's profile Send private message Visit poster's website
0xDB
Developer

Joined: 26 Dec 2005
Posts: 1666
Location: Your consciousness.
PostPosted: Sat Sep 06, 2014 5:51 am    Post subject: Reply with quote

Thoughts about writing to local files... with the File System API (FileWriter, ect.) draft being abandonded as of April 2014, currently the only safe way to save to local files is using the "download" attribute for anchor elements. This works in FF and Chrome and is officially not supported in IE yet but listed as "under consideration". While this is a solution to storing bigger chunks of data (like save games or output from tools, like images, maps, etc.) wherever the user wants to save it (instead of using limited local storage facilities provided by the browser) it is still limiting as it requires (for security reasons) the user to actively select a filename and click save and it is a one-shot type of operation as the blob can not change during the saving operation, so it is not possible to make the user select a file once for auto-saving periodically without requiring user interaction after the first selection.

When is that a problem? It disallows periodic auto-saving of whatever data is currently being worked on (e.g. an image or a map or even save-games) in tools/games (and especially in games, it will always require ugly OS-level save-file dialogs to pop-up which do not fit the theme of the game). So writing applications(in HTML/JS) which run entirely in client-side scripts, handling huge amounts of data is possible but problematic because it limits the size of the data to the RAM available to the javascript engine because it is not possible to cache any of the data on disk without repeatedly interrupting the user by presenting another save/load datachunk xzy dialog.

When is that not a problem? When using node-js or node-webkit which both have proper POSIX compatible file APIs to write/read from the local filesystem. But then that requires bundling either with the application again, re-introducing platform-specific downloads (and adding several MBs to the app footprint).

So... in an ideal world there would be a standardized Web API which would allow users to expose read/write privileges to a website on a per folder/file basis. By default, a website would have no privileges at all but users would be able to add for example "/myData/blah" with read/write privileges to a website, so that the website could then (as long as the privilege is not revoked) read and write anything in that folder(and subfolders) freely without having to ask the user every time it wants to store/restore any data from there. The future is close but not close enough yet :).
_________________
0xDB
View user's profile Send private message Visit poster's website
Sirocco
Moderator

Joined: 19 Aug 2005
Posts: 9453
Location: Not Finland
PostPosted: Sat Sep 06, 2014 6:19 am    Post subject: Reply with quote

I wonder how Java handles this? Is there a shared local directory apps can write to, or does each app get its own storage space? Or does the interpreter allow OS-level access for files? It occurs to me I've never really paid attention to that.
_________________
NoOP / Reyn Time -- The $ is screwing everyone these days. (0xDB)
View user's profile Send private message Visit poster's website
0xDB
Developer

Joined: 26 Dec 2005
Posts: 1666
Location: Your consciousness.
PostPosted: Sat Sep 06, 2014 7:51 am    Post subject: Reply with quote

In Java, it all depends in which VM the code/app is executed. In an applet which runs inside the browser, the VM is sandboxed in a way that disallows direct access to the local filesystem but it is possible(not without jumping through a bunch of hoops) to have a priviliged sandboxed applet which can access parts of it.

A Java app running in a VM outside of a browser has full user-level access to any OS resources, so it can see/read/write any files the user who executes the app can access and if that happens to be an admin account, that's almost full OS-level access (in other words, no difference here to compiled native applications which are running in an OS-level process instead of in a VM).

Java would/will be obsolete as soon as there is a widely accepted and standardized way of granting/revoking permissions for a website to "directly"(well not 'to-the-metal' directly but behind a secure API) access system level resources like filesystem and other hardware. Everything directly in The Browser... that could be the future of cross-platform application development but we're not nearly as close as I thought we'd be when I started looking into HTML"5" and javascript.

As of now, we still need the platform specific 'crutch' (node-js/node-webkit) to gain the access to the system we need to write applications that can do everything native apps can do already or write the app in a way where storage is handled by the(or another) server which is also serving the app itself but even then, distributing the app to users, so they can run it offline requires bundling a (platform-specific) server.

All of these issues are no real issues of course, just mental blockades. At the end of the day it really does not matter much which technology/platform we write our code for as there will always be different obstacles to overcome... it would just be so nice, to finally have real "cross-platform" apps where the only dependency is a standard compliant Browser. Before we can have that though... the standard needs to be finalized and widely accepted/adopted and that does not seem to happen fast enough. :D
_________________
0xDB
View user's profile Send private message Visit poster's website
PoV
Moderator

Joined: 21 Aug 2005
Posts: 10892
Location: Canadia
PostPosted: Sat Sep 06, 2014 9:12 am    Post subject: Reply with quote

As far as data and files are concerned, there are a few unusual ways to deal with them.

Most obvious: JavaScript Web Storage. The cross platform way to think of this is 2.5 MB of Session Storage (until you close the tab?) and 2.5 MB of Local Storage (persistent, but you need to be ready to restore it in some rare cases). This is isolated from the file system, and is just a raw data store (key:value).

There are also cookies. Much less storage here. I think there's an upper limit of just under 4k per cookie, and maybe a few hundred cookies. I forget the specifics. Also a data store (key:value).

There is also some APIs for opening local files, but in a "file uploader" sense. I.e. user picking specific files to expose to the browser.

Now this is the one that's easy to forget: Browser Cache. Caching is actually controlled by your web server (Apache, Nginx) by setting an expiration time for static files served by it. The browser will remember this, and as long as we are under our local usage quota, the file will be maintained. Any time we explicitly request that file, it is pulled from Browser Cache instead of the website.


Aside from that, your servers need to serve the files/data.


For a more native/offline experience, both Google and Mozilla have their concepts of apps. Zipped versions of pages and files executed locally, with more permissions than usual. They obviously don't work without the browser, but they can appear to be native applications. For example, I run google's messaging app. It starts when my system starts, and hangs out in the tray, with Chrome effectively closed. ChromeOS and FirefoxOS, this how all "native" apps work on them.

For a catch-all, Node-WebKit can be used to make a normal standalone app. And there are things for Mobile as well.

Practically speaking though, I'm kind-of leaning towards it being not worth it. If its just to save bandwidth, we have options (mentioned above). Chrome and Firefox we can integrate with more deeply thanks to apps. That leaves pretty much just the IE crowd, who we can just overload their browser cache and forget about 'em. :). If you are running IE, you're probably not savvy enough to install anything but spyware.

(Heh, it took a long time to reach this opinion. Until I started digging in to web servers again, I actually hadn't even considered browser cache, but it's there and has been there for a very VERY long time)

(Also mobile I'm undecided. These tend to be weaker devices, so native ports are certainly preferred)
_________________
Mike Kasprzak
'eh whatever. I used to make AAA and Indie games | Ludum Dare | Blog | Tweetar
View user's profile Send private message
0xDB
Developer

Joined: 26 Dec 2005
Posts: 1666
Location: Your consciousness.
PostPosted: Sat Sep 06, 2014 10:02 am    Post subject: Reply with quote

The APIs for opening local files are limited to read-only access (the only exception is using a Blob and an anchor element with the download attribute to save the blob data to a user-selectable file through a browser mechanism but you still don't get a filehandle or something, so you can't keep it and write to it later).

Browser cache is unreliable/unsuitable for the use-cases I have in mind, because the browser decides when to cache what and when to get rid of cached items to make room for other stuff(browser cache is also usually limited by default to around 50 MB or so and you don't have direct access to browser cache from javascript code) and it only works for static data, not for data generated on the fly(client-side).

The type of ("offline") applications I'm thinking of which I would like to be theoretically able to(but not necessarily proceed to) develop using HTML and Javascript would be no different from full featured "desktop" applications:

Example 1: an animation editor for HD cartoon movies where it's not possible to keep all the frames in RAM all the time and they'd have to be constantly stored/fetched to/from the local disk in some sort of temporary data project folder.

Example 2: a complex game simulation like Dwarf Fortress where the entire game world is generated by the game and too complex to stay in RAM as a whole at all times, changes also need to be periodically stored/fetched to/from disk.

Example 3: any data editor which would like to periodically autosave stuff to prevent accidental loss on crashes, power outages and other natural and unnatural disasters would need local disk access

Session storage/cookies/local storage... all of these are meant to be used for configuration data but unsuitable for the kind of data shoveling I have in mind as described above.

Those Google and Mozilla apps could be a solution... will have to look into it. :)
_________________
0xDB
View user's profile Send private message Visit poster's website
mikedoty
Developer

Joined: 18 Mar 2006
Posts: 1788

PostPosted: Sat Sep 06, 2014 10:24 am    Post subject: Reply with quote

I think I would store the data on the net if I were doing a web app, particularly with smaller amounts of data like game saves. If the user has to download / install an extension app to play your game, doesn't that put them back in the same boat as downloading a generic C executeable and running it, to a point?
_________________
The end of the game, yes, is pretty much getting the weapon and killing off the population.
mashup games . com | Finally! - A Lode Runner Story
View user's profile Send private message Visit poster's website AIM Address
IMakeGames
Contributor

Joined: 13 Apr 2011
Posts: 499
Location: Austria
PostPosted: Sat Sep 06, 2014 10:26 am    Post subject: Reply with quote

Man, I thought that HTML5 and what it offers for developing games was much more mature already, given that everybody seems to talk about it. All this talk about low-level stuff that does not seem to work out of the box and across browsers paints a very different picture now. :(

I've worked as a web developer before and browser inconsistencies still make me shiver... A standard everyone would adhere to would be a gift of god!
_________________
My current project: Hook'd
View user's profile Send private message Visit poster's website
0xDB
Developer

Joined: 26 Dec 2005
Posts: 1666
Location: Your consciousness.
PostPosted: Sat Sep 06, 2014 12:58 pm    Post subject: Reply with quote

mikedoty wrote:
I think I would store the data on the net if I were doing a web app, particularly with smaller amounts of data like game saves. If the user has to download / install an extension app to play your game, doesn't that put them back in the same boat as downloading a generic C executeable and running it, to a point?
Exactly. For very small amounts of data, what is provided is ok-ish already(far from good but somewhat workable) but for heavy duty programs, the bare un-extended technology is simply missing standardized permissions to access the client-side host machine, unless you include a web-server or an additional runtime environment(like node-webkit) in your download which can access the local filesystem and do all the storing and fetching there but yeah, that kills the cross-platform idea and makes it necessary to bundle up the code with a different runtime environment for each platform, at least the app code itself would be platform independent though.

IMakeGames wrote:
Man, I thought that HTML5 and what it offers for developing games was much more mature already, given that everybody seems to talk about it. All this talk about low-level stuff that does not seem to work out of the box and across browsers paints a very different picture now.
Yes, that's why I disliked web-development, because of that lack of widely accepted and adopted standards and the necessity to patch the code for every different browser in the past but I'm not seeing the situation as grim anymore: lot's of stuff already works and there are two big browsers(Chrome and Firefox) which support most of what is needed already (those minor issues aside which still need crutches if you want fully/truely cross-platform, entirely client-side applications).

Those other browsers which fail to keep up with the standardization process will bite the dust for good eventually as people simply will stop using them.

I will continue writing this lib as I am not in a rush to make and release anything soon, so the future still has time to catch up. Also, I can use the crutches we already have and throw them away when they become obsolete in the future or simply just make small stuff first which does not need to access the filesystem periodically or at all.

Another thought: Isn't it quite irrational for people to trust an executable(with full access to their system) they download more than they trust sandboxed javascript code which runs directly inside the browser? Why is it 2014 already without there being a usable standard for handling user-granted permissions to access system resources? Because, it is a non-sensical mental blockade powerful enough to keep the entire developer/user world of the Web in the stone age. :P
_________________
0xDB
View user's profile Send private message Visit poster's website
PoV
Moderator

Joined: 21 Aug 2005
Posts: 10892
Location: Canadia
PostPosted: Sun Sep 07, 2014 7:36 am    Post subject: Reply with quote

I'd say #2 and #3 can be handled in a respectable way by syncing your data to a server. Dwarf Fortress really is an extreme case, and to be honest, I'm not even sure what it does. There really isn't anything as complex as it. As for auto save, Google Docs have done this for years, in fact, they don't even give you a save button anymore. The data is synced constantly tho the server. They might be doing something clever, like sending only diff's. Plus it supports online collaboration, which is kind-of awesome.

Case #1 though, large files for video editing, okay sure. I would think though that most practical uses would be taking some simpler representation (sprites, vectors, models) and rendering out frames or clips of video. In the case of an Xtranormal or GIFERATOR, you would do it server side, because its partially about proving a sharable URL to people.
_________________
Mike Kasprzak
'eh whatever. I used to make AAA and Indie games | Ludum Dare | Blog | Tweetar
View user's profile Send private message
0xDB
Developer

Joined: 26 Dec 2005
Posts: 1666
Location: Your consciousness.
PostPosted: Mon Sep 08, 2014 12:04 am    Post subject: Reply with quote

True but then it is not an offline-ready :) application anymore. Storing everything server-side is not an option for me because I do not have the resources to provide virtually unlimited storage space for all potential users of the tools/games I make. :/ I also would like my stuff to be capable of running independent from any web infrastructure/cloud. The fact it will be hosted on a web server would just be for the convenience of easy deployment and instant portability.

Ideally (possible using jszip and preparing a Blob in javascript client-side) the application should be able to zip itself and letting the user download that zip to open the .html pages contained in there and run them directly on their local machine, independet of an extra server and an internet connection (which is impossible though due to file:// protocol security restrictions (e.g. so called 'same-origin' policy) for scripts).

But until access to the local filesystem is allowed and standardized in javascript directly (directly, as in, without making a Chrome/Mozilla app or using node-js/node-webkit) I am restricted to using RAM and the few limited in-browser storage facilities like cookies and web storage. However, due to the file:// protocol security restrictions discussed earlier in this thread, there is no way around bundling an extra server with the app to allow proper local execution of certain scripts anyway, which pretty much makes using something like node-webkit mandatory for developing offline applications in html/js at this point.

So it is not a problem but a bit of a damper on the whole cross-platform idea, because having to bundle extra (platform specific) software with the raw html/javascript code, really does eliminate the benefit of providing a single archive whose contents could just run on any platform where a compliant browser is already installed.

My (mental block) problem with all this is not that there are no options, it's that I do not like the options which are there for that portability reason. If I need local file access, I will still probably just bundle node-webkit and be done with it as that is the most straightforward solution available (it's just a bit painful to know that this will add about 30MB to the download size for a single platform specific archive where the actual application code is just a couple hundred KB itself). Another option would be to not bundle anything and just provide instructions on where and how to get the necessary runtime components and how to run the app using them, but then that locks out the not-so-tech-savvy users again... I am kind of leaning to that latter option though. It should not be that difficult to educate potential users to do stuff right and it certainly beats adding those 30MB to every app for every platform download.
_________________
0xDB
View user's profile Send private message Visit poster's website
PoV
Moderator

Joined: 21 Aug 2005
Posts: 10892
Location: Canadia
PostPosted: Mon Sep 08, 2014 6:10 am    Post subject: Reply with quote

These days, I'm partial to the idea of a Chrome app. If I really needed large files to cache things, theres this Chrome API:

https://developer.chrome.com/apps/fileSystem

Or I'd go native, but we solve a lot of portability and UI problems by making it work in the browser.

Chrome has the added benefit of NaCl (PNaCl, Pepper), if I truly needed an extra performance kick-in-the-ass. Emscripten is pretty good, but if we want to squeeze more oomph out of platform specific features (SIMD), it's there for the taking. Firefox is a good browser, and it'll be great for executing online content, but I don't feel it will ever truly be good enough for high performance local apps (even though they are supported). They will never do NaCl, so they will be forever bound by the performance of Emscripten and Asm.js. Chrome solved this years ago. Flash for Chrome is a Pepper plugin, sandboxed and everything.

One of my long time regrets is that I never particularly learned a native UI library. I dabbled a bit with the Win32 API, MFC, and eventually wxWidgets and Qt, but never to a point I was happy with them. All of them were somewhat flawed (Win32 and MFC being windows only, the other two being notoriously fat). This meant I never had a Nice+Clean way to make rough visual tools. I always had to rely on hotkeys or custom UIs in the things I created.

Of course nowadays I'd really consider just doing them as a Chrome App. Not in any particular JavaScript framework, but you get a lot of stuff free or easy in JS. And I have no qualms about making people download and install Chrome. You're better off if you do anyway (by design it's way more secure than the others with its extra sandboxing). I'm doing you a favour. :)
_________________
Mike Kasprzak
'eh whatever. I used to make AAA and Indie games | Ludum Dare | Blog | Tweetar
View user's profile Send private message
0xDB
Developer

Joined: 26 Dec 2005
Posts: 1666
Location: Your consciousness.
PostPosted: Wed Sep 10, 2014 1:04 am    Post subject: Reply with quote

The NaCl, PNaCl stuff looks interesting and would allow re-using some code I wrote in C/C++ in the past and also gives direct access to UDP/TCP sockets and other things like filesystem access, etc. but then the apps really become Chrome-only and would have to be installed as a web-app and would not just work as a simple website anymore.

Probably still better than native executables because of all the presentation features we get for free in HTML/CSS and the fast and easy development flexibility which javascript provides. Plus, with PNaCl it should still be a "write once, run anywhere" scenario (where "anywhere" means systems where Chrome is available... this would still give instant portability to Windows/Linux/iOS/Android4 I think without having to compile a different version/package for each platform). So... the VM to target is Chrome then. Having a single target should really simplify the development process a lot. :)

The native UI libraries are all somewhat bloated and more complicated to use than they should be, often making you initialize a bunch of structures/objects manually which should really be hidden behind some sort of high-level convenience-API doing all that for you (for the extra bit of control it should still be possible to do it manually though but in most use-cases, no-one ever really needs that fine level of control). WPF is a step in the right direction but its Windows only.

In HTML/JS I think I will try to really just use HTML for UI stuff where possible or I will just write my own UI routines for use within a canvas element. Should probably also not be too hard to port any lightweight UI lib from C to canvas/js but knowing myself I will probably go down the time-consuming "not invented here" route and implement my own instead of using/porting an existing one. Writing my own UI lib has been on my wishlist for many years and each time I have to hack up a quick&dirty UI without a lib, that wish grows stronger.

So... make a decision now Dennis. What's it going to be? Pure HTML/JS and code than runs in any website in any standard compliant browser or a Chrome App? My decision is to go for pure HTML/JS for now. Why? Because upgrading that to use advanced features only available to Chrome Apps will be easier than relying on those features now and then later butchering them out of the library for simple website compatibility of the lib code. Whenever I add library functions relying on Chrome App features, I should do that in a way where they are separated from the rest of the lib, so it would be easy to switch between different "runlevels" of the lib... hm... that separation should be really easy to achieve using/extending the bootloader I already wrote. :)
_________________
0xDB
View user's profile Send private message Visit poster's website
0xDB
Developer

Joined: 26 Dec 2005
Posts: 1666
Location: Your consciousness.
PostPosted: Wed Sep 10, 2014 3:20 am    Post subject: Reply with quote

put the early version on google code now: https://code.google.com/p/refugee-lib/
_________________
0xDB
View user's profile Send private message Visit poster's website
0xDB
Developer

Joined: 26 Dec 2005
Posts: 1666
Location: Your consciousness.
PostPosted: Sat Sep 13, 2014 1:59 pm    Post subject: Reply with quote

Working on Mouse and Keyboard Input handling:
  • added cross-browser MouseInput handling for rlEngine (position, capped position, buttons(including wheel info))
  • added custom built-in mousecursor and support for custom cursor images in rlEngine
  • adding cross-browser KeyboardInput handling for rlEngine (keystate (2x64 bits), rlKeyId) (basically done, may need some polish and more testing)
Unifying keyboard input was the most time-consuming task here (see linked table below) as every browser seems to roll their own way of identifying keys in keyboard events.
So I first wrote a test page which would give me CSV output for a sequence of keyboard events with all the differences per browser to compile an info table and then I wrote translation routines to tie it all together.
And, in game development, I'm usually interested in more than just "keyup" and "keydown" events, so I added stuff to have a keystate(for all keys) as well which will make it much easier to keep track of multiple keys being down simultaneously.

Each browser has different quirks there, e.g. IE never blocks F1 default behaviour, but knows the correct side of modifier keys being released, while Chrome only knows that the modifier key was released but not which side it was(edit: reported that as an issue in Chrome now). It only knows which one it is on a keydown event. Not a problem, just a random funny thing I found while exploring keyboard events.

browser differences unified in rlKeyId

Live example (may need hard reload and empty cache to work properly(also, clicking inside the iframe is required to get keyboard events)):

_________________
0xDB


Edited by 0xDB on Sun Sep 14, 2014 4:39 am; edited 1 time
View user's profile Send private message Visit poster's website
0xDB
Developer

Joined: 26 Dec 2005
Posts: 1666
Location: Your consciousness.
PostPosted: Sun Sep 14, 2014 3:55 am    Post subject: Reply with quote

  • added "Unidentified" key in location 3 in UbuntuVM running FireFox as "N5" (NumberPad5) to rlKeys
  • added "Meta" key from locations 1 and 2 as seen in UbuntuVM running FireFox when pressing Ctrl+Shift+Alt as "MetaLeft" and "MetaRight" to rlKeys
  • added unknownKey to rlInputEvent in case an unknown keyboard-driver-locale-specific character was handed in by the browser whose physical source key can not be identified
  • added fancy bit-by-bit display for (rl internal-)keyboard state in Debug overlay
--- rambling ---
Trying to do the best I can to get some sane values from keyboard input but strange (of the old lack-of-standard type) things are going on in the keyboard input evaluation world inside browsers:
As long as you assume the locale is fixed, things are fine and keys can be physically identified by the character they usually produce when pressed but as soon as you start switching around the locale(on the system level), you suddenly get a lot of "Unidentified" key events from the browser (noticed this primarily in IE) which do not even produce any char at all anymore. Could be a browser bug of course.
Unfortunately, all the properties from the keyboard event which do the old(sane) thing, giving us a printable char and/or the physical scancode, are deprecated and we're not supposed to use them anymore.

Now... what would be a sane solution to handle keyboard events in browsers which would take into consideration different locales and different hardware?
I think the best solution would be if the standard would give us two properties for each key event, first a unique physical key id(mandatory(the standard could derive those ids from the good old keyboard hardware scancodes or just use some new code)) and second, a value which holds either a unicode name(for unprintable keys like Shift/Enter/Esc etc.) or the printable character(in unicode) the key is supposed to produce(as decided by the keyboard device driver and the system level locale in use). Or... maybe just give us the raw unicode in all cases?

With the un-standardized situation as it is now, we do not really get unique physical key ids, it does in fact seem to be a wild mixture of un-standardized names/constants and sometimes printable chars(all supplied in the same event property with no way of determining what we actually got in there from the browser). Chrome is somewhat on the right track with its U+wxyz constants (you would assume they refer to the unicode character the key "should" produce but that's not even true, except when the locale is set to US... the U+ constants are consistent as to which char they produce even for different locales where the physical key producing the same U+ constant may differ but the physical keys in different locales do not produce the correct unicode character unless the locale is set to US). So... all we can do at this point is to work with "patchy" solutions, trying to make the most sane sense out of whatever the browser keyboard events tell us about which "key" was pressed. When the browser gives us "Unidentified" with location 0, we're out of luck though because there, unlike on the number pad(location 3), there is more than one key currently being reported like that by the browser. :D

As a consequence, it is impossible at this point, to write your own cross-browser text-editor relying only on browser keydown and keyup events, because, unless you fully re-implement locales in javascript, you simply can't know which unicode character is supposed to be produced by any given (never really uniquely identifiable) key. Madness. The safest way would be to display a virtual on screen keyboard for selecting and entering chars... like Zelda did it for entering names. This feels so nineteeneightysomething all over again. :)

Well... could always use customized HTML input elements for GUIs which need text input and use the raw key events only for game controls. In fact, that's the only real option we have until the raw browser dependent keyboard events are standardized in a way which allows us to determine if they should produce a printable character(and if they do, which one it is).
--- end of rambling ---
_________________
0xDB
View user's profile Send private message Visit poster's website
0xDB
Developer

Joined: 26 Dec 2005
Posts: 1666
Location: Your consciousness.
PostPosted: Sun Sep 14, 2014 5:38 am    Post subject: Reply with quote

Hm... looks like I will have to fix my bit arithmetic. All numbers are 64bits wide in javascript but the bitwise operators only handle 32bits.
_________________
0xDB
View user's profile Send private message Visit poster's website
PoV
Moderator

Joined: 21 Aug 2005
Posts: 10892
Location: Canadia
PostPosted: Sun Sep 14, 2014 6:39 am    Post subject: Reply with quote

Not a specific answer, but I think it would be helpful to have an actual international keyboard. I've only ever used US English and Canadian French keyboards, the later being exactly the same as a US English but with like 3 extra keys (3 annoying as F**k keys, ugh). I'm never going to believe what someone tells me as the "right way" to handle keyboard stuff until I have tried it myself.
_________________
Mike Kasprzak
'eh whatever. I used to make AAA and Indie games | Ludum Dare | Blog | Tweetar
View user's profile Send private message
0xDB
Developer

Joined: 26 Dec 2005
Posts: 1666
Location: Your consciousness.
PostPosted: Sun Sep 14, 2014 7:14 am    Post subject: Reply with quote

Alright, fixed the bit arithmetic for my internal keystate (which was surprisingly easy to do thanks to the Uint32Array type) (needs hard reload/empty cache in the above test).

A "one for all" international keyboard might be good but it would have to be done "right" to correctly handle all the different glyphs for all the different languages of the world. Each key would have to be a small display, so you'd know which uni-code character pressing the key would produce. That, or the keyboard would just have to be a simple flat general-purpose multi-touch screen with one of its uses being displaying a virtual keyboard.

Currently, there is no "right" way to do it. Just have to make do with the data fed to us by the browser events. Maybe it would be possible to write native code though, to directly pull locale information from the system in order to determine which character to produce or to get hardware scan-codes (which are meaningless though without locale information except for a few keys (Enter, Shift, etc.) which are the same on each locale).
_________________
0xDB
View user's profile Send private message Visit poster's website
PoV
Moderator

Joined: 21 Aug 2005
Posts: 10892
Location: Canadia
PostPosted: Sun Sep 14, 2014 9:25 am    Post subject: Reply with quote

Found a good reference of international keyboards.

http://ascii-table.com/keyboards.php

To my surprise, most layouts mirror QWERTY. And though some like German make small changes (Z is elsewhere), a very unscientific investigation tells me that almost everybody has WASD.


EDIT: Okay, now I know something. Turns out there are really only 3 notable international keyboard standards. The rest are derivatives.

- QWERTY (English, Canadian French, Spanish, ...)
- QWERTZ (German, Czech, Polish, Switzerland) -- Z+Y swapped
- AZERTY (France, Belgium) -- A+Q swapped, Z+W swapped, M beside L, Numbers require Shift

Notable QWERTY Changes in variants:
- Typically, an extra key is placed between the left shift and Z. [I hate this key SO MUCH]

Other not-so-popular layouts
- DVORAK (Optimized English Layout) -- Only M and A are in the same spot. [I actually use DVORAK myself]
- COLEMAK (Partially Optimized QWERTY layout) -- QW AH ZXCVBM in same spots.


So, poor man's international WASD:
- Up: W,Z (,)
- Left: A,Q
- Right: D (E)
- Down: S (O)

Item in brackets is DVORAK. Colemak wont work.
_________________
Mike Kasprzak
'eh whatever. I used to make AAA and Indie games | Ludum Dare | Blog | Tweetar
View user's profile Send private message
0xDB
Developer

Joined: 26 Dec 2005
Posts: 1666
Location: Your consciousness.
PostPosted: Sun Sep 14, 2014 10:29 am    Post subject: Reply with quote

I'm afraid looking at different keyboard layouts does neither solve the problem of the browser not giving us enough information to be able to physically(uniquely) identify keys for internal representation nor does it solve the problem of the browser not giving us enough information to derive the correct printable character from the key event.

Also, this is something which should not even be within the responsibility of user-code, it's something which should be solved on the system level and the browser should just give us printable character and if there is none, a unique key identifier instead. :/

I've been looking at these in the past two days:
http://www.w3schools.com/jsref/dom_obj_event.asp
https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent
https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent.code
https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent.key

No matter how many times I twist and turn that information around, the fact remains that the only properties giving the information we need, are deprecated(charCode,keyCode and which) and the new ones, which are supposed to solve the problems(code and key), are not yet fully implemented and supported in any of the browsers. How... why... WHY do they deprecate stuff when there is no replacement solution yet?

Well... I think I will just go ahead and implement something which works, using the deprecated stuff and then re-factor it when the replacements have arrived in the not-here-yet future. :P
_________________
0xDB
View user's profile Send private message Visit poster's website
0xDB
Developer

Joined: 26 Dec 2005
Posts: 1666
Location: Your consciousness.
PostPosted: Sun Sep 14, 2014 12:31 pm    Post subject: Reply with quote

I'm sorry, I'm tired and irritable and when I feel like I'm not being understood, I get angry. :(
_________________
0xDB
View user's profile Send private message Visit poster's website
PoV
Moderator

Joined: 21 Aug 2005
Posts: 10892
Location: Canadia
PostPosted: Sun Sep 14, 2014 1:30 pm    Post subject: Reply with quote

Ha, I'm sorry too. I was just doing related research on keyboards, and it didn't seem significant enough to post elsewhere. I wasn't actually trying to answer your question. I'm ignorant of the keyboards of the world.

Oh, and all I meant by "having" an international keyboard is owning one. Here in Canada/US, pretty much all keyboards are US English. You can sometimes find a Canadian French keyboard (US English with extra keys), but that's it. Again, we over this side of the pond are completely ignorant of anything that isn't US English/QWERTY. I've done localized versions of games for consoles and handhelds, but never on PC, so this idea of international keyboards is something I haven't dealt with.
_________________
Mike Kasprzak
'eh whatever. I used to make AAA and Indie games | Ludum Dare | Blog | Tweetar
View user's profile Send private message
Gil
Developer

Joined: 14 Nov 2005
Posts: 2341
Location: Belgium
PostPosted: Mon Sep 15, 2014 2:38 am    Post subject: Reply with quote

Yeah, my next keyboard will be a US/English one for that very reason. I can't even tell you how many indie games I missed out on, because they didn't support my keyboard. It's bloody annoying and I don't mind using a US keyboard anyway.

I do need to use these a lot: , how hard is it to type those with a US keyboard? I will also miss the euro key () on my keyboard, but I could handle that I guess. Would a Canada/US keyboard solve anything?
_________________
PoV: I had to wear pants today. Fo shame!
View user's profile Send private message Visit poster's website
IMakeGames
Contributor

Joined: 13 Apr 2011
Posts: 499
Location: Austria
PostPosted: Mon Sep 15, 2014 3:53 am    Post subject: Reply with quote

I'm using a German keyboard. Its main difference to the english one is the added keys for , , and . But that also moves many of the other keys around a bit, mostly special characters like -_,;.:#+'*`?. I once had to program with an english keyboard (setting) and it was a pain to get accustomed to.

The other main thing is that Y and Z are swapped. This is extremely annoying as many games default-map X and Z to something because they think they are next to each other. I think the reason for the swap is that German uses Y a lot less than English and Z a fair bit more?!? I dunno...
_________________
My current project: Hook'd
View user's profile Send private message Visit poster's website
Reply to topic GDR Forum Index -> Game Developer's Refuge -> Development Log - This And That (unfocused randomness) Page Previous  1, 2, 3, 4, 5, 6, 7, 8  Next
Game Developer's Refuge
is proudly hosted by,

HostGator

All trademarks and copyrights on this page are owned by their respective owners. All comments owned by their respective posters.
phpBB code © 2001, 2005 phpBB Group. Other message board code © Kevin Reems.