I'm trying to debug some OpenGL 3.3+ graphics code using RenderDoc and I would like to define some debug markers for render passes that can be recognised by RenderDoc.
I use GLEW and I tried to use glPushGroupMarkerEXT/glPopGroupMarkerEXT to define these markers but I get an access violation when I call glPushGroupMarkerEXT, so I guess that the extension that provides that functionality is not loaded.
I also tried to check if the extension GL_EXT_debug_marker is available using glewIsSupported but that returns false.
Is this functionality not supported or am I not using it properly? Or is there any other way of achieving this?
EXT_debug_marker is not the extension you want to use. It is old and was never really widely supported. Its functionality was absorbed into KHR_debug, which is more widely supported and itself has been core OpenGL since 4.3 (aka: 5+ years ago).
Now, debug marker functionality is different between the two. KHR_debug makes markers into just another kind of user-defined debug notification. So, where you would have called glInsertEventMarkerEXT, you instead call the more generic glDebugMessageInsert, using the GL_DEBUG_TYPE_MARKER as the message's type. Where you would use glPush/PopGroupMarkerEXT, you instead use glPush/PopDebugGroup, which is used for arbitrary scoping. Such groupings don't use the marker type; they use the GL_DEBUG_TYPE_PUSH/POP_GROUP types, so that you can tell the difference between grouping and markers.
Related
I am using QtCreator 4.12 as a generic C++ IDE, installed from my distribution's package manager, so this is a generic question about QtCreator usage, not related to Qt in particular, nor building QtCreator from source.
Like any IDE, QtCreator highlights potential errors while writing code.
in a .cpp file, if I write int x = 0 and press enter, the 0 will be underlined in red, and there will be a tooltip telling me that I forgot the ; at the end of the line.
This is described in the QtCreator documentation, but I couldn't find anything in that documentation about GLSL.
My actual project is a C++ with openGl game, and I'm editing my GLSL shaders within QtCreator.
Reading the answer to this question, I've learned that all the texture*D() functions were deprecated since openGL 3.3, and have to be replaced with texture() which infers the texture dimension, so I decided to update my shaders.
Within QtCreator, when I use the texture() function, the whole line gets underlined with red color, with a tooltip saying expression too complex, whereas when I use texture2D() (or texture1D() or else), the line isn't underlined as shown in following pictures :
deprecated GLSL:
non-deprecated GLSL:
This doesn't prevent my shaders to work as designed at all, so there's no real problem here, but it's really disturbing.
I don't know anything about the syntax error checking mechanism more than what is written in the linked documentation page, and I'm looking for a way to change this mechanism to accept GLSL 3.3+. I would accept an answer telling me how to silence this specific false positive as a workaround, or a way to deactivate the syntax error checking for .glsl files, but I would really prefer to understand how I could tweak the error checking mechanism to accept modern glsl as it does for legacy glsl.
In the end I wrote a bug report : QTCREATORBUG-24068.
There's a patch addressing the issue, which I could test. It will be merged in QT Creator's source v4.14.
Title says pretty much everything. Once upon a time when I was under 13, my older bro did in BorlandPascal a thing which amazed me. He defined kind of table [8][8] with values of 1 and 0, meaning respectively foreground and background. Having several of such tables he could somehow redefine default ASCII characters to look like in these tables. I have no idea how it was done, but it worked.
My question is: can I do similar thing in ncurses, and if I can then how to do it?
The short answer is no. What ncurses does is generating ANSI escape codes which are interpreted by the terminal. There are no codes for altering the font. (Althou there have been extensions propesed no commonly used terminal supports them, neither does ncurses.) And there is no generic way of communicating with the terminal through some kind of side channel for changing the font. But there might ways in some specific situations.
If you have direct access to a Linux console for example you could could do all sorts of things, much like in Borland Pascal. But it will likely be more messy and less impressive.
As the selected answer explains, this is not possible for NCurses to render custom glyphs. ncurses only manipulates the terminal screen state via escape codes (Clearing and rewriting lines to achieve interactivity).
However it should be noted that's very possible to use custom glyphs in the terminal via custom fonts.
This is what Powerline does (a popular terminal UI status line for vim, tmux and friends): https://github.com/powerline/fonts
By patching the fonts, you can inject your glyphs into the existing font being used by the terminal, which then you can access and render via ncurses as any other character.
Of course this is not ideal solution, but with some auto patching of the fonts, and careful testing, it makes it possible to build an app that uses custom glyphs—when your really in a pinch for more expressive UI tools than ncurses can offer.
Further reading: https://apw-bash-settings.readthedocs.io/en/latest/fontpatching.html
So there has been a lot of times where I needed to know what the enums returned by certain opengl operations are, to print them on the terminal to see what's going on.
It doesn't seem there's any kind of function available for stringifying the enums at the moment, so I'm thinking of going straight to gl.h (actually I'm gonna use libglew's header for now), grabbing the #defines and creating a huge switch table for convenience purposes.
Is there any better way, and how would you deal with having to port things to OpenGL ES?
gluErrorString is the function you're looking for in OpenGL, as GLU library is normally always available alongside with GL.
I don't have experience in OpenGL ES, but Google turned up GLUes that may help you.
OpenGL has some official .spec files that define the API, there is one enum.spec that lists all the enum names and their values. You just need to write a simple program to parse the file and produce a lookup mapping.
The file can be found at http://www.opengl.org/registry/ (specifically http://www.opengl.org/registry/api/enum.spec)
Manually processing gl.h would work but the spec files are updated for new versions and if you have a program to generate the code for you then you don't have to do anything to get the new enums in. Also gl.h file is implementation specific. So it might change between nVidia, ATI, and on different platforms.
The OpenGL Registry contains comprehensive information on the OpenGL API. Notably the gl.xml file in the XML API registry lists all enums, including their names and values. Creating a lookup table from that data should be simple enough.
I like to print a document. The content of the document are tables and text with different colors. Does a lightwight printer-file-format exist, which can be used like a template?
PS, PDF, DOC files in my opinion are to heavy to parse. May there exist some XML or YAML file format which supports:
Easy creation (maybe with a WYSIWYG-Editor)
Parsing and manipulation with Library-Support
Easy sending to the printer (maybe with Library-Support)
Or do I have to do it the usual way and paint within a CDC?
I noticed you’re using MFC (so, Windows). In that case the answer is a qualified yes. In recent versions of Windows, Microsoft offers the XPS Document API which lets you create and manipulate a PDF-like document using XML, which can then be printed using the XPS Print API.
(For earlier versions of Windows that don’t support this API, you could try to deal with the XPS file format directly, but that is probably a lot harder than using CDC. Even with the API you will be working at a fairly low level.)
End users can generate XPS documents using the XPS print driver that is available for free from Microsoft (and bundled with certain MS products—they probably already have it on their system).
There is no universal language that is supported across all (or even many) printers. While PCL and PS are the most used, there are also printers which only work with specific printer drivers because they only support a proprietary data format (often pre-rendered on the client).
However, you could use XSL-FO to create documents which can then be rendered to a printer driver using library support.
I think something like TeX or LaTeX (or even troff or groff) may meet your needs. Google them and see.
There are also libraries to render documents for print from HTML source. Look at http://libharu.sourceforge.net/ for example. This outputs a printer-ready .PDF
A think that Post Script is a really good choice for that.
It is actually a very simple language, and it must be very easy to parse becuse it is stack-oriented. Then -- most printers supprort it, and even if you have no support you can use GhostScript to convert for many different formats (Consider GS as a "virtual PS supporting printer").
Finally there are a lot of books and tutorials for the language.
About the parsing -- you can actually define new variables and functions in PS. So, maybe, your problem can be solved (almost) entirely using PS.
HTML + CSS can be printed -- properly. CSS was designed to support this with the media attribute to specify that your CSS is for printer layout, not for screen layout. Tools like PRINCE (free + commercial versions) exist to render this for printing.
I think postscript is the markup language used by printers. I read this somewhere, so correct me if postscript is now outdated.
http://en.wikipedia.org/wiki/PostScript
For more powerful suite you can use Latex. It will give options of creating templates where you can just copy the text.
On a more GUI friendly note, MS-Word and other word processors have templates. The issue is they are not of a common standard or markup.
You can also use HTML to render stuff in a common markup but it will not be very printer friendly.
I basically want to get the outline for a character. I was wondering how I could do this without drawing to the DC. Could I do something like this: (Psudocodeishly)
BeginPath()
TextOut("H")
EndPath()
GetPath()
Will something like this work for GetPath? Will it return the glyph outline that I can then draw?
Otherwise, how else could I do this (without freetype)
Thanks
If you want to get a glyph outline, why not just use GetGlyphOutline? There's the theoretical limitation that this is limited to TrueType fonts, but given the percentage of other fonts typically used on Windows, that's rarely a concern...
Edit: Yes, if you want to avoid using GetGlyphOutline, using a path instead will work (though only with TrueType fonts, not bitmapped fonts). The sample code included with the documentation for CDC::BeginPath shows how to do exactly what you seem to be after (though I'd strongly recommend using std::vector instead of new[] and delete[] as it does). One minor detail: that sample includes an implementation of PolyDraw. You'd only need (or want) this if you need to support ancient 16-bit versions of Windows -- all NT-based versions of Windows include it.