Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (539)
Games in Android Showcase (133)
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 5783 times)
0 Members and 1 Guest are viewing this topic.
Online princec

« JGO Spiffy Duke »


Medals: 435
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #30 - Posted 2003-01-23 19:08:50 »

Look, if anyone put SPGL or anything remotely like it in LWJGL I'd just forget it all and start over. I want the minimum required in the LWJGL to write games. Absolute minimum. The way I do a sprite library is pretty different I imagine than the way anyone else would do a sprite library. Only today I discovered what relying on just a tiny piece of someone else's idea of how to do things costs me (see diary for pathetic sorting performance). Read how Michael Abrash discovered something interesting about memcpy().

It's still a "G"ame library because we don't have any pretensions to integration with AWT and the native methods we've got are methods you need in games and that can't be done in Java (or can't be done in Java unless you have AWT).

If it can be done in Java it belongs in someone else's library.

If this means creating a subproject in LWJGL and calling it org.lwjgl.util.* then that's fine, but if it involves more native code, it's no longer the LWJGL.

Cas Smiley

Offline gregorypierce

Senior Devvie




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


« Reply #31 - Posted 2003-01-23 20:05:34 »

Quote

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


No, I'm saying that the naming of lwjgl probably will continue to cause some issue to those who see the words "game" and "library" and assume that its something they can use to create games in Java, when in reality its not a game library.

I'm also saying that one should monitor the requests for support that are coming in and address them within the framework of lwjgl. If people keep coming in and trying to figure out how to put text on the screen or load textures and no solution is provided - the library will not be used, plain and simple. Its not a gaming library just because it isn't tightly coupled to the AWT.

Bah, I've spent too much time belaboring this point Smiley The line should be clearly defined between what is considered lightweight enough to go into lwjgl and what isn't. But again, I've got my own solutions now so I'm really just trying to make sure the technology itself doesn't end up being neglected for the wrong reasons. People should not use it if it doesn't work for them, not because they can't figure out how to define a light in a bytebuffer.

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 markuskidd

Junior Devvie


Medals: 1



« Reply #32 - Posted 2003-01-24 00:25:23 »

Quote
Look, if anyone put SPGL or anything remotely like it in LWJGL I'd just forget it all and start over. I want the minimum required in the LWJGL to write games. Absolute minimum.


The absolute minimum required to do games is not a lightweight games library, plain and simple; therefore you should really rethink your project's name Cheesy.

Quote
It's still a "G"ame library because we don't have any pretensions to integration with AWT and the native methods we've got are methods you need in games and that can't be done in Java (or can't be done in Java unless you have AWT).


That doesn't make it a game library, since there's nothing specifically game-centric about it. AWT in and of itself has nothing to do with gaming specifically, and therefore your lack of pretensions relating to the AWT brings nothing to the table for your argument. Wisely, Sun chose a fitting name; the Abstract Windowing Toolkit, which describes the package's function. In the case of the LWJGL's current functionality, something like "The Lightweight Java Media and Graphics Toolkit" would be approprite. As far as I see it, the success or failure of this library to achieve far-reaching success for Java game development will be whether or not developers can be convinced it is the right tool for the job. If the name of the library is in any way misleading, it's going to be one more obstacle in the path of its acceptance.

edit: this is probably the last I'm going to contribute to the conversation, since I think I've made whatever point I'm trying to make Smiley I'll let the more qualified ones take over
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 #33 - Posted 2003-01-24 04:16:47 »

Quote

If this means creating a subproject in LWJGL and calling it org.lwjgl.util.* then that's fine, but if it involves more native code, it's no longer the LWJGL.


Yeah, this is where I am headed too.
So we'll add a bit supportcode to lwjgl, however we will distribute this code in the lwjgl_optional.jar - thus we still have a core library and a support library for making it easier to use lwjgl.
We have audio loading done, so we need classes for textures and fonts, right?

Regarding native code - controlling a cdplayer can hardly be a core requirement? - anymore than say moving the window around the screen (which we currently can't do)?

So if we choose to implement it, should some of the native code be implemented in a lwjgl_optional.dll instead of everything in the lwjgl.dll ?

Online princec

« JGO Spiffy Duke »


Medals: 435
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #34 - Posted 2003-01-24 09:01:31 »

I want anything requiring native code in the core library; and anything not requiring native code to be in the optional library, by and large. I think the CD player therefore is a core requirement. It's tiny anyway.

The Vector classes might end up in the optional library actually. They shouldn't really be in there at the moment. I can see people wanting to use javax.vecmath instead for example.

Cas Smiley

Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


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

I'd lean towards the idea of putting any 'pure java' util classes in an optional _lib jar, and then if it becomes apparent that they're hevily used moving them into the core. Likewise, anyone using just a few _lib classes can always produce a custom trimmed down version of the optional classes but still keep the core.

If the Cd player is as minimal as Cas mentioned, then it should be in the core - after all, its not something done via pure java. Some sort of optional .dll's could be a sticking point though. I'd suggest a _lib dll, and then playing it by ear on how much gets used etc.

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

Junior Devvie





« Reply #36 - Posted 2003-01-24 16:26:52 »

Ah, is there a way to set the title of the window in windowed mode? That would be my request for 0.5 ;-)
Anyone else has problems with window mode? Whenever my window gets obscured partly by another window and then comes back to front it is all white and nothing more will be redrawn (WinXP, J1.4.1_01).

And a lwgl.jar ready as a standard extension for easy deployment with applets on windows and linux. It's not that hard, add a manifest, add a little class to unpack the *dll or *so and sign it (with a fake certifikate if needed).
Offline EgonOlsen
« Reply #37 - Posted 2003-01-24 17:56:44 »

Quote
Ah, is there a way to set the title of the window in windowed mode? That would be my request for 0.5 ;-)
Anyone else has problems with window mode? Whenever my window gets obscured partly by another window and then comes back to front it is all white and nothing more will be redrawn (WinXP, J1.4.1_01).
I have the same problem under WinXP. Under Win2K, the window works quite well and under Win98, it's only visible if no other window gets the focus. The windowed mode definitly needs some work.

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 (37 views)
2014-12-15 09:26:44

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

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

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

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

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

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

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

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

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