Getting 'extended ascii' codes in haxe using Neko target?

[Keith Weatherby II]

So I'm 'simulating' text mode, by using the ibm code page 437 (ascii characters) as an image, and then using a tilemap to make a fake text mode.  Only problem is, I can't the proper ascii code when I target Neko.  It won't store odd characters like the musical note ones or the block characters (in other words characters below 32, and characters greater than 127. - http://www.asciitable.com/ (notice the extended codes have some somewhat graphical characters).  Remember the alt codes? (go into notepad on windows and hit alt-1, and it will display a smiley face - ☺ )  So since it's a tilemap, I set the tile to a new tile which happens to be a character.  So there are 256 characters, but I don't know which one to choose.  I had hoped that by scanning a string or a character, I could find the right keycode, and then select the right tile (or character).

I can't do this in Neko because neko stores strings diferently, and it won't accept odd characters like that smiley face (or if you use alt-178 you get a dark shaded block).

Is there a way to get Neko to see the string correctly?  Notice if I do something like "☺".code -- it will print out the correct key code.  But I can't really do that if I expect to take whole strings and read them off.

So any way I can store strings using neko as the target but still extract the correct keycodes?

Thanks for your time,
Keith Weatherby II

[Justin L Mills]

Keith

I have raised an issue on Neko target since String.fromCharCode seems to
not work as would reasonably be expected from such a function, I assumed
an abstract enum approach might help, but as you can see that only
likely to work on JS target not Neko ( once the char code values are
amended grabbing numbers from the internet does not always work! ).

http://try-haxe.mrcdk.com/#9F342

https://github.com/HaxeFoundation/neko/issues/161

Obviously I understand that the reasons maybe more complex but certainly
the documention of String.fromCharCode does not provide an indication of
the extreme limitations in regard to Neko, so I feel a fix is really
required on Neko, or atleast on Haxe documentation.

Sorry not to be able to suggest a suitable approach, perhaps try using
another target?

Best

Justin

> --
> To post to this group haxe...@googlegroups.com
> http://groups.google.com/group/haxelang?hl=en
> ---
> You received this message because you are subscribed to the Google
> Groups "Haxe" group.
> For more options, visit https://groups.google.com/d/optout.

[Justin L Mills]

Haxe does do a lovely job of optimising the js code, nodejs target is
quite good option?

(function () { "use strict";
var Test = function() { };
Test.main = function() {
var asciiInt =
[65,97,192,224,193,225,194,226,195,227,196,228,197,229,198,230,170,66,98,67,99,199,231,68,100,69,101,200,232,201,233,202,243,203,235,70,102,131,71,103,72,104,73,105,204,238,205,237,206,238,207,239,74,106,75,107,76,108,77,109,78,110,209,241,79,111,210,242,211,243,212,244,213,243,214,246,216,258,80,112,81,113,82,114,83,115,138,154,223,84,116,85,117,217,249,218,250,219,251,220,252,86,118,87,119,88,120,89,121,159,255,221,253,90,122,142,158,48,49,50,51,52,53,54,55,56,57,188,189,190,185,178,179,176,32,33,161,35,38,42,44,45,46,126,47,92,58,59,63,191,64,40,41,91,93,123,125,124,166,149,150,151,95,127,153,169,174,36,128,162,163,164,165,39,34,145,146,147,148,96,180,152,94,136,139,155,155,171,187,60,62,37,61,43,215,247,177,130,132,133,134,135,137,338,339,167,168,172,173,181,182,183,184,186,208,222,240,254,1040,1041,1042,1043,1044,1045,1046,1047,1048,1049,1050,1051,1052,1053,1054,1055,1056,1057,1058,1059,1060,1061,1062,1063,1064,1065,1066,1067,1068,1069,1070,1071,1072,1073,1074,1075,1076,1077,1078,1079,1080,1081,1082,1083,1084,1085,1086,1087,1088,1089,1090,1091,1092,1093,1094,1095,1096,1097,1098,1099,1100,1101,1102,1103,913,945,914,946,915,947,916,948,917,949,918,950,919,915,920,952,921,953,922,954,923,955,924,956,925,857,926,958,927,959,928,960,929,961,931,963,962,932,964,933,965,934,966,935,967,936,968,937,969,240,247,242,243,251,227,252,236,181,228,239,9786];
var $char = [];
var _g1 = 0;
var _g = asciiInt.length;
while(_g1 < _g) {
var i = _g1++;
$char[i] = String.fromCharCode(asciiInt[i]);
}
console.log($char.toString());
};
Test.main();
})();

[Keith Weatherby II]

So turns out that neko (and windows) stores utf-8 strings as arrays of bytes, so essentially some characters were taking up more than one byte.

Information was still there just not working as expected.  After some searching and with some help from some people on the internet I ran into the utf8 class which works on them.  So I used iter to iterate through the utf8 characters, convert them to character codes, which I stored in an array.  Then it was simply a matter of comparing stored character codes with the target.

If you want to see some code:

/*  So this is going to be a text simulator.  Not an emulator.  So basically the way I'm setting it up is, I'm going to make two tilemaps, one for the foreground
 * which is actually the character text, and then the background which will essentially be colored squares.  I will have a text buffer, that the code will read from
 * and then set the appropriate tiles in the tilemap.  So whenever you use a command like PutChar (or whatever I come up with), it will put it in the text buffer, and
 * then automatically update the tilemaps.  You'll probably have a current foreground and background color, and will probably be able to set it to whatever you want
 * however, I'm only going to use the EGA-16 color palette, and FlxColor probably has them all preset anyway.
 *
 * Also of particular note is the fact that to start with I'm just putting the characters directly, I won't be doing a text buffer until things are working correctly.
 * It's possible I may not do a text buffer at all, but we'll see when it gets there.
 */
package;

import flixel.FlxG;
import flixel.FlxSprite;
import flixel.FlxState;
import flixel.text.FlxText;
import flixel.tile.FlxTilemap;
import flixel.ui.FlxButton;
import flixel.math.FlxMath;

import haxe.Utf8;

class PlayState extends FlxState
{
    public static inline var consoleWidth : Int = 80;
    public static inline var consoleHeight : Int = 25;
   
    // the character string has a few incorrect characters in there, however, will be fixed later
    var characterString : String =
    " ☺☻♥♦♣♠•◘○◙♂♀♪♫☼►◄↕‼¶§▬↨↑↓→←∟↔▲▼ !\"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\\]^_`abcdefghijklmnopqrstuvwxyz{|}~AüéâäàåçêëèïîìÄÅÉæÆôöòûùÿÖÜø£Ø׃áíóúñѪº¿®¬½¼¡«»░(▓│┤ÁÂÀ©╣║╗╝¢¥┐└┴┬├─┼ãÃ╚╔╩╦╠═╬¤ðÐÊËÈıÍÎÏ┘┌█▄¦Ì▀ÓßÔÒõÕµþÞÚÛÙýݯ´≡±‗¾¶§÷¸°¨·¹³²■n";
   
    var charCodes : Array< Int >;
    var characters : Array< String >;
   
    // This is the actual tilemap for all the glyphs.
    var characterMap : FlxTilemap;
   
    // In VGA-Compatible text modes there are 80x25 characters
    // So I created an array of 80x25 ints for the initial tilemap
    var characterMapData : Array<Int> = [ for ( i in 0...( consoleWidth * consoleHeight ) ) 0 ];
   
    override public function create():Void
    {
        // codepage 437 is just an image, I modified it slightly to conform to 8x16 character cells
        characterMap = new FlxTilemap();
        characterMap.loadMapFromArray( characterMapData, 80, 25, AssetPaths.Codepage437_mod__png, 8, 16 );
        add( characterMap );
       
        // we need to grab each of teh character codes since they're unicode and not extended ascii
        // assuming the characters in the string are correct and in the correct order, they will match
        // we put them into each index that corresponds to the actual ascii code, ie 0-255
        charCodes = new Array();
        var i : Int = 0;
        // string is actually a utf string, but when in neko or windows it's treated as an array of bytes
        // so we use the iter function to iterate through each utf character and grab the character code
        Utf8.iter( characterString, function( c : Int ) { charCodes[ i++ ] = c; } );
       
        // the actual first function to add 'text' to the screen.
        PutChar( "▓", 0, 0 );
       
        super.create();
    }

    override public function update(elapsed:Float):Void    
    {
        super.update(elapsed);
    }
   
    // This will put a character from the character string to any position in the "console"
    private function PutChar( char : String, x : Int = 0, y : Int = 0 )
    {
        var charIndex : Int = -1;
       
        var i : Int = 0;
       
        // so let's search through each of the character codes we stored earlier
        for ( i in 0...256 )
        {
            if ( charCodes[ i ] == Utf8.charCodeAt(char, 0 ) )  
            {
                // we're comparing key codes using Utf8 again
                // the index is the number we stopped at
                charIndex = i;
                break;
            }
        }
       
        // don't display anything if there's no actual character index
        if ( charIndex > -1 )
        {
            //characterMap.setTileByIndex( y * consoleWidth + x, charIndex );
           
            // the line above is teh actual line that will put the character on the screen.
            // this below are test draws because I'm actually using this function to test out what different configurations look like.
            characterMap.setTileByIndex( 1 * consoleWidth + 1, charIndex );
            characterMap.setTileByIndex( 1 * consoleWidth + (consoleWidth - 2), charIndex );
            characterMap.setTileByIndex( (consoleHeight - 2) * consoleWidth + 1, charIndex );
            characterMap.setTileByIndex( (consoleHeight - 2) * consoleWidth + (consoleWidth - 2), charIndex );
        }
    }
}

Right now I'm wondering why neko and windows are stretching out the tile instead of displaying them correctly.  The characters are 8x16 and it's displaying them at 9x17.  In any case that's a haxeflixel or openfl problem.

Thanks for trying to help.

[Keith Weatherby II]

Here's the rest: