Hi !
Featured games (91)
games approved by the League of Dukes
Games in Showcase (757)
Games in Android Showcase (229)
games submitted by our members
Games in WIP (844)
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  Discussions / Miscellaneous Topics / Re: Favourite name for vectors? on: 2003-04-11 08:12:05
I am with the "block" crowd, much easier to read, esp. since I don't use {'s for on-line ifs


Mix that with the mis-aligned braces and things gets horribly complicated.

I align variables (both members and local).

I keep members at the beginning of the class and always prefix with "m_" - statics are prefixed with g_ and static final (constants) are all caps. (simple data-classes with no code and public fields don't have the m_)

I use i-prefix for integers (of all sizes), x for fixed point, f for floating points (float and double), a for arrays, v for vectors, s for strings. Other types are not prefixed. I occasionally stray from this (for example when using i, x, y, z etc. in loops and for local variables).

My vector class is an interface called Vec (and Vec2, Vec3 etc. for various impl.)

Upper-case first char in class names, lower case in methods and variables.

I don't use the I and C prefix on Interfaces/classes commonly used in C++ as I don't feel the need for that in Java (besides, my IDE clearly indicates which is what so I don't need it).

Oh, and I prefer grey background in my editor. Comments in dark-grey so they don't clutter the important part - the code Wink ...
2  Java Game APIs & Engines / OpenGL Development / Re: Frame rate capping (aka predictable drawing ti on: 2003-03-31 06:19:36
You are confusing framerate with monitor update frequency. The latter will make your eyes bleed if set to low, the first will just look ugly.

A 60 fps framerate is way more than what is used in Hollywood movies (20-something i believe?), and way way more than what is used in e.g. anime movies (12fps I think).

So yes, 60fps is quite enough. And no, it is not comparable to BGs famous 640K statement Smiley, as human eyes are not likely to evolve at the same rate that computer HW and SW has Tongue

(Oh, and another thing: Monitor update frequency is not a generic problem, but related especially to CRT monitors because these screens loose their charge quickly, a TFT at 60Hz is rock solid)
3  Games Center / Archived Projects / Re: Alien Flux Alpha Test 3 on: 2003-03-27 11:46:58
FWIW: AF runs on my dual-monitor setup (one TFT, one CRT) but it did require the most recent NVidia drivers. (So, in relation to recent discussion: the 16MB drivers would have been a larger barrier-to-entry than the 8MB JRE which I already had Tongue )

The default drivers supplied by Dell were too old (the machine is less than 4 weeks old), and caused the mysterious "not OGL compatible" error some of you have seen.
4  Game Development / Performance Tuning / Re: JRE Download Size on: 2003-03-26 07:03:07
I'm with erikd on this one... I don't think 8 mb is a problem. Game-demos are typically 100MB  for the small ones, video drivers as noted approaches 20MB, even very small games easily reach 10MB with maps, gfx, fx
, code and music (even a single mp3 track is 3megs)).

That said, it doesn't need to get any bigger (save perhaps to include lwjgl in the std. package Tongue )

What concerns me is that there are so many different RTs and really weird versioning - people are easily confuzed. Why, for example, is Java2 in a RT with version number 1.x ? Highly illogical.
5  Java Game APIs & Engines / Java 2D / Re: Why Java? on: 2003-03-07 10:41:32
A few points on Sun and expanding the Java API:

1) Sun are not actually making money from Java (at least not directly, and not in any major way), so I think we should be happy with what they've given us so far, and beg that they focus their future efforts where it makes a difference (VM research). Sun's efforts on the run-time APIs are somewhere between mediocre and horrible, so let's not encourage further efforts in that area.

Which leads me to point 2:

2) AWT, Java2D, Java3D, JavaSound, etc. ... Any of these strike you as major advances in any of their respective areas? No, because they aren't. All have been inferior to what was available for other platforms at their time of release. Sun is just not very good at this, each new API bloats the JRE but adds nothing, because you eventually have to roll your own anyway (LWJGL).

And bloating is, in fact, my 3rd issue with Sun's API efforts:

3) I work with Java every day and has been doing so for the past 6 years and I can't figure out what the hell is part of what "configuration", "spec", "api", "package", "option" or wtf they call it. How on earth do they expect end-user-joe to figure this out? Everything is over-engineered, over-designed and generalized to the point where it is generally useless.

So, my advice to Sun, and hope for the future, is that they focus all their resources on the Java language, VM and the very very basic of the JRE (basically JRE1.0 minus unnecesarry garbage), and leave everything else to those who know. (I.e. when there's a perfectly well functioning, open, industry accepted API already available, EMBRACE IT! Yes, I'm thinking OGL vs. J3D here, but there are other examples).

I'll shut up now - I really don't enjoy trolling  Roll Eyes, but sometimes it gets the better of me Tongue
6  Discussions / General Discussions / Re: Java Cartridge for GBA on: 2003-03-07 10:15:01

I'll give them an A for effort, and they score pretty high in the "technical novelty" category, but I'm not sure what else to think of it.

Are people actually going to buy this thing?

Because if not, it's no more usefull than the fact that you CAN (technically) run Java on an X-box.
7  Java Game APIs & Engines / Java 2D / Re: Why Java? on: 2003-03-07 06:47:50
I disagree...

My primary motivation for using Java is not platform independence - If I can sell my software to 95% of the worlds computers, then that's good enough for me Tongue.

No, I use Java because it is by far the most productive language I have ever used (and I have been programming everything from 6510 machine code to C++ over the past 15 years).

It's probably slower than C++, but C++ is slower than C (asuming you make use of C++ features), C is slower than assembler, yet gamedevelopers have walked that very path, sacrificing performance for reliability and productivity. Sooner or later, gamedevelopers will look at C++ and go: "why the f*** did anyone ever bother with that crap".

Whether Java is the next step on the evolutionary path of game development remains to be seen, but believe me, C++ is NOT the last.
8  Discussions / Miscellaneous Topics / Re: A Difficult One! on: 2003-03-05 05:50:54
I must select 5 recent plus at least one retro, right?  Grin

Doom II
Deus Ex
Half Life
Hitman 2
Quake 1+3 (well, technically, that's two, but hey! Smiley )
Warcraft I

Monkey Island (Amiga)
Kings Quest (pretty much any from the series) (Amiga)
Boulder Dash (C64)
Alien Breed (Amiga)
Hired Guns (Amiga)

That's my 5+1 list, and I'm sure I forgot somthing really cool  Roll Eyes
9  Discussions / Miscellaneous Topics / Re: Any pros here? on: 2003-03-03 10:33:11
Depends... If you mean "pro" as in "primary source of income", then no.

A friend and I run niemo entertainment as our spare time game company; It's a professional company, we're professional software developers, we write professional games and we do make money from them (occasionally Tongue), so in that respect, yes.

Never worked for someone else doing games, never will probably. I looked around a while back but ended up with the same impression as everyone else it seems: long hours, shitty pay, limited influence, big risk. Why bother?

The way things are right now, my dayjob pays the bills, I can work games when I feel like it (I.e. it's fun), and whatever money I make is just sugar on top (still trying to get sugar enough to trade in for that F355 spider though Cool).

Whether that is PRO or not, I'll let you decide, but it's definately a professionally (not to mention socially and financially) viable approach.
10  Game Development / Performance Tuning / Re: 1.1 performance renderer on: 2003-02-27 18:24:40
A little harsh maybe - Sun did create a wonderful (free) language and software platform in Java and its VM Wink. I do agree though, that their core APIs are mysteriously inefficient compared to the platform itself.

I think it's odd how MemoryImageSource can be so much less efficient than my own implementation - try calling newPixels twice on a MemoryImageSource. BAD idea, yet, in my own class I update several smaller chunks and it doesn't seem to have any impact at all.

I guess the conclusion is that there's no point in EVER using MemoryImageSource.

As for buffered Images - I doubt if I will have much to gain as I rely heavily on pixel-operations and have multiple gfx layers added/blended and multiplied together (extensive framebuffer access both read and write) - I assume the speed improvement with buffered images comes from storing data in vmem, no?
11  Game Development / Performance Tuning / Re: Newton-Rhapson sqrt to lwgl math package?? on: 2003-02-27 13:34:32
Amazing performance from the Float.xxxBits methods, eh?

How can it possibly be slower then NIO? It should at the very least be the same.
12  Game Development / Performance Tuning / Re: Newton-Rhapson sqrt to lwgl math package?? on: 2003-02-27 10:53:20
hmm.. I'm not sure I see the point in involving buffers - it's a simple float-in, float-out method call Huh...

Depending on the implementation of FloatToIntBits and IntBitsToFloat, a pure java implementation might also be viable.

--- modified:

sorry, didn't read all posts  Lips Sealed, the code in java would be:

float f = 2;
int x = Float.floatToIntBits(f);
f = Float.intBitsToFloat(x);
13  Game Development / Performance Tuning / Re: 1.1 performance renderer on: 2003-02-27 09:13:05
Thank you, thank you, thank you...  Cheesy

I've been using MemoryImageSource since forever - never bothered implementing my own ImageProducer since I figured the default implementation was so simple that there could hardly be any perfomance gains in messing with it.

How wrong I was.

And what's MUCH more important: it made me realize that I could blit my circular buffers in a single blit by wrapping data in the imageproducer rather than when blitting -> much faster and no shearing artifacts.

Thank you... In 30 minutes work I doubled my potential framerate. Why the f*ck is stuff like this not in the official documentation from Sun? Or in a tutorial? No wonder people think Java is slow........

Same thing with the color model issue - hardly documented, yet choosing the wrong model can chop your framerate in half with no warnings or indications of problems what-so-ever.

The Java gaming community needs a list of do's and dont's with respect to the performance of std. core java libraries (eg. JavaSound)...
14  Java Game APIs & Engines / Java Sound & OpenAL / Re: MOD Player in applet on: 2003-02-25 16:23:19
Must it be .mod? .XM is a better format and converting mod->xm is no loss on your part, or?

Don't need CVS - there's a web-enabled interface that allow you to download a zipfile from anywhere in the source tree..
15  Java Game APIs & Engines / Java Sound & OpenAL / Re: MOD Player in applet on: 2003-02-25 16:11:48
Try Silence:

Looked at it a while back - seemed ok, but never used it for anything...
16  Java Game APIs & Engines / Java Sound & OpenAL / Sound Fx and JavaSound on: 2003-02-25 09:38:19
After 6 years+ working with Java I once again find myself a total newbie; I've started implementing sound Fx for our latest project which is introducing me to a whole new world of interresting abstraction.

All very nice from a functional perspective, but I'm a little lost on the performance implications of the various options provided by the JavaSound API, for example:

1) Do I load all my sound effects (a couple of megabytes, probably 2-300 little samples) into Clips and play them when I need to, or do I reserve a constant pool of N Clips and open() my preloaded samples when I need them?

2) Some (most) effects may be active in several instances simultaneously (possibly, likely even, with different attenutation, panning and offsets) - do I create multiple Clips for the same buffer or is this something I need to avoid?

3) Alternatively, am I better off using a single SourceDataLine and do mixing and panning myself?

4) Preferred audio format? Both run-time size and decoding-speed considerations are important. (I.e. OggVorbis is small, but I don't see 50 Ogg decompression threads running simultaneously as a viable path for sound fx Smiley ). Wav is simple and high quality, but huge.

I guess what I'm looking for is info on the "weight" of e.g. Clip and SourceDataLine - can I throw these around in large quantities or are there a large amount of hardware resources allocated and attached to each Line instance?

If anyone out there has views on this, sample code, links to documentation, tests and benchmarks, or even experience  Shocked, please do tell  Wink
Pages: [1]
EgonOlsen (74 views)
2018-06-10 19:43:48

EgonOlsen (55 views)
2018-06-10 19:43:44

EgonOlsen (74 views)
2018-06-10 19:43:20

DesertCoockie (254 views)
2018-05-13 18:23:11

nelsongames (154 views)
2018-04-24 18:15:36

nelsongames (154 views)
2018-04-24 18:14:32

ivj94 (895 views)
2018-03-24 14:47:39

ivj94 (156 views)
2018-03-24 14:46:31

ivj94 (808 views)
2018-03-24 14:43:53

Solater (172 views)
2018-03-17 05:04:08
Java Gaming Resources
by philfrei
2017-12-05 19:38:37

Java Gaming Resources
by philfrei
2017-12-05 19:37:39

Java Gaming Resources
by philfrei
2017-12-05 19:36:10

Java Gaming Resources
by philfrei
2017-12-05 19:33:10

List of Learning Resources
by elect
2017-03-13 14:05:44

List of Learning Resources
by elect
2017-03-13 14:04:45

SF/X Libraries
by philfrei
2017-03-02 08:45:19

SF/X Libraries
by philfrei
2017-03-02 08:44:05 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‑
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!