Windows 64bit. Whats the status?

[Roland]

The Kickstarter ended up in 42.358$.

 

$35,000 - 64-bit Builds: We’ll provide 64-bit builds of the Leadwerks engine library, along with the 32-bit library. (We decided to provide this for Linux by default. The stretch goal is for 64-bit builds on Windows and Mac.

 

What's the status of this?

[YouGroove]

@Roland :

64 bits advantage will be more and better memory management, i don't htink today some people have big world levels or memory problems with LE3. That won't speed up your game if you are already running LE3 in some 64 bits OS.

[Roland]

I didn't ask for what the advantages or disadvantages are. Think I know them.

I asked for the status of the stretch goal

[Josh]

The Linux library and interpreter are provided as 64-bit builds. This is a big deal on Linux because deployment of 32-bit software no 64-bit systems is not as smooth as it is on Windows and Mac.

 

On Windows, this turns out to be not such a good idea right now. Last time I checked, something like 20% of Steam users still have a 32-bit OS. Probably because they just don't know the difference, and MS still sells 32-bit versions of Windows, for some reason. So that means we can't just switch to 64-bit, I would realistically have to provide 32 an 64-bit builds. This slows down the speed at which I can release updates, because each update takes longer, and there's more mistakes that can be made.

 

Well, what are the benefits of a 64-bit build? It allows you to have a larger range of memory, but the editor cannot be built in 64-bit mode at this time. (There is a BlitzMax to C++ translator that's pretty far along, but it's not ready to be used in a commercial product.) So the engine would still be limited by the maximum load the editor can handle. At the same time, even the largest maps I've ever seen in Leadwerks used less than 50% the maximum memory available for 32-bit apps.

 

The editor has recently displayed some OUT_OF_MEMORY errors, but this would occur when the memory usage was nowhere near the limit of 32-bit applications. So it didn't actually have anything to do with memory usage, more likely it was a memory buffer overrun error that corrupted the thingiemajig that allocates memory. t traced the problem to a third-party library and believe this will be fixed in the next update. Have not experience this since I made that change.

 

So basically, the stretch goal was added in a hurry without enough planning, and part of it was a bad idea for practical reasons. A proper implementation of a 64-bit Windows build will involve the editor being compiled in C++ code, and that is a ways off from being possible.

[Rick]

Should just pull that last plug on BMax and find something else (for some future release of the editor). Either Mono/Xamarin (so you have a company to yell at) or Qt or something. Would probably set you up better for the future.

[Roland]

Thank's a lot Josh for taking the time to elaborate your thoughts on this, and reading that I can fully understand the decision. Here's a suggestion. Could the 5.000$ raised for this be moved over to "The Visual GUI Editor" which then could be financed within the raised amount of Kickstarter.

 

Looking at the kickstarter the cost of The GUI is set to 10.000$. Skipping the 64-Build gives a gain of 5.000$.

 

Some math gives that the project is then 'over'-funded with 42.358$- 30.000$ = 12.358$ which covers the cost of The GUI, still with a reaming profit of 2.358$ reserved for unplanned costs.

 

Wouldn't that be a good idea

[DerRidda]

Should just pull that last plug on BMax and find something else (for some future release of the editor). Either Mono/Xamarin (so you have a company to yell at) or Qt or something. Would probably set you up better for the future.

 

Not the first time I've heard that from people that have been in this community for far longer than me and I generally agree. No point in relying on unmaintained, dead tech that limits your product. Josh is usually very picky about 3rd party tech as he doesn't want to rely on something he can't control, or so he said. That's why I really don't understand why BlitzMax is still being relied upon when it already causes all these problems and something as proven as SDL is being ignored.

 

And about that visual GUI editor, that stretch goal was already mathematically reached when the OUYA one was canned, I also agree on that front. Cutting two stretch goals and not delivering on the other ones even though the math makes sense leaves a bit of bitter aftertaste in my mouth.

 

I would love to see one - the best - of the community made GUIs to be bought/licensed and fleshed out into an editor. That would eliminate duplication of effort in the community with every other project rolling a GUI system of their own and for Josh who doesn't have to start from scratch, keep the money to the stakeholders and the competition might just encourage people to deliver something great.

[Guppy]

Somewhat related, I'm currently working on porting myGUI to Leadwerks - It has a whole host of editors; http://mygui.info See downloads tab for pre compiled binaries, windows but works with wine if you can't be bothered to recompile

[Josh]

That's why I really don't understand why BlitzMax is still being relied upon when it already causes all these problems and something as proven as SDL is being ignored.

All SDL does is create a rendering context, and maybe some extra stuff I don't need. The rendering contexts in Leadwerks are already created using the native system calls for each OS. BlitzMax is used for the editor, not the engine. Throwing all that code away on a whim would involved a two year delay, and realistically would be the end of any platform for the editor other than Windows.

 

SDL performs a simple task for people who don't want to bother learning how each OS works (which is fine for many games). Because I need to control and understand the code, I wrote my own implementation that performs the same function better, for my purposes. SDL has nothing to do with the user interface.

 

​Stay focused on the games, guys. Minecraft, a game written in Java, is not technically impressive but it's fun.

[Rick]

and realistically would be the end of any platform for the editor other than Windows.

 

There are frameworks that support cross platform UI most likely better than BMax. You are probably just more used to BMax than those frameworks. However, at some point learning those other frameworks will be better in the long run. Many companies bigger than Leadwerks take advantage of these frameworks to do their UI.

 

Maybe you should make LE all using offline/online HTML 5/javascript/WebGL for the context. That would be pretty neat and give you some nice UI options

[Josh]

There are frameworks that support cross platform UI most likely better than BMax.

People keep asserting that, but can never name one.

 

Right, everything's cancelled. Next update will be ready in two years.

[Rick]

People keep asserting that, but can never name one.

 

They get named, I think you don't like them, which is why I think you are just comfortable with BMax because it seems like one of the first UI frameworks you've used for a long time. I'm more comfortable with .NET so Mono is my choice if I need to do this (which is rare).

 

I named 2 in my first post in this topic.

 

I would love to see an online/offline HTML5 Leadwerks though. How cool would that be! This would give the best options for UI honestly. Just would have to get WebGL working for the 3D perspective.

 

http://www.tidesdk.org/

 

http://code.tutsplus.com/tutorials/introduction-to-html5-desktop-apps-with-node-webkit--net-36296

 

 

 

https://github.com/rogerwang/node-webkit

 

This looks to be the best in this space. I might play with this a little to see how this runs. Very neat to be using HTML5, CSS, WebGL, & Javascript to make desktop apps!

 

 

https://github.com/zcbenz/nw-sample-apps/tree/master/webgl

 

 

Guess you'd have to deem if the differences between WebGL and normal OpenGL are editor breaking:

 

https://www.khronos.org/webgl/wiki/WebGL_and_OpenGL_Differences

[Josh]

.NET and Mono do not have a native cross-platform UI. They just have wxWidgets, GTK, etc., all of which I have evaluated.

 

The design of wxWidgets is not practical for actually writing programs. Every single button you create is a class. Hundreds of classes, one for each little item in your UI. The size of the source code would quadruple and development would crawl to a halt.

 

GTK is fundamentally broken by design. I only use it because it's the closest thing there is to a native Linux UI. The asynchronous nature of it has forced me to disable some features on Linux, like viewport resizing. And it doesn't look like the native UI on Windows or Mac.

 

QT is incompatible with Visual Studio and Code::Blocks, as far as I can tell. By default they want you to compile everything in the QT Editor. I can already tell everything will be an uphill battle with that crowd, because any time I try to do something different, the answer will be "do it the QT way". It's just way too invasive and seems ideologically-driven.

 

The perfect UI library would be a simple C interface that abstracts out all the system code for the Windows API, Cocoa, and GTK (for Linux). There's nothing like that out there, except MaxGUI (the BlitzMax GUI module). I don't know why, it seems like a really simple need many people have.

 

I investigated all of these at the start of development, and did not find any of them to be suitable. BlitzMax offers a real cross-platform native UI, a stable predictable feature set, and high compatibility with the C++ engine. The upcoming translator offers a way to compile the language with C++ compilers, which eliminates the limitations of the compiler. It may not be the hottest flavor of the week, and the developer is frustratingly unambitious, but it does a good job and meets my needs.

[DerRidda]

I know that SDL is not UI related, it was just a general comparison about your stance on third party libs but still you are underselling SDL by orders of magnitude, it does more than just context creation, input handling and windowing are also included two areas in which Leadwerks currently has issues especially on Linux.

If those get fixed, fine, I like how few dependencies Leadwerks has but having seeing how I still can't get a full screen window on that platform, let alone use any of the other window flags, nor use my mouse wheel I personally don't see it working out in a way I could reasonably consider acceptable. But enough about that.

 

Since this has become a UI discussion: Have you ever considered a Blender-esque approach? They basically went and flipped the bird at all the UI toolkit stuff and implemented their UI in OpenGL "in engine" as far as I understand it. It doesn't look native anywhere but that's also an advantage because no matter what you run Blender on, everything looks and works the same.

The Leadwerks editor basically just being a Leadwerks engine application, using its own GUI implementation to supply all the tools needed. If that GUI was completely exposed to Lua this could mean crazy potential for customizability. The Steam Workshop full of community made editor customization? Sounds like a selling point to me.

And while it initially means more work, because all new things do, in the end you only have to support one distinct code base instead of the aging BMax editor + engine.

 

I know you don't want to throw away all the effort you have put into the editor so far, nobody would, doesn't the state of the project concern you? What if you were suddenly forced to jump ship? Will that mean 2 years of recovering as well? Not a situation I would want to find myself in, feels like being held at gunpoint.

[Josh]

Since this has become a UI discussion: Have you ever considered a Blender-esque approach? They basically went and flipped the bird at all the UI toolkit stuff and implemented their UI in OpenGL "in engine" as far as I understand it. It doesn't look native anywhere but that's also an advantage because no matter what you run Blender on, everything looks and works the same.

When I started development, it was basically a tossup between that or using MaxGUI. I chose the latter.

 

What if you were suddenly forced to jump ship? Will that mean 2 years of recovering as well? Not a situation I would want to find myself in, feels like being held at gunpoint.

Why would I be concerned? It's good to anticipate, but you can be too paranoid about technology changes, and become afraid of any commitment.

 

There's an article somewhere that basically says something like "the companies who spend too much time trying to read tea leaves and guess where Microsoft will go next fail, and the ones who just buckle down and get things done succeed". Basically, it'd saying to move forward, not laterally.

 

Here it is: http://www.joelonsoftware.com/articles/fog0000000339.html

 

If you are moving forward, writing code and fixing bugs constantly, time is on your side. Watch out when your competition fires at you. Do they just want to force you to keep busy reacting to their volleys, so you can't move forward?

[DerRidda]

I think it might be worth reevaluating that choice. Source2 seems to be going that way too and Valve is quite a fitting example here, because they have been criticized for their tools - especially Hammer - for years and it looks like UE4 is doing the same thing.

Aren't the issues with the OS X version related to the editor as well? I don't really believe all that much is holding back the engine component.

[Roland]

Reading all this, I take that the answer on my suggestion is No.

Thanks for the info

[ChrisV]

Stay focused on the games, guys.

Well, we are.

 

But, if the 64 builds will not come (in the near future), and the stretch goal was reached (which it was), then what will it be spent on to improve LE even more? A visual GUI editor? Oculus Rift? Integrated ocean/river/road tools? Day/night system? ?

 

Any information on that would be great, Josh! Thanks.

[YouGroove]

Now that Linux si fully supported, LE3 is based on a solid Windows/Linux editor, not many engines support both OS.

Asking a migration would bee indeed too long, this is the second main part of code of a 3D engine that can be lot more bigger than the rendering part sometimes.

 

You could otherwise create your own real time world editor using LE3, but you would need LE3 to be able to run in a windows and be able to be called by some .Net interface or other interfaces.

If LE3 had this possibility perhaps some people would make some community editor based on other interfaces, but like plugin system i'm not sure that will come some day.

 

I think there are many more important needs like some advanced water, CSG tools and incoming vegetation tools.

TheSci Fi and incoming FPS pack are great addition, i think many non 3D artists users would need lot more packs and actually this is also time consuming.

 

About new features , i think the vegetation tool to quickly place some trees and grass will help a lot to quickly make gorgeous levels, this should be in top priority,we have terrains but not optimized trees and grass system, and no water system, and i hope this will be implemented for the end of year or beginning of next year

(The CSG tool will be a really big new feature also when LE3 will be able to do what we can do in 3D World studio)

 

​Stay focused on the games, guys. Minecraft, a game written in Java, is not technically impressive but it's fun

This is not the only Java one

 

Yep, this is your work and not the editor interface that makes your game great

 

If your level design or 3D art is bad , 64 bits editor won't make better

[Roland]

@YouGroove.

You do not cease to amaze me

[YouGroove]

Lol , you have to adapt yourself to the product , nothing is perfect, you have good points and bad points on any 3D engine.Only software owners decide to priorize what they want and work at their own rythm , like Esenthel chossing monthly subscription or Shiva 2 announced years ago and still not here.

I asked too much things in the past without realising LE3 is not some EA 3D big team, so why asking things that could take a year or more ?

 

Each of us give priority to something different from others , for example i don't mind 64 bits in LE3 at all, i would priorize 100% some minimal packaging system allowing us to deliver demos and prototype to players. Until that i won't be able to propose some demo to players, it has been asked so i just use LE3 less and less hoping packaging for Lua version only will pop up someday

 

For some people priority is CGS , as not using BSP i would instead priorize in second vegetation and water system, without them terrain feature is not complete. But finally it's only Josh choosing what feature he wants to implement and when they can be implemented.

 

But Roland, i agree you needed some clarification on 64 bits as it was among planned features.

[Roland]

What amazes me is that whenever I ask a simple question it derives into something else.

In this case I started by just asking what the status on 64-bit was, got an answer from Josh on that,

which I could accept. All good. Then I made a suggestion and that seemed to be out of line for now.

Again I accepted that without discussion.

 

Where have I said something about that I need 64-bit to make a game better or that I can't live

without a GUI (I have made a working GUI myself already).

 

It must be possible to ask simple questions without getting dragged into some weird assumptions

on what may or may not bee behind the question.

 

Anyway, all OK YouGroove.

 

Summary:

- I asked two questions and they got an answer. I'm satisfied with that.

- I did not go into anything about art, art-pipeline or anything else.

- I miss some public plan for the future of the engine, but can live with that.

 

Cheers

[DerRidda]

Sorry, I'm partially at fault for the massive derailment that has happened here.

 

Dominoes, the whole lot of us!

[cassius]

Yeah. Hijackers at work ( again)...but interesting read.

[Hamguy]

ok so its 2018, what's the status on 64bit?