imo libgdx is so great a very low yearly few of I dunno 5 bucks to be able to publish games using libgdx would hurt nobody and benefit the creatorswith so many contributors the distribution would be problematic, but yeah, I dunno

The animation timelines are a little tricky to get right too. Most of the libgdx runtime isn't actually libgdx specific, you can reuse almost all of it and for the most part just swap how you draw attachments. This means if the format changes or features are added, re-porting the runtime is easy. To give you some sense of the size, the libgdx runtime is 1600 LOC, which includes both the JSON and binary loaders.

That does make sense, and I was expecting the runtime to be somewhat larger than that. I'll hopefully get a chance to try porting it to my runtime soon, and I'll let you know how smoothly it goes. I think if you're expecting people to use one runtime as a reference and port it then there's probably quite a lot you can do in that runtime to make it easy to port. But you won't notice until people start trying to do that, so we'll see how it goes.

What kind of external features does the runtime need? Does it spit out things like drawQuad() to libgdx or does it create geometry and hand that off? Any other dependencies/libraries/functionality I should be aware of?

For most of those porting is as easy as copy/pasting into your project. You could skip the JSON loader and just use binary. You'd probably need to make changes for code that uses FileHandle and maybe Color. The biggest difference will be how you handle drawing.

Attachments are abstracted. A RegionAttachment has an SRT offset from the bone and a texture region. It computes vertices based on the bone it is attached to, then uses SpriteBatch to draw.

Probably more could be done to make it use less libgdx stuff so it is easier to port to other Java apps. It might make more sense to make an LWJGL runtime, but then I don't know how many users would use that and Unity and cocos2d probably should get priority. I'm not totally sure how the runtime for those two will look, but if we can refactor things so the code remains similar for the different game toolkits that would be nice.

He has Windows XP x86 5.1, Java 1.7.0_10, and (I think) an Nvidia NVS 300. I tried asking the LWJGL guys here but didn't get much help. StumpyStrust, have you updated your drivers to the latest? I would really like to fix this, but I'm not sure there is anything else I can try.

I have exactly the same config here at work, and I have exactly the same exception.I'm now using scene2d.ui for my game editor, so now I can tell a bit more: I have this exception only when using libgdx through the LwjglFrame. Using the LwjglApplication is working fine. I tried to call Display.create(...) in LwjglGraphics.java ( with the debugger) with the exact same parameters as the ones I use for my game, and I got strange results: sometimes it worked and sometimes not ...

I did a new Spine release, 0.89. I've updated LWJGL to the latest nightly and made a few small changes that likely don't help, but maybe you can try again? Maybe that GPU is just too old or the drivers are broken...

He has Windows XP x86 5.1, Java 1.7.0_10, and (I think) an Nvidia NVS 300. I tried asking the LWJGL guys here but didn't get much help. StumpyStrust, have you updated your drivers to the latest? I would really like to fix this, but I'm not sure there is anything else I can try.

I've been doing a bit of googling and have found a couple of interesting things, unfortunately none of which can be tested without being able to reproduce the problem myself. I wonder if its the combination of Nvidia and XP

I love programming and can do it 14+ hours/day, but doing it for a job is different than doing it for fun. A job involves all sorts of stress and the work isn't what you would be doing for fun. It isn't the same at all. Overworking for a job isn't worth it. First, management is going to pat you on the head and tell you that you're doing a great job, whether you are killing yourself at it or just putting in normal hours. You won't get paid more and any meager recognition you might get for going the extra mile is not worth it. But the real reason to not overwork yourself is because you will get burnt out eventually and you'll begin to hate the work. Yes, even programming. They call it work/life balance because work != life. If it was all fun and sunshine and flowers they wouldn't call it work and you wouldn't be getting paid to do it.

Quoted for truth... I've done coding for a living, and honestly I can't put in the hours on someone elses project like I can on my own... It's just not the same.

Damn. Hmm. I've tried a different approach to waiting. I was blocking the EDT when waiting 1 second, now I set it free and try again after 1 second. If this doesn't work, I'm afraid I'm at a loss. One last try, pretty please? Updated download to 0.91 with this potential fix.

kappa, uhg. Interaction with Swing/AWT gets nasty if I don't use the EDT. Spine only does that a little, but many other LwjglFrame classes do.

How about doing just the Display.create() calls (The createDisplayPixelFormat() method) and the 1 second sleep retry thing outside the EDT, once Display and OpenGL Context successfully creates, then switch to the EDT (using Display.makeCurrent()) so you don't have to change the rest of the code, might work. I'm guessing AWT is doing something at around the time or during the Display.create() call which causes it to fail on certain drivers.

Just curious, but why do you use Swing and the EDT at all when you have the user interface library in libgdx? I just tried your latest version and I couldn't see any AWT/swing, not even in a filechooser.

Just curious, but why do you use Swing and the EDT at all when you have the user interface library in libgdx? I just tried your latest version and I couldn't see any AWT/swing, not even in a filechooser.

We're using swing so we can make our own titlebar and make it sexier looking. Also a coupe of other benefits with that, but that's basically it, at least from my understanding, I'm just the artist slave, not the programmer.

kappa, I tried that but after switching the context to the EDT, nothing was drawn in the window. I could only see the window underneath, but the Spine window was receiving the mouse events.

We use Swing because LWJGL can't set the window maximized/minimized state. LWJGL can do undecorated, but I didn't know about the secret system property at first. I posted about it in the LWJGL forums here, with more details about implementation later in the thread, but it doesn't look like it's on anyone's list to implement. I could convert and give up trying to restore maximized state (which is lame!), but it is unfortunate that using LWJGL with Swing doesn't work on some machines and I'd have to redo my window resizing and a few other AWT things.

I also want to set the window opacity on Windows (the app window fades in), as I do with AWT. This isn't that important, but it's the little polish that makes things nice. If I didn't care I'd just use Swing's Metal L&F.

There is probably something else I need AWT for... ah, native cursors. I want to use the predefined cursors for resize, move, hand, arrow, etc. Also in addition to maximize I have a fullscreen mode, so I use Swing's setMaximizedBounds and GraphicsEnvironment getMaximumWindowBounds for that.

All these things add up and I don't really want to lose these features. I wonder if the JOGL libgdx backend that Julien just resurrected would work better for me...

I changed LwjglFrame and LwjglCanvas all around. Maybe it works better now? New version up, 0.92. Because of the order things used to happen, the canvas had a size of 0x0 when the display was first created, then it was resized. Maybe this assploded some drivers. But chances are nothing is fixed. It would also be great if someone could test this on a Mac, as that OS is a picky SOB.

Specifically import and position a background image / or place static props for an animation. (doesn't need to be exported just animated against)

For example:I have these goblins And Ideally they'd be able to climb/scramble up the one block height difference by playing a climb animation instead of the usual 'magic jump' that you see in side scrollers.

However unless I can see the edge that it's climbing up to it makes really hard to position the hands and keep things from floating and figure out the final offset.Same thing goes with getting on and off a ladder and lots of other non walk cycle things.

Drakkheim this is something Nate and I have talked about earlier and we will probably eventually make a specific node for it in the tree where you can place your background images. For now you can do the following though, place the images needed on a bone you aren't animating linked to the root. It's not optimal we know, but it will be improved later on.

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