Ya SDL is great…
What kind of function do u want to developp ???
base functions (copy, rectangle…) or advanced functions (scrolling, layers, various 2d effect library …) ??
Ya SDL is great…
What kind of function do u want to developp ???
base functions (copy, rectangle…) or advanced functions (scrolling, layers, various 2d effect library …) ??
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.
Cas
As far as I know, the old DirectDraw interface only allows non-alpha’d bliting, so using that is not really practical.
A point to bear in mind could be making coversion into a Gl texture nice and easy, so people can use the 2d routines for altering textures on the fly
and for images, if you won’t use AWT, what would you use ? an extra lib ?
I seem to get by without it…
Cas
vrm: If you look in the spgl, you’ll see that all images used, are processed ahead of time by the awt package, and then saved in raw form as a .jgimage.
won’t help the game download time ;D
The jgimage format is compressed, and I’ve always got a smaller file size than the png its created from.
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
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.
i don’t have any costs for traffic so i don’t care!
i would agree with mill. first, fill lwjgl out and once you’re all out of neat little features to add (ha!), build lwjgl2d on top of it.
this will allow for the 2d api to be a seperate download (one far less than 5mb!). additionally, the api will use OpenGL (better speed, features, compatibility).
As for SDL…