Yes, that looks like you have mismatched lwjgl jar + source setup in eclipse. The debug info from the .class file it's running says that the function is at line 2052, but when eclipse tries to find that in the source attachment you've given it it doesn't exist.

I'd suggest upgrading your lwjgl (jars + source + docs) to the latest so you know they're all the exact same version.

I just updated all of the jars and DLLs. I don't use the sources or docs, so I leave them out. Same problem persists.

About 90% of the time though, things don't work just because I'm the one using it ;p

You are trying to use OpenGL before it's been initialized (this also happens when you try to render from a different thread). GL calls should be made from the same (rendering) thread.

The solution to your problem is to move your GL11 calls to your game's init() method.

Why the ScalableGame? Also, if you haven't already, be sure to update to the latest slick dev branch code. Then you can use getContainer().exit() instead of manually destroying the display/AL. I'll try to put up a tutorial on pulling dev branch code in the next couple days, and hopefully get a merge in soon so the code is downloadable in binary form on Slick's website.

You are trying to use OpenGL before it's been initialized (this also happens when you try to render from a different thread). GL calls should be made from the same (rendering) thread.

The solution to your problem is to move your GL11 calls to your game's init() method.

Why the ScalableGame? Also, if you haven't already, be sure to update to the latest slick dev branch code. Then you can use getContainer().exit() instead of manually destroying the display/AL. I'll try to put up a tutorial on pulling dev branch code in the next couple days, and hopefully get a merge in soon so the code is downloadable in binary form on Slick's website.

Okay. Scalable is so I can resize the window, and stretch it if I want too. Weird situation. lol. It needs A LOT of fine tuning.

Anyway, since you seem to know a lot about this stuff, can you answer a question I put on here earlier?

"Well, the lighting I want is really simple. I just want black if there's no light, and circles of light where there is. If you can just point out functions in the direction of doing this, I can just kind of bullcrap my way through."

Also, why the need for 3D perspective, depth testing, etc? Are you making a 3D game? You'll have a rough time with Slick2D if you try to integrate certain utilities (like, say, Image or ScalableGame) alongside low-level GL calls. If you plan to do 3D, I'd recommend either avoiding Slick2D altogether (instead choosing Slick-Util or a different library), or using SlickCallable to be safe. Even then, ScalableGame + GL calls will give you trouble (as it warns in ScalableGame JavaDoc).

Quote

"Well, the lighting I want is really simple. I just want black if there's no light, and circles of light where there is. If you can just point out functions in the direction of doing this, I can just kind of bullcrap my way through."

I'm just jumping into this thread now, but there are some ways to do this in Slick2D without relying on low-level OpenGL calls.

The easiest is to use an alpha map, and you won't need to worry about math or combining lights or what have you. One of the downsides to this is that it requires extra passes, which may lead you to fillrate limitations. The result is nice, though:

Is that what you're looking for? Or are you looking for a more "low-res" / retro look? e.g. In Terraria; each tile is affected.

Also, why the need for 3D perspective, depth testing, etc? Are you making a 3D game? You'll have a rough time with Slick2D if you try to integrate certain utilities (like, say, Image or ScalableGame) alongside low-level GL calls. If you plan to do 3D, I'd recommend either avoiding Slick2D altogether (instead choosing Slick-Util or a different library), or using SlickCallable to be safe. Even then, ScalableGame + GL calls will give you trouble (as it warns in ScalableGame JavaDoc).

Quote

"Well, the lighting I want is really simple. I just want black if there's no light, and circles of light where there is. If you can just point out functions in the direction of doing this, I can just kind of bullcrap my way through."

I'm just jumping into this thread now, but there are some ways to do this in Slick2D without relying on low-level OpenGL calls.

The easiest is to use an alpha map, and you won't need to worry about math or combining lights or what have you. One of the downsides to this is that it requires extra passes, which may lead you to fillrate limitations. The result is nice, though:

Is that what you're looking for? Or are you looking for a more "low-res" / retro look? e.g. In Terraria; each tile is affected.

The game is 2D, and all the graphics are sketched out/pixel drawn by me, so I need something that would fit this:

I've consider both styles of shading, but I think the alpha map would go best. What do you think? They need to be dynamic and re-sizable on the go.

What do you mean "dynamic"? Do they need to interact with walls? (i.e. will walls affect the lighting)

Alpha maps should be easier, and resizing is just a matter of drawing the map at a different size. If I get a chance I'll throw together an example, although there should be some rudimentary code lying around slick forums already.

What do you mean "dynamic"? Do they need to interact with walls? (i.e. will walls affect the lighting)

Alpha maps should be easier, and resizing is just a matter of drawing the map at a different size. If I get a chance I'll throw together an example, although there should be some rudimentary code lying around slick forums already.

I'd like walls to affect lighting, but, if it's one of those overcomplicated not worth it type deals I think I'll just go with alpha maps. Haha. I'd appreciate that example too, if you get around to it.

Alpha maps won't be very efficient if you plan to have many lights at once (in that instance, you could improve efficiency by "baking" the lights, i.e. rendering static lights to an offscreen image). Also, the lighting won't interact with walls or corridors. If your game is very particular, you might be able to hack around with some different alpha maps to fake that "dynamic" aspect, but it would probably be easier to just use per-vertex lighting or shaders.

Alpha maps won't be very efficient if you plan to have many lights at once (in that instance, you could improve efficiency by "baking" the lights, i.e. rendering static lights to an offscreen image). Also, the lighting won't interact with walls or corridors. If your game is very particular, you might be able to hack around with some different alpha maps to fake that "dynamic" aspect, but it would probably be easier to just use per-vertex lighting or shaders.

There might be a way using Slick's blending modes, but the simplest would be to bake your sprites/overlays/etc onto the same texture (via offscreen images), and only apply the lighting as if it were a "post processing" effect.

Should the player background be filled with alpha, so the player blends right in?

Yes.

Edit: Also..I need a better way of handling these lights. I need to draw them kind of in-between blending, instead of before blending. If I do it before blending, it really makes the engine unflexible and messy. If I need to use OpenGL I'm completely fine with it, I just need someone to explain it in relatively simple terms.

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