Bugs in cpp/neko and assets handling

#1

Hi.

  1. Std, regexp, zlib ndlls are not copied into output, so you have to do it manually or ask the user to install neko.

  2. Openfl and NME neko/cpp builds are broken. Resulting executables “are not win32 application”. Looks like there is some issues with how you embed icons because if you try obj/ApplicationMain.exe it works just fine. I did “nekotools boot ApplicationMain.n” and checked diff - there is two fields in PE header what are incorrect (do not remember which ones); it’s not so for cpp builds - they are completely broken.
    Oh, looks like it’s already reported here: Not a valid win32 application on windows xp I’m reading it now.

  3. There is a problem with assets exporting. When you do <assets ‘dir’ rename=‘dir2’/> all your assets go into “dir” AND “dir2” even though ‘dir’ ones are not ever used. Even in flash they are embedded twice.

  4. A lot of glitches in native builds. Here is some screenshots from game I tried to do for small local game jam. One is flash, other is cpp/neko. Sorry for links like that, but I’m not sure if embedding 4 1040x800 images is really good idea, and I’m allowed only two links per post (srsly?).
    flash rghost. ru/private/7NPK8wc6L/c94e8c9da91ea25a75febf2709704b37.view
    neko/cpp rghost. ru/private/6FsyB8RtW/85802abeb6e33b541689bf4a3d7e928e.view
    Dialogs (letters is Tilesheet):
    flash rghost. ru/private/8wjRlVzFm/63e794c6a3bca5e626b4f8002d3c9935.view
    neko/cpp rghost. ru/private/6Cz2p7zXb/ccbaec67f84230de690a6677299922ed.view
    It’s probably because I have Intel hd3000 instead of graphics card, but still. Do you have log files of something like that?

Builds are done in winxp with MSVC Express 2008 or 2010 (I’m not sure, which one hxcpp chooses) tried to run in 64-bit win7. Haxe version is 3.2.0, hxcpp 3.2.102 and openfl is 3.2.2. Everything is (almost) freshly installed.

#2

It’s me again. First, it’s bugs in cpp/neko output. Second 3) should be “When you do <assets path=‘dir’ rename=‘dir2’>” (those angle brackets…).
So, I checked 2) again, and it two fields that are different, but only one is wrong. SizeOfImage is not recalculated and is 0. Also “.rsrc” is completely broken, its name is 0, its size/offset/everything is 0.

#3

The neko ndll files should be copied now and allow the application to run even without neko installed, what version of lime do you use?

The “are not win32 application” is when you compile from windows xp?
You mentioned trying in windows 7, does it work?

It’s possible the intel card is responsible, could you retry it wih --window-hardware=false? Could help.
What rendering method do you use? BitmapData, Tilesheet, other?

I’m not sure I get what your asset problem is, if you do <assets path="dir" rename="dir2" /> you’ll end up with a dir2 folder with the content of the dir one, there should be no dir folder in the output.

#4

–window-hardware=false
Tried this and got same results.
Images are rendered using beginBitmapFill, dialog backgrounds is just beginFill and fonts are Tilesheet.drawTiles. Map is three layers - ground, objects and decals. Objects are stub, logs, bottom tiles of well and trees. Decals - top tiles of trees, top tiles of well, archway and also flowers. Object layer get copyPixels’ed into ground layer with alpha channel at creation time, so I have two huge BitmapDatas. Also in some images (fonts for example) I’m using color to represent transparency and then loop over and do getPixel/setPixel right after loading.

2.5.2. It looks like you cannot just update haxe and libraries (you’ll get a lot of weird errors) so 24 days ago I just deleted and reinstaled everything.

I’m compiling in winxp, can’t do it in win7. Just found that cpp executables sometime do work in winxp and win7. Neko ones don’t.

But it’s there. This is directory tree right after export
And when I deleted ‘rename’ part of tag and renamed manually my flash file shrinked to 3.6M from 7.3M. I’m pretty sure it was always like this.

#5

Looks like I cannot reproduce exactly this graphical bugs in smaller project, but after copyPixels’ing one bitmap into other, cpp build says “Invalid object” and closes. Flash works as expected. Am I doing something wrong? http://pastebin.com/vm111MEq
Also, I have two pc’s, one is very old and have old version of haxe updated to 3.2.0, and second is newer and have clean installation of everything (including flashdevelop), so when I create project on new pc, there is no bugs with assets exporting. But load project created on old pc and it breaks again. Probably, should reinstall this old stuff and see what happens.

#6

Does the project break when running, or compiling?

If compiling, make sure you have current OpenFL, Lime and Haxe versions

#7

Running, of course.

So yesterday I reinstalled haxe on my old pc and also updated lime to 1.6.0 and openfl to 3.1.1. Neko ndlls are now exported and neko builds are running.
On old pc assets are still exported twice even with new projects. I have no idea why this is happening. The only difference is FlashDevelop project file. I even tried to replace/remove it, but looks like lime does not care about it anyway.
Graphical bugs are still there.

#8

Do you have troubles when you try running the core samples? What OS is the old PC using?

#9

Bunnymark (tilesheet and copypixels versions) and Pirate Pig are working just fine.

WinXP sp2 (or sp3, do not remember).
I found why the code I posted above gives me “Invalid object” error. If you add “new Point(), false” as two last arguments to the first.copyPixels() call then it will work.
And if in my actual project I change last argument to copyPixels to false, then map will look like it should (except there is no transparency anymore).

#10

Thanks, I just committed a change that defines a new point if you have an alpha image but no alpha point. This is probably the correct behavior :slight_smile:

#11

New lime cannot find SHCreateItemFromParsingName in shell32. Have you officially dropped winxp support even for compiling stuff? If not you may be interested in this http://stackoverflow.com/a/20887104
I found you can do -Dlegacy and everything will run perfectly even on xp, so I can stick to this for now.
Also, thinking about code above, If I pass true to mergeAlpha, then source image becomes invisible. I didn’t payed attention yesterday, but then I realised this is not how it should be.

#12

Thank you!

Are you building from source? I have just committed an improvement to the dialog code which (I think) should address this problem and fix XP support. How much is working for you in Windows XP?

To be fair, I was testing in Windows XP x64 edition, which might have had unique issues over a standard 32-bit XP install :slight_smile:

#13

No. Just haxelib update.

If you mean new lime version, then lime.ndll statically imports this SHCreateSomething and thus cannot load. If you are talking about slightly older version with -Dlegacy, then everything works. Without this legacy flag all builds are creating window and failing with segfault almost immediately (and because window persist for a while, I think it probably crashes in first Event.ENTER_FRAME).

#14

Hmm. If NumLock is on and you’re hitting numpad keys, flash player will send events with keyCode=NUMPAD_x; if it’s off then you will receive LEFT, PAGE_DOWN etc. On neko you will always receive NUMPAD ones. Not sure about cpp, too long to compile, but probably it’s the same as neko. This is in lime 2.6.0 and openfl 3.3.1. And you’ll also get different key codes with -Dlegacy.
I actually like neko behaviour more and not sure if I want this fixed. Maybe compilation flag or one line somewhere in the documentation?

#15

In Neko (and other native targets) we get key events for different keys, I believe it’s designed to be one key per key, regardless of num lock, shift, etc

Flash gives different values based on shift, for example. We should probably handle num lock to do better Flash compatibility here, though it won’t change in Lime

First enter frame, perhaps that is in GL code or Cairo

#16

Hm… I’m getting the same "“Invalid object” on CopyPixels for Windows platform, even with “new Point(), false”.
BunnyMark works fine, but I can’t find problem in my code.
My code:

trace(sheet+", "+rect.toString()+", "+p.toString()+", "+bmpd);
bmpd.copyPixels(sheet, rect, p, false);

trace shows the following:

BitmapData, (x=0, y=0, width=1024, height=600), (x=0, y=0), BitmapData

But game crashes with the following:

Called from openfl.display.BitmapData::copyPixels openfl/display/BitmapData.hx line 579
Called from lime.graphics.Image::copyPixels lime/graphics/Image.hx line 326
Called from lime.graphics.utils.ImageDataUtil::copyPixels lime/graphics/utils/ImageDataUtil.hx line 162

I have latest lime 2.6.4 and openfl .3.3.5.

Any suggestions?

#17

Do you have a way that you might reproduce it in a small sample that has the problem?

That should make it much simpler to try and fix :slight_smile:

#18

I think there is some problem with swf library.
If I get image directly from assets, copyPixels works fine, but if I get it from swf, copyPixels fails.
Here is sample project: http://wikisend.com/download/290136/DisplayingABitmap.zip

#19

Thanks! It’s fixed now :success:

SWF getBitmapData was calling Image.fromBitmapData, which was nulling the image buffer bytes – would explain the crash :wink:

2 Likes
#20

That was fast, big thanks to you!