Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (540)
Games in Android Showcase (133)
games submitted by our members
Games in WIP (603)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  mark/reset datainputsream  (Read 1503 times)
0 Members and 1 Guest are viewing this topic.
Offline Goika

Senior Newbie




Java games rock!


« Posted 2005-04-26 14:11:54 »

As many handsets do not support this functionality has anyone heard about how to get round the fact that when reading in from a datainputstream (i.e. a textfile as I am doing) most phones don't support mark/reset.

e.g. to continue to use the same inputstream by just reseting the index  but as this doesnt work the bug on the early s60 hansets means that the heap space doesnt get deallocated causing out of memory errors in my program (app. closed and kernel errors have been happening).

At the moment I have been defining new inputstreams each time which is fine for s60 midp 2.0 as the space seems to clear each time.

Anybody thought of a way round this problem?

Cheers,

Goika
Offline Abuse

JGO Knight


Medals: 15


falling into the abyss of reality


« Reply #1 - Posted 2005-04-26 15:15:30 »

Load the whole file into the heap?

Make Elite IV:Dangerous happen! Pledge your backing at KICKSTARTER here! https://dl.dropbox.com/u/54785909/EliteIVsmaller.png
Offline Goika

Senior Newbie




Java games rock!


« Reply #2 - Posted 2005-04-26 17:14:51 »

The problem is that there are many text files, some of which are quite large and cannot all be loaded into the heap at the same time. But if I am switching between the different text files all of the time instead of the heap space that the inputstream is using being freed as it is supposed to, the memory is never released. Which is causing the memory leak. Any alternatives>?
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Abuse

JGO Knight


Medals: 15


falling into the abyss of reality


« Reply #3 - Posted 2005-04-26 20:28:13 »

O_o

The heap is huge (compared to the jar size limits) on Series 60.

How big *are* these text files?

Make Elite IV:Dangerous happen! Pledge your backing at KICKSTARTER here! https://dl.dropbox.com/u/54785909/EliteIVsmaller.png
Offline Goika

Senior Newbie




Java games rock!


« Reply #4 - Posted 2005-04-27 06:37:54 »

It is the 3650 and 7650 heaps I am having trouble with the 6600 and above do not seem to get as fragmented.
My program uses the following files:

Initialisation text files:
1x12k, 20x1k

Game text files:
30x1k and under, 4x8k(these are read in and out a lot throughout the program) - these are lookups and game text.

The game is quite heavily dependent on text, but these textfiles are causing most of the problem memory-wise - but to have them loaded into memory alongside all of the unpacked class files and their variables is proving unusable.

Is there another way to access a text file without using getresourceasstream as that is the known bug in the 3650 or instead to keep the resourcestreams open and be able to reset them without re-creating them all of the time?

Offline Abuse

JGO Knight


Medals: 15


falling into the abyss of reality


« Reply #5 - Posted 2005-04-27 07:07:28 »

Thats still only 122kb of text files?

I presume some of these text files are scripts interpretted by the game?

You could compile them down to a binary format, that should reduce the heap needed to load them in by atleast a factor of 2.

Obviously you could also pack them into a single file, reduce the number of InputStreams you have to create.

Make Elite IV:Dangerous happen! Pledge your backing at KICKSTARTER here! https://dl.dropbox.com/u/54785909/EliteIVsmaller.png
Offline Goika

Senior Newbie




Java games rock!


« Reply #6 - Posted 2005-04-27 07:26:53 »



Thats still only 122kb of text files?
Yes, the trouble is that they have to be loaded into the heap continuously for them to be read - but on some phones the heap memory used is not released properly.

http://discussion.forum.nokia.com/forum/showthread.php?s=&threadid=59423&highlight=%2AApp+closed%2A

I presume some of these text files are scripts interpretted by the game?
mainly they are just text that we do not want to have in the heap memory all at the one time and also cannot have them hardcoded for the same reason and also for localisation purposes.

You could compile them down to a binary format, that should reduce the heap needed to load them in by atleast a factor of 2.

We have turned them into binary format externally by converting the .txt files using the same method as saving to an rms db (to a bytestream)- is this the correct method?

Obviously you could also pack them into a single file, reduce the number of InputStreams you have to create.
This would mean having to load the entire 122k file into memory everytime it would need to be read, meaning that the memory would be used up far more quickly as the inputstream cannot be reset each time.
Offline Abuse

JGO Knight


Medals: 15


falling into the abyss of reality


« Reply #7 - Posted 2005-04-27 16:36:01 »

lol, I work with Graham Wink

His advice is sound.

If you repeatedly load in resources, your game *will* leak memory.

Therefor logically, you must load your resources in *only once*

Having to load all 122kb of text into your heap at once is not so horrendous - there should be plenty of memory left over.

If there isn't, you need to start compromising - highlight where your most expensive assets (in terms of heap) are, and reduce/remove them.
Typically this will be images

You also need to pay attention to the order and way in which you load resources - memory fragmentation is a serious issue on early Series 60's.
Typically the best solution is to load your assets 'largest first'.

Another optimisation that you may want to look into, is keeping the txt assets in a compressed form even when in memory.

Pure text will compress down using zlib by roughly a factor of 4.
So storing your text in a compressed zlib stream in memory will save you around 60kb of heap. (taking into account the buffers needed to decompress the zlib stream efficiently)
It will obviously be slower, but no slower than streaming it from a file in a compressed jar.
The hard bit will be writing the zlib decompressor - but im sure there are many reference implementations you can 'borrow'.


Quote

cannot have them hardcoded for the same reason and also for localisation purposes.


That sounds suspiciously like coding standards, and acceptance criteria layed down by a certain publisher  Wink

Make Elite IV:Dangerous happen! Pledge your backing at KICKSTARTER here! https://dl.dropbox.com/u/54785909/EliteIVsmaller.png
Offline Goika

Senior Newbie




Java games rock!


« Reply #8 - Posted 2005-04-28 09:02:32 »

Thanks for your detailed advice. I am going to give the zlib solution a try, as long as the compressor code isnt going to be too much code, and therefore more heap.

What company do you and graham work for? you must be an experienced team to have both of you on board Smiley
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

Mr.CodeIt (24 views)
2014-12-23 03:34:11

rwatson462 (53 views)
2014-12-15 09:26:44

Mr.CodeIt (45 views)
2014-12-14 19:50:38

BurntPizza (85 views)
2014-12-09 22:41:13

BurntPizza (110 views)
2014-12-08 04:46:31

JscottyBieshaar (79 views)
2014-12-05 12:39:02

SHC (89 views)
2014-12-03 16:27:13

CopyableCougar4 (97 views)
2014-11-29 21:32:03

toopeicgaming1999 (155 views)
2014-11-26 15:22:04

toopeicgaming1999 (152 views)
2014-11-26 15:20:36
Resources for WIP games
by kpars
2014-12-18 10:26:14

Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!