Hi !
Featured games (90)
games approved by the League of Dukes
Games in Showcase (754)
Games in Android Showcase (229)
games submitted by our members
Games in WIP (842)
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
1  Discussions / Business and Project Management Discussions / Re: advergaming+mobile games on: 2005-06-08 14:22:26
We're also conducting extensive studies with some Universities in advergaming, expecially in Europe.

Figures look interesting, but the success rate of the phenom cannot be so easily predicted.

BTW advergaming itself is a too broad definitions. For example: the new Anarchy Online (that now offers free accounts with advertisement banners in-game, like advertisement panels on the edge of the roads in real life)) is an Advergame or not? Gran Turismo series (or FIFA) are advergames or not? Even if people pay (a lot!) for them, all these games are permeated by commercial trade marks and explicit advertisements of merchandise and people.

Reducing the phenom to only shallow web based games featuring a product can be reductive in my opinions.
2  Discussions / Business and Project Management Discussions / Re: List of commercial games using Java? on: 2005-06-08 14:14:34
I think also the more recent LockOn Modern Air Combat is Java-Based like its cousin IL2
3  Games Center / Archived Projects / Re: Zplax 1.0b on: 2005-04-02 08:41:12
I noticed that latest Java 5.0 version had the insane habit to switch my mouse 2nd and 3rd buttons.

So a right click will be a middle click. Maybe the problem why the gun is not reloading is VM-related.
4  Discussions / General Discussions / Re: PuzzlePirates game engine opensourced! on: 2005-03-30 18:45:07
Thx for the pointer.


It is legal relying in an external FAQ to shed lights on a bad written license?

In court I expect a contract be taken for what is written on it, not by the personal interpretations (or addenda, like in this case) of the writers.

The MySQL is emblematic on how a restrictive OSS license can be used to blackmail people that are using an "open source industry standard", if personal opinions are weighted over verbatim words.
5  Discussions / General Discussions / Re: PuzzlePirates game engine opensourced! on: 2005-03-29 06:18:17
Other licenses distinguish Original Creator and Users, GPL doesn't. It's an all or nothing affair. Sub/Dual licensing is forbidden, many who does so maintains two distinct versions of their software to justify the duality in license.
Why you think SCO is trying to sue Linux for copyright infringments and royalties? If even only one of the accusations are recognized in court EVERYONE including authors will lose rights over the artifact and distribution will became illegal since the matter will not be settled. A commercial advantage to have some millions illegal linux boxes and you're one of the few that can serve a legal unix/linux...

My concern was in another way, BTW. According to FSF FAQs, if you derive a LGPL class you are creating derivative work that has to be distributed under LGPL itself (so LGPL becam basically GPL if you use an OOP language). No mention about pure abstracts and interfaces...

It is common for graphical an Windowing kit to use provided classes as a "blueprint" to specialize your own. Since PP is also commercial and FSF are quite a pain in the ass on anything is commercial or commercial aligned (read the today news about their will to stop to being distributed just because uses Java?), I'd be extra cautious about how to license a core element of PP. There's a reason why almost no one uses GPL licenses for OOP libraries (and applications, too).

Anyway I'd rather step away from licenses written by hackers, not lawyers. A licenses that uses programming terms to define how distributing something and tightly bonds itself to a technology (C) is amateurish, no matter how many people use it. Add to it points that contradicts previous ones, a long and convoluted wording and you have what I call a mess...

6  Discussions / General Discussions / Re: PuzzlePirates game engine opensourced! on: 2005-03-22 13:25:16
Really nice architecture, that's explain why PP is so good Smiley

BTW take a look at using (L)GPL, expecially in the FSF FAQs where is stated that if you're subclassing a (L)GPL artifact you're creating a derived work... (No mention about interfaces, wonder why FSF "lawyers" will drop the C is everything attitude).

This may also threathen PP at some extent, so be careful.
7  Discussions / Jobs and Resumes / Re: Staff for A grade game (Italy) on: 2005-02-25 03:38:07
No, sorry.
8  Discussions / General Discussions / Re: good 2d engine? on: 2005-02-23 16:15:02
Not right, I've finished the pathfinding and state based ai some weeks ago and I'm not releasing it because I want to provide a sounding documentation, BTW you can go to my site

and download the Blockz sources.

It is a game prototype we made for third party and it uses most of the Basilisk framework (it was built on top of version 1.x, but I ported it for 2.x).

When SF will restore my account for basilisk I will add it to the source repository of the Basilisk Project.
9  Discussions / General Discussions / Re: good 2d engine? on: 2005-02-23 11:32:11
There's also mine:
10  Java Game APIs & Engines / OpenGL Development / Re: LWJGL vs Jogl on: 2005-02-17 15:05:20
One other thing to throw into the mix, and it's not a fault of JOGL: LWJGL fullscreen works correctly on 1.4.0 and above. JOGL has unfortunately falley prey to a ton of bugs in AWT that to this day remain unfixed.

Regarding work on LWJGL, I do almost bugger all these days, as Elias is driving the implementation to get Tribal Trouble released. This is actually the best possible situation, as instead of writing an API for n00bs and wannabees and theoreticians and hobbyists, LWJGL has only ever been designed around the fundamental problem of getting a commercial game out there.

Cas Smiley

Testcase not propaganda.
I used JOGL (on a ATI, I must add) and LWJGL equally well in fullscreen without hassle. Just a coincidence? People have problems even with LWJGL, you're about to add Swing AWT support to LWJGL too, you're using a bug free AWT?

* AWT is buggy (that's true, but JOGL uses only a small subset of it).
* Swing is slow.
* JOGL is slow (in fact speed is not that different between LWJGL actually).
* Java is crap.
Common statements that most of the time are completely wrong or only superficial or driven by pride.

I can only shiver if people are trying to go in production with alpha versions (I've doubt how pro they can be to do such decisions) of their core tech.

I simply admire Elias with its tribal trouble project (the kind of game I strived to develop but wasn't able to find able people for, here in Italy), expecially since he is maintaining the lib at the same time... Being there done that, it is the only way to do the stuff, as said before.

You should get more easy on criticism, btw. I read almost all the board (Indiegamer too) and blatant FUD against everything is not LWJGL is rampant.

I must reckon you are not so fond to negative feedback about your work (after all people ship games from it, it must be good, wow!), but you must accept it.
After all other people are enduring your propaganda for months (if not years) without getting it close & personal like you did...

BTW I suggest to steer the 3d out of this sterile (if polite) flame war.
11  Game Development / Game Play & Game Design / Re: JRPG Design/Development on: 2005-02-16 02:53:29
Why not trying to implement a time based progression system (like the one on EVE online) instead using the old & boring XP system fantasy rpg use over & over?
12  Java Game APIs & Engines / OpenGL Development / Re: LWJGL vs Jogl on: 2005-02-15 17:17:08
>But the more you try to reach 1 the more your
>specifications should be consolidated.


But if there are some things which doesn't make much sense, you have to change them. Remember the days where we had a display and window class? I always mixed em up and I'm really glad that they were merged. It just makes much more sense this way.

Many moons ago there where even pointers in lwjgl. Do you miss em? Smiley

Maturity is a good thing, but it takes it's time. It's evolutionary. If you don't want to do any changes every once in a while... you certainly don't need to. You can continue using an older version and - eventually - do all the changes at once at some point in the future (eg if you're entering the beta phase).


I only feel odd that supporters continue to stress the in-development of the library but, on the other hand, continue to support the idea that it is a "pro" tool.

Sticking on an alpha or beta (and outdated) build to avoid misalignment is not my way to develop things.

13  Java Game APIs & Engines / OpenGL Development / Re: LWJGL vs Jogl on: 2005-02-15 17:05:53

Just because someone makes a change to the API, does not mean it is a hack.  There are reasons for it and discussions are made behind the scenes between the developers.  That is also the reason for 0.95a.  It is not considered a production release, so ANYTHING can change until version 1.0 comes out.  That is always the risk you take when using a tool that is in alpah/beta/pre-1.0 release.  If you want to have a stable release, then stick with one version for your project until you are done.

Yes, as said before I'd rather fork an immature lib to handle my own project, since we can't start a serious project (an experimental worldwide GPS software in 3D using sat maps to handle logistics) using immature tools (JOGL, LWJGL or whatever). Better to develop it in-house so you can support what you need and ditch the other stuff you'll not need and have a stable release ASAP.
It's the centerpoint of software engineering, the vision must be consolidated before starting the development.
14  Java Game APIs & Engines / OpenGL Development / Re: LWJGL vs Jogl on: 2005-02-15 16:59:57
Matzon saying stupid to others and keeping things close & personal will not make you be smarter, just childish.

If JME is not able to run for a simple 0.01 update is your fault no matter how right you think you are.
If you're providing a library you shall provide the less possible hassle for the developers, expecially when closing to a major release.
Have you thought of just deprecate features to give developers time to adjust their libs (giving them time till 0.99)?
You've just broken support for one of the best 3D library out there.
And what about the countless professional games developed around the library? It's stupid "whining" (or it was suggesting, point of views) for an unfinished library but is intelligent (and pro) using an immature artifact to develop professional things? You've a quite confused opinion about how "pro" software is developed (I must assure than starting on the base of an alpha lib is not part of the equation, JOGL is not excluded from these considerations).

Before another flame will start I will leave Puppygames projects outside on purpose since Cas is involved in the development and knows where the lib will go (It's his own middleware after all).

Anyhow, let me remember you that most of the features removed where because you cannot stand the effort to support them cross platformly (like the input devices or EAX sound) at the moment.  Will we must assume "blinking" features? Better to leave them incomplete to than removing them to be added later.

BTW my first post was more broader than you undestood, there are a lot of potentially good (but unfinished) products out there. Xith3D and JME are just splendid examples of Scenegraph engines, JOGL and LWJGL are decent wrappers. My opinion about JOGL is a better RI candidate is because JOGL is just OpenGL for Java. No other stuff involved.

Nobody is saying that you all are doing bad jobs, just keep things on track and do not take unilateral decisions convinced that your choices are the choices of the community (or of the "pro").
15  Java Game APIs & Engines / OpenGL Development / Re: LWJGL vs Jogl on: 2005-02-15 16:07:08
> You changed lots of things in LWJGL 0.95 [...]

I would like to point out that the leading 0 is there for a reason Wink

Well, yes.
But the more you try to reach 1 the more your specifications should be consolidated.
Otherwise you're just hacking your way out of troubles.

But I'm just saying stupid things... like someone like to think, instead of trying to get something out from constructive criticism.
16  Java Game APIs & Engines / OpenGL Development / Re: LWJGL vs Jogl on: 2005-02-15 13:10:39
A very surprising number of people jumped straight at JOGL to write games with, probably because it got that golden halo from Sun. But it's not a gaming oriented API, it's a completely integrated AWT solution for general purpose OpenGL. Similarly JInput is a hugely complex Swiss-army knife of an API. We just cut out everything that 99% of us don't need and left it at that.

When we get AWT rendering some eyebrows will be raised I should think.

Cas Smiley

Well, the problem is not the halo, but the focus.

You changed lots of things in LWJGL 0.95, removing something, too, and leaving lots of unresolved issues to whom want to upgrade (like the ILU.DLL dependancies just to be able to run a LWJGL game).

This left me uncapable of using JME with LWJGL 0.95 since
I figured the fix, fix that when first appeared not even the development team wwas aware of (look at your forums).

This is not way a finger pointed in your direction but it's an hint to fly low with the ego... Cross platform support was clumsy from time to time (like in the donation drive for mac support), if also the architecture (well, it's not the exact term since LWJGL/JOGL  are substantially wrappers) fails to remain stable and consistent there's no way to define it professional. Hacky may be a more appropriate term.

JOGL has focus on a subset of what LWJGL does but does it trying to remain compliant with old code. It has a slower development process, but it is also more harmonic.

You'll not see many: "I at the moment don't need it, so I will put it on the backburner", from the JOGL team.

Sure, Alien Flux drained some attention to the lib (but also spotlighted some issues in the deploy, like you admitted), but the aims are different.
JOGL is a reference implementation, LWJGL is an hacky tool made to satisfy Puppygames needs, just like my Basilisk and the non OS Stirge engine were.

Don't get edgy when people spots the differences, the projects have different aims and intents, if decide to drop Java like many times you used to claim in the Indiegamer Forum, LWJGL will suddenly be without a huge part of its committment (but I'm pretty sure the project will continue).

These are the factors that are relevant when you are  developing real software (that spans years, not a couple of months) and have to make choices.

Rest assured that I've nothing against JME, LWJGL, JOGL or Xith3D, but if one has to *rely* on a mature technology for a real project he has two choices: fork an existing project, or adopt a support license. For professional needs I'd like to use AgentFX, more than rely on unsure & unstable specifications, for example. If I've the money I'd like to try to get my in-house one. And for that I thank you all to release the libs in the OS-friendly BSD instead of the zealotish GPL.
17  Discussions / General Discussions / Re: Runescape - bigger market share than..... on: 2005-02-09 09:10:52
it's unfortunate the kind of audience that a free online multiplayer game draws though. for every three players, one is trying to talk, trick and scam their way into stealing other's accounts, the second is dumbly falling for it, and the third only plays with people they know personally.

You've been out of the MM scene lately?
18  Discussions / Jobs and Resumes / Re: Java 2D/3D programmers needed on: 2005-02-02 04:03:16
LOL, Cas, here in italy you can earn these figures in euros and be considered lucky in many senior eng positions.
It's equally true than Italy is different from Uk in terms of life cost.
19  Java Game APIs & Engines / Tools Discussion / Re: How to use windows fonts in Netbeans? on: 2005-02-02 03:58:34

Doesn't work. If the question could be solved that easily then it isn't worth asking. Smiley

Netbeans doesn't even detect the font exists.

Mine did it for years. Maybe we have different format of the same font?

IIRC bitmap fonts are not supported by Java, only TTF are.
20  Java Game APIs & Engines / Tools Discussion / Re: How to use windows fonts in Netbeans? on: 2005-01-26 15:28:22
The raize font is the programmer's best friend I like it!
21  Java Game APIs & Engines / Tools Discussion / Re: How to use windows fonts in Netbeans? on: 2005-01-26 15:27:55
Tools/Options/Editing/Editor Settings/Java Editor

Font & Colors property.

BTW it has an online help, just typing F1 and font in the search box should have answered your question Smiley
22  Java Game APIs & Engines / Tools Discussion / Re: Netbeans as powerful as Eclipse? on: 2005-01-26 15:24:00
Oh I don't want to start a Flame war.

Aside what I like is clear that the days where lightweight apps were heavyweight in performance are far behind! Smiley
23  Java Game APIs & Engines / Tools Discussion / Re: Netbeans as powerful as Eclipse? on: 2005-01-26 15:21:16
Aside the font matter all the issues you note are in reality just equivalent features, one can not just switch IDE and feel itself at home...

BTW at least NB doesn't destroy your project if it core dumps (like I saw in IBM Italy, two weeks ago). Having an IDE built upon not so stable (and cross platform) native libs is evil.

I regret to not have come down with my NetCat 4.0 shirt (the one about working in the dark).

When I use Java I try to use Java tools, expecially because my platform floats a lot (from solaris to windows passing by linux) and having to rely in buggy native libraries to do my day to day work is not so cool.
It's just like I was working with GTK 1.x... Wink

But aside these babbles my greater concern is about the memory (and CPU power) IBM tools eat. WFT using Poseidon is 5 times better than using Rational Rose, Using NB (that is native java) is 2 times better than using Eclipse (that has native OS support on its roots)?

Not to mention using the two on really dated software like a P3 400 or a Ultra5... Only NB was usable in these context for a mammoth projects (5 webservices + 2 webbaps using 40 libraries and a total of near 600 classes source files + Tomcat + MySQL).

24  Java Game APIs & Engines / Xith3D Forums / Re: How to get object picking system work? on: 2005-01-26 04:45:50
My 2 cents are that you are testing the root node of the scenegraph too, and it ALWAYS intersects the ray, unless you panned the view far away all the objects in the scene. In Xith3D nodes in an higher hierarchical level have bounds built to include all their own children.
I will leave the root node out of the loop and all should be fine.

To get picking working you should place all the pickable objects on a branch (it's what I do), so you can test only what you need, otherwise, if you have lots of things on screen is difficult to maintain good performance.
25  Java Game APIs & Engines / Java 2D / Re: It's official, Sun's Opengl pipeline is blown on: 2005-01-20 06:41:52
Having worked (and often working even these days) on C++  (other than Java) OpenGL games and apps I can just confirm what was said.

I can also add that even Nvidia drivers have their bunch of bugs, even if they are more sided on the cutting edge 3D features (expecially extensions) and so for hackers and hobbysts are almost inexistant.
26  Java Game APIs & Engines / Java 2D / Re: Reviving Mini Adventure on: 2005-01-20 06:33:22
again, it's a good idea
27  Java Game APIs & Engines / Java 2D / Re: Reviving Mini Adventure on: 2005-01-18 13:35:21
The IDE concept is indeed really nice
28  Java Game APIs & Engines / Java 2D / Re: Reviving Mini Adventureconcerned by money on: 2005-01-14 16:20:27
Well, I like to contribute, too.

I worked on one of the first incarnations of POL (an Ultima Online Server) and It's a lot of time since I was involved in a no-profit game without having to worry about contracts and deadlines (and following payments that always arrive late).
29  Game Development / Game Play & Game Design / Re: XML in games? on: 2005-01-03 12:10:03
gh, sorry blah I'd have to read your post more accurately Sad
30  Game Development / Game Play & Game Design / Re: XML in games? on: 2005-01-03 12:07:56
A good request is to cleraly distinguish pre-compiled parsers based on xsd (a la XMLBeans or ANTLR if you're mad enough) to simple parsers devolped to cope with more generic XML document formats.

While the first are dead slow for overall game use, the second are blazing fast (since the parser is tailored for your XML and your only) and can be also viable for real time (I speak for experience on RT Mapping and Industrial Automation tools).

Many say that there is also an API issue for the w3c parsers in the Java distro (never bother to read the code though).
Pages: [1] 2 3
DesertCoockie (33 views)
2018-05-13 18:23:11

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

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

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

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

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

Solater (98 views)
2018-03-17 05:04:08

nelsongames (179 views)
2018-03-05 17:56:34

Gornova (405 views)
2018-03-02 22:15:33

buddyBro (1065 views)
2018-02-28 16:59:18
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!