Tiles from a tilemap displaying incorrectly in Neko and Windows targets

  • I'm building a little text mode 'simulator' and I'm using a tilemap, where the tiles are characters of text (taken from a slightly modified ibm code page 437 character set). So essentially you're going to be able to fake text mode using haxeflixel so you can do stuff like dwarf fortress, rogue, and even just a standard dos-like console. The characters (tiles) are 8x16 (I chose this instead of 9x16 or 9x14 or some other weird thing to help me a bit with the math) pixels. Makes 80x25 character cells fit neatly in 640x400. Okay so in flash, and html5, the characters turn out okay, but in neko and windows it's actually drawing it 9x17 -- it's stretching it out by one pixel on each axis. You can see it below.

    Text Display

    I wanted to be able to run this on pretty much anything that haxeflixel will run on, but it's not consistent. Any ideas why it's not drawing it pixel perfect at 8x16 in neko and windows targets?

    I'll post the code below:

    /*  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.
    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 );
    	override public function update(elapsed:Float):Void	
    	// 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;
    		// 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 );

  • I just solved this problem. I kept searching the forums for stuff on tilemap and tile scaling and what not, and came across some threads on github about some sort of tiling problem where there would be gaps and what not when zooming. Well a solution was hacked in called useScaleHack which scaled the images by 1 pixel on each axis. Apparently this was actually set to true on windows and neko targets. So I just set it to false and viola, no more tile stretching!

Log in to reply

Looks like your connection to HaxeFlixel was lost, please wait while we try to reconnect.