Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (477)
Games in Android Showcase (108)
games submitted by our members
Games in WIP (536)
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] 2
1  Discussions / Miscellaneous Topics / Re: What's the next number in the sequence on: 2006-11-16 02:05:43
LOL. Thanks.  If I win, you can have my Oceanic flight tickets to Los Angeles. Grin
2  Discussions / Miscellaneous Topics / Re: What's the next number in the sequence on: 2006-11-16 01:42:33
Great. Now for your next challenge.
Could you tell me the next 7 numbers in this sequence... http://www.lottery.co.uk/euro-millions.htm  Cheesy
3  Java Game APIs & Engines / J2ME / Re: Motorola SDKs on: 2006-08-16 01:44:10
You want the Motorola J2ME™ SDK v6.1.1.  It will emulate most Motorola handsets, including V3.
4  Discussions / General Discussions / Re: Will we have Java on PS3 ? on: 2006-06-13 23:24:53
I recognise that list from the blu-ray forums.  This thread suggests it was last updated on 19th March and I doubt the situation has changed much since then.  Blu-ray is clearly at an advantage, but trying to get all of those companies to agree on anything is presumably what is causing the delays they're having.
5  Discussions / General Discussions / Re: gates planes handheld with games support so maybe ipod should have java? on: 2006-03-24 15:45:36
Perhaps.

PortalPlayer, the manufacturer of the iPod chipset, quietly revealed that it has licensed J2ME technologies for inclusion "within its personal media player platforms", which are "expected to be released in the first half of 2006".

Not entirely sure if that means a Java-enabled iPod, but it's interesting nonetheless.
6  Java Game APIs & Engines / J2ME / Re: Which is the best Java 3D Mobile Device? on: 2005-12-06 03:07:09
Another free M3G benchmarking test is <a href="http://www.futuremark.com/download/?spmarkjava06.shtml">SPMark Java06</a>.  Checkout the <a href="http://www.futuremark.com/download/?spmarkjava06videos.shtml">video</a> of it in action.

Running the 3D animation gives these results:
<a href="http://service.futuremark.com/compare?spmj06=335">SonyEricsson K750i : 4.2 FPS</a>
<a href="http://service.futuremark.com/compare?spmj06=228">SonyEricsson W800 : 4.2 FPS</a>
<a href="http://service.futuremark.com/compare?spmj06=329">Nokia 6630 : 13.5 FPS</a>
<a href="http://service.futuremark.com/compare?spmj06=357">Nokia 6680 : 11.4 FPS</a>

Sadly there isn't a listing for the Sharp 903 which should be a lot faster than all of these.  (and I don't have access to one yet either  Cry )

Both the Nokia 6630 and the SonyEricssons are great for developing midlets. The SonyEricssons have on-device debugging which is always good.  The Sharps can be a bit of a pain.

(I should point out that I don't have access to the latest M3G devices, these are just the ones I know, so there might be better ones out there)

If money is no object then I would suggest buying all of them.  Cheesy   They will all behave differently anyway.
7  Discussions / Miscellaneous Topics / Re: why is there no jre for PDAs ? on: 2005-10-09 21:21:30
(Another thead turns into a Java-on-consoles topic. LOL Grin )

Surely it's only a matter of time before Java will penetrate other devices.  It certainly has penetrated mobiles.  And the mobile phone has every intention of becoming the consolidated, always-worn, games console, personal media player, PDA device.

Notice how all of the established games companies are moving into mobile.  All of them are announcing mobile game divisions (forget Tetris - they're thinking much bigger).  They're all following the same roadmap - form the management team now and start recruiting Java game developers in late 2006 (which is when programmable hardware accelerated 3D devices are due).

Admittedly it still remains a potential future technology, but given the entire gaming industry (an incredibly narrow-minded bunch) is seriously making moves, I find it difficult to dismiss that potential.
8  Discussions / General Discussions / Re: Will we have Java on PS3 ? on: 2005-09-24 18:23:45
Indeed, if we're talking about the Blu-ray JVM, only licensed manufacturers can make those BD-ROMs.  Sony has full control over that franchise.  BD-ROMs can download Java classes via the network, so there is a possibility for Sony to allow some discs to act as distribution portals - although I doubt they will.

I strongly believe we are likely to see Java based consoles appearing soon - obviously they won't be as powerful as PS3 or PSP but does that matter?
9  Java Game APIs & Engines / Java 2D / Re: ImageIO png decoder still &£$%^£ on: 2005-09-11 15:21:45
Surely that bug has inflicted pain on every mobile games studio. Yet Sun still hasn't fixed it.

Whenever we try to develop a new tool which uses optimised low-colour PNGs from our midlets you'll hear someone cursing about it.

Our solution has been to maintain 2 copies of the graphics.  Optimised PNGs for the midlet and non-optimised copies for the editor software.  This of course leads to a maintenance nightmare.  Admittedly it is not a very good solution.
10  Discussions / Miscellaneous Topics / Re: AGEIA physX PPU (novadex/ODE) on: 2005-08-13 14:49:54
That PPU chip is amazing!!
I can't wait to see it embedded in Java-powered devices.  I've been looking at the <a href="http://www.physicstools.org/">Open Dynamics Framework</a> initiative where Ageia are trying to get everyone to agree on a standardised API interface for all physics engines.  This will undoubtedly lead to Java bindings.  If you're aware of the <a href="http://www.khronos.org/">Khronos Group</a> consortium then you will know there is a lot of ongoing activity towards creating Java bindings for embedded hardware such as <a href="http://www.jcp.org/en/jsr/detail?id=239">OpenGL-ES</a>, <a href="http://www.jcp.org/en/jsr/detail?id=234">OpenSL-ES</a> and <a href="http://www.jcp.org/en/jsr/detail?id=226">OpenVG</a>.  Ageia is a member of that group and it's not difficult to see why - they want their chip to be embedded in future Java-powered devices, such as smart phones and set-top boxes.  So surely it's only a matter of time before us Java game developers get to play with OpenGL-ES and a physics PPU on Java-enabled devices.  Smiley
11  Discussions / General Discussions / Re: Java to be on new DVD players on: 2005-07-17 12:39:02
I'm trying to get my head around this whole Blu-ray business. Here's my understanding of it. Please correct me if I'm wrong.

There will be 3 varieties of Blu-ray disc: BD-ROM (read only), BD-R (recordable) and BD-RE (rewritable).

Only BD-ROM will play Java content (known as BD-J applications). Unfortunately only licensed manufacturers can burn these discs, so no chance of us making indie PS3 titles in Java. 

The good news is that companies like Disney will commission Java programmers to make games, and other interactive features, to be embedded in their movie DVD's.  Quite how advanced these games will be is anyone's guess. And that is the big question - just how advanced can they be?

The discs will run on a variety of home entertainment platforms, inc. computers, digital set-top boxes and PS3.  On some systems the games will be controlled via an infra-red remote control, whilst others will use a devoted game controller.  Will these games be able to take advantage of extra capabilities in the higher-end systems, or will they all be designed for the minimum spec?

Anybody have any thoughts?  I'm curious as to how advanced these games could become?  Will they be simple puzzle games? Or adventure games with 50Gb of pre-rendered movies? Or is their scope here for something far more advanced?

My wishlist would be:
- They include the Java OpenGL-ES bindings (JSR-239)
- That the JVM can be remotely updated. (JSR-232)
12  Discussions / General Discussions / Re: Java to be on new DVD players on: 2005-07-02 21:07:02
From what I can gather it will use the Personal Basis Profile, but I'm not sure which version.  (PBP-1.0 is lightly based on Java 1.3, whilst PBP-1.1 has some Java 1.4.1 additions).

It will also be interesting if they allow the JVM to be updated via the network. There are several upcoming JSRs based on OSGi which would enable them to do this, so it's certainly possible.  If Sony wants to make the PS3 futureproof, and ensure Blu-ray wins, then enabling Blu-ray players to update their JVM would make perfect sense?  (does anybody know if all Blu-ray players must be network enabled?)
13  Discussions / General Discussions / Re: about that "your games here" split up on: 2005-06-08 20:33:20
Initially I found it awkward too, but now we have a fully functional "show unread posts since last visit" feature.  Which is so much easier than navigating through the forums anyway.
14  Java Game APIs & Engines / J2ME / Re: Mobile Java-3D on: 2005-05-10 20:54:50
Once you've extracted a section from the m3g file (lets say it's stored in a byte array called compressedByteArray) then you might invoke Inflater like this:  
1  
2  
3  
4  
5  
Inflater decompresser = new Inflater();
decompresser.setInput(compressedByteArray);
byte[] decompressedByteArray = new byte[32768];
decompresser.inflate(decompressedByteArray);
decompresser.end();

And hey presto, decompressedByteArray now contains the unpacked section.  (Also remember there can be multiple sections in an m3g file)

Furthermore, you might like to checkout the M3GToolkit thread as they've produced an open-source toolkit which might have all the information you need.
15  Java Game APIs & Engines / J2ME / Re: MIDP 3 started on: 2005-03-16 02:48:43
Yep I have used JSR-184 to do image scaling. I guess it depends on what you are trying to achieve but nothing ever seems straight-forward with M3G. Ideally all of your game content would be drawn using 3D co-ordinates as there is little point in trying to persuade M3G to draw a textured object at a predestined 2D screen location due to the number of factors involved. And Sprite3D can be incredibly slow on the current devices. Don't get be wrong, M3G has great reasonable potential for 3D games, but personally I try to avoid it for 2D content. Perhaps when M3G devices become faster, more stable and more widespread will I change that view.

Image scaling and rotations is something that should have been in the original MIDP spec from the beginning. MIDP3 has the opportunity to put that right. MIDP2 took at least 2 years, so I'm hoping to see the first MIDP3 device in 2007 with amazing image scaling capabilities. Grin
16  Java Game APIs & Engines / J2ME / Re: Fadingin in and out on: 2005-03-15 23:30:26
Yes that's right, sorry, it will only fade between the polygon color (eg. blackness) and whatever is being drawn underneath.   Admittedly it is rather limited, especially as it requires the Nokia API, but it can be a simple and cheap alternative if you don't mind it fading-out to black.  Once the black polygon is fully opaque you can switch the graphics underneath before fading back in to slowly reveal the new screen.
17  Java Game APIs & Engines / J2ME / Re: Fadingin in and out on: 2005-03-15 22:25:17
Fading can be done very cheaply on Nokia devices just by using DirectGraphics.fillPolygon().   Simply paint your graphics as normal but afterwards draw a rectangle (using fillPolygon) to cover the entire screen.  This is drawn using an ARGB color so by slowly modifying the alpha component every frame you can fade the polygon in or out.   This is a nice and cheap trick - but sadly it only works with the proprietary Nokia API.
18  Game Development / Game Mechanics / Re: Okay, Give it to me straight, is this possible on: 2005-03-13 19:28:16
It's certainly worth a shot.

I wouldn't worry so much about floating point. I'm sure that the situation will improve soon and, even if it doesn't, you could release your code as open-source and somebody is bound to convert it to fixed-point.  I believe there is a strong demand for a J2ME physics engine.

However I am concerned about the fact you might not be able to retrieve the transformed data from a JSR-184 scenegraph.  I am not familiar with combining physics engines and scenegraphs, so bare with me here.  In JSR-184 you can create a scenegraph, rotate things about a few times and then you have no idea where anything is.  You cannot retrieve much data from it, you can only render to the screen.  So would you need 2 copies of the data?  One copy in the scenegraph (that you cannot access) and another copy for calculating collision intersections.  Both would have to be transformed independently, causing further computations, and both would be consuming valuable heap.  Is this the case? and can it be avoided?
19  Game Development / Game Mechanics / Re: Okay, Give it to me straight, is this possible on: 2005-03-13 13:27:35
So are you developing the game for a limited handheld device using J2ME?   If you are, then it will be impossible to use ODEJava with JSR-184.  But I do agree that a light version of ODE in pure Java is certainly possible.  Many of the current devices aren't really powerful enough to cope with the number of computations, but they are getting faster day by day.

I've heard rumours that some companies are considering whether to embed a physics API in their J2ME devices.  But even if that was to go ahead now, it would take year or two before anything becomes of it.  Eventually it will surely happen, but there is currently very little on the horizon.

A pure Java version of ODE would be a very cool piece of technology to have.
20  Java Game APIs & Engines / J2ME / Re: MIDP 3 started on: 2005-03-13 00:29:47
Manipulating png data and recalculating it's CRC is uber-hardcore. I like it. Wink
21  Java Game APIs & Engines / J2ME / Re: MIDP 3 started on: 2005-03-12 11:36:06
yuyou: Thats a good piece of code.  It could be useful for rescaling images before the game starts.  I think that due to the restrictions in MIDP, the transparent pixels would be lost, but I don't see any way around that.  (Edit: on second thoughts, the tranparent pixels would be kept intact; so ignore that)

david: It's amazing. kvm-interest has suddenly sprung back into life after being almost dormant for several months.

I fully agree with the TCK comments.   We can only hope.
22  Java Game APIs & Engines / J2ME / Re: Tira Jump, good or bad? on: 2005-03-09 00:50:44
They have a J2ME developers website with forums and articles on 'developing portable code'.  It's free to register. http://www.tiradeveloper.com/

I agree with your scepticism.  We are currently considering whether to outsource some of our more difficult ports to a 'Tira Certified Partner'.  I can't imagine they'll do a perfect conversion without dropping a few features.   But we'll do the easy ones and they can do the difficult ones Cheesy that is assuming they can do it.
23  Java Game APIs & Engines / J2ME / Re: MIDP 3 started on: 2005-03-09 00:45:07
The most important feature would be drawing scaled images.  Having a variation of drawImage() scale the image to fit inside a specified rectangle, just like in the J2SE edition.   Obviously this would have to be very fast, with a strong emphasis on being implemented as low-level as possible (perhaps hold a gun to their head!).  It must also support transparency and avoid using any heap.   If this were done properly then it would be the single most useful game-related feature of them all.  Of course, in reality, each implementation would do it differently and none of them would get it right. Cry

And the following would be welcomed too:-
- Arbitrary image rotations/transforms.
- A palletised version of drawRGB()/drawPixels().
- The ability to create mutable images with transparency.
- Anti-aliased drawing.
- More fonts.

And now for the 'moon on a stick' wishlist:-
- Guaranteed midi sound support (with no prefetch delays).
- Guaranteed semitransparent pixel support.
- System.disableGC(), enableGC(), forGodSakeDoItNowGC().
24  Java Game APIs & Engines / J2ME / Re: Tira Jump, good or bad? on: 2005-03-07 17:21:53
You don't have to use getWidth(); they will still accept your code if you use a member variable containing the screen width - as long as it isn't declared 'final'.

It is my understanding that they have a tool which will change the properties in your .class files.  So if you had a global variable called 'screenwidth' and it was set to 128, their tool could change the bytecode to assign it a different width.  Clearly it only works if the tool can identify code relating to the screen width.  If you were to use hardcoded values then they would be meaningless to the tool, as it would just be a number, there is no label associated with it.  

At least that's how I think it works, but I could be wrong.
Not sure how good they are.
25  Java Game APIs & Engines / J2ME / Re: java midp key listener problems on: 2005-02-13 14:35:57
Hey Abuse, do you remember which phones have buggy implementations of callSerially().   I've started to use it recently, so I would be interested to know which phones might become a problem.
26  Discussions / Jobs and Resumes / Re: Wanted: J2ME programmer to port Alien Flux on: 2005-02-13 14:24:53
Puppytron would be perfect as a mobile phone game!

According to the Elspa games chart, the average mobile user is only buying games that they know - like tetris and monopoly.   Rename it as "Puppytron Asteroids" and you will be onto a winner.  Smiley
27  Game Development / Artificial Intelligence / Re: Steering behaviors.  We need a Java versi on: 2005-01-15 18:26:18
The source code for the Fuze3D port can be downloaded from here.  It's in Fuze3D-0.2.jar.
28  Java Game APIs & Engines / J2ME / Re: VSCL2.0 on the E1000 on: 2005-01-14 22:29:08
The VSCL2.0 Javadoc contains the following...
com.vodafone.io.RemoteControl
com.vodafone.io.RemoteControlData
com.vodafone.lcdui.SVGImage
com.vodafone.media.barcode.BarcodeControl
com.vodafone.midlet.ResidentMIDlet
com.vodafone.system.BodyOpenListener
com.vodafone.system.PhoneStateListener
com.vodafone.system.DeviceControl
com.vodafone.util.ImageEncoder

Mascot isn't listed, but I assume it is embedded on the phone.  M3G certainly is.

The Motorola SDK v4.3 has an E1000 emulator which should give you more information.
29  Game Development / Shared Code / Re: Using double on cldc 1.0 on: 2004-12-30 14:36:06
(This thread would be better served in the J2ME forum section)

Presumably if you were to use MathFP it could be written like this:-
long a = MathFP.toFP("2.5");
long b = MathFP.toFP("2.8");
long result = MathFP.add(a, b);
(editted: my previous attempt was wrong)

But Herks solution is much easier to read.

There are many good tutorials about fixed-point math available, and it is always worth studying, but now that CLDC-1.1 is slowly becoming common-place it can be skipped should you wish to avoid it.
30  Discussions / Miscellaneous Topics / Re: Why my computer no start? on: 2004-10-03 19:09:43
Sounds like a typical day for anybody relying on the electrical grid system in Guildford.  Grin
Pages: [1] 2
 

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

The first screenshot will be displayed as a thumbnail.

CogWheelz (16 views)
2014-07-30 21:08:39

Riven (22 views)
2014-07-29 18:09:19

Riven (14 views)
2014-07-29 18:08:52

Dwinin (12 views)
2014-07-29 10:59:34

E.R. Fleming (32 views)
2014-07-29 03:07:13

E.R. Fleming (12 views)
2014-07-29 03:06:25

pw (43 views)
2014-07-24 01:59:36

Riven (42 views)
2014-07-23 21:16:32

Riven (30 views)
2014-07-23 21:07:15

Riven (31 views)
2014-07-23 20:56:16
HotSpot Options
by dleskov
2014-07-08 03:59:08

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:58:24

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:47:22

How do I start Java Game Development?
by ra4king
2014-05-17 11:13:37

HotSpot Options
by Roquen
2014-05-15 09:59:54

HotSpot Options
by Roquen
2014-05-06 15:03:10

Escape Analysis
by Roquen
2014-04-29 22:16:43

Experimental Toys
by Roquen
2014-04-28 13:24:22
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!