openmw.org

psi29a wrote: ↑12 Apr 2018, 20:29 https://www.youtube.com/watch?v=dNcPapn ... e=youtu.be

Very nice!

https://travis-ci.org/Mindwerks/XLEngine/jobs/366028831

It finally compiles on MacOS: please test!

Status Update: We hit the big three now, Linux, MacOS and Windows.

On the opengl front Im getting the same results as the last video.

I checked for opengl errors from glError and nothing is reported.
Use opengl for making mipmap's
Use GL_RGBA instead of 4
Made GLEW optional (not really adding much in my opinion)
Added OpenGL-ES 1.1 options and code (has more issues than desktop GL, but runs)
Some other minor cleanup things

Im concentrating on the texture problem and im trying to use apitrace to find the issue. The couple of runs I did not show issues, but it didnt get to the startup screen for DaggerXL. It was late so ill try more this weekend.
Since the 2d sprites shapes are showing up the textures are being loaded to some degree (alpha works at least).
So I also suspect the vertex color might be throwing things off.

I should be able to use apitrace to see exactly what is being loaded for textures.

Be sure to do a pull, Chris/Kcat managed to get some textures/objects rendering, but not 100% correctly... the ground and skybox are still funky black/white.

I wish you luck!

Can we get rid of GLEW? Can't we just use GLext to test for OpenGL 2.1?

GLEW helps on Windows, where even standard versions need to be loaded through extensions (because MS hasn't updated opengl32.dll in years, so basically all functions need to be retrieved from the ICD). It automatically handles loading extensions for us, which will be useful with future work on the renderer.

Chris wrote: ↑13 Apr 2018, 20:31 GLEW helps on Windows, where even standard versions need to be loaded through extensions (because MS hasn't updated opengl32.dll in years, so basically all functions need to be retrieved from the ICD). It automatically handles loading extensions for us, which will be useful with future work on the renderer.

But really only necessary for Windows?

Chris wrote: ↑13 Apr 2018, 20:31 GLEW helps on Windows, where even standard versions need to be loaded through extensions (because MS hasn't updated opengl32.dll in years, so basically all functions need to be retrieved from the ICD). It automatically handles loading extensions for us, which will be useful with future work on the renderer.

I understand where your coming from with your case. Im typically working on embedded devices that support GLES only which as far as i know isnt supported by GLEW. My approach was to use either SDL_GL_GetProcAddress or eglGetProcAddress to get funtion pointers and just use my own string compare for the extensions. It was just easier not worry about getting another library cross compiled then just do it.

psi29a wrote: ↑13 Apr 2018, 23:24 But really only necessary for Windows?

It's only necessary insofar as it avoids needing to do a lot of boiler-plate work. Defining all the function pointers, checking for all the extensions, loading the functions for the supported version and extensions, etc. OpenGL has a lot of functions and extensions, most of which we don't use but some of which we may in the future. There's nothing stopping us from doing it all ourselves, but it would be extremely tedious. Having it all automatically set up, and only requiring to check at run-time for the appropriate version or extensions before using functions, makes development that much smoother.

On non-Windows systems, we could avoid this only for the bare minimum of required functionality, that being GL1.1 for the software renderers (or 2.1 if we require the hardware renderer, though it may be a good idea to up the hardware renderer to a GL3.3 core profile as soon as we can, since the fixed-function pipeline will be a limiting factor in the future). Anything more than that needs to be loaded at run-time in case the user's system doesn't have it. Windows is only odd in that it needs it even for the minimum required functionality.

I've moved away from GLEW around the time core profile became a thing and GLEW didn't support it.

Nowadays there are scripts to generate GL loaders, so that you don't have to do it manually.

https://github.com/Dav1dde/glad

https://bitbucket.org/alfonse/glloadgen/overview

I do think it's an interesting experiment that LuciusXL enabled procedural height generation in Daggerfall, but frankly the more I walk around in the game space, the less I like it, due to the fact that the clutter sprites are quite flat, and it very much doesn't look right. Perhaps it could be configurable in the future.

EDIT: I got DarkXL to display the opening animations, it seems. my lfd/ directory, the engine is looking for as LFD/ and a few files therein it is looking for in different case. It displays the opening crawl, but only as a vertical scroll, without the usual Star Wars moving into the distance effect. Still no sound, and these animations are not smooth, very slow. The transitions between animations are also not correct. So far, it doesn't seem to advance beyond the opening crawl... Which I think is when it should transition to an animation from the CD, which I don't have inserted. (I should buy it on steam or GOG, so I don't have to dig through boxes to find the CD) This is using the OpenGL renderer. That happens when I hit the Launch button on the main menu, the settings menu still comes up with a black screen.

EDIT2: After the opening animations for DarkXL, the engine can and does get to the Agent Menu, but none of the buttons there seem to do anything, other than the DOS button, which exits the program cleanly. (Apparently the escape key DOES work to skip the opening animations, and abrating the game window with another window [i.e scrubbing another window over it] increases the animation's frame rates so long as you are doing so. How... Odd.)