Game crashes when attacking with Eclipse tome (new animation)

[ghost]

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:

Loaded res/gui/player_phase.png
Loaded res/gui/blue_flash.png
Loaded res/map_mugshots/ewan_mugshot.png
Loaded res/map_mugshots/ewan_mugshot.png
Loaded res/map_mugshots/knoll_mugshot.png
Loaded res/map_mugshots/phantom_mugshot.png
Loaded res/gui/selectArrow.png
Loaded res/gui/selectArrow.png
Loaded res/gui/x2.png
Loaded res/gui/x4.png
Loaded res/gui/trianglemod_up.png
Loaded res/gui/trianglemod_down.png
EQUIP Ewan 0 EQUIP Ewan 0 ATTACK Phantom 1 
Loaded res/map_mugshots/ewan_mugshot.png
Loaded res/battle_anim/sorcerer_magic_attack.png
Loaded res/battle_anim/sorcerer_magic_critical.png
Loaded res/battle_anim/sorcerer_magic_dodge.png
Loaded res/battle_anim/phantom_axe_attack.png
Loaded res/battle_anim/phantom_axe_critical.png
Loaded res/battle_anim/phantom_axe_dodge.png
Loaded res/gui/gui_tickFilled.png
Loaded res/gui/gui_tickEmpty.png
Loaded res/battle_anim/static/platform_plain_far.png
Loaded res/battle_anim/static/platform_plain_far.png
Loaded res/gui/gui_battleStats.png
Loaded res/battle_anim/static/plain_bg.png
PRELoaded res/battle_anim/magic_effect_null.png
PRELoaded res/battle_anim/magic_effect_null.png
PRETexture not found: res/battle_anim/hit_effect_eclipse.png
java.io.IOException: Attempt to allocate a texture to big for the current hardware
    at org.newdawn.slick.opengl.InternalTextureLoader.getTexture(InternalTextureLoader.java:392)
    at org.newdawn.slick.opengl.InternalTextureLoader.getTexture(InternalTextureLoader.java:342)
    at org.newdawn.slick.opengl.InternalTextureLoader.getTexture(InternalTextureLoader.java:288)
    at org.newdawn.slick.opengl.TextureLoader.getTexture(TextureLoader.java:64)
    at org.newdawn.slick.opengl.TextureLoader.getTexture(TextureLoader.java:24)
    at chu.engine.AnimationData.getTexture(AnimationData.java:113)
    at net.fe.FEResources.getTexture(FEResources.java:69)
    at net.fe.fightStage.FightStage.preload(FightStage.java:246)
    at net.fe.fightStage.FightStage.preload(FightStage.java:218)
    at net.fe.fightStage.FightStage.<init>(FightStage.java:211)
    at net.fe.FEMultiplayer.goToFightStage(FEMultiplayer.java:380)
    at net.fe.overworldStage.ClientOverworldStage$5.execute(ClientOverworldStage.java:521)
    at net.fe.overworldStage.ClientOverworldStage.processCommands(ClientOverworldStage.java:557)
    at net.fe.overworldStage.OverworldStage.beginStep(OverworldStage.java:263)
    at net.fe.overworldStage.ClientOverworldStage.beginStep(ClientOverworldStage.java:249)
    at net.fe.FEMultiplayer.loop(FEMultiplayer.java:327)
    at net.fe.FEMultiplayer.main(FEMultiplayer.java:101)
Exception occurred, writing to logs...
java.lang.NullPointerException
at chu.engine.anim.Animation.<init>(Animation.java:61)
at chu.engine.anim.Animation.<init>(Animation.java:112)
at net.fe.fightStage.anim.HitEffect$1.<init>(HitEffect.java:69)
at net.fe.fightStage.anim.HitEffect.<init>(HitEffect.java:69)
at net.fe.fightStage.anim.HitEffect.getEffects(HitEffect.java:176)
    at net.fe.fightStage.FightStage.processAttackQueue(FightStage.java:361)
    at net.fe.fightStage.FightStage.beginStep(FightStage.java:272)
    at net.fe.FEMultiplayer.loop(FEMultiplayer.java:327)
    at net.fe.FEMultiplayer.main(FEMultiplayer.java:101)
AL lib: (EE) alc_cleanup: 1 device not closed

[HamaIndustries]

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.

[ghost]

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.

[ghost]

I append those options after the jar's filename, right? I get an error if I append it to the java command.

java -xmx -xms -jar Fire_Emblem_Multiplayer_V2.jar or either one individually is met with: "Unrecognized option" and then proceeds to complain that it cannot create the Java VM and a fatal exception has occured.

Meanwhile something like java -jar Fire_Emblem_Multiplayer_V2.jar -xmx -xms results in the same outcome as running them without it.

[HamaIndustries]

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.

[ghost]

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

[ghost]

If ran as java -jar Fire_Emblem_Multiplayer_V2.jar -xmx2048m -xms2048m the crash still happens. If ran as the inverse: java -xmx2048m -xms2048m -jar Fire_Emblem_Multiplayer_V2.jar , then like before, it complains that I've given it an unrecognized option. Or are these options I should somehow be feeding the compiler or ant? Instructions unclear, cast Eclipse on self.

It's not my PC, it's pretty modern 5 years old with a dual-core 64-bit AMD processor, 8GB RAM (that should be plenty of memory), and a NVIDIA GeForce 6150SE graphics chipset (1GB shared vidmem - i.e. 1GB of RAM is reserved and treated as video memory). Check the code, maybe it's handling the animation bad because like I said before, I'm running a build I compiled from Master this morning, this crash did NOT exist in v1.3. What changes were made to the Eclipse tome between then and now both in code and / or graphics? Or do I need to issue a special option / command during compiling?

[HamaIndustries]

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.

[ghost]

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 javac or ant that I don't know about, as I'm only familiar with Make? Cause, no offense, if 8GB of RAM isn't enough, then the code either is horribly inefficient or causing a memory leak and the anim shouldn't be crucified.

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 javac compile option that no one taught me - as this is the first java project worked with, meaning I have no past java experience; so compile options and such one might take for granted, I'm oblivious to.

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?

I'm going to substitute the image with hit_effect_eclipse_old.png and see if that fixes it. We may just have to roll it back to what it was. Nevermind, I can't do that cause the way frames are actually being called is hardcoded and it'd catch fire when it begins to call frames that are nonexistent in the old png. Rollback to the old animation I suppose.

[rayrobdod]

But using hit_effect_eclipse_old.png didn't cause the program to crash, right?

[ghost]

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 hit_effect_eclipse_old.png is identical to v1.3's hit_effect_eclipse.png and v1.3 doesn't exhibit this bug.

[rayrobdod]

You underestimate the insanity and/or genius that went into lwjgl. Hotswapping hit_effect_eclipse_old.png and hit_effect_eclipse.png worked on my machine; It looked weird, but it was just that, graphical weirdness. Nothing mechanical broke.

[ghost]

Should I attempt this then?

[rayrobdod]

Yes?

[ghost]

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?

[HamaIndustries]

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:

use the combining script to make those frames into a square, see what happens.

[ghost]

its not memory addresses that's silly. it looks weird because you're using different frame/column sizes,

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.

[rayrobdod]

This part of a LWJGL tutorial says something interesting:

You can query the maximum texture width and height with the following: … Generally, most modern computers allow for at least 4096x4096 textures, but if you want to be really safe, you can limit yourself to 2048x2048. If you think you will be working with old or limiting drivers (or Android, iOS, WebGL), you may want to limit yourself to 1024x1024.

Anyway, the new eclipse animation as currently laid out is 1200×8640, which is larger than 4096 in height. √(1200×8640)=3220, so it should be possible to rearrange the animation so that it fits in a 4096x4096 square.

[HamaIndustries]

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

[ghost]

Both ideas sound like a plan to me.

[ghost]

This part of a LWJGL tutorial says something interesting:

You can query the maximum texture width and height with the following: … Generally, most modern computers allow for at least 4096x4096 textures, but if you want to be really safe, you can limit yourself to 2048x2048. If you think you will be working with old or limiting drivers (or Android, iOS, WebGL), you may want to limit yourself to 1024x1024.

Anyway, the new eclipse animation as currently laid out is 1200×8640, which is larger than 4096 in height. √(1200×8640)=3220, so it should be possible to rearrange the animation so that it fits in a 4096x4096 square.

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 both its current state, as well as the new proposed size EDIT: Didn't initially notice you saying the sheet itself will be a PoT) is not a PoT. (Emphasis added by me to highlight key points)

One thing I have yet to note is the use of power-of-two (POT) dimensions. Historically, OpenGL only allowed POT texture dimensions: 1, 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024, 2048, 4096... etc

Today, however, most drivers will support non-power-of-two (NPOT) texture sizes. You can check to see if your user supports NPOT textures with the following code:

boolean npotSupported = GLContext.getCapabilities().GL_ARB_texture_non_power_of_two;

It should be noted that even if the driver does support NPOT textures, it's generally still advisable to stick to POT sizes as it will often lead to better performance and storage. At a later point, this tutorial may include a segment on padding NPOT textures to a power-of-two size, for drivers that don't support NPOT textures.

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.

[HamaIndustries]

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.

[ghost]

We can't scale them without graphical anomalies

I fully understand that.

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.

Are you positive about this?

[HamaIndustries]

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.