Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (539)
Games in Android Showcase (132)
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   
  Show Posts
Pages: [1]
1  Java Game APIs & Engines / J2ME / P800 sound on: 2005-05-11 10:32:48
Does anyone know if a p800 midlet can play sound and if it supports MMAPI?

I have tried using the following code to play an amr but when trying it on the phone it exits when attempting to play it?

Player player = null;
try {
player = Manager.createPlayer(this.getClass().getResourceAsStream("/sound.amr"),"audio/amr");
player.prefetch();        
} catch (Exception e0) {}
try {
player.start();
}catch (Exception e5) {}
try {
player.stop();
}catch (Exception e5) {}
2  Java Game APIs & Engines / J2ME / Re: mark/reset datainputsream on: 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
3  Java Game APIs & Engines / J2ME / Re: mark/reset datainputsream on: 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.
4  Java Game APIs & Engines / J2ME / Re: mark/reset datainputsream on: 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?

5  Java Game APIs & Engines / J2ME / Re: mark/reset datainputsream on: 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>?
6  Java Game APIs & Engines / J2ME / mark/reset datainputsream on: 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
7  Java Game APIs & Engines / J2ME / Queued-up keypresses on: 2005-04-08 13:32:14
Can anyone advise on the best way to prevent keypresses from being executed whilst switching between canvases, I am finding that when processing occurs between when the user switches to another canvas that if the double keypress a softkey for example by acciddent that keypress is carried out onto the the next canvas once it has been displayed - as if it has been queued up. Obviously this is not valid on the switched to canvas and causes an error.

I am finding this mainly on the 6600 which is dreadfully slow, on other phones i.e. n-gage, 7650 I do not find this problem as the VM seems to process the switching far quicker and doesn't cause a problem.

Is it best to use a thread, timer or another method (for instance can all keypresses be ignored or cleared by a line of code?) to avoid this as it is causing major errors in my program and is very annoying indeed! If you could share your experiences with these types of issues it would be of great assistance,

Cheers,

Goika
8  Java Game APIs & Engines / J2ME / Re: Strange Canvas repaint problem on: 2005-02-24 06:37:35
Just had to call a dummy keypress right after the setcurrent is called for the next canvas, and in that canvas's keypress function it is caught and forces another repaint().
9  Java Game APIs & Engines / J2ME / Strange Canvas repaint problem on: 2005-02-16 07:04:09
Has anyone ever experienced a problem with getting the P800 canvas to repaint automatically when switching between canvases (when using display.setcurrrent(myCanvas);)? Instead of repainting properly the screen just goes white until you 'force' the canvas to repaint by sending a keypress. If you have not directly experienced this problem can you offer any suggestions of what might be the problem?
SE Forum
http://developer.sonyericsson.com/show_thread.do?forumId=10&searchBy=MSGTHREAD_IS_STICKY_FL&searchValue=N&searchBy2=MSG_PARENT_ID&searchValue2=-1&searchBy3=MSGFORUM_FORUMID&searchValue3=10&searchBy4=MSGTHREAD_IS_STICKY_FL&searchValue4=N&ps=50&threadid=15318&sortDirection=0&sortCol=MSG_AUDIT_MOD_DT&forumId=10&readOnly=false
KVM Archive:
http://archives.java.sun.com/cgi-bin/wa?A2=ind0212&L=kvm-interest&P=R7716&D=0&I=-3

I thought I would try on this forum to see if anyone has any suggestions as it is unlikely it will be replied to over at the se forum.
10  Java Game APIs & Engines / J2ME / Re: P800/P900 on: 2005-01-31 06:40:02
Thanks for the reply once more.

I meant  that there is an area of the screen which the user cannot see because of the virtual keypad on top of it.

This area has commands etc that the user would require to see, and the screen doesnt automatically resize to suite whether the virtual keypad is hidden or not.

I assumed that applications have to resize themselves to suit whether the keypad is there or not?


By Industry testing I would probably mean being satisfactory to pass uk Babel Testing for getting it vodafone approved?
11  Java Game APIs & Engines / J2ME / P800/P900 on: 2005-01-28 06:29:03
For the P900 Is it possible to specifically say in the midlet that the virtual keypad will be disabled by default, without having to get the user to hide it manually?

Is there no way for the user to manually hide the flip for a P800? - (this is a really annoying missing feature!)

Finally if my midlet will only be fully functional once the autokeypad has been hidden, will this get past industry testing? i.e. even if the user can still perform every function of the application with the jog wheel and touchpen by detecting my own penpresses and not the users presses on the virtual keypad?

As a side not does anyone know why the commands do not appear on forms for the P800/P900 emulators?
12  Java Game APIs & Engines / J2ME / Binary Data Files on: 2005-01-26 10:28:59
In my application I have begun to use data files as resources in order to read in the game specific data that I need for the app. My question is - is my java code converting the textfiles of data into the correct format as I have ten different .txt files which I convert into binary format but once this is done each of the ten converted data files are slightly bigger than each of the  equivelant .txt files. I realise that the reading in of the data in this format is quicker for the j2me app and that it is better to have all your game data into these data files for localisation and for heap memory etc but I also assumed that the actual size of a converted data file would be smaller than the .txt file it had been converted from?

Is this correct and am I converting the txt files in the correct manner i.e. (I am requiring the text files to be in UTF 8 format):

//Main idea of how the .txt files are being converted

ByteArrayOutputStream bout = new ByteArrayOutputStream();
     
                 DataOutputStream      dout = new DataOutputStream( bout   );

dout.writeUTF(buffer);

dout.writeInt( Integer.parseInt(buffer) );

dout.flush();

bout.reset();

dout.close();


Thanks for any valuable advice
13  Java Game APIs & Engines / J2ME / Re: P800 & J2ME on: 2005-01-24 13:30:04
Thanks shmoove,

your medal is on it's way.

208x172 is measly for me being used to 176x208 minimum!

Is it possible to rotate the origin when painting onto a canvas in the same way that you can translate it to be a different location on the screen? That way I could use the screen width(208) as the height and that would solve a lot of my problems apart from the keypad being on the right-handside of the screen.

14  Java Game APIs & Engines / J2ME / P800 & J2ME on: 2005-01-24 12:23:50
I am starting to port my series 60 based application to other handsets and at the moment the newer sony ericssons e.g. k700, P900 etc seem to be not too bad for porting.
However I am trying to do the same for the P800 and there is the problem of when using canvases that a virtual keypad is visible all of the time to catch specific events - up,down,left,right,fire and also green, pink, yellow and blue buttons (which I cannot get the specific keycodes for - does anyone know of them as I use -6,-7 for the green crossand red tick which work on the emmulator?) and I have discovered that this cannot be removed as it is standard for midp 1.0 on this handset. Does anyone know of a way around this or at least to get more drawing height on the canvas as it only allows access to 208x172 with this keypad. Can you remove any of the status/menu bars or set a different clipping area to paint over certain areas of the screen to get more space or is it just impossible?

If there are no ways around this as above I was thinking that the main problem is that I can't use the setfullscreen(true) line as it is MIDP 2.0 specific, but I have heard that MIDP 1.0 phones can get access to MIDP 2.0 specific features by being built with j2mepolish, does anyone know if this is possible and if it would solve my problem by being able to set this to true and gain more space or to at least hide the virtual keypad that just won't go away?

Many thanks for your valued responses.
15  Java Game APIs & Engines / J2ME / Phone specific bugs on: 2004-11-26 08:16:33
Hello I have an application and have finished a version for the series 60 platform.
To take the project forward and make it as lucrative to a publisher as possible I am trying to come up with a list of phones that we can try and port the game to so that I can show a large list of phones that it will work on.

App specs are 155k jar size, MIDP 1.0 and above, RMS size 90k, heap 1Mb,FullCanvas, Uses Nokia UI API but - could be changed to work with fairly easily, min screen - 176*208, it is a game that would prob be aimed at the uk market at first and we have coded it in the 5 main languages EPIGS.

Any suggestions of phones I should look into supporting would be brilliant. I have included the 6600 with the dodgy firmware version that crashes upon switching between canvases - which have not found a proper resolution to yet!


So firstly are there any serious bugs that could be expected from any of the 14 series 60 Nokia models or from the sendo x or siemens sx-1?

Which SE phones would have little or no trouble porting to from past experiences - and is implementing touch-screen a big issue for the P800 etc
Are there any other models that would be worthwhile trying to port to that wouldnt cause too much trouble and are/will be popular?


Finally what is a reasonable number of phones that I should approach a publisher with as I do not want to be committed to too many - but I can also see from the pub's point of view that they will require a lot of phones espec if the app isn't supported on anything lower than the series 60 platform.

Many thanks, any of your comments would be of a real help to me.
16  Java Game APIs & Engines / J2ME / Re: Cpu speed required on: 2004-11-23 06:55:28
I have came across http://www.futuremark.com/download/?spmark04.shtml  that will help give the benchmarks for smartphones, but I guess this will be of no use for testing how fast the phone's kvm might be. Looks like I will have to try and buy/borrow a lot of phones then!

17  Java Game APIs & Engines / J2ME / Re: Cpu speed required on: 2004-11-22 13:06:26
So the only way to do this would be test it on each individual phone to see how it runs ( I have heard the T610's virtual machine is really slow and a lot of games developers swerve this phone?) or is there somewhere that i can find out the kvm speeds, I have looke at jbenchmark.com but i don't know exactly what I should be looking for?
18  Java Game APIs & Engines / J2ME / Cpu speed required on: 2004-11-22 09:09:31
I am trying to compile a list of possible phones which my j2me application will run on(or should run on!) and have the jar sizes, heap memory etc. Can anyone give me some advice on how to best find out the minimum cpu speed that a phone would require to run my app as this is the final parameter that I require to finish my list of compatible phones?

Many thanks
19  Java Game APIs & Engines / J2ME / Re: Nokia API on Ericcson? on: 2004-11-18 08:50:41
Hello,

I am using the Sony Ericsson 2.1.4 SDK and am trying to convert one of my java applications which uses the Nokia UI API so that it will run on the F500i, K700, and Z1010 emulators(which now have the UI API included). The project compiles and builds fine but cannot find the com/nokia/mid/ui/FullCanvas.


Has anyone managed to get this API working on an emulator as it would be great to know if my app would work on these phones in a real-life situation, and I cannot get access to one of these phones.


Many thanks for any help provided.
Pages: [1]
 

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

The first screenshot will be displayed as a thumbnail.

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

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

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

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

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

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

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

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

toopeicgaming1999 (122 views)
2014-11-26 15:20:36

toopeicgaming1999 (34 views)
2014-11-26 15:20:08
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!