Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (539)
Games in Android Showcase (132)
games submitted by our members
Games in WIP (603)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1] 2
  ignore  |  Print  
  And what next ?  (Read 5761 times)
0 Members and 1 Guest are viewing this topic.
Offline Chman

Junior Devvie




Nothing more that... Java games are cool !


« Posted 2003-01-19 13:53:39 »

What will bring the future version of LWJGL ? because version 0.4 seems very complete...

++
Chman
Offline princec

« JGO Spiffy Duke »


Medals: 434
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #1 - Posted 2003-01-19 14:30:23 »

- keyboard translation (should make it into 1.0)
- donate the screen mode selection code from SPGL as it seems to be universally useful
- considering fast 2D surface & blit API for systems without OpenGL support
- considering ogg vorbis decompressor
- considering CD player controller
- any other suggestions which meet general approval

Cas Smiley

Offline Chman

Junior Devvie




Nothing more that... Java games are cool !


« Reply #2 - Posted 2003-01-19 15:15:02 »

what is keyboard translation ?
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline gregorypierce

Senior Devvie




I come upon thee like the blue screen of death....


« Reply #3 - Posted 2003-01-19 15:50:29 »

- Moving issue and bug tracking to JIRA (underway)
- Gathering screenshots and tech demos
- Addition of utility code to make it easier to make games, since its not *just* a binding

http://www.gregorypierce.com

She builds, she builds oh man
When she links, she links I go crazy
Cause she looks like good code but she's really a hack
I think I'll run upstairs and grab a snack!
Offline Chman

Junior Devvie




Nothing more that... Java games are cool !


« Reply #4 - Posted 2003-01-19 15:56:28 »

no, i think lwjgl sould only be a binding... else it will become a big library and it won't be interesting to use it only for opengl... look at the SPGL if you want a game library...

screenshots support is a very good idear...

for tech demos, look at my website... http://chman-area.tuxfamily.org (if you have some demos, please send me a link and a short description)

++
Chman
Offline gregorypierce

Senior Devvie




I come upon thee like the blue screen of death....


« Reply #5 - Posted 2003-01-19 16:23:04 »

Its a lightweight game library (according to its name) so it should actually provide some assistance for actually building games... but this is something that has been debated in the development group for some time now. Adding functionality for texturing, easily loading a shader, etc. will in no way make the API large (because all of this is *utility* code which is optional and you don't need to carry it around).  The point is to give people stuff so that they can get up and running quickly in order to increase the adoptance of lwjgl.

We aren't talking about adding in a scene graph, for example.

http://www.gregorypierce.com

She builds, she builds oh man
When she links, she links I go crazy
Cause she looks like good code but she's really a hack
I think I'll run upstairs and grab a snack!
Offline princec

« JGO Spiffy Duke »


Medals: 434
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #6 - Posted 2003-01-19 17:52:38 »

It's still a separate layer though. No harm in that; people always like to find their own way of doing things, especially programmers. I don't think everyone would be too pleased if I forced SPGL down everyone's throat.

Cas Smiley

Offline Jacko

Junior Devvie





« Reply #7 - Posted 2003-01-19 18:49:48 »

How about formalising some idea of LWJGL plugins?

These could be additional "bits"  that you can download from the sourceforge site for specific purposes, or if you want to, you could still roll your own.

Just an idea off the top of my head...

Offline elias

Senior Devvie





« Reply #8 - Posted 2003-01-19 18:51:58 »

chman: http://www.JavaGaming.org/cgi-bin/JGOForums/YaBB.cgi?board=volunteer;action=display;num=1041779009

- elias

Offline gregorypierce

Senior Devvie




I come upon thee like the blue screen of death....


« Reply #9 - Posted 2003-01-19 19:17:29 »

Quote

No harm in that; people always like to find their own way of doing things, especially programmers. I don't think everyone would be too pleased if I forced SPGL down everyone's throat.


I certainly don't disagree with that.  The big thing that I'm running across are things like:

a) looks interesting, but I can't fingure out how to texture map through NativeByteBuffers

b) how do I create a shader and render with it

c)  how to I render a vertex array

d) how do I set up multiple rendering passes


Everyone who might be interested in using lwjgl is all that interested in the actual implementation details as much of it is much lower level than some Java developers care to get - especially since they really don't care how it works... just that it works, and that they have the ability to override the default implementation later if they so choose.

LWJGL certainly gives people the flexibility to do whatever they want - but a newcomer adopting lwjgl is really left with a lot of questions and frustrations. I personally don't have any issues, but it would be ashamed to see good technology go to waste because the people most likely to adopt it don't because Java3D is just easier to get working with.


http://www.gregorypierce.com

She builds, she builds oh man
When she links, she links I go crazy
Cause she looks like good code but she's really a hack
I think I'll run upstairs and grab a snack!
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Matzon

JGO Knight


Medals: 19
Projects: 1


I'm gonna wring your pants!


« Reply #10 - Posted 2003-01-19 19:52:25 »

but lwjgl should still be an enabling technology - not nescecarily an easy to use library...
All the "fancy" stuff should be in a optional jar, and not in the lwjgl.jar - as already discussed on irc.
But it is a very thin line - on one hand we want it to be lightweight and other hand we want it to actually be usefull...

Offline erikd

JGO Ninja


Medals: 16
Projects: 4
Exp: 14 years


Maximumisness


« Reply #11 - Posted 2003-01-20 07:45:16 »

For what it's worth, I like lwjgl to stay small and yes I think it should be nothing more than enabling technology.
Sort of like becoming for java what directx is for windows (at least I *think* so, not knowing all that much about dx  Grin)
As for adopting the technology, I think it's being adopted not that bad at all, looking at what Egon Olsen is doing with it with his jPCT for example (which I think is pretty cool).
But, I think many people hesitate to start using it because they think something like 'it's low level, it's got pointers, it's directly binding to ogl, it's for professionals ooh... difficult!' (or maybe that was just me  Grin). But when you actually start looking and playing with the examples, then it turns out to be not that hard at all.
I found understanding j3d for doing basic stuff a lot harder than lwjgl even though I'm only scratching the surface yet.
Maybe it could do with a little more documentation or at least a readme with something useful like 'how to start an example' (I didn't know the dll had to be in the root for example). Also, the current documentation stretches the point a little too much that it is 'aimed at professional games developers' for my taste which adds to the perception that it is too hard for 'hardly professional game developers' like myself  Tongue
I believe people can judge for themselves if they're up to using it or not by just reading what it is and what it isn't.

Well that's my 2 cts.

Greetings,
Erik

Offline elias

Senior Devvie





« Reply #12 - Posted 2003-01-20 08:11:45 »

Well, isn't all that documented after all. But yes, we could sure use some basic setup instructions. OpenGL docs are out there in the thousands, so we really only have to document the obscure parts of lwjgl thoroughly.


- elias

Offline princec

« JGO Spiffy Duke »


Medals: 434
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #13 - Posted 2003-01-20 09:14:11 »

Maybe I might explain a couple of the most common things like "how do I load a texture?" and stuff which I've done do death for a couple of years now.

Cas Smiley

Offline cknoll

Junior Devvie




Flame On!


« Reply #14 - Posted 2003-01-20 12:34:41 »

A CD controller in a gaming library?  I think you're beginning to take a step down the dark path...

Why not call the featureset of the LWJGL complete and make a LWJMU (light weight java multimedia utilities) that has those sort of things in it.


-Chris
Offline Captain-Goatse

Junior Devvie




I suck at teh 2D. XBOX IS BIG LOL!111


« Reply #15 - Posted 2003-01-20 15:17:26 »

Quote
A CD controller in a gaming library?  I think you're beginning to take a step down the dark path...

Why not call the featureset of the LWJGL complete and make a LWJMU (light weight java multimedia utilities) that has those sort of things in it.


-Chris



Exactly. I think LWGL would loose its purpose if it'd have all these things. CD controller is not exactly game related, where as sound system would be. However, why not make these things as plugins? MP3 plugin would be great as well as some way to play AVIs, but cd cntroller?

I like the way LWGL is kept abstract, usually the point where i stop using certain apis is when they take control and become part of the programming. APIs are supposed give me the ability to take advatange of things I wouldn't otherwise be able to use.

I agree with lw multimedia package. If you begin to do this, at least leave a stripped down version of LWGL without these "great" abilities.
Offline cfmdobbie

Senior Devvie


Medals: 1


Who, me?


« Reply #16 - Posted 2003-01-20 16:55:16 »

I was under the impression that all these things effectively *would* be plugins...?  Huh

Considering late-loading of DLLs, proper separation of functionality into different packages etc, is there any reason why you can't just not distribute the "CD player" DLL and jar?

Hellomynameis Charlie Dobbie.
Offline Matzon

JGO Knight


Medals: 19
Projects: 1


I'm gonna wring your pants!


« Reply #17 - Posted 2003-01-20 18:31:46 »

as much as humanely possible, all dll's will be loaded dynamically. That said, some features will have to be in the lwjgl.dll, which is the core - however, any features - and this is where the community comes in - will be made part of the core or made optional depending on what *you* say.

The two main reasons for determaning whether a class is part of the core, or optional are size and relavancy - both of which should be discussed when any feature is implemented.

Offline Matzon

JGO Knight


Medals: 19
Projects: 1


I'm gonna wring your pants!


« Reply #18 - Posted 2003-01-20 18:37:11 »

Quote

Considering late-loading of DLLs, proper separation of functionality into different packages etc, is there any reason why you can't just not distribute the "CD player" DLL and jar?


Yes. We load OpenGL and OpenAL dynamically since they're rather large, and you might want to run lwjgl without oal or ogl. However at the moment ALL native code is deployed in one dll - we have discussed (and turned down) the option of having a package containing
lwjgl_core.dll
lwjgl_gl.dll
lwjgl_al.dll
lwjgl_vector.dll
lwjgl_input.dll
we could then add a _cd and a _vorbis - which would make it all more dynamic - at the price of clutter...

We might in the future split the dll, but I don't think this will happen for 1.0 - but then again - if this is what people wan, we will most likely do this...

Offline princec

« JGO Spiffy Duke »


Medals: 434
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #19 - Posted 2003-01-20 19:48:12 »

Whilst the .dll and .jar combined come in at under 300Kb I don't think there's any reason to split anything up as it's just not worth the bother. But because we're open source there's nothing stopping you from splitting it up yourself.

RE: a cd player being beyond the remit of game functionality - there are many games which have relied on CD music tracks for one reason or another, and currently this is not possible for Java, so we can enable this. It's probably going to cost about, ooh, 8Kb on the library. Big deal.

RE: plugins, I think we'll be making all external dependencies dynamically loaded from now on as it seems to be really easy if a little more onerous to code. (Heh - thanks elias Smiley )

RE: ogg, it'll be very small, and very very useful to a lot of developers. It isn't, however, necessary to put it in LWJGL because it is entirely possible in pure Java or as a 3rd party lib - all you need is to be able to stuff bytes in a buffer and stream it out using OpenAL. So probably not.

RE: 2D, more and more I think this is going to be essential for those older systems without 3D cards. We have something in Java1.4 now called VolatileImage but of course it relies on the huge AWT infrastructure and licensing so really, we've got to do it or there'll be no graphics on my old laptop Sad

Cas Smiley

Offline princec

« JGO Spiffy Duke »


Medals: 434
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #20 - Posted 2003-01-20 19:50:12 »

Oh, and we need someone clever with #asm, MMX, SSE, and Altivec to write proper optimised code for the vector processing part, because currently it's just straight C.

Cas Smiley

Offline gregorypierce

Senior Devvie




I come upon thee like the blue screen of death....


« Reply #21 - Posted 2003-01-21 00:51:36 »

Quote

Sort of like becoming for java what directx is for windows (at least I *think* so, not knowing all that much about dx  )


Yeah, bad comparrison because with DX there is a metric assload of utility code for everything from loading shaders to loading models in the DirectX distribution.

But I've already said my peace on the matter. I'll add anything else I need to add outside the framework of LWJGL.

In order for any API to be adopted it must be heavily documented and provide enough sample code and utilities such that a person can get up to speed fast enough to put together a demo to see what the strengths and limitions are. As long as that path remains difficult for all but people close to the project or those familiar with NativeBuffers and able to read through and understand the sample code, just don't expect it to be more than just another Java OpenGL binding (because really I don't know a single person clamoring for a binding to OpenAL as sound, nor input were never really a problem).

I think that not providing these ease of use benefits is a critical mistake. But, of course, I want it to be more than just another API.

http://www.gregorypierce.com

She builds, she builds oh man
When she links, she links I go crazy
Cause she looks like good code but she's really a hack
I think I'll run upstairs and grab a snack!
Offline Matzon

JGO Knight


Medals: 19
Projects: 1


I'm gonna wring your pants!


« Reply #22 - Posted 2003-01-21 03:14:20 »

Quote
just don't expect it to be more than just another Java OpenGL binding (because really I don't know a single person clamoring for a binding to OpenAL as sound, nor input were never really a problem).

That depends on what is available in the optinal package.

Regarding OAL - have you actually tried using Java sound for a game? - I find it rather unusefull. The latency is just waaay to high.  Though the mix n bytes approach might work better in JavaSound...

Offline erikd

JGO Ninja


Medals: 16
Projects: 4
Exp: 14 years


Maximumisness


« Reply #23 - Posted 2003-01-21 06:44:49 »

Quote
RE: 2D, more and more I think this is going to be essential for those older systems without 3D cards.

Yes I totally agree. OGL on my old laptop is dead slow.

Quote
Yeah, bad comparrison because with DX there is a metric assload of utility code for everything from loading shaders to loading models in the DirectX distribution.

Ok, I take it back Grin.
I'd hate lwjgl to become as big as dx anyway, but it would be nice if it would get the same 'status' as a standard for building games on.

As for CD support, I think that's typically the kind of thing LWJGL would need to include and NOT become a plugin. Unlike ogg or mp3.

Erik

Offline gregorypierce

Senior Devvie




I come upon thee like the blue screen of death....


« Reply #24 - Posted 2003-01-21 15:30:32 »

Quote

That depends on what is available in the optinal package.

Regarding OAL - have you actually tried using Java sound for a game? - I find it rather unusefull. The latency is just waaay to high.  Though the mix n bytes approach might work better in JavaSound...


Yes, I just used the SPI interface to add in what I needed.

http://www.gregorypierce.com

She builds, she builds oh man
When she links, she links I go crazy
Cause she looks like good code but she's really a hack
I think I'll run upstairs and grab a snack!
Offline princec

« JGO Spiffy Duke »


Medals: 434
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #25 - Posted 2003-01-21 19:52:06 »

I've got to put me foot down about LWJGL:

All it is is an enabling technology for Java games programmers, the very minimum required to allow you to do the things you can't otherwise do without help from Sun (eg. AWT, JavaSound, Java3D). Any more than that belongs in another library on top of it - and that's exactly what we'd like to see happen - the "HWJGL", with all the extra cream and sugar in it.

Cas Smiley

Offline markuskidd

Junior Devvie


Medals: 1



« Reply #26 - Posted 2003-01-21 20:02:39 »

I think simply by virtue of the word "library" you are implying that there is going to be code that lies in that wide, gray expanse between the category of game engine and that of driver-wrapper. One test you developers might also perform mentally is to ponder whether wrappers for OpenGL, OpenAL, et al. and some Vector-related code actually constitute a game library by any other criteria than that it brings together some assets which *can* be used for game making. I realize I'm coming at this in a roundabout way, but it seems like if it is to be called the Lightweight Java Game Library, it should be in a form which is immediately usable in coding a game. I assert that, if it appears that the LWGJL is unusable in it's current form in 90% or more situations (ie it requires middle layer of tools or interfaces) then it is perhaps best called something more indicative, the Java I/O and Graphics Library or something in that vein.

Either route will produce something useful, but these are just my thoughts. I'm sure you guys who are actually working on this will come up with a workable solution.
Offline Matzon

JGO Knight


Medals: 19
Projects: 1


I'm gonna wring your pants!


« Reply #27 - Posted 2003-01-22 04:53:00 »

Quote
I realize I'm coming at this in a roundabout way, but it seems like if it is to be called the Lightweight Java Game Library, it should be in a form which is immediately usable in coding a game.

Yeah, but then again lightweight is also a part of the name, which implies that some of the more advanced stuff is left out - or at least not in the core distribution.

Quote

I assert that, if it appears that the LWGJL is unusable in it's current form in 90% or more situations (ie it requires middle layer of tools or interfaces) then it is perhaps best called something more indicative, the Java I/O and Graphics Library or something in that vein.

Agree 100%. Which is why we have examples and we have some basic utility classes (WaveData for instance). We need to seperate between must/should/could/won't have (MoSCoW).
lwjgl is first and foremost an enabling technology, that is we provide the interface for some of the stuff that just isn't possible from the Java framework. Secondly we are a game library and as such whatever features we implement must be relevant for games - not general applications. Thridly - the above statements doesn't exclude utility classes, that make life easier - but they should be placed in any optional package, so that _everybody_ doesn't get a copy, even though they don't need it. And this is exactly the problem with the lwjgl.dll - it contains _all_ native code - this means (at the current point in time) that all features we implement that need native access _will_ be distributed to all developers, regardless if they need it or not. We therefore need to evaluate any feature that requires native code, while any Javacode may be added whenever someone adds a nice general utility class.
Lwjgl will never become a fullfledged game library - this we leave to others (ie. spgl).

Offline gregorypierce

Senior Devvie




I come upon thee like the blue screen of death....


« Reply #28 - Posted 2003-01-23 16:46:18 »

Quote

I realize I'm coming at this in a roundabout way, but it seems like if it is to be called the Lightweight Java Game Library, it should be in a form which is immediately usable in coding a game.  


Ding. We have another winner Smiley

Quote

Secondly we are a game library and as such whatever features we implement must be relevant for games - not general applications.


This is where the trouble starts. What specifically does LWJGL do that helps one develop a game. By calling it a game library, the suggestion is made that there is functionality in it to allow the easier development of games. Otherwise its just a binding (not that that's a bad thing) or a Java Native Media Acceleration Framework. During the marketting of LWJGL these are the types of emails I've gotten from the several folks who chose to ask about functionality of the API.

Personally I don't see the distinction between adding in code to control a media player and adding in code to load a texture, but that's just me. I've already written all the utility code I needed for both purposes. I mean after all there are things like alerts and the like in the native binding - something I found puzzling but implemented anyways.

Quote

Thridly - the above statements doesn't exclude utility classes, that make life easier - but they should be placed in any optional package, so that _everybody_ doesn't get a copy, even though they don't need it.


Very fine undefined line between what's needed and what makes life easier. But I mean that's all cool. People are just writing their own stuff on top of the native library binding and they don't expect it to provide game related functionality anymore. I mean seriously, if a 2D game library didn't even define a sprite (part of J2MEs original problem), there are going to be issues and lots of people wasting time and energy trying to create their own sprite classes - which is what happened with J2ME.

http://www.gregorypierce.com

She builds, she builds oh man
When she links, she links I go crazy
Cause she looks like good code but she's really a hack
I think I'll run upstairs and grab a snack!
Offline Matzon

JGO Knight


Medals: 19
Projects: 1


I'm gonna wring your pants!


« Reply #29 - Posted 2003-01-23 17:47:53 »

Quote

This is where the trouble starts. What specifically does LWJGL do that helps one develop a game. By calling it a game library, the suggestion is made that there is functionality in it to allow the easier development of games. Otherwise its just a binding (not that that's a bad thing) or a Java Native Media Acceleration Framework. During the marketting of LWJGL these are the types of emails I've gotten from the several folks who chose to ask about functionality of the API.

So what you're saying is that spgl and lwjgl should be merged?

Pages: [1] 2
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

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

The first screenshot will be displayed as a thumbnail.

rwatson462 (30 views)
2014-12-15 09:26:44

Mr.CodeIt (22 views)
2014-12-14 19:50:38

BurntPizza (43 views)
2014-12-09 22:41:13

BurntPizza (77 views)
2014-12-08 04:46:31

JscottyBieshaar (38 views)
2014-12-05 12:39:02

SHC (52 views)
2014-12-03 16:27:13

CopyableCougar4 (50 views)
2014-11-29 21:32:03

toopeicgaming1999 (116 views)
2014-11-26 15:22:04

toopeicgaming1999 (106 views)
2014-11-26 15:20:36

toopeicgaming1999 (32 views)
2014-11-26 15:20:08
Resources for WIP games
by kpars
2014-12-18 10:26:14

Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50
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!