Java-Gaming.org    
Featured games (91)
games approved by the League of Dukes
Games in Showcase (581)
games submitted by our members
Games in WIP (500)
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 3 ... 16
1  Discussions / General Discussions / Re: Tracing Point A to Point B, detecting rectangular obstacles in 2D on: 2006-04-18 21:54:58
Did you consider the Line2D.intersects(Rectangle2D r) and Line2D.intersectsLine methods? These are quite fast as they don't use any trig methods.
2  Discussions / General Discussions / Re: Math.abs() discussion on: 2006-02-20 17:52:36
I get these results on a 3.06GHz P4

1  
2  
3  
4  
5  
6  
7  
8  
0: 15.937469 ns (combined result: -703529116)
1: 4.216863 ns (combined result: -703529116)
0: 16.258211 ns (combined result: -782838401)
1: 3.796482 ns (combined result: -782838401)
0: 15.778359 ns (combined result: -1823151896)
1: 3.805004 ns (combined result: -1823151896)
0: 15.950707 ns (combined result: 1636766866)
1: 4.353477 ns (combined result: 1636766866)


As I noted on the other thread, some P4 processors have a very slow shift operation.
3  Discussions / General Discussions / Re: If you ever wanted a reason to use a modern langauge... on: 2006-02-17 17:46:49
Sweet! I like your further optimised version!
I presume that is the optimal solution.
It may not be so efficient on processors that lack a fast shifter. While many processors will do a 31 bit shift in 1 or 2 clock cycles some require 31 clock cycles.
4  Discussions / General Discussions / Re: If you ever wanted a reason to use a modern langauge... on: 2006-02-12 19:18:50
However, I was hoping to get reasons why Java wasn't being picked up (why it wasn't viable) since having used it for games development for a few years and for other applications for a lot longer I still can't see and reasons other than a stigma associated with the language.
Graphics performance has been rather slower to improve than computational performance. Especially if you consider the basic Java API (AWT, Java2D, Swing) as opposed to extensions allowing access to OpenGL.

Otherwise there has been a lot of unjustified performance stigma.
5  Discussions / General Discussions / Re: If you ever wanted a reason to use a modern langauge... on: 2006-02-12 17:37:16

Even after 10 years of speed increases we're not there yet. At any given point during this long period of time have those who bought into the hype and bet on Java becoming as fast as C++ been disappointed. This is part of Java's huge credibility deficit.

When I was first looking at using Java (> 5 years ago) I tested some of my own code and even then the speed difference between Java and C++ was modest on that code. Since then a greater variety of code now approaches C++ performance, and fewer coding tricks are required. Adding stuff like escape analysis may not speed up code which has been optimised by the programmer, but rather allow ordinary straight forward code to run as fast as that written by the performance specialist.
6  Discussions / Miscellaneous Topics / Re: Fast and effecient way of scaling JPEG images? on: 2006-01-07 17:58:00
Try using the imageio package (javax.imageio). This allows you to read an image and reduce its size in a single step. Depending on the implementation this may not require as much memory as would be required to read in the entire original image. The downside is that the quality of rescaling is likely yo be reduced. Alternatively it also allows you to read in parts of an image, so you could divide the larger image into many pieces and rescale each separately (you will need some overlap) and finally recombine the reduced pieces.
7  Discussions / Miscellaneous Topics / Re: Instanceof issues on: 2005-12-31 17:43:56
do...while is only good if you want to run the code inside the loop one time before checking the condition. can't think of any useful examples though ... o_O;;
Usually where you have special case code for the zero case, so that you know the loop will run at least once but don't want to redundantly repeat the test on that first iteration.
8  Java Game APIs & Engines / J2ME / Re: Host for a small midlet on: 2005-12-30 12:10:23
Thanks, the midlet works as expected.
My work email adress my be better: mthornton at optrak.co.uk
9  Java Game APIs & Engines / J2ME / Re: Host for a small midlet on: 2005-12-24 16:28:07
Thanks for the offer, I have sent an email to your hotmail address.
10  Java Game APIs & Engines / J2ME / Host for a small midlet on: 2005-12-23 23:57:22
I've written my first midlet, now I just need somewhere to put it. It isn't actually a game --- I needed to start with something more trivial. Any suggestions as to where I could put it without going to the trouble of setting up a server myself?
11  Discussions / Miscellaneous Topics / Re: 2 reasons to celebrate on: 2005-12-06 12:21:49
the most amazing, sweet, funny, smart, beautiful girl ever to walk this earth
Impossible, I'm already married to that one! ;-)

Anyway, congratulations.

Mark
12  Game Development / Performance Tuning / Re: What are the Default Heap Sizes? on: 2005-11-18 18:06:23
One way to implement multiple heaps might be to make use of JSR 121 (Isolates).
http://www.jcp.org/en/jsr/detail?id=121

Each isolate would have its own heap which is discarded when the isolate completes.
13  Discussions / General Discussions / Re: Java Structs, in Progress? on: 2005-11-18 14:40:54
They just assume that it will be a struct keyword like in C.
Well that was the original proposal, and there are now rather a lot of comments to read. Working out what the current consensus proposal would be from that JRE is no trivial task.
14  Game Development / Performance Tuning / Re: What are the Default Heap Sizes? on: 2005-11-15 13:43:35
That's a low starting value.
Higher values would further increase the whining about how much space Java uses.

It would be nice to be able to give the gc a hint at run time to the effect that you were about to allocate ~40MB of data. In effect to override the -Xms value. I have code that allocates several hundred megabytes of data and the run time is very dependent on the minimum heap size. I understand that there are difficulties changing the maximum heap size at runtime, but surely changing the minimum size is much easier.
15  Discussions / Miscellaneous Topics / Re: Floating point accuracy in Java not as accurate as C/C++? on: 2005-11-15 10:41:47
I'm betting there is already an RFE for this, anyone know the number?
There was a JSR:
http://jcp.org/en/jsr/detail?id=84

Quote
Withdrawn 2002.03.01. Due to the general absence of interest in the community, the Specification lead withdrew the JSR.
16  Discussions / Miscellaneous Topics / Re: Floating point accuracy in Java not as accurate as C/C++? on: 2005-11-14 22:38:12
Not quite the precision is always as specified. Without strictfp the range of the exponent can be extended for intermediate values only.

As for "fastfp" I think a complete anything goes would be  bad idea --- there should still be some minimum requirements.
17  Discussions / Miscellaneous Topics / Re: Floating point accuracy in Java not as accurate as C/C++? on: 2005-11-14 10:13:03
strictfp does not change the accuracy requirements at all, instead not using it allows the use of an extended exponent range. So that instead of overflowing at about 1e308, much larger values can be represented. This is only permitted for the intermediate values of an expression. On Intel hardware it allows intermediate values to be kept on the FP stack which uses an 80 bit representation. With strictfp each intermediate value has to be saved to memory and then reloaded to force overflow to occur at the expected point. Note that although the FP stack has 80 bits for each entry calculations do not necessarily use the full 64 bit mantissa --- there is a mode setting which controls the accuracy required (float, double, extended).

Fused multiply and add is a separate issue usually relating to Power cpus, and this is still not permitted because it uses additional accuracy for the intermediate result.
18  Game Development / Performance Tuning / Re: How much memory consumes my java application ? on: 2005-11-13 16:45:44
Which memory size column in Task Manager are you refering to? Note that the VM size column also includes memory which has been reserved but not allocated (i.e. there is no real memory used).
19  Game Development / Performance Tuning / Re: Vectorization-Optimization RFE accepted on: 2005-11-07 12:16:00
Relaxing the operation order of expressions and statements in Java is probably a non starter. Not enough interest in the potential benefits and too many people who find floating point baffling enough as it is.
20  Discussions / Miscellaneous Topics / Re: Unwelcome reminder on: 2005-11-07 11:34:05
how many bytes are on a punch card?
A standard card had 80 columns each with twelve rows. The common encodings produced a 64 character set, thus each column was equivalent to 6 bits. Programs were stored in boxes which held 2000 cards.

http://www.cs.uiowa.edu/~jones/cards/codes.html

and this paper seems to describe one of the systems I used in Adelaide back in 1973

http://portal.acm.org/citation.cfm?id=810798&jmp=cit&dl=portal&dl=ACM

I knew the program was somewhat experimental, but hadn't previously realised that it had resulted in published papers. This system used cards which you marked using a soft pencil instead of using a punch, thus avoiding the problem of sharing a limited number of punch machines amongst lots of students.
21  Discussions / Miscellaneous Topics / Re: Unwelcome reminder on: 2005-11-06 12:45:49
I'm 34.  I've never used punch cards or paper tape... though I hear that the paper tape is better 'cause when you drop it on the floor you don't have to worry about putitng it in the right order when you pick it up Smiley
The better card punch machines could be set to automatically put a sequence number in specified columns. Then if you dropped a deck, you just fed the cards into the automatic sorting machine. Paper tape was slower and more fragile than cards.
The first computer I used (1973) was an IBM 1130:
http://www-03.ibm.com/ibm/history/exhibits/1130/1130_intro.html
22  Discussions / General Discussions / Site problems on: 2005-11-05 22:56:50
I'm finding that over the past 24 hours or so this site has frequently stopped responding. Anyone else had similar problems?
23  Discussions / Miscellaneous Topics / Re: Unwelcome reminder on: 2005-11-04 12:00:06
Not only punch cards, but also paper tape. In the project for my honours degree, I used one of these:

http://www.brouhaha.com/~eric/retrocomputing/dec/gt40/

which used paper tape for loading programs. I even remember playing the lunar landing game (1979). The project was on the "Mathematical evaluation of facial expressions", and paper later appeared in the British Journal of Psychiatry (1984).
24  Discussions / Miscellaneous Topics / Re: Unwelcome reminder on: 2005-11-04 11:23:11
Jeeez.. old people, do you remember punch cards? Tongue

Kev
Yes. I even remember a computer that was programmed using a plug panel. It was used to produce the program list for Channel 7 (I think) in Perth. At the time I was an exchange visit, staying with the family of the man responsible for programming it. Long out of date at the time it was kept in use on the basis of "if it ain't broke don't fix it".
25  Discussions / Miscellaneous Topics / Unwelcome reminder on: 2005-11-04 10:24:21
The upcoming birthday list is full of youngsters ... I'll be 47 on Monday!
 Wink
26  Discussions / Miscellaneous Topics / Re: Floating point accuracy in Java not as accurate as C/C++? on: 2005-11-04 10:21:27
'Argh' is not directed at anyone else, usually, when you read it on the forums. It's the equivalent of slapping your forehead in real life when you realize you've made a mistake.  Or, as Homer would say, "Doh!".
Exactly right. The peculiar characteristic that NaN isn't equal to itself was something I ought to have remembered. At the time I was concentrating on the fact that the String conversion should round trip the values exactly (including the NaN case) and forgot that the equality test is tricky.
27  Discussions / General Discussions / Re: Creating a new byte-code compatible java vm on: 2005-11-03 12:25:18
It may be more important with apps that use physics packages more intensively.
Very likely. However I don't think that just turning of the checks is the correct approach. It would be far preferable to improve the JIT's ability to tell when the checks weren't necessary. For example good Pascal compilers were able to eliminate more checks when the integer subrange types were used appropriately.
Could we add attributes to declarations in Java that made similar assertions. Then so long as the assertion was true the JIT could make more aggressive optimizations. If an assertion was found false then either an exception could be thrown, or the optimizations unwound and the application left to continue and fail in the normal manner when the bad value was used.
Also would it be reasonable for a JIT to take notice of assert statements even when they were 'disabled' --- but of course only when the assert condition is helpful to the optimiser.
28  Discussions / General Discussions / Re: Creating a new byte-code compatible java vm on: 2005-11-02 17:19:24
removing those nasty array bounds checks.
I think this gets more attention than it deserves. In a number of important cases the HotSpot server can remove these checks safely (or at least hoist them out of loops). Even when they remain they aren't as expensive as many people seem to think (and a lot less expensive than overrunning buffers as Microsoft can no doubt attest).
29  Discussions / Miscellaneous Topics / Re: Floating point accuracy in Java not as accurate as C/C++? on: 2005-11-02 16:30:05
Not true! If x == Float.NaN, result will be false.
Argh, because of course Float.NaN != Float.NaN
The round trip through String does recover the identical value even for NaN, it is just the test which is tricky.
The test should read
Float.toIntBits(z) == Float.toIntBits(x)
30  Discussions / Miscellaneous Topics / Re: Java enum functionality on: 2005-11-02 12:26:20
Using naked bit operations to represent set operations is a bad hack too, albeit one of long standing.

I concede that the recursive generic declaration takes some understanding, but most people will just gloss over it and accept that it does the right thing. however without generics we have a semi-staticly type checked language which seems intellectually unsatisfactory. A sort of half way house between the fully dynamic languages and a complete static type checking. While some type casts are always likely to be necessary, without generics I find I have just too many of them for my peace of mind.
Pages: [1] 2 3 ... 16
 

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

The first screenshot will be displayed as a thumbnail.

xsi3rr4x (64 views)
2014-04-15 18:08:23

BurntPizza (62 views)
2014-04-15 03:46:01

UprightPath (75 views)
2014-04-14 17:39:50

UprightPath (58 views)
2014-04-14 17:35:47

Porlus (76 views)
2014-04-14 15:48:38

tom_mai78101 (101 views)
2014-04-10 04:04:31

BurntPizza (161 views)
2014-04-08 23:06:04

tom_mai78101 (256 views)
2014-04-05 13:34:39

trollwarrior1 (209 views)
2014-04-04 12:06:45

CJLetsGame (216 views)
2014-04-01 02:16:10
List of Learning Resources
by SHC
2014-04-18 03:17:39

List of Learning Resources
by Longarmx
2014-04-08 03:14:44

Good Examples
by matheus23
2014-04-05 13:51:37

Good Examples
by Grunnt
2014-04-03 15:48:46

Good Examples
by Grunnt
2014-04-03 15:48:37

Good Examples
by matheus23
2014-04-01 18:40:51

Good Examples
by matheus23
2014-04-01 18:40:34

Anonymous/Local/Inner class gotchas
by Roquen
2014-03-11 15:22:30
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!