Archief - [PROG][J2ME] Beperkingen

Hallo,

Met een groepje ben ik bezig om een soort van framework te bouwen om spelletjes te maken in java. Nu moet ik op mijn stage wsl een spelletje maken in j2me en ik vroeg mezelf af wat de beperkingen zijn op een mobiel toestel qua floating points, threads, geheugencapaciteit, rekensnelheid, tekensnelheid e.d.
Als het mogelijk zou zijn maak ik een mini framework om makkelijk te tekenen en makkelijk collisie toe te passen. Kan iemand mij vertellen of dat mogelijk is, dan heb ik altijd een librarie met delen code die ik niet gebruik, ik weet niet of dit nadelig is.

Groeten!!

Waarom zou je met threads willen werken op een singlecore embedded platform voor een game?
Ik kan me voorstellen dat je je game logic niet zo vaak wil updaten als dat je frames rendert, maar dat kan je met een normale update-loop ook oplossen. Ik zie verder geen enkel nut voor threads(enkel problemen zoals debuggen en mogelijke problemen met bepaalde platformen die dit niet goed ondersteunen)?

threads kunnen toch goe zijn voor multiplayer spellekes
dat em nie moe wachten tot als em gegevens van 1 speler binnenkrijgt voor em de gegevens van de andere speler kan verwerken.
of peizek da gewoon

schop aars zei:

threads kunnen toch goe zijn voor multiplayer spellekes
dat em nie moe wachten tot als em gegevens van 1 speler binnenkrijgt voor em de gegevens van de andere speler kan verwerken.
of peizek da gewoon

Klik om te vergroten...

Dat klopt, voor multiplayer kan dat handig zijn als je gegevens asynchroon binnenkomen, maar als ik aan portable j2me games denk, dan denk ik niet aan multiplayer.
Sowieso denk ik bij een gameframework niet aan netwerk code, das een project op zich(en collision detection ook eigenlijk, tenzij het heel simpel wordt gehouden).

Is gewoon maar om te weten of het mogelijk is
Ik heb het niet over threads alleen. Bij geluidjes afspelen kunt ge toch goed gebruik maken van threads.
We gaan idd ook nog netwerk in ons framework proberen implementeren, alhoewel dat dat veel en moeilijk gaat worden. Dat van die collisie, ik heb er 3 soorten collisie in gestoken en een nieuwe bijvoegen gaat héél makkelijk, dat is toch wat de bedoeling. Een uitbreidbare kern.

http://sourceforge.net/projects/binge/

jodeman zei:

Is gewoon maar om te weten of het mogelijk is
Ik heb het niet over threads alleen. Bij geluidjes afspelen kunt ge toch goed gebruik maken van threads.
We gaan idd ook nog netwerk in ons framework proberen implementeren, alhoewel dat dat veel en moeilijk gaat worden. Dat van die collisie, ik heb er 3 soorten collisie in gestoken en een nieuwe bijvoegen gaat héél makkelijk, dat is toch wat de bedoeling. Een uitbreidbare kern.

http://sourceforge.net/projects/binge/

Klik om te vergroten...

Een paar tips:
- Splits de netwerkcode, de collisiedetectiecode, gamecode en rasterizer code duidelijk af in je framework (dmv een namespace bijvoorbeeld, waar je dan je klassen onder kan brengen).
- Gebruik SVN met TortoiseSVN in plaats van CVS op SF.net, dat is een pak gebruiksvriendelijker (imo).

[edit] ps: mooi hee, dat SF.net ik ben erg blij dat ze de interface een paar maanden geleden vernieuwd hebben. Alleen jammer dat de SVN/CVS servers zo traag zijn. Maar jah... het is en blijft een gratis dienst natuurlijk.

Hallo,

Standaard bieden J2ME toestellen geen ondersteuning voor floating points, dus er is geen float of double beschikbaar. Hiervoor bestaan er wel libraries die floating points simuleren. Eén van deze libraries is MathFP.

Het gebruik van Threads wordt wel ondersteund en kan gebruikt worden zoals in J2SE.

De overige onderwerpen geheugencapaciteit, rekensnelheid, tekensnelheid zijn sterk toestel afhankelijk. Algemeen vallen de prestaties mee, zeker voor de nieuwere telefoons. Je kan dus zonder problemen je eigen mini-framework maken voor J2ME toestellen.

In verband met het gebruik van Threads wens ik toch nog bij te vermelden dat dit de standaard manier is van werken, ook voor J2ME toestellen.

Groeten

MemberX zei:

Hallo,

Standaard bieden J2ME toestellen geen ondersteuning voor floating points, dus er is geen float of double beschikbaar. Hiervoor bestaan er wel libraries die floating points simuleren. Eén van deze libraries is MathFP.

Klik om te vergroten...

Fixed point dus! De Nintendo DS werkt daar ook mee en das best k*t.

In verband met het gebruik van Threads wens ik toch nog bij te vermelden dat dit de standaard manier is van werken, ook voor J2ME toestellen.

Klik om te vergroten...

Bij games maken in't algemeen is dat echt niet de standaard manier van werken, omdat het software onnodig complex maakt, een stuk moeilijker is om te debuggen en vaak random behavior oproept ivm multithread problemen op het platform waar je op werkt. Als je dan de pech hebt dat telefoontype X een slechte j2me implementatie heeft dan kan je als ontwikkelaar niet gaan debuggen tenzij je dus die telefoon in je bezit hebt?

Vich zei:

ps: mooi hee, dat SF.net ik ben erg blij dat ze de interface een paar maanden geleden vernieuwd hebben. Alleen jammer dat de SVN/CVS servers zo traag zijn. Maar jah... het is en blijft een gratis dienst natuurlijk.

Klik om te vergroten...

Je kan hen uiteraard steeds sponsoren hé, via een subscription op hun service vb. (doe dat zelf ondertussen al sedert 2004 - dat is mij wel 39 USD/jaar waard).

dJeez zei:

Je kan hen uiteraard steeds sponsoren hé, via een subscription op hun service vb. (doe dat zelf ondertussen al sedert 2004 - dat is mij wel 39 USD/jaar waard).

Klik om te vergroten...

Krijg je dan een snellere SVN access?

Ik zie wel dit staan:

* Realtime Statistics
* Direct Downloads
* Priority Technical Support
* Project Monitoring

Klik om te vergroten...

Bedoelen ze met "Direct Downloads" ook SVN access?

Fixed point dus! De Nintendo DS werkt daar ook mee en das best k*t.

Klik om te vergroten...

Gebruik zeker een J2ME floating point library omdat je anders problemen zal krijgen met afrondingen. Dit is de beste oplossing.

In de documentatie die ik gelezen heb over het ontwikkelen van J2ME games worden steeds Threads gebruikt. Dit is misschien niet de standaard manier van werken voor c++ games, maar voor Java wordt het vaak gebruikt en zou ik het zelfs een standaard durven noemen (zeker op het J2SE platform).
Met een goede IDE (Eclipse, Netbeans, ...) valt het debuggen van applicaties die gebruik maken van Threads zeker mee.

Persoonlijk raad ik het gebruik van Threads dus wel aan. Waarom? Je maakt los van de hoofd applicatie Thread een andere Thread aan, hier regel je al uw logica en spel gerelateerde zaken. Deze Thread laat je uitvoeren, bijvoorbeeld 50 keer per seconde. De overige tijd laat je de Thread "slapen" met de Thread.sleep methode. Wanneer uw Thread slaapt of inactief is kan de applicatie Thread verder zijn ding doen. Bijvoorbeeld resources opkuisen enz.
Indien je dus geen Threads zou gebruiken en je wenst een framerate te krijgen van 50, dan moet je eigenlijk de applicatie Thread laten slapen. Dit zou volgens mij veel slechtere gevolgen hebben (bijvoorbeeld wanneer er op dat moment iemand belt) dan wanneer je Threads wel gebruikt.

Als je dan de pech hebt dat telefoontype X een slechte j2me implementatie heeft dan kan je als ontwikkelaar niet gaan debuggen tenzij je dus die telefoon in je bezit hebt?

Klik om te vergroten...

Neem bijvoorbeel Motorola, zij hebben één emulator voor al hun mobiele toestellen. Deze emulator kan dus nooit het echte apparaat volledig benaderen.
Een gouden regel, als je wenst te weten of uw applciatie werkt op een toestel, gebruik het toestel zelf en geen emulator. Uiteraard kan een emulator helpen bij de eerste testen.

Groeten

Vich zei:

Krijg je dan een snellere SVN access?

Klik om te vergroten...

Geen idee eigenlijk, maar ik denk het niet.

Vich zei:

Bedoelen ze met "Direct Downloads" ook SVN access?

Klik om te vergroten...

Neen, daarmee doelen ze op het feit dat je geen x aantal keer moet doorklikken om iets te downloaden, maar dat rechtstreeks kan doen vanop de Downloads pagina. Maar sedert de redesign is die optie weg dacht ik... ofwel kijk ik er gewoon over.

Wat ik persoonlijk heel nuttig vind is de project monitoring. Die is heel handig om automatisch op de hoogte gehouden te worden van updates ed meer van je favoriete projecten (zeker als die geen mailing list hebben ).

MemberX zei:

Gebruik zeker een J2ME floating point library omdat je anders problemen zal krijgen met afrondingen. Dit is de beste oplossing.

Klik om te vergroten...

Ik heb m'n eigen fixed point templates in C++ Dat platform heeft geen Java.
Ik gok dat die floating point library voor J2ME intern ook gewoon met fixed point werkt? (tzou erg traag werken als floating points ook echt als floating points intern worden behandeld, omdat deze dan moeten geemuleerd worden, omdat er vaak geen CPU support voor is)

In de documentatie die ik gelezen heb over het ontwikkelen van J2ME games worden steeds Threads gebruikt. Dit is misschien niet de standaard manier van werken voor c++ games, maar voor Java wordt het vaak gebruikt en zou ik het zelfs een standaard durven noemen (zeker op het J2SE platform).

Klik om te vergroten...

Op J2SE kan ik het me voorstellen, omdat je dan in een desktopomgeving bent die er ook nog eens nuttig gebruik van kan maken. Op een J2ME platform vind ik het nutteloos omdat het platform het niet ondersteunt, het moeilijk te debuggen is(omdat je geen "devkit" van elk gsm toestel om te testen wat er fout gaat als er iets fout gaat) en het te vermijden is door je programma goed te designen.

Met een goede IDE (Eclipse, Netbeans, ...) valt het debuggen van applicaties die gebruik maken van Threads zeker mee.

Klik om te vergroten...

Het lijkt mij sterk dat jij realtime die telefoons kan debuggen met die IDE's(en dan heb ik het niet over emulators maar over de toestellen zelf)?

Persoonlijk raad ik het gebruik van Threads dus wel aan. Waarom? Je maakt los van de hoofd applicatie Thread een andere Thread aan, hier regel je al uw logica en spel gerelateerde zaken. Deze Thread laat je uitvoeren, bijvoorbeeld 50 keer per seconde. De overige tijd laat je de Thread "slapen" met de Thread.sleep methode. Wanneer uw Thread slaapt of inactief is kan de applicatie Thread verder zijn ding doen.

Klik om te vergroten...

Waarom zou je je program logic of render logic willen laten slapen? Je wil toch altijd iets renderen en je logic doet toch altijd iets (menu/game update). Afhankelijk van je menu of game kan je gewoon een andere logic module als actief aanwijzen en die gaan updaten.

Bijvoorbeeld resources opkuisen enz.

Klik om te vergroten...

Resources opkuisen hoeft toch niet in een thread, dat kan toch gewoon realtime? Sowieso is resources opkuisen iets wat meestal erg snel gaat.

Indien je dus geen Threads zou gebruiken en je wenst een framerate te krijgen van 50, dan moet je eigenlijk de applicatie Thread laten slapen. Dit zou volgens mij veel slechtere gevolgen hebben (bijvoorbeeld wanneer er op dat moment iemand belt) dan wanneer je Threads wel gebruikt.

Klik om te vergroten...

Das gewoon een kwestie van je programma goed designen, daar heb je geen threads voor nodig. Je zorgt er trouwens altijd eerst voor dat je programmalogic het gewenste aantal updates per seconde krijgt(in het geval van gebeld worden bvb 0) en dán pas ga je proberen om de framerate naar het gewenste aantal te krijgen. Als de logic incorrect is(door te trage updates) dan kan je game nooit correct worden weergegeven, dus logic updates zijn sowieso belangrijker. Die logic kan je ook gewoon pauzeren als je je programma goed ontwerpt.

Bedankt voor het antwoord, zal binnen 2 weken de library posten met een voorbeeld spelletje..
Ik heb nu die EasyEclipse geinstalleerd voor J2ME en ook die WPT toolkit. Nu vraag ik me af, is er een mogelijkheid dat ik de resolutie van een gsm scherm kan opvragen? Dan kan ik verder met die floating points.
Zijn er trouwens ook verschillen tussen de J2ME versies of zijn die altijd backward compatible. Ik had ergens gehoord dat er een groot verschil is tussen de verschillende toestellen.

Merci voor de antwoorden al.

@Vich : ja ik weet het die CVS is heel traag maar code is niet groot he . Dat is wel een probleem bij foto's en al. Als ge kijkt in de code dan ziet ge dat alles mooi apart staat hoor . Ge kunt afzonderlijk elk deel gebruiken van de library.