.swf to .bundle generation fails with TypeError

Hello!

I am trying to load old SWF files to see if I can revive my game, but seems there are problems with them.

What I did:

git clone --depth=1 https://github.com/openfl/openfl-samples-es6
cd openfl-samples-es6/demos/NyanCat
[ replaced assets/library.swf with my SWF file ]
npm run build

which fails with error:

Module /home/node/app/openfl-samples-es6/demos/NyanCat/node_modules/openfl/bin/tools.js requires node.js version 4.0.0 or higher
[lime.graphics.Image] WARNING: Image.fromBytes not supported on this target
/home/node/app/openfl-samples-es6/demos/NyanCat/node_modules/openfl/bin/tools.js:13480
				var values1 = new haxe_io_Bytes(new ArrayBuffer((image.width + 1) * image.height));
				                                                       ^

TypeError: Cannot read properties of null (reading 'width')
    at format_swf_exporters_SWFLiteExporter.addBitmap (/home/node/app/openfl-samples-es6/demos/NyanCat/node_modules/openfl/bin/tools.js:13480:60)
    at format_swf_exporters_SWFLiteExporter.processTag (/home/node/app/openfl-samples-es6/demos/NyanCat/node_modules/openfl/bin/tools.js:14111:17)
    at format_swf_exporters_SWFLiteExporter.addShape (/home/node/app/openfl-samples-es6/demos/NyanCat/node_modules/openfl/bin/tools.js:13557:10)
    at format_swf_exporters_SWFLiteExporter.processTag (/home/node/app/openfl-samples-es6/demos/NyanCat/node_modules/openfl/bin/tools.js:14119:17)
    at format_swf_exporters_SWFLiteExporter.addSprite (/home/node/app/openfl-samples-es6/demos/NyanCat/node_modules/openfl/bin/tools.js:13634:11)
    at format_swf_exporters_SWFLiteExporter.processTag (/home/node/app/openfl-samples-es6/demos/NyanCat/node_modules/openfl/bin/tools.js:14109:17)
    at format_swf_exporters_SWFLiteExporter.processSymbol (/home/node/app/openfl-samples-es6/demos/NyanCat/node_modules/openfl/bin/tools.js:13870:20)
    at new format_swf_exporters_SWFLiteExporter (/home/node/app/openfl-samples-es6/demos/NyanCat/node_modules/openfl/bin/tools.js:13304:10)
    at Tools.processFile (/home/node/app/openfl-samples-es6/demos/NyanCat/node_modules/openfl/bin/tools.js:1287:17)
    at Tools.main (/home/node/app/openfl-samples-es6/demos/NyanCat/node_modules/openfl/bin/tools.js:1265:10)

When I open page it fails with error GET http://localhost:8080/dist/1d5c97fb8576e6825f67c0dc9f77f9dd.bundle/library.json 404 (Not Found) I guess due to bundles not being generated due to error.
What could be the problem with my SWF files? Is there a way to fix it?
My SWF file: library.swf - Google Drive

I run everything inside docker.
Dockerfile:

FROM node:20.5

RUN apt-get -y update && \
    apt-get -y install \
    sudo

RUN adduser node sudo
RUN echo '%sudo ALL=(ALL) NOPASSWD:ALL' >> /etc/sudoers

USER node

WORKDIR /home/node/app

docker-compose.yaml:

version: "3.9"

services:
  try_openfl_npm:
    build:
      context: .
    tty: true
    volumes:
      - ./:/home/node/app
    ports:
      - 8080:8080
    restart: always
    command: tail -F /dev/null

So the command is:

docker compose up -d --build --force-recreate --renew-anon-volumes --remove-orphans
docker compose exec try_openfl_npm bash

Thanks in advance!

I tried OpenFL from haxelib and everything worked like a charm!
I guess it’s because npm version is slightly outdated: 8.9.6 vs 9.2.2 from haxelib.

Anyway, it’s a mystery to me why npm version even exists, since haxe (lime?) naturally supports targeting html5 - maybe to enable user developing in TypeScript instead of Haxe? Seems so …
Wondering how npm version even developed … Generated with lime? Guess so …

Yep, this allows developers to use JavaScript, TypeScript, or any other language that can compile to JavaScript (including ActionScript 3.0, which was the language used by Flash, using the Apache Royale compiler).

Compiled from Haxe to JS and bundled with Webpack.

Here’s the GitHub repository, if you’re interested in the nitty-gritty details:

1 Like

@joshtynjala Thank you for your comments!
I’m still trying to figure out the whole pipeline of modern Haxe/OpenFL development to target, mostly, browsers:
Webpack’s power lures to build project around it, especially when dedicated loader exists, but I still can’t determine is it JavaScript that should boss around and call Haxe, or Haxe should be calling JavaScript?

For example, if I need to use Spine in my app, should I incline towards official package and somehow tinker it’s integration with OpenFL rendering (if it’s even possible) and Haxe language, or use Haxe’ solution? So much choices!

What’s the best practice?

For me, personally, if I’m writing any code in Haxe, I probably want the Haxe code to be primarily in control of everything in the project. There can be value in integrating native libraries, whether JS when targeting html5 or C++ native extensions when targeting windows/mac/linux/android/ios. However, from my perspective, those libraries are there to assist the Haxe code, and not the other way around.

I’m sure part of that is simply because I find working with Haxe to be more enjoyable that writing JS or C++. I guess you need to figure out which you like better, and the answer may certainly be different than mine.

1 Like