Putting the dylib issues aside for the moment, the top ss is when I'm using opengl es with angle and the bottom is when I'm using opengl.
Does anyone know what might be causing the difference?
Does anyone know what might be causing the difference?
I see
window: Vector(1280, 720) framebuffer: Vector(2560, 1440)for both cases
i don't remember how you fixed the original scaling issue :)
@ryzhikovas fix pushed as mosra/magnum@3c5e42b, will appear in master once the CIs get sufficiently green :)
hmm of course i messed up, another try
@hsdk123 just to rule out the silly issues: you don't have any code depending on the
MAGNUM_TARGET_GLES define, right?
(most probably not, but) it could also be that SDL does things right for desktop GL but messes it up for GLES, you could check that by running e.g the simple triangle example on ANGLE
i never tried ANGLE on Mac, so I have no idea about any bad interactions
Hi, I've just tried pulling from the latest openal soft master branch, and I'm getting the following build errors:
C:\Users\daego\Desktop\Projects\Light.vn-multi\core\out\build\x64-Debug\MyCore.lib(AudioMgr.cpp.obj) : error LNK2019: unresolved external symbol __imp_alGenBuffers referenced in function "public: __cdecl Magnum::Audio::Buffer::Buffer(void)" (??0Buffer@Audio@Magnum@@QEAA@XZ)
C:\Users\daego\Desktop\Projects\Light.vn-multi\core\out\build\x64-Debug\MyCore.lib(AudioMgr.cpp.obj) : error LNK2019: unresolved external symbol __imp_alDeleteBuffers referenced in function "public: __cdecl Magnum::Audio::Buffer::~Buffer(void)" (??1Buffer@Audio@Magnum@@QEAA@XZ)
C:\Users\daego\Desktop\Projects\Light.vn-multi\core\out\build\x64-Debug\MyCore.lib(AudioData.cpp.obj) : error LNK2019: unresolved external symbol __imp_alBufferData referenced in function "public: class Magnum::Audio::Buffer & __cdecl Magnum::Audio::Buffer::setData(enum Magnum::Audio::BufferFormat,class Corrade::Containers::ArrayView<void const >,int)" (?setData@Buffer@Audio@Magnum@@QEAAAEAV123@W4BufferFormat@23@V?$ArrayView@$$CBX@Containers@Corrade@@H@Z)
C:\Users\daego\Desktop\Projects\Light.vn-multi\core\out\build\x64-Debug\MyCore.lib(Sound.cpp.obj) : error LNK2019: unresolved external symbol __imp_alGenSources referenced in function "public: __cdecl Magnum::Audio::Source::Source(void)" (??0Source@Audio@Magnum@@QEAA@XZ)
C:\Users\daego\Desktop\Projects\Light.vn-multi\core\out\build\x64-Debug\MyCore.lib(Sound.cpp.obj) : error LNK2019: unresolved external symbol __imp_alDeleteSources referenced in function "public: __cdecl Magnum::Audio::Source::~Source(void)" (??1Source@Audio@Magnum@@QEAA@XZ)
C:\Users\daego\Desktop\Projects\Light.vn-multi\core\out\build\x64-Debug\MyCore.lib(Sound.cpp.obj) : error LNK2019: unresolved external symbol __imp_alSourcef referenced in function "public: class Magnum::Audio::Source & __cdecl Magnum::Audio::Source::setGain(float)" (?setGain@Source@Audio@Magnum@@QEAAAEAV123@M@Z)
C:\Users\daego\Desktop\Projects\Light.vn-multi\core\out\build\x64-Debug\MyCore.lib(Sound.cpp.obj) : error LNK2019: unresolved external symbol __imp_alSourcei referenced in function "public: class Magnum::Audio::Source & __cdecl Magnum::Audio::Source::setLooping(bool)" (?setLooping@Source@Audio@Magnum@@QEAAAEAV123@_N@Z)
C:\Users\daego\Desktop\Projects\Light.vn-multi\core\out\build\x64-Debug\MagnumAudio-d.lib(Source.cpp.obj) : error LNK2001: unresolved external symbol __imp_alSourcei
Found the reason - this seems to happen if I try to use the static version of openal soft
Also some feedback on video
https://icculus.org/theoraplay/
If ffmpeg might take a while, this seems to be a relatively simple api into getting video capabilities.
Thanks, yeah, that did it, had to set the attributes in the Gl::Mesh::mesh.addVertexBuffer, that fixed the problem, thanks.
Did a bit of debug tracing, and figured out that this calls
glBindVertexArray bind the array, then
glEnableVertexAttribArray(attribute.location);
glVertexAttribIPointer(attribute.location, attribute.size, attribute.type, attribute.stride, attribute.offset);I'm not really sure why GL needs the glEnableVertexAttribArray, when the shader declares the data layout right there, and then glMapBufferRange should just give you a pointer to a data block, with the structure layout defined by the shader.
GL is confusing, I think DirectX is a lot easier to understand.
i don't think the shader declares the structure layout fully .. it only says that it expects floats here, ints there, but you can still pass half-floats to the floats or unsigned bytes to the ints, unpacking those is the responsibility of the vertex pulling hardware, not the shader
tho glEnable*Array() is probably mostly historical, yep :)
$ magnum-imageconverter --info tenor.gif --importer StbImageImporter
Image 0:
Level 0: PixelFormat::RGBA8Unorm Vector(135, 90)
Image 1:
Level 0: PixelFormat::RGBA8Unorm Vector(135, 90)
Image 2:
Level 0: PixelFormat::RGBA8Unorm Vector(135, 90)
Image 3:
Level 0: PixelFormat::RGBA8Unorm Vector(135, 90)
Image 4:
Level 0: PixelFormat::RGBA8Unorm Vector(135, 90)
Image 5:
Level 0: PixelFormat::RGBA8Unorm Vector(135, 90)
...
now i just need to hook up a timeline
https://www.glfw.org/docs/latest/input.html#path_drop this thing i guess
oh sorry nevermind, by calling window()...
ah it points to the GlfwApplication, so I guess I can cast it to my child class
for future reference, this works, thanks
class CustomApp : public Platform::Application {
public:
CustomApp(){
glfwSetDropCallback(window(), glfwDropCallback);
}
void fileDropEvent(const std::string& filepath);
static void glfwDropCallback(GLFWwindow* window, int count, const char** paths){
reinterpret_cast<CustomApp*>(glfwGetWindowUserPointer(window))->fileDropEvent(paths[0]);
}
}
hmm, seeing
const char there, did the glfw documentation mention anything about unicode on windows?
i hope the API supplies UTF-8 or something
actually... why not make a terminal gif player while i'm at it