Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (538)
Games in Android Showcase (132)
games submitted by our members
Games in WIP (601)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Lightweight Java Game Library - Opinions, please..  (Read 6126 times)
0 Members and 1 Guest are viewing this topic.
Online princec

« JGO Spiffy Duke »


Medals: 429
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Posted 2002-10-29 14:44:34 »

We are considering splitting the LWJGL deployment up into separate .dlls and .jars for core, input, opengl, openal, and vector.

Our reasoning is that it's entirely probable you won't be using all of the features - particularly the vector code. Or if you're just doing tiny graphics demos you might not want to ship the OpenAL stuff. Etc. Perhaps all you want is a hires timer?

So votes please: to SPLIT or NOT TO SPLIT?

Cas Smiley

Offline zparticle

Senior Devvie




Thick As A Brick


« Reply #1 - Posted 2002-10-29 14:49:23 »

I have yet to have a chance to look at this but it seems to me that unless the code base is already getting large (> 2 meg) splitting it up right now just wouldn't be worth the trouble.

Offline Matzon

JGO Knight


Medals: 19
Projects: 1


I'm gonna wring your pants!


« Reply #2 - Posted 2002-10-29 18:53:59 »

Heh - it said *Lightweight* jgl  Grin

alpha 2 is ~ 440 kb, this includes:
lwjgl.jar - jar file - needed (156kB, compressed)
EaxAC3.dll - OpenAL Eax + Ac3 Support - not needed, I am speculating (24 kB compressed)
lwjgl.dll - Actual native implementation - needed (64kB Compressed)
lwjgl_d.dll - Debug native implementation - not needed (131 kB Compressed)
OpenAL32.dll - OpenAL Implementation - needed, since most don't have OpenAL installed (61 kB compressed)

So we end up with:
lwjgl Jar file + native dll + OpenAL32.dll = 281 kB

Rather small. But *if* someone where to do an OpenGL application, not using vector code or OpenAL or Input, why should the user then dwl it?

I am a bit torn on this one - theoretically I am all for splitting it up, but is it worth the effort?

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Herkules

Senior Devvie




Friendly fire isn't friendly!


« Reply #3 - Posted 2002-10-30 07:53:47 »

Definetely: SPLIT!

Think of a webstart application and rapidly changing LWJGL implementations. Splitting will reduce d'load times....

HARDCODE    --     DRTS/FlyingGuns/JPilot/JXInput  --    skype me: joerg.plewe
Offline kents1

Senior Newbie




Java games rock!


« Reply #4 - Posted 2002-10-31 07:22:01 »

I personally don't think it's worth it.  Especially to the extent Cas it talking about.
Maybe just consider splitting out OpenAL from the rest..but again, if it were me, I really wouldn't bother.
Online princec

« JGO Spiffy Duke »


Medals: 429
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #5 - Posted 2002-10-31 08:37:08 »

Well, we'll try an experiment and see.

Cas Smiley

Offline Chman

Junior Devvie




Nothing more that... Java games are cool !


« Reply #6 - Posted 2002-11-02 08:58:45 »

Split... personnally, i use all features (openal, input, vector) but it would be better for people who don't...

LWJGL is a great lib...

Ch*man
Offline cknoll

Junior Devvie




Flame On!


« Reply #7 - Posted 2002-11-08 13:36:13 »

Hi,
 I think it's a good idea to split it up.  I consider it similar to the apache's large repository of projects/libraries, it would be painful if I had to download all of apache.org's software just to get at something simple.  Unfortunately, the name 'Lightweight Java Gaming Library' implies a sort of monolithic chunk of code that you use to build games with.  I'm not sure exactly how to address this, but the concept of 'packages' comes to mind.  You could still keep the 'Library' name (in the sense that a real library has many books in it) but break out the components of the library into packages, such as OGL APIs, timing, sound, Graphics, Vectors, Pathing, etc.  It could be that there are dependencies between these packages, but I don't think that should mean you need to bundle it all together.  (for example, the FOP project form apache requires many other packages from other apache projects for it to operate (xalan, xerces, batik, ant (compile only), some SVG stuff, etc).  It's the responsibility of the developer to know what package dependencies exsist if you are going to use a certain package.  This also means that improvements can be made to very localized sections of an entire library....in addition to being ablet o pick and choose the sections of the library you needed (Could you imagine if you only wanted information in volume X of an encyclopedia but they said you need to chck out the entire encyclopedia if you want it!  would suck...)

-Chris
Online princec

« JGO Spiffy Duke »


Medals: 429
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #8 - Posted 2002-11-10 12:46:15 »

Right now the library is organised in a way that makes it highly amenable to being split, and also provide the full distribution as well because it's just not that complex.

There's a "core" LWJGL, which contains a few basic utilities required by most users of the library, such as pointer fiddling and hires timers. Currently the vector maths is in there too (but not the vector packages).

As dependents of the core LWJGL package we've got input, OpenGL, and OpenAL, which are easy to split out of the Java distribution although it's slightly fiddlier removing the C++ parts because you need a C++ compiler to hand.

I think I'm right in saying that we never intend to add more to the LWJGL than the bare minimum required to write a high-performance Java game in Java without having to code your own C++ to do something for you, so it is unlikely to ever grow significantly larger than it already is. A lightweight monolith...

Cas Smiley

Offline gregorypierce

Senior Devvie




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


« Reply #9 - Posted 2002-11-11 17:46:56 »

Spplit it.... that way when it reaches 1.0 I only have to worry about porting the portions of the system that I really want to port Smiley

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 Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #10 - Posted 2002-11-11 19:03:26 »

Since someone trying to play my 48-hour game has it crash out straight away with "The procedure enty point alcGetEnumValue could not be located in the dynamic link library OpenAL32.dll", despite me no having any sounds at all  Shocked I'd say a split would be preferable if only to avoid such situations.

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline Matzon

JGO Knight


Medals: 19
Projects: 1


I'm gonna wring your pants!


« Reply #11 - Posted 2002-11-11 19:57:20 »

Hmm

The OpenAL part shouldn't be loaded, unless you reference it?

and even though you do,  'alcGetEnumValue' *should* be defined in the dll:
section 6.3.5 of the OpenAL Sepcification:
uint alcGetEnumValue (const ALCdevice * deviceHandle, const ubyte enumName);

Does your friend have his own OpenAL.dll, which somehow got loaded instead of the one you're supplying?

Can you reproduce the error, and if so - get the full source codes to lwjgl, and run org.lwjgl.openal.test.ALCTest and tell me the results...
the following works fine here at my end:
       

//get an enumeration value
System.out.println("Value of ALC_MAJOR_VERSION: " + alc.getEnumValue(device, "ALC_MAJOR_VERSION"));


Huh

Offline gregorypierce

Senior Devvie




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


« Reply #12 - Posted 2002-11-18 02:49:53 »

Personally I would have preferred that most of this stuff was just set up using SPIs (service provider interfaces) so I could replace the OpenAL stuff with easier to use and more capable platform specific sound engine (for OSX).

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 #13 - Posted 2002-11-18 03:14:51 »

well, then it wouldn't have been Lightweight  Wink
Anyhows - the library is specifically tied to OpenGL and OpenAL - what would the point be of a SPI?

If one was to do what you're talking about, then we would be talking about a completely other game library, one which didn't expose how it played sound or draws graphics. This just isn't what we wanted to do. We wanted to create a library that is a fast as possible to use, from within java - we acknowledge that some might be turned of by having to use OpenGL or OpenAL (and any of the other packages), but we did this to allow for people to do it as fast as possible. That said, we do expect people to build a library on top of lwjgl for easier usage. (see: http://sourceforge.net/projects/spgl)

Pages: [1]
  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 (29 views)
2014-12-15 09:26:44

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

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

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

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

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

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

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

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

toopeicgaming1999 (30 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!