Kappa that app works fine.
It is really weird as I have never had any issues with an opengl things on this comp.
Here is the log it gives in a txt file. Maybe it will help.
Nate: try create the Display on a thread other than the EDT.
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.
Damn. I really hoped that last fix would work. 
Strange the applet works. I guess I need to reproduce the problem in order to fix it. Who with this problem is in Austria or Denmark? 
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.
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.
Is it too early for feature requests?
;D
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.
Just a thought 
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.
Is the above currently done? if so, maybe the fade effect is interfering with the Display creation as the window may not be visible or partially fading at that time.
Just curious, what is the minimum OpenGL version requirement for Spine?
Is there a way to convert old project (from Spine 0.81beta) so it works in new Spine? I thought it would be XML file, so it would be posibble to convert it, but it seems to be binary (but maybe it’s just an archived XML?).
Afraid not, the file format changed due to skin attachments being added, was not possible to keep the old format.
Even as a simple converter or partial loader? Shame it’s not XML or JSON, that would allow to modifying it by hand.
That would allow to write loaders and converters for the internal skeleton animations as well, which would lead to people writing their spine-project-file to json-animation converter and using spine for free.
[quote=“matheus23,post:155,topic:40264”]
Then encrypt that XML/JSON with a unique key (binded to user e-mail or even credit card number for example) and give the key only to those who paid. Or at least make converter allowing loading old animations. Right now I consider dropping Spine for Spriter because of that. Export to XML/JSON is not enough too - import would also be needed.
as far as I understand it, the basic exported file for libgdx will be JSON.
The protected part is the Export process that goes from the internal project file to the exported animation file.
Once you buy a license that lets you export, you can look at the exported file and see if you can make a player for your engine.
This is not the problem. I’m using libGDX anyway.
The problem is that project files are binary which means you can’t modify them by hand - for example recently the file format changed, if it wasn’t binary we could fix old files ourself by hand or writting a simple script. Export is not available so I can’t export my old animations (fortunately I made only four but they took hours to make) but even if I could there couldn’t be ever modified in newer Spine because there is no import. That thing makes my faith in Spine shake because for work I need sth that is 100% sure and that in case the author stop supporting it can be rewritten (hence open format is needed).
Remember DOC files from Word? They were also binary. Binary file formats are hell.
Please remember that Spine is unreleased, it is only available in this thread to you guys while we iron out the last few things. We didn’t plan to break the format, but we ended up making big changes to how things work and decided it wasn’t worth the large amount of work it would be keeping around a lot of code to continue to load the old format and convert to the new format. Very sorry!
Once Spine is released, we won’t break the project file format, guaranteed. If we have to make such large changes to how things work, we will do the extra work to continue being able to load projects saved with any version of Spine.
We could support importing from the JSON/binary exported files in the future.
Would a donation help you make that converter? How do you intend not to break a binary format in the future? With XML/JSON it would be easy, binary tends to be hell to support in the long term - this situation shows it by the way.