Collectible Card Game Headquarters

Why does the game seemingly come to a halt the longer the game goes on? It cant be the amount of cards on the board because after a board wipe or similar there is no improvement in performance. Is there a way to resolve this? Allocate more resources to the game? Is this a Java limitation? I should have no issues running this on an 8th gen i7 with 16GB of ram.

Treebeardz wrote:Why does the game seemingly come to a halt the longer the game goes on? It cant be the amount of cards on the board because after a board wipe or similar there is no improvement in performance. Is there a way to resolve this? Allocate more resources to the game? Is this a Java limitation? I should have no issues running this on an 8th gen i7 with 16GB of ram.

I thought that this happened just in the Android version because mobile phones are not so powerful. With that PC you should run the game very well. I notice that some specific cards like Fires of Invention slow down the game a lot. In games against scapeshift or decks that puts lots of creature in the battlefield this also happens. Maybe is the amount of cards. I don't know.

There is a longstanding issue with garbage collection in Forge. More memory is used over time until the available heap space runs out.

It also slows down not just after long games, but if you play lots of games it can slow down too. I quite often have to restart Forge when I'm playtesting decks

Has this been addressed by the developers? Have said they are choosing not to fix it or if it cant be fixed?

I'm guessing its not been officially addressed by the devs based on the lack of response. My next questions is has anyone not had this issue where the performance stays the same during a very long game?

Treebeardz wrote:Has this been addressed by the developers? Have said they are choosing not to fix it or if it cant be fixed?

As a programmer, I would say that memory leaks are not always easy to find and fix. In general, you don't get an error message saying, "blah.java, line 14: memory leak". You just tend to get increasing memory usage. And undesired behavior that follows. Yes, coders generally try to catch memory leaks and fix them but finding them is not always trivial. Ask Microsoft guys - more than one Windows release has contained notable memory leak issues. Among other things.

Forge developers do their coding in their freetime, with no pay. Given the choice between implementing interesting new features and game mechanices or spending long hours trying to nail an elusive memory leak (with no guarantee of success), I know which task I would take...

I have some similar issues while playing this game in my phone. I dont know because by phone is not very powerful to support it or there is a problem with the game itself. anyone playing on android phones ?

It's been a long time but maybe for those with lots of ram this can still work to help play longer before everything slow down too much :
viewtopic.php?f=26&t=22756#p227726

I've been using the command line option to increase the max memory for a while to get around the issue. But recently I've noticed that even with that option, the game starts to slow down noticeably after 2-3 consecutive games.

Maybe some new functionality or recent refactoring has introduced a new memory leak?

Glad I came back and checked this out. I did have an issue running the command however. Finally fixed it after I removed the 32bit version of Java and installed the 64bit. I will report back how my performance was effected.

Also, memory footprint of each scan/card image has to be considered!

When I used XLHQs, I could either play a few matches (5-7) OR do a new draft, maybe play 2-3 draft pool AIs, before Forge always quit on me (talking Android here, but as Timmermac said above, it seems to be a Forge issue).

I didn't really attribute this to the scans before, thinking:"Well, it's still Alpha" (again, Android) until I got reminded once more by something in my image viewers file info on an XLHQ scan.
(I knew of this, since Photoshop shows this info as well, never really needed that info for work before )

An XLHQ .jpg-file, with a resolution of 745x1040 at 24bit colordepth, while e.g. being only 300kbyte in filesize, uses a memory size of ~2271kbytes or ~2.2mbyte. Per scan.

It seems that Forge starts with 1Gbyte of memory allocation. With that number above in mind, a conservative playing field, mid- to late game, might consist of at least 15 lands on each side, maybe 10 creatures each, up to 5 non land/creature permanents each. Even without throwing in some tokens, or knowing if Forge can use the same image data for multiple instances of the same scan (e.g. lands), ~13% of allocated memory is gone at that point

Now add other sections of displayed cards, like your hand, scrolling through your and your opponents graveyard, etc.
If unused image data isn't properly unloaded from memory, you might add those as well..
..and you can easily approach 20% and more.
For this match
(Not sure if and how image memory is wiped between matches)

In short: Keep the scans memory footprint as low as possible! Forge will run much longer!!

I'm testing 352x491 pngs with a 160 colors palette or "8bit colordepth" and memory footprint is at 0.165mbyte per image. That's just 7.5 percent of an XLHQ image.
Filesize isn't really important here, memory size is.
I'll add an example PNG at the end.
(For example, I think they are still too big for smartphone displays in the ~5.2" range, when zoomed while playing in landscape layout.)

I can now draft, edit, play all 7 AIs, draft again, edit, play 2-3 matches and Forge still runs, without any noticable slowdown

Maybe it'll help you as well!
K.

Well, I know a lot of games with slow performance. And I think, this is the reason it's slow.

CptKird wrote:[...]

This is very interesting CptKird !

With batch conversion from irfanview and riot, i have experimented with this and my cards picture folder and found out that all my cards (that i had height 450 pixels) the difference between JPG and 8bitsPNG was that :
- the 8bits PNG size on disk is +/- 1.5 or 2 times bigger than the JPG
- the 8bits PNG size in memory is +/- 3.5 or 4 times smaller !! than the JPG

And with the various memory leaks that may be affecting Forge, it's a real must to have small memory footprint for the cards considering how many there are.


I then did an experience.
- Launched Forge
- Go to Deck Editor , click on the down slider and drag the to the middle (it will be laggy and jumpy until it goes to the middle) of the deck list
- Check the memory used by Java/Forge
- Do 1 round of a match (me and cpu playing the Eldrazi vs Zendikar duel deck, me using the Zendikar deck)
- Once round is ended, go to Deck Editor and do the same "dragging slider to the middle"
- Do another 1 round of the same match
- Once round is ended, go to Deck Editor and do the same "dragging slider to the middle"

Results for my cards having 450 pixels of height and being all in JPG
* first check Forge is eating 660 mb
* second check Forge is eating 790 mb
* third check Forge is eating 880 mb

Results for my cards having 450 pixels of height and being all in 8bits PNG
* first check Forge is eating 550 mb
* second check Forge is eating 690 mb
* third check Forge is eating 775 mb

Conclusion : there's indeed a nasty memory leak of at least +/-100mb by round (not match) played that is pilling up (and may be more probably if you play with certain effects-tricks heavy decks)

Having cards in 8bits PNG (not 24bits PNG as it's worse than JPG in memory use) despite being bigger on the disk allow for +/- 100mb by round played of memory saved, at least on my Forge (it's been a while i haven't updated as i'm still using 1.6.23 , i imagine the leak may be worse on current version as there's more card effects and checks that have been added since) with the card size i use.

But i really hope someone will figure out one day how to kill that memory leak

EDIT : the memory leak is not new at all unfortunately, i found in my archive an old version of Forge ( 1.5.14 ) and did my test.
It appears that it was memory leaking +/- 50mb by rounds pilling up already from my test.

I was experiencing poor performance on version 1.6.33 in a 16Gb Linux machine, but changing the start up script did the job. Here it is my forge.sh:

Code: Select all

#!/bin/sh
cd $(dirname "${0}")
java -Xmx4096m -Dsun.java2d.opengl=true -Dfile.encoding=UTF-8 -jar forge-gui-desktop-1.6.33-jar-with-dependencies.jar