Problem with older openFL projects and versions

Help
#1

In the past I’ve done several Ludum Dare games using openFL (without specifying the openfl version).
But since then I’ve run haxelib upgrade several times, and now it seems impossible to get any of those old projects to compile.

It seems to me like openFL don’t give high priority to being backwards compatible, at least not between the versions I’ve upgraded between. And on top of that, it seems to me like you also need to roll back to the correct version of Lime since your project also breaks if Lime is not set to the version that was “the latest” when that version of openFL was released.

If I’m correct in this assumption, is there a list somewhere where you list which lime version is needed for each released openfl version?

It seems extremely important to set the version of every library you ever use in your project.xml. This is not something I’ve seen highlighted anywhere, and something it seems I have now learned the hard way.
If I want to set a specific version of openFL for a project, are there any other things I have to consider? For example, are there any hidden dependencies that needs versioning as well? Besides Lime?

1 Like
#2

I don’t think there is a list somewhere, all you can do it’s trying to use openfl and lime that have been released at the same date.

Other thing to consider : version of hxcpp.

#3

Are you using HaxeFlixel?

HaxeFlixel has relied on non-Flash behaviors in older versions of OpenFL, which have not been possible to keep as we move forward. Flash API projects have not taken a hit in backward compatibility, as we continue to improve the consistency and stability of OpenFL

The fundamental problem is that haxelib does not support wildcard versions, so we cannot do “version 2.9.x” when referencing Lime. Referencing an exact version of Lime is bad (IMHO) so we’re stuck with some of the trouble if you must have an old version

One workaround might be to specify your own versions in your project.xml before any other haxelib

<set name="lime-legacy" />
<haxedef name="lime-legacy" />
<haxelib name="lime" version="2.9.0" />
<haxelib name="openfl" version="3.6.0" />
#4

@singmajesty ‘The fundamental problem’ is that you just keep messing up the code.
You don’t have a Bitmap font option any more…
You just ignore serious issues (my issues :slight_smile: (1200, 1117, 1088), and just work on your own stuff.
If you want OpenFL to succeed, make it more stable. Your dropping of Tilesheet (without telling us what to do about it) is just ridiculous.

2 Likes
#5

What bitmap font solution are you referring to?

There are a lot of issues to go through, it is hard to know how many apply to the current codebase

I apologize for the inconvenience with Tilesheet, I blogged about this a long time ago, and have been working hard to provide an alternative that doesn’t suffer from the fatal flaws built into drawTiles :frowning:

#6

I’ll be happy with any bitmap font. The only one I know of is Beeblerox’s https://github.com/Beeblerox/BitmapFont.

My major problem with OpenFL is stability. Keep some sort of versioning with libraries that work.
And solve issues first, before going on to implement new stuff.

Thanks for the excellent work though :slight_smile: I don’t want to sound ungrateful…

#7

BitmapFont use drawTiles. I don’t think it’s hard to adapt for Tilemap. The only thing that will not work for now it’s color change because it hasn’t been implemented yet in Tilemap I think.

#8

@singmajesty @loudo Thanks for your answers!
I’ve not used haxeflixel. I’ve used a customized/forked version of haxepunk once, and my own lib twice.

Generally I have no problem with new versions breaking backwards. I prefer that to having huge mess of legacy code that needs to be maintained by the project owners, growing with each new release.

But if that’s the case I think it’s important to be able to lock down the openfl-version, and all it’s dependencies. Locking to a specific patch-version might not be optimal, but it beats not being able to lock at all, and it definetly beats not being able to compile your old projects at all.

Is lime and openfl the only libs I need to lock, or should I lock hxcpp as well, as @loudo suggests?

#9

HXCPP is probably fine, but again, I wish we could do wildcard versioning, that would make this much simpler, choose an OpenFL release and it will lock what Lime version is compatible

#10

This I have also found. More often then not, doing an upgrade tends to break existing projects. And when framework API changes, theres no deprecated functions, only replacements. Possibly recommended/suggested function changes in a blog? I.e. if function A is no longer included, recommendation to use function B with a quick code example would help people migrate from one version to another and keep to the latest.

The other pain-point I have found is, having to force legacy mode on OpenFL all the time. If I take it off, even more stuff is broken. :-/

#11

It seems extremely important to set the version of
every library you ever use in your project.xml. This is not something
I’ve seen highlighted anywhere, and something it seems I have now
learned the hard way.

I agree. Since Openfl depends on lime features, it always should say “Needs Lime 2.5.x.x”

This is what i do… I check the Changelog file on both github projects (Lime and openfl)
and generally the release date of both projects work well together,
so if you want an older version of openfl, you should use a lime version released on the same date (or near) checking the changelog file

#12

I agree with @Tommislav , the instability of OpenFL versions is a huge problem when you want to update your library or recompil an older project.
And no explicit of the link between Lime version and OpenFL version is a another problem, especially when you work on differents project with differents OpenFL version. I always note in comment the Lime version.

But i’ll just say more that you do, @singmajesty, a fantastic job and i send you a big thank you for that !