I've been looking forward to this for a long time [1]. I had no idea they would release the source under a permissive license. Can't wait to try it out!
Haven't fully digged into it, but firstly, the executable is tiny, source code seems sane, performance for average sized projects appears to be better than existing solutions, and also some interesting features such as viewing texture/image buffers within the debugger
x64dbg is primarily made for reverse engineering but RAD Debugger is made more for the context of game development. Those are two different usescase with different priorities. I would expect source code debugging and debug symbol related features much more prioritized in RAD debugger compared x64dbg. Even x64dbg own feature list calls it's PDB support as basic. RAD Debugger supports natvis (same format as used by VS for describing how to visualize more complex data structures), I don't think x64dbg supports that.
A more relevant question might be what RAD debugger offers or plans to offer compared to Visual Studio C++ debugger. Based on http://web.archive.org/web/20230923095510/http://www.radgame... seems like an important part of motivation was providing Visual Studio quality or better debugging experience for Linux and console targets and doing that with single tool.
Nice! Another FLOSS GUI debugger is always welcome. A historical capture of this page provides some more context: http://web.archive.org/web/20230923095510/http://www.radgame... It's rather open, which I appreciate (I suppose it's partly why so many companies licence Bink).
Interestingly, it seems to have been primarily a Linux project at some point, but this released version only has Windows support. I'd also like to know what this release means for the project's future.
Thanks! Looks like this project has some high ambitions:
> What's after that?
>
> Tons of stuff. Tons and tons and tons of stuff.
> Debuggers have not substantially evolved since the first Turbo Debugger in 1988!
> For example, we have had GUI debuggers for 20 years now, and we can't see bitmaps! We can't hear sound buffers. We can't view vertex arrays.
> We can't graph values over time. We can't even load a debugging session from yesterday and review it! We have a long way to go.
> Debugging is desperate need of updating, and we see as a long term project. We'll be adding visualizers, new debugging workflows (step through code on multiple platforms at the same time for example), and new features for a long time.
When I used Xcode for the first (and so far only) time I was surprised I could actually view bitmaps in the debugger and I've wondered why that's not commonplace ever since.
Most people don't know what they're missing. None of the pages linked (in either the submission itself or the comments here) or other comments actually show any of these graphical features in use.
This is a problem that extends beyond this submission and talk of debuggers. It's basically insurmountable for anyone who didn't use Google Reader to know what the experience is using it looked and felt like (and in a few months when it will no longer be possible to use Google Podcasts, there'll be another casualty).
Reading your comment, all I know is that Xcode lets you "view bitmaps in the debugger", but that's a pretty varied range of possibilities for someone who hasn't actually seen it.
Folks who are looking to have an impact would do well to document their setups and show how they actually get work done, lest we end up in a future where people don't know how to run a Python program[1] because nobody was ever explicit about it, instead relying on tacit familiarity.
I suppose one reason is that images can be stored in many different ways in memory. For OpenCV images in C++ the Visual Studio extension Image Watch is quite nice, I think it's been around for more than 15 years:
Fun fact, you can plot variable values over time with gdb. You just have to create a gdb extension to do it: https://github.com/jyurkanin/gdb_extensions
This blew my mind when I figured out how to make these extensions and everyone should be making their own extensions. It's a force multiplier. Literally life changing
The archived page claims they started in 2013. Time travel debugging was commercially available (by other vendors [1]) for over a decade by that point.
> It currently only supports local-machine Windows x64 debugging with PDBs, with plans to expand and port in the future. In the future we'll expand to also support native Linux debugging and DWARF debug info.
All languages that have compilers able to produce PDB debug symbols, and in the future all those that can produce DWARF symbols.
That's not restricted just to C/C++ as the sibling comment suggests.
Even if other codecs can beat it on size and quality, if the ergonomics of the playback library are substantially better for game developers (as they claim) then that would make it a compelling choice.
If it ain't broke don't fix it. Games aren't under the bandwidth pressure streaming services are so there's not as much reason to switch to something like AV1.
Yeah. But maybe game devs should finally realize their game is not the only application on my computer and make HD textures an optional download.
Games look fine without them and with every modern game using TAA anyway, things will be blurry even with them.
Bink can handle 4K HDR decoding even without hardware accelerator chips by using regular GPU shaders. That means you don't need to fiddle with any system library and it just works. It's also great for streaming overlays, animated textures, explosion effects because it can render in HDR inside your core engine loop. So if you use deferred shading, you can even stream material properties, e.g. an object becoming more metallic during a texture animation video.
Ah right - I remember looking at their site maybe 15 years ago and they definitely seemed independent.
I didn't realise they'd been bought out but probably makes sense - I assume Epic uses their tools heavily.
I find myself writing a great deal of C++ these days, building jank (the native Clojure dialect on LLVM with C++ interop). Even with modern practices, and Rust-like semantics (i.e. `result<R, E>`, `option<T>`, etc), every large feature implemented is followed by some period of debugging. None of the GUI debuggers I've tried, on Linux, have been compelling. Most either require IDE setup for my project or still look like they're from the 90s. I just end up using gdb, with some improved configs, in my terminal.
So far, the most exciting project to follow for this has been Cutter. However, I'd be easily sold on this once it gets Linux support. Thanks for making it open source. :)
I want to make a few predictions for the next 10 years:
- Godot will win over indie devs and start to become feature-comparable with Unreal and Unity. By the end of the decade, fewer corporate projects will choose Unreal or Unity and instead opt for internal forks of Godot. This is repeating the same formula the Blender-ization of 3D software packages did.
- Non-C++ engines such as Bevy will start to grow a large base of their own and step into the realm that Godot once occupied. Lots of use by hobbyists, especially those wanting to dive into lower level pieces and wanting to avoid C++isms.
- Epic Games Store won't reach a significant fraction of Steam's user base.
I see a lot of potential for Unreal Engine simply because of their ecosystem. Game assets will soon dominate the costs of any game. That means a full asset store and a few AI tools will be the deciding factor between "too expensive" and "highly profitable" games.
> Game assets will soon dominate the costs of any game.
I'm not even so sure! I don't know which costs will trend towards zero.
If I had to make another prediction, though, it's that all the centuries of engineering that went into Unreal Engine will wind up being revealed as just solving for a local optima. Signs point to neural rendering and neural engines possibly being a thing, and if so, everything we've built so far is just legacy tech.
I would expect that neural rendering could be integrated into UE5 while still keeping the amazing tools ecosystem. And, accordingly, I would expect them to remain market leader anyway. Also, looking back, Epic has been incredibly fast at integrating other bleeding edge research results into their engine, like Nanite geometry-as-texture and Lumen global illumination. And when it comes to training neural rendering pipelines, their Quixel dataset will surely be extremely helpful.
> Porting the src/os layers to Linux. This includes core operating system abstraction (virtual memory allocation, threading and synchronization primitives, and so on), and graphical operating system abstraction (windows, input events, and so on).
Looks like a massive undertaking. They should stick with Wayland only to limit the effort scope.
Wayland, and the entire Linux Window manager situation seems like a massive mess from the pov of an outsider, a widely used, stable and open-source app that can bypass this unnecessary complexity could be a great example for other apps to follow
Not sure what you mean about bypassing complexity, but reinventing the wheel might be a waste of time unless you really need it.
For example Wine supporting Wayland had to do a lot of relatively direct work with the protocols and it made sense there, but otherwise you can just use SDL or something similar or even a higher level toolkit like Qt.
There are certainly issues (it’s in alpha after all—this was meant to be more of a soft launch, but it then kind of blew up), but I don’t think anything you listed would qualify as “jank”, and rather your unfamiliarity with the system or non-standard/idiosyncratic designs? That doesn’t apply to the “underline to hint @ shortcut” point, which has been a standard Windows UI principle since, well, before I was born…
But for instance, there are visible controls—they are available via a central command layer which fuzzy matches virtually every operation available in the debugger. This lister also in-place allows rebinding of any command. The panels don’t disappear when empty to avoid janky consequences that arise in traditional docking systems, like DearImGui’s & others. Panels and tabs are completely orthogonal. I plan to introduce a more familiar docking system which offers, in effect, fast paths for the more granular panel/tab operations.
But the overarching reason why I chose a from scratch UI layer is because DearImGui leads to more janky results and is much less-suited for the ambitions of the frontend. I don’t think the frontend would be nearly as solid had I chosen a different route.
> this was meant to be more of a soft launch, but it then kind of blew up
Congrats and/or sorry. Lots of people definitely following this project closely and with great excitement!
> I don’t think anything you listed would qualify as “jank”, and rather your unfamiliarity with the system or non-standard/idiosyncratic designs
The line between unfamiliar and jank is awfully fuzzy! I'm always willing to try new things. Always a learning curve. But definitely felt a little lost and confused at a few things. Knowing about F1 helps a lot. There's no Detach option in the toolbar!
I also had issues with std::string not showing any value in the debugger. VS2022 and RemedyBG show the string just fine.
> That doesn’t apply to the “underline to hint @ shortcut” point, which has been a standard Windows UI principle since, well, before I was born…
Maybe it's a 4K rendering issue? The underlines are kindar fubar. Too high in the "descender area". And doesn't render wide enough. I mean look at those sad little pixels on Step Into! https://i.imgur.com/gasiauv.png Or how the underline on "Registers" makes the R look like a B. https://i.imgur.com/UnnIeAT.png
There's a lot of weird font spacing issues that kinda just make a lot of things hard to read.
Not, uh, that this matters at all in the grand scheme of things!
Amusingly I went to look for examples of how the underlines are rendering in other tools and... I couldn't find one? TIL this may not be a thing anymore? Whoa. (Windows 11)
> But the overarching reason why I chose a from scratch UI layer is because DearImGui leads to more janky results and is much less-suited for the ambitions of the frontend. I don’t think the frontend would be nearly as solid had I chosen a different route.
Dear ImGui definitely has it's "look". But RemedyBG is pretty slick and I'm not sure this is ultimately going to provide any significant capabilities other than a better visual style? Could be wrong! Look forward to seeing your ambitions realized!
52 comments
[ 3.8 ms ] story [ 119 ms ] thread[1]: https://web.archive.org/web/20160806065601/http://www.radgam...
Being limited to windows makes it difficult to try out, and understand what it brings over existing debugger options.
https://twitter.com/mrexodia/status/1745769835215139131
https://twitter.com/MyNameIsMJP/status/1745663984408351028
https://pbs.twimg.com/media/GDnYJFOaQAAuNTq?format=jpg&name=...
(those are the urls from the Xeets; I didn't alter the query params, they came that way)
A more relevant question might be what RAD debugger offers or plans to offer compared to Visual Studio C++ debugger. Based on http://web.archive.org/web/20230923095510/http://www.radgame... seems like an important part of motivation was providing Visual Studio quality or better debugging experience for Linux and console targets and doing that with single tool.
Interestingly, it seems to have been primarily a Linux project at some point, but this released version only has Windows support. I'd also like to know what this release means for the project's future.
> What's after that?
>
> Tons of stuff. Tons and tons and tons of stuff.
> Debuggers have not substantially evolved since the first Turbo Debugger in 1988!
> For example, we have had GUI debuggers for 20 years now, and we can't see bitmaps! We can't hear sound buffers. We can't view vertex arrays.
> We can't graph values over time. We can't even load a debugging session from yesterday and review it! We have a long way to go.
> Debugging is desperate need of updating, and we see as a long term project. We'll be adding visualizers, new debugging workflows (step through code on multiple platforms at the same time for example), and new features for a long time.
This is a problem that extends beyond this submission and talk of debuggers. It's basically insurmountable for anyone who didn't use Google Reader to know what the experience is using it looked and felt like (and in a few months when it will no longer be possible to use Google Podcasts, there'll be another casualty).
Reading your comment, all I know is that Xcode lets you "view bitmaps in the debugger", but that's a pretty varied range of possibilities for someone who hasn't actually seen it.
Folks who are looking to have an impact would do well to document their setups and show how they actually get work done, lest we end up in a future where people don't know how to run a Python program[1] because nobody was ever explicit about it, instead relying on tacit familiarity.
1. <https://corecursive.com/brain-injury-with-jason-mcdonald/>
The answer even has a comment saying:
> Ages coding in Xcode and I never knew about this feature! This is awesome!!! Thanks a lot
We really have a problem in this industry about documenting institutional knowledge huh?
https://marketplace.visualstudio.com/items?itemName=VisualCP...
There's also a recent extension called Image Preview for path references:
https://devblogs.microsoft.com/visualstudio/working-with-ima...
Time Travel Debugging provided by WinDbgX doesn't count? Or are they talking about all of the commands executed, etc. along with that?
[1] https://jakob.engbloms.se/archives/1564
I kinda miss Lauterbach...
All languages that have compilers able to produce PDB debug symbols, and in the future all those that can produce DWARF symbols.
That's not restricted just to C/C++ as the sibling comment suggests.
http://www.radgametools.com/
How is Bink video still a thing? Aren't the other well established codecs able to beat it?
Edit: Some answers here, if you believe their own stats: http://www.radgametools.com/bnkmain.htm
So far, the most exciting project to follow for this has been Cutter. However, I'd be easily sold on this once it gets Linux support. Thanks for making it open source. :)
- Godot will win over indie devs and start to become feature-comparable with Unreal and Unity. By the end of the decade, fewer corporate projects will choose Unreal or Unity and instead opt for internal forks of Godot. This is repeating the same formula the Blender-ization of 3D software packages did.
- Non-C++ engines such as Bevy will start to grow a large base of their own and step into the realm that Godot once occupied. Lots of use by hobbyists, especially those wanting to dive into lower level pieces and wanting to avoid C++isms.
- Epic Games Store won't reach a significant fraction of Steam's user base.
- Growth of Unreal and Unity will stall.
I'm not even so sure! I don't know which costs will trend towards zero.
If I had to make another prediction, though, it's that all the centuries of engineering that went into Unreal Engine will wind up being revealed as just solving for a local optima. Signs point to neural rendering and neural engines possibly being a thing, and if so, everything we've built so far is just legacy tech.
Wouldn't really call it launched, just in development publicly.
Looks like a massive undertaking. They should stick with Wayland only to limit the effort scope.
For example Wine supporting Wayland had to do a lot of relatively direct work with the protocols and it made sense there, but otherwise you can just use SDL or something similar or even a higher level toolkit like Qt.
The fact that it’s MIT open source is incredible.
Font rendering feels off.
Toolbar lists are super compressed. Needs more vertices spacing. Underlined characters for shortcut hints is absolutely awful.
Various commands create kinda-sorta pop-ups that are really weird and atypical.
I’ve only played with it for a little bit. This is all surface level stuff. Not a big deal. But RemedyBG has a better UX.
But for instance, there are visible controls—they are available via a central command layer which fuzzy matches virtually every operation available in the debugger. This lister also in-place allows rebinding of any command. The panels don’t disappear when empty to avoid janky consequences that arise in traditional docking systems, like DearImGui’s & others. Panels and tabs are completely orthogonal. I plan to introduce a more familiar docking system which offers, in effect, fast paths for the more granular panel/tab operations.
But the overarching reason why I chose a from scratch UI layer is because DearImGui leads to more janky results and is much less-suited for the ambitions of the frontend. I don’t think the frontend would be nearly as solid had I chosen a different route.
Congrats and/or sorry. Lots of people definitely following this project closely and with great excitement!
> I don’t think anything you listed would qualify as “jank”, and rather your unfamiliarity with the system or non-standard/idiosyncratic designs
The line between unfamiliar and jank is awfully fuzzy! I'm always willing to try new things. Always a learning curve. But definitely felt a little lost and confused at a few things. Knowing about F1 helps a lot. There's no Detach option in the toolbar!
I also had issues with std::string not showing any value in the debugger. VS2022 and RemedyBG show the string just fine.
> That doesn’t apply to the “underline to hint @ shortcut” point, which has been a standard Windows UI principle since, well, before I was born…
Maybe it's a 4K rendering issue? The underlines are kindar fubar. Too high in the "descender area". And doesn't render wide enough. I mean look at those sad little pixels on Step Into! https://i.imgur.com/gasiauv.png Or how the underline on "Registers" makes the R look like a B. https://i.imgur.com/UnnIeAT.png
There's a lot of weird font spacing issues that kinda just make a lot of things hard to read.
Not, uh, that this matters at all in the grand scheme of things!
Amusingly I went to look for examples of how the underlines are rendering in other tools and... I couldn't find one? TIL this may not be a thing anymore? Whoa. (Windows 11)
> But the overarching reason why I chose a from scratch UI layer is because DearImGui leads to more janky results and is much less-suited for the ambitions of the frontend. I don’t think the frontend would be nearly as solid had I chosen a different route.
Dear ImGui definitely has it's "look". But RemedyBG is pretty slick and I'm not sure this is ultimately going to provide any significant capabilities other than a better visual style? Could be wrong! Look forward to seeing your ambitions realized!