Java Lilith's Throne [v0.4.10.7 Hotfix] [Innoxia]

[tehlemon]

Wont help, at least much.
From quick, diagonal glance on a code it looks like most of stalling happens due to overcomplicated calculations aka "who shit when under which bushes, while walking three meters to the nearby shop for 17 hours". It all should be reduced in size/complexion/quantity, or calculate it all in steps, aka process npcs with id % 13 == 1 on the next player turn, than npcs with id % 13 == 2 and so on. There are wouldnt be a big difference anyway, since its a turn based game.

Oh it's not supposed to *help*

It just hides the problem by keeping the UI active while the game shits the bed so Windows doesn't think the program hung. But it won't do anything to prevent the hanging.

I'm not willing to put in any effort to fix this game unless I'm getting paid for it.

 

[Sarkath]

would converting parts of it to some jvm side language make a diffrence? something like kotlin?

The only reason that might help is that you're going through the code and rewriting it, presumably making some better decisions along the way.

The issue was never the language. The issue is what's being done with it.

 

[BobCarter]

Having a library like this in native code introduces a bunch of complications. Namely, the fact that it'll have to be built for every platform. At the very least: one x64 DLL for Windows, ELF for Linux/x64 and Linux/arm64, and Mach-O for macOS/x64 and macOS/arm64. Add in a few more if you want to support 32-bit systems. Cross-compiling is possible, sure, but at some point it'll need to be tested by someone who uses the target platform.

Linux can emulate windows for programs now, fairly sure this would work for that. Not sure about Mac, but Mac's always gotten the short end of the stick.

 

[Sarkath]

Linux can emulate windows for programs now, fairly sure this would work for that. Not sure about Mac, but Mac's always gotten the short end of the stick.

Yep. Things can get a little dicey when you're using bytecode languages, but I think wine-mono would probably do the trick if you're using, say, a native Windows DLL with a .NET app.

Intel Macs support Wine about as well as Linux boxes in my experience. Apparently some madlads even managed to get it working with Rosetta 2 (the x64 to ARM binary translation layer, if you aren't familiar with it), so even the new ARM Macs can get in on the fun.

 

[jfmherokiller]

macs get a stick so short it might as well be little more then a sprouting bud

 

[BobCarter]

Yep. Things can get a little dicey when you're using bytecode languages, but I think wine-mono would probably do the trick if you're using, say, a native Windows DLL with a .NET app.

Intel Macs support Wine about as well as Linux boxes in my experience. Apparently some madlads even managed to get it working with Rosetta 2 (the x64 to ARM binary translation layer, if you aren't familiar with it), so even the new ARM Macs can get in on the fun.

So really we'd just need to make a windows version, and the only one that might be SOL is 32 bit users. Which is fairly normal, few people are still using those anyways.

Then again most 64 bit OS's have support for 32 bit as well, so maybe only make a 32 bit version if you care?

 

[Sarkath]

So really we'd just need to make a windows version, and the only one that might be SOL is 32 bit users. Which is fairly normal, few people are still using those anyways.

Yep. Honestly, I can't fault that idea given that it's the dominant OS. It'd be a good way to get things off the ground at the very least.

Another option would be using GitHub Actions (or something like that) to automatically produce cross-platform builds, then just recruiting community members to test them once in a while.

I'd say producing both 32-bit and 64-bit would be best. macOS has been pure 64-bit since High Sierra (~3 years ago), and I know I'm not the only one who doesn't like using multilib in my Linux distros. Neither of those platforms would be able to run 32-bit Wine.

 

[jfmherokiller]

Yep. Honestly, I can't fault that idea given that it's the dominant OS. It'd be a good way to get things off the ground at the very least.

Another option would be using GitHub Actions (or something like that) to automatically produce cross-platform builds, then just recruiting community members to test them once in a while.

I'd say producing both 32-bit and 64-bit would be best. macOS has been pure 64-bit since High Sierra (~3 years ago), and I know I'm not the only one who doesn't like using multilib in my Linux distros. Neither of those platforms would be able to run 32-bit Wine.

well i think wine 7.0 can run 32bit stuff via some kind of vdm thing. I have used it to run an installation of "The Way Things Work" and "Encarta 98"

 

[Quintilus]

would converting parts of it to some jvm side language make a diffrence? something like kotlin?

Kotlin compiles to same bytecode as java AFAIK, so it didnt change anything.

 

[jfmherokiller]

Kotlin compiles to same bytecode as java AFAIK, so it didnt change anything.

fair but i think it does it in a way that might br more organized. I have seen lower ram usage/better performance in apps that make use of both java and kotlin.

 

[Sarkath]

well i think wine 7.0 can run 32bit stuff via some kind of vdm thing. I have used it to run an installation of "The Way Things Work" and "Encarta 98"

I just checked it out and that looks really promising! From what I can gather it doesn't do any instruction translation, but rather puts in a means for 32-bit PE EXEs to call 64-bit libraries. It doesn't look like the library support is complete at the moment, but I imagine most of the important ones are done.

I'm kinda curious what means it uses to execute the 32-bit code. I imagine you'd still have to have 32-bit support enabled in the kernel, you just wouldn't need a 32-bit userland. That probably also means that it won't be too useful to Mac ports of Wine (it might work on Intel Macs, but I don't think Rosetta 2 has the means to translate 32-bit x86 code at all) but it'll definitely be fantastic for Linux users who want a pure 64-bit userland.

fair but i think it does it in a way that might br more organized. I have seen lower ram usage/better performance in apps that make use of both java and kotlin.

That's definitely a possibility, but LT's issues purely stem from application design (or lack thereof). If it were written as-is in Kotlin you'd run into the same issues, it would just take a few more milliseconds before the garbage collector goes into panic mode.

If you want to have a laugh, play LT until it starts getting a little sluggish, then attach a profiler to it. You'll be amazed at how much it thrashes memory. Some measures have been put in to improve things, but it still does way too many large allocations and deallocations each turn (and simply moving between map tiles ends the current "turn").

 

[Quintilus]

fair but i think it does it in a way that might br more organized. I have seen lower ram usage/better performance in apps that make use of both java and kotlin.

Ehhh...
Kotlin is just a hyped attempt of 'reject modernity, embrace traditions' by functional programmers in Java world, because "OOP IS BAD, MNKAY!!!!!! FUNCTIONAL PROGRAMMING IS AN ONLY TRUE PROGRAMMING!!!!!111111". You know, same guys who still wages war against C++ and its OOP.
In any case, code quality/correctness and so on solely depends from one and only 'layer of abstraction', located between chair and keyboard. LT is a great example of it. Even with something like Rust it would be buggy crutchy sluggish mallocing mess, if it would be written in same way.

Also according to Scott Meyers, this noname block

Kotlin currently repeats path of a C++ in Java world. Same type/kind of problems, as 'young', from around 90, C++ had.

 

[Carl0sDanger]

... the only thing you can really do is try to limit the number of NPCs that exist in the world.

Should honestly be a big sign in the OP.

 

[jfmherokiller]

I just checked it out and that looks really promising! From what I can gather it doesn't do any instruction translation, but rather puts in a means for 32-bit PE EXEs to call 64-bit libraries. It doesn't look like the library support is complete at the moment, but I imagine most of the important ones are done.

I'm kinda curious what means it uses to execute the 32-bit code. I imagine you'd still have to have 32-bit support enabled in the kernel, you just wouldn't need a 32-bit userland. That probably also means that it won't be too useful to Mac ports of Wine (it might work on Intel Macs, but I don't think Rosetta 2 has the means to translate 32-bit x86 code at all) but it'll definitely be fantastic for Linux users who want a pure 64-bit userland.



That's definitely a possibility, but LT's issues purely stem from application design (or lack thereof). If it were written as-is in Kotlin you'd run into the same issues, it would just take a few more milliseconds before the garbage collector goes into panic mode.

If you want to have a laugh, play LT until it starts getting a little sluggish, then attach a profiler to it. You'll be amazed at how much it thrashes memory. Some measures have been put in to improve things, but it still does way too many large allocations and deallocations each turn (and simply moving between map tiles ends the current "turn").

I think the last time I profiled java code was back in minecraft 1.3 but this seems like they are just hoping java will pick up the slack no matter how they write the code

 

[jfmherokiller]

Ehhh...
Kotlin is just a hyped attempt of 'reject modernity, embrace traditions' by functional programmers in Java world, because "OOP IS BAD, MNKAY!!!!!! FUNCTIONAL PROGRAMMING IS AN ONLY TRUE PROGRAMMING!!!!!111111". You know, same guys who still wages war against C++ and its OOP.
In any case, code quality/correctness and so on solely depends from one and only 'layer of abstraction', located between chair and keyboard. LT is a great example of it. Even with something like Rust it would be buggy crutchy sluggish mallocing mess, if it would be written in same way.

Also according to Scott Meyers, this noname block
View attachment 2052194
Kotlin currently repeats path of a C++ in Java world. Same type/kind of problems, as 'young', from around 90, C++ had.

I dont know about all that I just know giving it a chance isnt a bad idea. sometimes

 

[BobCarter]

Yep. Honestly, I can't fault that idea given that it's the dominant OS. It'd be a good way to get things off the ground at the very least.

Another option would be using GitHub Actions (or something like that) to automatically produce cross-platform builds, then just recruiting community members to test them once in a while.

I'd say producing both 32-bit and 64-bit would be best. macOS has been pure 64-bit since High Sierra (~3 years ago), and I know I'm not the only one who doesn't like using multilib in my Linux distros. Neither of those platforms would be able to run 32-bit Wine.

Got it, so just 64-bit windows then? Make a 32 bit option later or have something convert it and let the users figure out how to get it working. After all letting people rely on emulation isn't really that bad these days.

 

[Sarkath]

Got it, so just 64-bit windows then? Make a 32 bit option later or have something convert it and let the users figure out how to get it working. After all letting people rely on emulation isn't really that bad these days.

Yep! Windows x64 is a pretty safe bet these days, and considering how good Wine is nowadays everyone else has a good shot at getting it running.

I think the only people that would have an issue are people with old budget PCs.

 

[jfmherokiller]

the biggest issue i have ever had with wine is on linux mint where i have issues with some windows apps failing to regain focus. this is until i completely restart the app by either using the widow manager x or killing it via cmdline

 

[BobCarter]

the biggest issue i have ever had with wine is on linux mint where i have issues with some windows apps failing to regain focus. this is until i completely restart the app by either using the widow manager x or killing it via cmdline

That's just issues with Linux, all you need to do is go into the source code and code away your issues, maybe if your lucky you can fix it via command line.

 

[jfmherokiller]

That's just issues with Linux, all you need to do is go into the source code and code away your issues, maybe if your lucky you can fix it via command line.

well tbh the issue seems to most happen when running unity games under wine