@salas00 Seems i completely blind, as after reading your link i still think it will not help to run current minigl apps, as well as will not help to port pure opengl1 / opengl2 or pure sdl1/opengl games (such as xmoto for example) without touching code much.
@kas1e You are right about that, EGL is for managing OpenGL contexts. Think of the functions CreateContextTags, SwitchDisplay, etc in MiniGL. It was meant as a platform independent replacement for native APIs, it's used mainly on Android and Linux. People usually go for SDL, because it provides abstractions for more than just the OGL context.
This is just like television, only you can see much further.
I chose EGL for reasons of ports facilities and a lot of examples are easily found. I know he would keep a compatibility but I do not have the motivation and above all time. This library is still initially made for me to allow me in my rapid integration portages. Look at the last great sharing SDL2 (which I donated to the good work), there was very little porting and everyone waiting games or applications, fine workmanship that is not not fully use. I propose this library and those who will want to use the can but I focus on something else now. thank you for your understanding HunoPPC
I can try to add OpenGL ES 2 support for SDL2 but I can't test it myself at the moment. If someone else can, then good..
That would be great! I could test it, and I'm sure that other people with the right hardware would be willing to test it as well.
BTW, I tried compiling SDL2 last night. Compilation went okay except for one hiccup with the struct timeval hack (which isn't needed with newlib). However, I tried running a few of the tests, and they all crashed/froze.
That's strange. Which compiler you use? Can you describe timeval issue and crash issue in details?
I followed the build instructions in the AmigaOS readme. In one of the files there's an #ifdef __amigaos4__ with a struct timeval definition and a note about it being a hack for clib2. The readme said to configure with newlib, and I got a struct redefinition error.
Just do a search for struct timeval, and you'll find it
As for the crashes. After building the main library I did a configure and make in the tests drawer. Running testautomation first said it couldn't find the *.so.** After fixing that, it crashed. I then tried a few different test programs at random, and they all failed. Sorry, I don't have any crashlogs right now.
NOTE: I'm using GCC 5.3.0, which may or may not be relevant. I may also have newer header files than are publicly available, which might explain why I get the struct timeval error.
Hans
** I forgot about this. Make install really should copy the *.so to SOBJS: Should I submit a bug ticket on sourceforge?
especially int what case attribNum!=arrayIdx happen ?
attribNum seems to be the order of input variables in the shader :but what happen when vert and frag shader dont have same inputs...
I mean typically vert shader will have a position as input and frag shader will have a color : so how does it reflect in BindVertexAttribArray ?
Globally in Nova the "linking" between the vbo and shaders seems obscure
just noob questions
Also what happen when you have several vbo ? I mean one per object to draw ? arrayIdx still begin with 0 for each object or increase among them?
Last: Is there a simple way to set a default mvpMatrix & normalMatrix with constant values because my code using kmMat4Multiply/etc... seems to be wrong : I mean just to verify if this is this part that is bugged
especially int what case attribNum!=arrayIdx happen ?
The first is the order of the attributes in the VBO, the second the position they appear in shader, which unless you explicitly use the (location=n) syntax in GLSL 1.4 is up to the compiler.
Comparing the AutoDocs with the examples I do wonder if the *names* of the arguments are the "wrong way round". I didn't really spot that before as I was mainly following example code, but just trying to explain it the names of the arguments seem backwards compared with how they are used in the example code.
Study the W3DNHelloTriangle example for simple usage case. The examples are really usful IMHO to get things started up.
Quote:
but what happen when vert and frag shader dont have same inputs...
I mean typically vert shader will have a position as input and frag shader will have a color : so how does it reflect in BindVertexAttribArray ?
The vertex and fragment shader almost certainy won't have the same inputs, they work in a pipeline so the output variables from the vertex shader form the inputs to the fragment shader.
I may be wrong but if you had a seperate piece of data you wanted to pass through to the fragment shader you would need to pass it to the vertex shader and then code that shader so that it passes the data straight through to the fragment shader as an output variable.
Quote:
Also what happen when you have several vbo ? I mean one per object to draw ? arrayIdx still begin with 0 for each object or increase among them?
Assuming all the VBOs have the same structure and same shaders then the array and indexes values remain the same.
And you mentioned render to texture before, will that be possible later?
Yes, it's on the to-do list.
@broadblues Quote:
The first is the order of the attributes in the VBO, the second the position they appear in shader, which unless you explicitly use the (location=n) syntax in GLSL 1.4 is up to the compiler.
Comparing the AutoDocs with the examples I do wonder if the *names* of the arguments are the "wrong way round". I didn't really spot that before as I was mainly following example code, but just trying to explain it the names of the arguments seem backwards compared with how they are used in the example code.
Oops! Looks like I got the examples round the wrong way. I'll correct that.
Yes, vertex attributes are the inputs to the vertex shader, and vertex array indices are the indices to the individual arrays in the VBO. For example, if a shader's attribute 0 is position, and you stored the position array in VBO's array 2, then attribNum = 0, arrayIdx = 2.
You've described how the shader pipeline works accurately. I'll just add to this one: Quote:
Also what happen when you have several vbo ? I mean one per object to draw ? arrayIdx still begin with 0 for each object or increase among them?
It's entirely up to you. You decide which VBO arrayIdx is what when you use VBOSetArray(). So, you could: - Store the vertex attributes in the same order in all VBOs - Store vertex attribute arrays for multiple objects in one VBO (e.g., arrays 0-2 are for object 1, arrays 3-5 for object 2, etc.) - Store the position array in a separate VBO from your colour, surface normal, tex-coord and other arrays. Why would you do this? Well, sometimes you need to update one vertex attribute frequently, whereas the others remain static. For example, you might be rendering particles where the CPU updates the positions every frame. In that case it's best to put the position in a W3DN_STREAM_DRAW VBO while the other attributes should be in a W3DN_STATIC_DRAW VBO
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
