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).

Well - you know I am in - 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...

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).

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.

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?

yep

Quote

Anyways, even without that dll LWJGL approaches your "~500 KB".

well, lwjgl is 14,4% smaller than 500 kB

Quote

Thats funny since SDL dll is only 220 KB.

except jsdl needs smpeg.dll too and the jar:

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

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

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 - 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...

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.

What's needed is a general-purpose library for allocating, locking, unlocking, and deallocating video RAM for starters - this can't be done from Java minus AWT.

Then what's needed is a blitting function which will copy areas of memory from A to B in various formats, using MMX, SSE or Altivec depending on what's available, which also is not available from Java. Under Win32 it's possible we get some blitting functions for free in DirectX but I'm not so sure they support alpha which is a definite requirement. At the end of the day you can still write your own blit routines direct to the memory but we're confident the C/#asm routines will be a lot faster.

The API will be very, very, simple, and might have some GL-like state in it. I'm thinking of a design right now.

Weird, I never noticed that before.They zip up further a teeny little bit too.I was wondering whether to do a little more clever compression on them as well, perhaps storing deltas, or deltas of colour planes, which often compress better.

cas: i'd suggest you finish lwjgl first and then start on the 2d stuff.

why not put lwjgl2d on top of lwjgl directly? that would make it a tad bigger.

as a side note i don't 100% agree with your download size theory. 5 mb is small nowaways and the percentage of people having fast internet access is very high here in sweden.

besides, i'm thinking of making my current game very big, perhaps hundred mbs. people might think "whoah, it seems like a proper game" or something of course, a small 15 mb version wil be available too. it's the music that takes up space. a couple of songs in mp3 format = big file size.

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