2D in LWJGL

A question for all concerned with LWJGL:

Although I think OpenGL is probably the most useful graphics driver available, there remains a very large proportion of computers out there without OpenGL drivers. This matters not for those programming 3D using LWJGL, as they’re stuffed either way. But for people only doing simpler 2D operations you get 2fps from the standard MS OpenGL driver.

The large proportion of computers I’m thinking about are anything over about 3-4 years old, and nearly all laptops.

You might not care about these computers but the fact is they make up the majority of all the PCs in the world, and this means they’re a proper target for games sales. I don’t want to get into a religious discussion about hardcore gamers and marketing etc. so don’t start that here.

In order to do 2D, though, you may ask “Well why not just use VolatileImage and friends?” And the answer is because it relies on the AWT, which is a complex beast, and most importantly of all, it’s not freely distributable.

I’m proposing doing a simplified 2D API for LWJGL, which will look a little like DirectDraw or SDL in that it will give you the most basic blitting operations and the ability to grab memory addresses of bits of video memory so you can poke them directly.

Who is interested? What are your thoughts? Should it be an add-on or should we bundle it into LWJGL? (It won’t be big).

Cas :slight_smile:

Well - you know I am in ;D - this is one of my future projects - Java’s current 2D support sucks!

I am not in total agreance of what the purpose of this kit is - you seem to want the 2d kit, because of the sheer availability of cards that cannot do 3d. I want a 2d kit, because 3d adds lots of stuff I am not very interrested in, while doing a tetris close for instance…

One concern of mine have been to do a strictly 2d api, or only somekind of interface to something that can draw on screen. By using 2d only, you miss out on all the nice features of capable HW. M$ already deprecated DirectDraw, in favor of Direct3D…

[quote]Should it be an add-on or should we bundle it into LWJGL?
[/quote]
That really depends on the size of the library - sdl is ~ 100 kB packed.

If included in lwjgl, we need to change it’s purpose from 3d only to general purpose game library - which the name does actually imply - sort of …

ohh - totally forgot:
http://jsdl.sourceforge.net/

Or try SDL4Java on Sourceforge at the end of this month.

So do we reckon it’s best to just leave it well alone and let the SDL guys do it? After all, SDL’s got a bunch more stuff in it that does other things like loading images etc. hasn’t it?

Cas :slight_smile:

well sdl might be nice for some - but its dependencies wehigh in at ~ 500 kB - a bit much, not excessively much, but still…
besides I tried it jsdl, based on sdl 1.2.0 with the 1.2.5 lib ( cannot find 1.2.0) - and it was buggy as hell!

Fwiw - I’d settle for a simple 2d blitting thingy for lwjgl. What I’d really like though (which is a lot more work) is to use ogl for doing 2d, that way we will get access to fast HW and effects - which just can’t be done as fast (think rotating, translucensy and so forth).

Unless your coding applets or must have your game fit on a single 3.5" floppy, ~500 kb is really small.

Spongebob, if you’re trying to code a demo that people can be bothered to download then 500kb is huge considering it’s just supporting code.

Remember, over 5Mb and downloads drop of drastically (and that’s one of the fundamental reasons Java has really failed on the desktop).

And every meg under 5Mb downloads increase significantly.

Worth bearing in mind.

Cas :slight_smile:

princec, 500 KB is not 5 megs. Also, at last I checked LWJGL dlls weigh in more than 500 KB (actually on Windows it was 790528 bytes or 772 kilobytes).

gl dll shouldn’t be counted, as it is always available

Didnt count the gl dll in my total since I have a graphics card which puts it past the basic 1.1 version (bigger dll in otherwords compared to a basic Windows install). And OpenGL is only always present on Windows computers.

lwjgl.dll : 220
OpenAL32.dll: 88
lwjgl.jar: 120

total: 428

how does that even 772 kB ?

428 compresses to 213 kB, zip archive

I only counted the DLLs in my original figure which includes a lwjgl_d.dll. I am guessing you are not including this because its a debug dll?

Anyways, even without that dll LWJGL approaches your “~500 KB”. Thats funny since SDL dll is only 220 KB.

[quote]I only counted the DLLs in my original figure which includes a lwjgl_d.dll. I am guessing you are not including this because its a debug dll?
[/quote]
yep

[quote] Anyways, even without that dll LWJGL approaches your “~500 KB”.
[/quote]
well, lwjgl is 14,4% smaller than 500 kB :stuck_out_tongue:

[quote]Thats funny since SDL dll is only 220 KB.
[/quote]
except jsdl needs smpeg.dll too and the jar:

sdl.jar: 101
SDL4Java.dll : 24
SDL.dll : 220
smpeg.dll : 220

total: 565 kB - am amazing 32 % more than lwjgl :stuck_out_tongue:

and if this would be included in lwjgl, we’re looking at 565 + 428 = 993 kB of support code!

lwjgl wouldn’t be so light anymore…

but going back on topic ;D - sdl does a lot more than basic blitting - it is a game library in itself!
So using sdl for basic stuff seems like overkill - better to roll our own, though this will take some more time…

SDL does not require smpeg.dll. JSDL does due to how it was designed by its coders. Your point is moot since JSDL will not work with LWJGL anyways and I dont think that was ever princec intent.

yeah - ok, the Java binding for sdl requires the the smpeg.dll, because the don’t dynamically load it - like lwjgl loads opengl/al dynamically.

[quote]Your point is moot since JSDL will not work with LWJGL anyways and I dont think that was ever princec intent.
[/quote]
See - thats what happens when a thread goes OT - I get confused ;D
You’re right.

But having evaluated the sdl binding (jsdl) using current version, I can only say that it is waaaay to buggy to be of any use.

  • looking forward to sdl4java…

Hey with some fast java 2D i’ll be very happy!
I like the idea of a simple api to access the backbuffer, and some simple drawing functions. Any extra stuff can be in a util library.

SDL is more a game library, with all its extra features. All we really need is some fast 2D.

Question of bundling with lwjgl, id say they aren’t that similar and don’t need to be together. I can’t see when you’ll be using both in one project.

Just thinking about demos, don’t most of the demo writters create most/all of their graphics stuff themselves?

Mmmhhh do u know TinyPTC ???

Little library (who exist for Java). With it, u can initialize video mode and draw pixel very quickly… but only pixel draw (not rectangle, copy block or other 2d functions).

Yes i know TinyPTC. Have you looked at the source?
It hardly does anything. And it still uses the java rendering system.
I was thinking of video back buffer access, so you could draw onto the backbuffer then swap buffers to display. I would also like to see some drawing functions like draw/fill Polygon, drawOval,etc.

I like the way its done in SDL, uses a platform neutral public interface, with a platform specifc backend. Using directx 5 on windows for example.

As size is very important for many projects, having just the basic drawing facilitys in the core library, with supporting librarys to give people the option.