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
PoV
Moderator

Joined: 21 Aug 2005
Posts: 10904
Location: Canadia
PostPosted: Mon Sep 15, 2014 5:25 am    Post subject: Reply with quote

Canadian French keyboard adds 2 keys (think) for doing your accents. Aside from that, it's the same as the US English. One key is between left shift and Z, and the other is beside (near?) Enter. I've only used it on a laptop though, and I never learned enough French to actually use it properly.

On US English we have a big-fat left shift key (and enter). Having those keys there are an annoyance for US English users. :)
_________________
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: 1670
Location: Your consciousness.
PostPosted: Mon Sep 15, 2014 2:40 pm    Post subject: Reply with quote

--- on topic of the keyboard discussion:
You do not need a locale-specific/international keyboard in real hardware, as you can simply change the locale on the system/driver level and your keyboard will start behaving like that towards programmes, including mimicking the behaviour of so called "Dead" keys like Circumflex and Acute, allowing it to produce accented locale-specific characters.

I've switched to using a US keyboard(in hardware) for programming a few years ago, because most of the special characters needed for that are more easily produced (require less keypresses) on it but I switch around between a German driver-level layout and an English driver-level layout when I type text in different languages (and I also have some custom layouts for specific needs where I can enter commonly needed symbols without having to hold any modifier keys).
---

--- on topic of Refugee Lib develeopment
made great progress in Refugee Lib regarding keyboard input:
  • updated rlKeyId table/translation, so key ids do not contain any locale specific symbols anymore (which could be confusing when using different locales and seeing symbols as ids which are different from the locale-specific character produced by that key)
  • added patchy code (using deprecated properties for now as the DOM Level 3 properties are not yet standardized/implemented in browsers) to get an rlKeyId and/or a printableChar from keydown/keypress events to always have at least one usable info item from keyboard events (tested and patched up for Chrome/FF and IE)
  • casted keystate magic for unknown key identifiers which produce unique printable chars, so it is even possible to check printable chars against state bits now (Refugee Lib will "learn" about those chars at runtime)
!!! Success! :) !!!

The information I get from keyboard events this way is always usable now in one way or another for both game controls and for text input.

Game control scenarios can use the 'rlKeyId' value internally to refer to uniquely identifiable well known keys(which do not produce printable chars) on 'keydown' and 'keyup' events.

Text input scenarios can use the 'printableChar' value (an empty string if the 'keydown', 'keypress' could not be interpreted as a printable character by the browser).

The library internal code I wrote to make this work is quite a bit patchy and hard to read, relying on some pretty non-obvious combinations of sequences of 'keydown' and 'keypress' events and various properties and in-between book-keeping, but it delivers correct locale-specific characters and keeps correct (magic!) state without having to know about the locale by trying to interprete the messy browser-specific mixture of the deprecated event properties as sane as currently possible. :)

Today, I am quite proud of this accomplishment. Looking forward to the future though, when I can throw this code away and use the DOM Level 3 .key and .code properties as soon as browsers have implemented them.
---

Well... I tested this code in Chrome, FireFox and IE with US and German keyboard layouts. No idea, how well it will work with Japanese or Chinese or other non-latin locales but in theory, because of the magic, it should just work. :)
_________________
0xDB
View user's profile Send private message Visit poster's website
0xDB
Developer

Joined: 26 Dec 2005
Posts: 1670
Location: Your consciousness.
PostPosted: Mon Sep 15, 2014 2:43 pm    Post subject: Reply with quote

Forgot to add relevant links:
updated rlKeyId table
updated keyboard test code (may, as always, need hard reload to work)
_________________
0xDB
View user's profile Send private message Visit poster's website
0xDB
Developer

Joined: 26 Dec 2005
Posts: 1670
Location: Your consciousness.
PostPosted: Wed Sep 17, 2014 3:09 am    Post subject: Reply with quote

Sometimes... I am amazed by how fast the hours/days pass by when I am busy polishing up things which should have been really "simple" in theory... e.g. things like maintaining a consistent keystate (in a cross-platform/cross-browser way). :D
  • simplified keyState/lookup logic for "Unknown" keys and added common symbols to initial state
  • made "Unknown" bit to always be the first bit in the state to indicate symbols(printableChars) which originated from undeterminable physical source keys (each unique symbol still gets its own unique bit in the state on top of that, so the Unknown bit is an indicator that a key event came from a locale-specific but "Unknown" physical source key)
  • simplified keyUp bit clearing, so rlEngine now only needs to call a single function on rlKeys for that instead of three
  • fixed rlKeys key range initialization for common letters to exclude non-letter "L[" constant
  • fixed bit clearing for modifier(Shift, Alt, Control, OS) keyup cases when multiple (same kind) mod keys were held down but browsers only sent a keyup event for the first or last released modifier key
  • added clearing of input(mouse/keyboard) state on blur/focus root events
With that, keyboard and mouse input is in good shape now and the next thing I will do is to look into jsdoc and writing documentation for everything I've implemented so far. A library is not of much use, if it is undocumented and even I already keep forgetting parameters and function names as the library grows, so I should start working on reference docs now and then keep them up to date as I'm adding/changing things.

edit:
  • started adding documentation inside source files in jsdoc format
  • added configuration file for jsdoc and readme file in markdown format for use with jsdoc
  • prepared tutorials folder and added a template for a quickstart tutorial for use with jsdoc
Refugee Lib - reference docs
_________________
0xDB
View user's profile Send private message Visit poster's website
0xDB
Developer

Joined: 26 Dec 2005
Posts: 1670
Location: Your consciousness.
PostPosted: Sat Sep 20, 2014 9:49 am    Post subject: Reply with quote

  • changed/removed/added some odd-to-use/redundant/better-to-use stuff while trying to document the oddities/redundancies/lack-o-this-n-thatsies
  • added jsdoc format documentation to everything there is so far
  • boldly changed version number from the negative v.-1.0 (very early wip) to a boasting v.0.01
Phew!, writing the documentation for everything there is so far took much longer than I thought, which is mainly because there is much more done already than I thought. It really felt like I was not making much progress, but now that I've documented it all, I see I have been quite productive so far. Lots of stuff still to implement of course. :)
_________________
0xDB
View user's profile Send private message Visit poster's website
0xDB
Developer

Joined: 26 Dec 2005
Posts: 1670
Location: Your consciousness.
PostPosted: Mon Sep 22, 2014 10:17 am    Post subject: Reply with quote

  • added LICENSE.txt and updated readme to mention third party libraries and their licenses
  • added data folder with data to use for library usage examples
  • added rlDataObjectFactory to instantiate image/audio objects from binary data
  • changed dataEntry.info to dataEntry.metadata and added automatic loading of metadata objects from .metadata files in JSON format to rlDataManager (when such files are available next to the actual data files and no metadata was set manually in startload)
  • integrated JSZip into rlDataManager, to load/add files from zip files as data entries (and metadata from .metadata files within zip if available)
  • added jsdoc comments for the new rlDataManager.unzipAndCollectItems function and adjusted documentation elsewhere to reflect all changes
  • added basic example for demonstrating rlDataManager usage
Summary: added zip file support and automagic .metadata object loading in rlDataManager

The .metadata stuff will be most useful for putting additional descriptions to an asset file(e.g. an image) right next to the asset file (e.g. frame descriptions for animation strips).

rlDataManager demonstration (not iframed this time, as the sounds could start getting annoying :) )
documentation of the zip and .metadata stuff

But tomorrow, tomorrow I'll take a break to check out Wasteland(1 and/or 2). :)
_________________
0xDB


Edited by 0xDB on Thu Sep 25, 2014 7:51 am; edited 1 time
View user's profile Send private message Visit poster's website
Gil
Developer

Joined: 14 Nov 2005
Posts: 2341
Location: Belgium
PostPosted: Mon Sep 22, 2014 10:27 am    Post subject: Reply with quote

Are you doing the open-source thing btw? I love seeing new Github repos pop up :)
_________________
PoV: I had to wear pants today. Fo shame!
View user's profile Send private message Visit poster's website
0xDB
Developer

Joined: 26 Dec 2005
Posts: 1670
Location: Your consciousness.
PostPosted: Mon Sep 22, 2014 12:42 pm    Post subject: Reply with quote

Yes, going fully open source with this one (see sig). :)
_________________
0xDB
View user's profile Send private message Visit poster's website
0xDB
Developer

Joined: 26 Dec 2005
Posts: 1670
Location: Your consciousness.
PostPosted: Tue Sep 23, 2014 1:37 am    Post subject: Reply with quote

Bummer of the day... turns out IE does not support PCM wave files: https://developer.mozilla.org/en-US/docs/Web/HTML/Supported_media_formats#Browser_compatibility
The Web Audio API is not implemented in IE either( http://caniuse.com/#feat=audio-api ) yet (otherwise it might have been possible to write a custom wave file loader/player).

A workable non-programmatic solution is to provide each sound effect in both wave and mp3 format and then bundle up a wave.zip and an mp3.zip and load the appropriate one depending on which browser is used.

That though, would still not give the needed functionality for generating sound at runtime, because of the lack of missing Web Audio API implementation.

I'm tempted to just stop trying to make everything work in IE. In fact, without the Web Audio API some things will be impossible in IE, so... I have to drop IE support.
_________________
0xDB
View user's profile Send private message Visit poster's website
PoV
Moderator

Joined: 21 Aug 2005
Posts: 10904
Location: Canadia
PostPosted: Tue Sep 23, 2014 6:37 am    Post subject: Reply with quote

Web Audio coming in IE 12.

http://status.modern.ie/webaudioapi?term=Web%20Audio

I wouldn't bother with IE until 12 comes out (no ETA AFAIK).
_________________
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: 1670
Location: Your consciousness.
PostPosted: Fri Sep 26, 2014 3:05 am    Post subject: Reply with quote

That's good to know, so no worries about having to support IE at this point.

minor update:
  • added an optional way of defining palette entries in a single string to shorten the code required for the builtin palettes
  • added a couple of well known classic palettes in rlG.js to the rlColors singleton: AMSTRADCPC, APPLEII, C64, CGA, GB, MSX, TELETEXT, TO7/70, VIC20, ZXSPECTRUM
  • added length property to rlPalette and added more precise documentation on accessing palette entries
  • added methods to rlG for conversion between RGB<-->YPbPr and YPbPr<-->HTML
  • adjusted hello world demo code
Summary: Oldschool colors!

another minor update:
  • added drawNormalizedPolygon and drawRefugeeLibLogo to rlG for 2D context
  • added growing/shrinking logos to hello world demo
  • improved default cursor rendering (produces cleaner lines now by going from pixel center to pixel center (previously lines were drawn between the upper left corners of pixels))
  • disabled image smoothing for default 2D context, so sprites are not blurry anymore when drawImage is used to display them

_________________
0xDB
View user's profile Send private message Visit poster's website
0xDB
Developer

Joined: 26 Dec 2005
Posts: 1670
Location: Your consciousness.
PostPosted: Sun Sep 28, 2014 12:28 am    Post subject: Reply with quote

another couple of minor changes:
  • added key handling of ScrollLock and Pause to rlEngine for toggleing the engines Debug and Paused states
  • switched debug overlay off by default in hello world demo
  • added hasPalette and getPaletteNames to rlColors
  • added parameter to rlDemos.insertHelloWorldDemo for using different palettes
  • changed letter movement in hello world demo, so follow-up letters move towards their previous letter
  • changed demo font to Courier
  • changed palette in rlTemplate_HelloWorld.html from C64 to CGA
  • added key controls to change palette on the fly to hello world demo
Summary: Wasting time on improving the HelloWorld demo. :)

current HelloWorld demo (ScrollLock(or Alt+Pause) and Pause keys while mouse is inside to toggle Engine Debug & Paused states):
(edit, removed iframe: current hello world demo (likely different from what's described above as development progressed)
_________________
0xDB


Edited by 0xDB on Tue Oct 07, 2014 1:25 pm; edited 2 times
View user's profile Send private message Visit poster's website
Gil
Developer

Joined: 14 Nov 2005
Posts: 2341
Location: Belgium
PostPosted: Sun Sep 28, 2014 12:07 pm    Post subject: Reply with quote

I don't have a ScrollLock key :p

Pause key works though :)
_________________
PoV: I had to wear pants today. Fo shame!
View user's profile Send private message Visit poster's website
PoV
Moderator

Joined: 21 Aug 2005
Posts: 10904
Location: Canadia
PostPosted: Sun Sep 28, 2014 12:22 pm    Post subject: Reply with quote

Nice, love the color modes. I did something like that too in one of my prototypes. I had a C64 mode and a Vibrant mode, which basically picked 1 of 2 palettes.

Great little widget. :)
_________________
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: 1670
Location: Your consciousness.
PostPosted: Sun Sep 28, 2014 11:44 pm    Post subject: Reply with quote

Thanks for testing. :)

Gil, I added Alt+Pause as an alternate way of toggling Debug state now (may need clear cache to work). ScrollLock still works as well for keyboards which have it. I was unaware there are keyboards without it. :o

Also, question to everyone: Are there any other classic old-school palettes you would like to see included in the lib? Did I miss any of your favorite machines/consoles from the golden era of home computing?

I'm also currently playing with the thought of adding a function to render certain old-school modes from a memory buffer, e.g. a function to interpret and display the contents of an array of unsigned 8bit ints the way a C64 would read it to display a bitmap in colored wide pixel mode. This might be too special for a general purpose library though and should probably be an optional addon, not something the lib loads by default. Must resist temptation of writing a graphics emulator: Each day only has a limited amount of hours. Priorities... there is way too much cool stuff to do to choose from!
_________________
0xDB
View user's profile Send private message Visit poster's website
Gil
Developer

Joined: 14 Nov 2005
Posts: 2341
Location: Belgium
PostPosted: Mon Sep 29, 2014 5:26 am    Post subject: Reply with quote

I would say a NES palette might be something people want. I personally don't think it's an interesting one, but tons of retro indie games use the NES palette.
_________________
PoV: I had to wear pants today. Fo shame!
View user's profile Send private message Visit poster's website
0xDB
Developer

Joined: 26 Dec 2005
Posts: 1670
Location: Your consciousness.
PostPosted: Tue Sep 30, 2014 12:18 am    Post subject: Reply with quote

Couple of hours of research, head-scratching and lots of testing, I've come to the conclusion the NES palette is an oddball among oddballs. There does not seem to be consensus within the emulation scene about how to properly generate it. Sometimes it even seems like people are not even talking about the same thing even when they refer to it by the same name. There seems to be a lot of confusion about YUV/YIQ/YPBPR and color generation/conversion. There are several generators around the web, all of which produce quite different results, so who is doing it "right"?

My best guess is: No one and at the same time everyone.

So I decided to read technical docs and write my own generator routine (which I do not claim to be "right" either, but...) which I feel looks better and makes more (aesthetic) sense than the NES palettes I've seen for example on wikipedia. :)

As I don't have any real hardware to examine the actual signals though, I call the palette I generate NES* (NES"like") as it is likely to not be accurate to the metal.Here's what the generated NES"like" palette looks like:

_________________
0xDB
View user's profile Send private message Visit poster's website
PoV
Moderator

Joined: 21 Aug 2005
Posts: 10904
Location: Canadia
PostPosted: Tue Sep 30, 2014 1:19 am    Post subject: Reply with quote

I want to know what palette changes the Shovel Knight devs made. According to an article I read, they claim the NES palette is incomplete. If I followed the Hue spectrum around I might notice, but ever since I read that I've been curious.

I would love a generally accepted NES Palette 2.0.

EDIT: they were 4 "as needed" colors.

http://www.gamasutra.com/blogs/DavidDAngelo/20140625/219383/Breaking_the_NES_for_Shovel_Knight.php
_________________
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: 1670
Location: Your consciousness.
PostPosted: Tue Sep 30, 2014 2:53 am    Post subject: Reply with quote

What the NES palette lacks imho is a good grey scale(as general purpose buffer shades), a saturated yellow, additional earth/brown tones and probably more turquoise and green variants.

Seems like the Shovel Knight devs came to a similar conclusion but it they only added 4 colors and did not try to use up all possible 64 entries to make a NES2.0 palette.

Making a compatible NES2.0 palette would have to leave the indices as they are there unchanged too, as you never know which index was used in binary data of existing ROMs to select one of the duplicate black/greys and almost identical whites. So the new colors would have to start at 0x40 and existing games and software would have to be patched to use more suitable colors if necessary.

(mh... dreams about writing his own virtual console... an emulator for hardware which does not exists :) )

meanwhile, minor update as requested by surt(on pixeljoint):another minor update:
  • added DawnBringer's 32 color palette ( http://www.pixeljoint.com/forum/forum_posts.asp?TID=16247 )
  • tweaked hello world demo (added invisible char, so text does not bounce back as sharply on borders anymore)
  • holding/clicking the left mouse button down now will make letters in hello world demo move towards the cursor

_________________
0xDB
View user's profile Send private message Visit poster's website
PoV
Moderator

Joined: 21 Aug 2005
Posts: 10904
Location: Canadia
PostPosted: Tue Sep 30, 2014 7:42 am    Post subject: Reply with quote

I've always liked Arne's palette. The thread where he created it was a lot of fun, debating the existence of certain color choices to give him the flexibility to do more and more things. Something tells me the same sort of analysis (artist facing) wasn't put in to the other system palettes. :)
_________________
Mike Kasprzak
'eh whatever. I used to make AAA and Indie games | Ludum Dare | Blog | Tweetar
View user's profile Send private message
Alex
Developer

Joined: 05 Sep 2005
Posts: 1159

PostPosted: Tue Sep 30, 2014 12:30 pm    Post subject: Reply with quote

I've often considered trying to develop a universal palette myself, so if you want to have your own default palette for your lib, I can help you with that if you need it.
also, I like your new avatar.
View user's profile Send private message Visit poster's website
Gil
Developer

Joined: 14 Nov 2005
Posts: 2341
Location: Belgium
PostPosted: Wed Oct 01, 2014 3:58 am    Post subject: Reply with quote

PoV wrote:
Something tells me the same sort of analysis (artist facing) wasn't put in to the other system palettes. :)
Maybe the C64 palette. It has some odd consistency to it that can't be just a coincidence.
_________________
PoV: I had to wear pants today. Fo shame!
View user's profile Send private message Visit poster's website
0xDB
Developer

Joined: 26 Dec 2005
Posts: 1670
Location: Your consciousness.
PostPosted: Thu Oct 02, 2014 2:31 am    Post subject: Reply with quote

Gil wrote:
PoV wrote:
Something tells me the same sort of analysis (artist facing) wasn't put in to the other system palettes. :)
Maybe the C64 palette. It has some odd consistency to it that can't be just a coincidence.
In case of the C64 palette is is lucky coincidence though. The success of the C64 palette is mostly due to high artistic skill in countless applications of it and due to the good taste of the chip engineers(they just picked colors they liked), as described in an e-mail at end of that page: http://www.pepto.de/projects/colorvic/

Alex wrote:
I've often considered trying to develop a universal palette myself, so if you want to have your own default palette for your lib, I can help you with that if you need it.
also, I like your new avatar.
Thanks. Yes, I keep thinking of collecting colors for a general purpose palette myself too. In 2011 I also briefly started on it but then (as always) got distracted with other stuff, so it never went anywhere; pics(from 2011, two different approaches):


I doubt though, that we could make a "better"(I guess it comes down to personal preference anyway) general purpose palette than Arne and the whole Pixelation community combined. They put a lot of thought into that palette and it is in a tried and true state and has been used over and over again, proving its' worth/versatility/usability. The same is true for the DawnBringer palettes.

So... while it could be fun trying to make another general purpose palette but it probably would not end up being adopted by anyone if it's just based on theory and picking any number of good looking colors. The best approach would probably be to pixel many different materials, creatures, things and whatnot and add/change colors in the new general purpose palette as needed. It would also have to be suitable to different pixelling styles/techniques to get accepted by the community.

I'm not saying no, just thinking the time might better be spend working on something else instead. But well... making palettes is fun and it is a topic I can obsess about as well... so, feel free to start. :)

minor update:
_________________
0xDB
View user's profile Send private message Visit poster's website
Alex
Developer

Joined: 05 Sep 2005
Posts: 1159

PostPosted: Fri Oct 03, 2014 11:38 pm    Post subject: Reply with quote

yea.. everyone has their own preferences when it comes to color, and everyone probably doesn't see color exactly the same way, I know that all my life my left eye has seen color differently than my right eye.
I like your left palette more because I think it is more balanced. The right one lacks green(only has one green).
I often feel like color limitations don't necessarily allow you to learn how to pick colors(if you rely on one palette), which is why I don't reuse palettes or other people's palettes. but it is fun to force yourself to work with limited colors because you find yourself becoming creative to get yourself around the limitations.
View user's profile Send private message Visit poster's website
0xDB
Developer

Joined: 26 Dec 2005
Posts: 1670
Location: Your consciousness.
PostPosted: Tue Oct 07, 2014 1:22 pm    Post subject: Reply with quote

I think if I ever get around to working on them again, I'll go for a 32 color palette as 16 really is limiting in terms of covering a good range of tones.

-and now for something completely different-

I was thinking of porting DrPetter's sfxr to javascript the other day but when I checked the web, someone already did that! So adopting that went quite smoothly. Made a couple of changes, cleaned up the code a bit and switched v.0.2(came with jsfxr) for v.0.3 of RIFFWAVE.js (which unlike v.0.2(GPL) is Public Domain).

so yeah, small update (sfxr! \o/):
  • adopted slightly modified jsfxr.js/riffwave.js and slapped them behind an easy to use interface in rlSfxr
  • added quick and dirty minimalistic tracker code to the hello world demo and added short and shitty ToBeOnTop (C64) tribute loop (think I messed up the timing ;D )
  • fixed an issue in rlScriptShrink.js with potential code expansion issue for token "instanceof"
  • added rlMath.getCapperFunction
  • version changed from 0.1c to 0.1d
The rlSfxr interface needs some thorough testing and probably some changes for better convenience. Will do that as I gain a deeper understanding of what all those parameters actually do and what the real ranges for the values are.

updated hello world demo (including quick and dirty mini-tracker hack :D)

edit: Ok, in Chrome the timing is halfway ok but in FireFox it's totally messed up, so if you're on FireFox, you're probably not hearing what you're supposed to hear.
_________________
0xDB
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

Use this link to get a Sign-On Bonus when you get started!

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.