I've seen a few posts about the odd additive blending with alpha. Because so many people expext the alpha to be handled properly, I think replacing the blend mode implementation is reasonable. (I'm not an expert)

_________________"Artificial intelligence will never be a match for human stupidity" - "Jamos Kennedynos"

Yay, but what if you effects rlies on this effect? Where you render a alpha images normal, and for special effects with the ADD type ignoring alpha values? A test case should be added but I'm fully loaded with work :/ I will do it on weekend

Okay, then if I get the okay from the devs I do that. I implemented the ADD_ALPHA to the graphics mode and realized that the lwjgl jar was a 2.8.x Version but we use an old one so I changed it. Had no time to push it tho... Will do that if I get some free time again xD (darn work!)

Edit:Btw you got the wrong idea. I KNOW what setDrawMode is doing, I asked for an implementation like it's done in the method Or I misunderstood you^^

2002. That was 10 years ago. All the video cards that *can* run LWJGL should support OpenGL 1.4.

Also, stuff used by setDrawMode are actually aliases for GL11.blahblah, so you can use GL14.blahblah without any problems.

Slick's core (graphics, textures, fonts, etc) targets the lowest OpenGL version (GL 1.1). From there, it's up to the game developer to decide which OpenGL version to target and what extra features to include (e.g. FBOs, VBOs, shaders, what have you). If you need advanced GL14+ features, it's best to add them yourself.

If the same thing can be written using OpenGL 1.1 pipeline, then we could look into adding it.

What's the LWJGL opinion here? I mean, if they already use a minimum version of GL 1.4 (for example), we could do the same.Is there a statement somewhere? Or do they say the same: assume GL 1.1 and check for better features on your own?

LWJGL doesn't rely on any OpenGL version; it simply wraps new features in their respective GLXX class. From there, it's up to the developer to decide which OpenGL version to target.

Slick has features that require greater versions of OpenGL (e.g. offscreen rendering), but for the most part it should work on OpenGL 1.1. Hell, if Ardor3D is working on GL1.2, then it would seem a bit daft that Slick, a simple 2D sprite library, would need higher requirements.

Slick has features that require greater versions of OpenGL (e.g. offscreen rendering)

What version of OpenGL is required for off-screen rendering? If slick already uses a newer OpenGL for one of its features, it might as well allow itself to use that version for other features as well, right?

_________________"Artificial intelligence will never be a match for human stupidity" - "Jamos Kennedynos"

Slick has features that require greater versions of OpenGL (e.g. offscreen rendering)

What version of OpenGL is required for off-screen rendering? If slick already uses a newer OpenGL for one of its features, it might as well allow itself to use that version for other features as well, right?

IMO, no. (A) There is no simple "minimum OpenGL version" for offscreen rendering(B) It's not a core requirement of Slick; you can make a 2D game without offscreen rendering

Slick uses two main strategies for offscreen rendering: FBOs or Pbuffers. Pbuffers are deprecated (replaced by FBO) in new versions of OpenGL. FBO did not become core until 3.0, although they have been around long before that (through EXT_framebuffer_object). FBOs are faster than Pbuffers since they don't require two context switches. Also, FBOs seem much more widespread than Pbuffers -- I can't even get Slick's Pbuffer to work on my iMac. (On that subject, could some people test it out by setting GraphicsFactory.setUseFBO to false and posting the results somewhere?)

Who is online

Users browsing this forum: No registered users and 1 guest

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum