You *also* need to be at least a certain cup size, D IIRC. Maybe C. But anything smaller then that is a no-go even with the nipple-cunts.Fuckable nipples.
View attachment 2050558
You *also* need to be at least a certain cup size, D IIRC. Maybe C. But anything smaller then that is a no-go even with the nipple-cunts.Fuckable nipples.
View attachment 2050558
So, we can't help you. Sorry.ok i found 2 or 3 major problems id like to address 1 weird crash issue if the game runs too long 2 if not crash it does not save 3 the lag holy crap. i sware i can run subnatica on this pc with verry little lag but this no those are my issues
8 gb ram amd ryzen 9 processor 8 core are my specs video card 2gb ddr4
Wont help, at least much.Or contact me and I'll explain how you can run the UI on a separate thread from the game logic to hide the fact that your game stalls so long that Windows thinks it crashed anytime you try and skip time on decently populated save.
Not that you'd need to do something like that if your game didn't borderline crash anytime you skip time. It won't help, but at least you won't see "Not responding!" and the screen turning grey each time you skip a day.
would converting parts of it to some jvm side language make a diffrence? something like kotlin?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*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.
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.would converting parts of it to some jvm side language make a diffrence? something like kotlin?
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.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.
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.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.
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. 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.
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.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.
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"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.
Kotlin compiles to same bytecode as java AFAIK, so it didnt change anything.would converting parts of it to some jvm side language make a diffrence? something like kotlin?
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.Kotlin compiles to same bytecode as java AFAIK, so it didnt change anything.
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.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"
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.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...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.
Should honestly be a big sign in the OP.... the only thing you can really do is try to limit the number of NPCs that exist in the world.
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 codeI 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").