Java-Gaming.org Hi !
Featured games (90)
games approved by the League of Dukes
Games in Showcase (707)
Games in Android Showcase (206)
games submitted by our members
Games in WIP (781)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: 1 ... 6 7 [8] 9 10
 71 
 on: 2017-01-12 14:27:39 
Started by Galdo - Last post by Galdo
I feel quite stupid right now - tested it on one of the problematic devices and its GLCapabilities tell me that OpenGL20 isn't supported.

Thanks for the feedback Smiley

 72 
 on: 2017-01-12 14:10:28 
Started by Galdo - Last post by Spasi
on some systems

Sounds like you might be calling glGenVertexArrays without checking if OpenGL 3.0 is available.

 73 
 on: 2017-01-12 13:50:18 
Started by Galdo - Last post by Galdo
Hi guys - I hope you are able to help me with one of the nastiest bugs that I've seen so far Clueless
I'm using LWJGL and tried to implement VAO usage.
When I call glGenVertexArrays on some systems the whole jvm crashes. After some further investigation I got the following dump:
http://www.java-gaming.org/?action=pastebin&id=1505

As far as I get it, the problem is that I try accessing some wrong storage memory (?)
But I don't get what I'm doing wrong - after all I just call glGenVertexArrays ....

Here's the code of createMesh:

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
22  
23  
24  
25  
26  
27  
28  
29  
30  
31  
32  
33  
34  
private void createMesh(float[] vertexCoords, float[] vertexTexCoords, float[] vertexNormalCoords) {

      vertexCount = vertexCoords.length / COORDS_PER_VERTEX;
     
     
      float[] combinedData = new float[vertexCoords.length+vertexNormalCoords.length+vertexNormalCoords.length];
      for(int i=0;i<vertexCoords.length; i++){
         combinedData[i] = vertexCoords[i];
      }
      for(int i=0;i<vertexTexCoords.length; i++){
         combinedData[i+vertexCoords.length] = vertexTexCoords[i];
      }
      for(int i=0;i<vertexNormalCoords.length; i++){
         combinedData[i+vertexCoords.length+vertexTexCoords.length] = vertexNormalCoords[i];
      }
     
      texOffset = vertexCount*3;
      normOffset = vertexCount*5;
     
      vao = glGenVertexArrays();
     
      glBindVertexArray(vao);
      vbo = glGenBuffers();
      glBindBuffer(GL_ARRAY_BUFFER, vbo);
      glBufferData(GL_ARRAY_BUFFER, createFloatBuffer(combinedData), GL_STATIC_DRAW);
      glEnableVertexAttribArray(0);
      glEnableVertexAttribArray(1);
           
      glVertexAttribPointer(0, COORDS_PER_VERTEX, GL_FLOAT, false, 0, 0);
      glVertexAttribPointer(1, TEX_COORDS_PER_VERTEX, GL_FLOAT, false, 0, texOffset*BYTES_PER_FLOAT);
     
      glBindVertexArray(0);
     
   }


I hope you can help since I'm really getting nowhere with this. Every feedback or clue is highly appreciated!

 74 
 on: 2017-01-12 13:49:39 
Started by DayTripperID - Last post by 65K

I like the simple
That's an example why the Java universe is famous for its love for over engineering.
Keep it simple, readable and maintainable.

 75 
 on: 2017-01-12 13:03:18 
Started by DayTripperID - Last post by nsigma
I agree with @princec. The code linked to by @nsigma is nothing but instanceof-in-disguise wrapped in Java 8 to make it less intelligible.

But done in a less verbose, safer and compile-time-checkable way!  It's getting closer to smart casts in Kotlin (eg. https://kotlinlang.org/docs/reference/typecasts.html)

I generally agree with the bulk of what you've said by the way - this is always for edge cases.

 76 
 on: 2017-01-12 12:51:58 
Started by DayTripperID - Last post by nsigma
Jeez, that's among the most awful code I've ever had to look upon Sad

Welcome to our functional future!  Grin

4. You want to write (and hence maintain) the bare minimum of actual code

1-3 may be right (3 might depend on number of types), but 4?!  That's why I hate it.

IMO casting in OOP is one of the strongest bad smells in code, and instanceof is essentially a cast.

So is breaking encapsulation, which is why I'd shy away from both whenever possible.

 77 
 on: 2017-01-12 12:51:44 
Started by DayTripperID - Last post by KaiHH
I agree with @princec. The code linked to by @nsigma is nothing but instanceof-in-disguise wrapped in Java 8 to make it less intelligible.

The reason why people "feel" that the use of instanceof "might" be bad, is because most of the time it is used because the model already breaks the Liskov substitution principle.
The always-excercised example is
Square extends Rectangle
. In that case you will have to use
if (rectangle instanceof Square) {...}
in some places because you have modelled your classes in such a way that you cannot easily substitute a Square for a Rectangle, because they have different semantic behaviours, which is implemented in their operations/methods.
The reason why using instanceof in that case is bad, is because you are coupling the behaviour and the constraints of your model to places other than the model classes.
And again: Changes become more difficult to incorporate.
I say it all the time: Think about how _changes_ can be contained to as few places as possible. @princec named a few motivations for changes. And the visitor pattern is a good way to contain those changes to as few classes as possible (most likely just the visitor implementation itself).

 78 
 on: 2017-01-12 12:28:05 
Started by DayTripperID - Last post by princec
Jeez, that's among the most awful code I've ever had to look upon Sad

Here's why and when you should use visitor:

1. You know all the possible types in advance but you might add more later
2. You have access to the types to change them have them all implement the acceptor
3. You need it to be fast-as-f**k
4. You want to write (and hence maintain) the bare minimum of actual code

This so happens to fit collision detection in games but there are lots of other cases where these four criteria are bang-on.

I tend to use instanceof only when I can't apply a visitor because it's not my code so I can't just stuff an acceptor interface on it. I tend to shy away from switch statements on enums because when enums grow, switch statements tend to fall behind, whereas the visitor breaks immediately at compile time (without default interface implementations) or at least doesn't actually fail.

IMO casting in OOP is one of the strongest bad smells in code, and instanceof is essentially a cast.

Cas Smiley

 79 
 on: 2017-01-12 12:12:29 
Started by DayTripperID - Last post by nsigma
Seriously, what is wrong with visitor? It's fast, it works, it catches anything awry at compile time, and with default methods on interfaces it's not even ugly any more - what's not to like?

A lot!  It breaks abstraction, adds a load of code and ends up with logic in the wrong (or less convenient) place.  instanceof and the visitor pattern are both workarounds to Java's lack of double-dispatch, the latter originating from C++ IIRC.  Needing to use either can therefore be a sign that your code is structured wrongly.  That doesn't mean that you should never use either!  A few instanceof statements may then actually perform equally well or better than the visitor pattern, not use 10x the code, and keep your logic in the right place.

I agree with both @CoDi^R and @philfrei - look at code restructuring and look at enums before using either instanceof or the visitor pattern.  But also don't listen to anyone saying that any use of instanceof is a code smell.

I like the simple (or less simple) approaches to pattern matching over the visitor pattern, because it doesn't require changes to the target classes and keeps the logic together.

 80 
 on: 2017-01-12 10:23:54 
Started by ral0r2 - Last post by cylab
googling libgdx gui gave me this:
<a href="http://www.youtube.com/v/ELkqiMpvMLA?version=3&amp;hl=en_US&amp;start=" target="_blank">http://www.youtube.com/v/ELkqiMpvMLA?version=3&amp;hl=en_US&amp;start=</a>
LibGDX Scene2D -- UI, Widgets and Skins

Pages: 1 ... 6 7 [8] 9 10
 
Galdo (237 views)
2017-01-12 13:44:09

Archive (405 views)
2017-01-02 05:31:41

0AndrewShepherd0 (864 views)
2016-12-16 03:58:39

0AndrewShepherd0 (801 views)
2016-12-15 21:50:57

Lunch (938 views)
2016-12-06 16:01:40

ral0r2 (1169 views)
2016-11-23 16:08:26

ClaasJG (1270 views)
2016-11-10 17:36:32

CoffeeChemist (1305 views)
2016-11-05 00:46:53

jay4842 (1390 views)
2016-11-01 19:04:52

theagentd (1207 views)
2016-10-24 17:51:53
List of Learning Resources
by elect
2016-09-09 09:47:55

List of Learning Resources
by elect
2016-09-08 09:47:20

List of Learning Resources
by elect
2016-09-08 09:46:51

List of Learning Resources
by elect
2016-09-08 09:46:27

List of Learning Resources
by elect
2016-09-08 09:45:41

List of Learning Resources
by elect
2016-09-08 08:39:20

List of Learning Resources
by elect
2016-09-08 08:38:19

Rendering resources
by Roquen
2016-08-08 05:55:21
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
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!