|
trollwarrior1
|
 |
«
Reply #1 - Posted
2014-02-08 06:54:10 » |
|
Its pretty obvious.. Null pointer exception means you're trying to access object that is set to null. Line number at which it is thrown would be nice.
Also, unless you're planning on making the game for more than desktop, I would suggest to use only LWJGL. From my experience at least, Libgdx is a mess to work with..
|
|
|
|
Gibbo3771
|
 |
«
Reply #2 - Posted
2014-02-08 09:15:50 » |
|
Libgdx is a mess to work with..
Don't go around giving false information, your ability to use it and it's functionality are 2 different things. There is nothing wrong with libgdx, usual PEBKAC error
|
"This code works flawlessly first time and exactly how I wanted it" Said no programmer ever
|
|
|
Games published by our own members! Check 'em out!
|
|
Phibedy
|
 |
«
Reply #3 - Posted
2014-02-08 10:00:40 » |
|
From my experience at least, Libgdx is a mess to work with..
Why do you think it's a mess to work with?
|
|
|
|
Gibbo3771
|
 |
«
Reply #4 - Posted
2014-02-08 10:10:05 » |
|
From my experience at least, Libgdx is a mess to work with..
Why do you think it's a mess to work with? He could be used to using something else, I tried LWJGL and felt like smashing the screen.
|
"This code works flawlessly first time and exactly how I wanted it" Said no programmer ever
|
|
|
Phibedy
|
 |
«
Reply #5 - Posted
2014-02-08 10:29:54 » |
|
From my experience at least, Libgdx is a mess to work with..
Why do you think it's a mess to work with? He could be used to using something else, I tried LWJGL and felt like smashing the screen. I just want to know why think that it's a mess 
|
|
|
|
Andre Lopes
|
 |
«
Reply #6 - Posted
2014-02-08 20:04:41 » |
|
From my experience at least, Libgdx is a mess to work with..
I Totally disagree. Libgdx is very easy to use. "public ShapeRenderer shapeRenderer;" You didnt instantiate it. Did you?
|
|
|
|
trollwarrior1
|
 |
«
Reply #7 - Posted
2014-02-08 20:26:15 » |
|
I can make a little list of stuff that I really hated.. * Multiple projects. Always have to wait 5 seconds after editing image or press refresh on android project. * Cannot access original LWJGL GL classes. They put stuff into glcommon, gl11, gl20. They didn't put everything. * Cannot use GL11 and GL20 at the same time. * You only get 1 method for updating your game: only render, no tick/update method. Cannot render at maximum speed. Always capped at 60 fps. * I couldn't find a way to measure performance. * Shaders are stupid or what? Gives errors when LWJGL doesn't. I mean, when I load shader into Libgdx, it "works" differently than in LWJGL. Variables that do not affect the output of the shader are not compiled to the shader. This is probably to boost performance, but is really annoying. Could have just given warnings telling that some uniforms are not used. * Sprite class doesn't have anti bleeding built in.
These are the most annoying things that are just keeping me from using Libgdx.. I'm not saying Libgdx is shit.. I just don't like it.. It makes developing more like a drill to me. There is always that stupid something that doesn't need to be there.. Of course, Libgdx has much more upsides than it has down ones.. I just happen not to like it. Its like choosing operating system.. You don't choose it, because its better. You choose it, because you like it more.
|
|
|
|
Jimmt
|
 |
«
Reply #8 - Posted
2014-02-08 20:33:19 » |
|
Multiple projects is a feature. Having it all embedded into one project is way too messy. And pressing refresh is an eclipse problem, not libgdx.
|
|
|
|
jonjava
|
 |
«
Reply #9 - Posted
2014-02-08 20:58:10 » |
|
You choose a tool based on what it provides for you, i.e, based on your needs. Learning the peculiarities of a library/tool that provides the things you need is what most of programming is about - especially game development. If you don't like it - do it yourself. Perhaps in 10 years you will be able to reinvent the bicycle.  Additionally, comparing libGDX to LWJGL is like: 
|
|
|
|
Games published by our own members! Check 'em out!
|
|
Phibedy
|
 |
«
Reply #10 - Posted
2014-02-08 21:11:33 » |
|
I can make a little list of stuff that I really hated.. * Multiple projects. Always have to wait 5 seconds after editing image or press refresh on android project. * Cannot access original LWJGL GL classes. They put stuff into glcommon, gl11, gl20. They didn't put everything. * Cannot use GL11 and GL20 at the same time. * You only get 1 method for updating your game: only render, no tick/update method. Cannot render at maximum speed. Always capped at 60 fps. * I couldn't find a way to measure performance. * Shaders are stupid or what? Gives errors when LWJGL doesn't. I mean, when I load shader into Libgdx, it "works" differently than in LWJGL. Variables that do not affect the output of the shader are not compiled to the shader. This is probably to boost performance, but is really annoying. Could have just given warnings telling that some uniforms are not used. * Sprite class doesn't have anti bleeding built in.
These are the most annoying things that are just keeping me from using Libgdx.. I'm not saying Libgdx is shit.. I just don't like it.. It makes developing more like a drill to me. There is always that stupid something that doesn't need to be there.. Of course, Libgdx has much more upsides than it has down ones.. I just happen not to like it. Its like choosing operating system.. You don't choose it, because its better. You choose it, because you like it more.
No offence, but 1. Multiple projects -> Eclipse's problem, if you don't use the internal storage you don't have to wait 2. I havent missed some GL-stuff yet ( for example glPushMatrix isn't available but libgdx has it's own matrices, they are more powerfull) 3. "Cannot use GL11 and GL20 at the same time." Why would you do that? 4. Just wrong, you can have your own render-loop. 5. Count your fps. 6. I don't see the problem. 7. That's the problem of the texture you created and the texturefilters you use. You don't have to use it, but don't say that it's messy if you haven't really used it 
|
|
|
|
trollwarrior1
|
 |
«
Reply #11 - Posted
2014-02-08 21:33:35 » |
|
I might be in the wrong, but are you suggesting me to do multi threaded game, because Libgdx couldn't make 2 separate methods? Did you try counting fps? You will never count higher than 60. Well which texture filters am I supposed to use to get rid of bleeding? Would be really willing to learn those..
|
|
|
|
HeroesGraveDev
|
 |
«
Reply #12 - Posted
2014-02-08 21:45:54 » |
|
As far as programming goes, use LWJGL. As far as game development goes, use LibGDX.
To each their own.
|
|
|
|
BurntPizza
|
 |
«
Reply #13 - Posted
2014-02-09 04:17:04 » |
|
Did you try counting fps? You will never count higher than 60.
1
| cfg.vSyncEnabled = false; |
Instant 1600 FPS, not that you need any more than the default 60, and excessive frame rate only burns up your graphics card. Google libgdx vsync, and read the docs before making assumptions.
|
|
|
|
trollwarrior1
|
 |
«
Reply #14 - Posted
2014-02-09 07:26:16 » |
|
Thanks I will try that. EDIT------------ 60fps with screen tearing  ))))
|
|
|
|
Phibedy
|
 |
«
Reply #15 - Posted
2014-02-09 08:29:51 » |
|
I might be in the wrong, but are you suggesting me to do multi threaded game, because Libgdx couldn't make 2 separate methods? Did you try counting fps? You will never count higher than 60. Well which texture filters am I supposed to use to get rid of bleeding? Would be really willing to learn those..
Why "multi threaded game", I think GL20 and GL11 are seperate because of cross-plattform performance. If you really want to, you can add lwjgl jars and access interfaces directly. As you can have your own render-game-whatever loop you can get as much fps as you want. Vsync is enabled by default because it needs a lot of energie and mobile-bateries won't do it long. If you have texture-bleeding you can reduce it by using texturefilter-nearest instead of linear (if you texture isn't resized to strong). Of course it doesn't solve the problem completely, but in most of my cases it helped and if you add padding to your textures it works fine. In addition Sprite.class is just made for drawing a textureregion you have to care about the accuracy yourself.
|
|
|
|
Nate
|
 |
«
Reply #16 - Posted
2014-02-09 18:49:04 » |
|
* Multiple projects. You can have a single project if you target a single backend. * Always have to wait 5 seconds after editing image or press refresh on android project. Load your assets from the filesystem, not the classpath, to bypass this Eclipse refresh issue on the desktop. This is not a libgdx problem. * Cannot access original LWJGL GL classes. You can access the LWJGL GL classes directly. You aren't trying. * Cannot use GL11 and GL20 at the same time.  * You only get 1 method for updating your game: only render, no tick/update method. Create your own method and call it. * Cannot render at maximum speed. Always capped at 60 fps. On what backend? See vsync. * I couldn't find a way to measure performance. Gdx.graphics has FPS counter. Otherwise you are complaining about something you fail to do. * Shaders are stupid or what? No idea. * Sprite class doesn't have anti bleeding built in. Sprite doesn't manage texture regions. See libgdx's texture packer. * These are the most annoying things that are just keeping me from using Libgdx. I get the impressions your issues aren't with libgdx. * It makes developing more like a drill to me. There is always that stupid something that doesn't need to be there. I'm pretty sure there are few things that are in libgdx for no reason. It's OSS, contributions are welcome. * Of course, Libgdx has much more upsides than it has down ones.. I just happen not to like it. Fair enough.  Good thing you didn't pay anything for it. 
|
|
|
|
Opiop
|
 |
«
Reply #17 - Posted
2014-02-09 18:59:05 » |
|
Its not fair to compare LWJGL to LibGDX, but its also not fair to bash LWJGL. Of course its difficult to use, get over it or don't use it. I'm quite sick of people bashing libraries and saying this one sucks etc... Use what you want and get over it. Thank you.
|
|
|
|
trollwarrior1
|
 |
«
Reply #18 - Posted
2014-02-09 19:44:07 » |
|
@Nate I don't want to look like a dude who is a noob and tries to look pro, but I tried turning off vsync, still 60 fps.
Ofcourse I can make my own method for updating, but you didnt get my point. I want to get 1000fps and 60 updates. I didn't manage to do that. From my experience, it would only be possible by implementing multiple threads to run a single game. That's what I meant by multiple methods.. So render methods gets called 1000 times a second and update would get called 60 times..
|
|
|
|
EgonOlsen
|
 |
«
Reply #19 - Posted
2014-02-09 19:55:39 » |
|
* Shaders are stupid or what? Gives errors when LWJGL doesn't. I mean, when I load shader into Libgdx, it "works" differently than in LWJGL. Variables that do not affect the output of the shader are not compiled to the shader. This is probably to boost performance, but is really annoying. Could have just given warnings telling that some uniforms are not used.
As mentioned in the other thread, this is done by the shader compiler, which is part of the graphics driver not of the library that you are using ( http://ogltotd.blogspot.de/2007/12/active-shader-uniforms-and-vertex.html). The fact that this might work under LWJGL is because you don't check for your assigment going wrong, which lidGDX seems to do for you. You can ignore this as long as you like, but why don't you simply fix your stuff by not assigning values to uniforms that you don't use instead of blaming the library?
|
|
|
|
BurntPizza
|
 |
«
Reply #20 - Posted
2014-02-09 19:59:15 » |
|
Just use a variable-time update method, then updates/sec don't affect physics, etc. (for reasonable framerates, ofc) And there is still no sane reason for wanting 1000 fps rendering.
It should also be pretty trivial to lock to any specific framerate using non-continuous rendering mode coupled to a custom gameloop using either your own timing or the LWJGL backend's Display.sync()
|
|
|
|
Gibbo3771
|
 |
«
Reply #21 - Posted
2014-02-10 05:03:45 » |
|
@Nate I don't want to look like a dude who is a noob and tries to look pro, but I tried turning off vsync, still 60 fps
Graphics card can force it as well, check your settings, either that or your hardware is dated, sound like it because when I refresh or clean all my projects (which I have about 20) it's pretty much instantaneous.
|
"This code works flawlessly first time and exactly how I wanted it" Said no programmer ever
|
|
|
Nate
|
 |
«
Reply #22 - Posted
2014-02-10 09:11:35 » |
|
I tried turning off vsync, still 60 fps.
Set LwjglApplicationConfiguration foregroundFPS to zero and vSyncEnabled to false. RTFM before complaining. 
|
|
|
|
Cero
|
 |
«
Reply #23 - Posted
2014-02-10 22:30:36 » |
|
Everybody should be allowed to express their opinion and criticize even libgdx without people jumping down your throat. however disappointingly your complains weren't professional and all seemed to stem from ignorance rather than actual technical suggestions. Always capped at 60 fps You never want to draw faster than your monitors refresh rate... right ? that would be stupid. so what the deal ? Even if you have 120hz monitor im sure you can sync to 120 via vsync if thats at all desirable. Sprite class doesn't have anti bleeding built in Wow hm. I guess you dont really understand how bleeding happens - which is ok its not immediately obvious since its low level; Point is: its not the sprite classes fault.
|
|
|
|
BurntPizza
|
 |
«
Reply #24 - Posted
2014-02-10 22:54:06 » |
|
Sprite bleedingThis is a good write about texture bleeding and how to deal with it, it is due to the image scaling interpolation algorithm used, particularly a linear algo. This is again not related to libGDX. Use the TexturePacker to make your atlases and your shouldn't have problems. - I did notice he first says it's part due to jpeg noise, that's not really correct, but will play a factor if you save images with jpeg q<100.
|
|
|
|
|