New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Game crashes when attacking with Eclipse tome (new animation) #66
Comments
x86 is for the lowmem branch. it looks like you're using too low settings for memory, try launching with higher memory available via the -xmx and -xms commands. |
I used whatever it defaults to. Not even sure if what it compiles is either x86 or x64 since no one told me how to specify what architecture I want when compiling, or if it just defaults to my native architecture, which is x64. This was from testing the latest code from Master when compiled and built. Both editions of v1.3 run just fine. It's just the latest code from Master that's crashing. |
I append those options after the jar's filename, right? I get an error if I append it to the java command.
Meanwhile something like |
no, like -Xmx2048m and -xms2048m, sorry. If it doesn't work, I'll need to ask cardalilyn to trim down the anim. It will prolly need to be done anyways since I don't think it will be very fun telling everyone to launch with higher settings, and it won't work at all on machines with low memory in general. |
Before or after the filename? Going to test. Meanwhile, why did I not need these when running v1.3? Was there an option I forgot to issue during compile? I used the Master branch |
If ran as It's not my PC, it's |
it's working perfectly for me, but then again I have massive RAM and an ssd. I'll make a request to cardalilyn aboout trimming down the anim, if you would kindly refrain from using eclipse, for now. |
Question: Why didn't the anim trigger this in the last official release? I think we're blaming the wrong thing. Are you sure there's nothing special I need to instruct to Speaking of the animation, I'm going to compare the png files to see if they're even different, if they're identical, then it's definitely the code - or there's a UPDATE: So the animation I noticed has changed since v1.3. The file size only increased by 100kb but the size of the sprite sheet is MUCH physically larger. I think the physical size, not the file size, might be the issue somehow idk - perhaps buffering it wrong and accessing parts of RAM it shouldn't?
|
But using |
I was going to try swapping the image until I realized that animation frame calls are probably hardcoded, and it'd ultimately start calling nonexistent frames and catch fire. So I can't simply rename the file and test to my knowledge in order to confirm my theory. What I will say is that |
You underestimate the insanity and/or genius that went into lwjgl. Hotswapping |
Should I attempt this then? |
Yes? |
Sorry for the late reply, was performing other tests with it. Hotswapping the image prevents the crash, but like you pointed out, there's weirdness. The filesize, byte wise isn't much different, only about 100kb difference, so is it the physical size of the sheet that's causing it to crash, and why when I got so much memory? Or is it somehow spilling into memory addresses that it shouldn't? |
its not memory addresses that's silly. it looks weird because you're using different frame/column sizes, which can be edited to what they were before provided that if you just look for it in resources.json. I'm putting this here to remind myself:
|
I meant for why it crashes with the new png that's really huge length-wise. Not why it acts weird with the old one. With 8GB RAM, 1 of which being shared as video memory, I doubt it's due to insufficient memory unless the game is causing a memory leak. |
This part of a LWJGL tutorial says something interesting:
Anyway, the new eclipse animation as currently laid out is 1200×8640, which is larger than 4096 in height. |
o, ha. I guess I'll do that. btw ray, have you seen the frame combining script I added? It should make our lives a lot easier for putting sheets together |
Both ideas sound like a plan to me. |
Wow, that's really insightful @rayrobdod . Cause of that link and article, I decided to search for a way to determine my PC's maximum supported texture size, and was able to find this The results of the test are that my PC only supports up to OpenGL 2.1 with a maximum texture size of 4096x4096. Meaning that the texture is just simply too big for the average end-user PC. Also, like the article says, "Power of Two" is a thing, and the offending texture (under
That being said, we can improve the performance and efficiency of FEMP if we go ahead and make all the spritesheets a POT in size, which so far, almost none are. |
That's because the dimensions of most frames are not multiples of a PoT. We can't scale them without graphical anomalies, and anyways, getting sheets to a PoT is really only good for retrieving static images from a single sprite sheet, and would likely not very much impact performance. I will, however, remember to get sheets to as close to 1024 as possible from now on. I've already finished the new sheet, so after some testing & messing with blending I'll close this. |
I fully understand that.
Are you positive about this? |
I'm 90% sure it wouldn't matter, but if someone else feels it's worth the effort, I'm not going to stop them. |
Issue type:
problem
Description:
Game crashes when using the Eclipse tome to attack. This is with the most recent code. Eclipse works fine on v1.3 (both x86 and x64) so this must be due to a recent change. (EDIT: Said change has been revealed to be the new animation. Most likely due to it's physical, not file, size)
P.S.: When compiling and building from the latest source, no one told me if there's argument I need to use in order to generate the x64 version, so I could very well be running the x86 version unknowingly. Please advise.
Relevant Portion of Terminal Output / Error Log:
The text was updated successfully, but these errors were encountered: