RAD Debugger | Hacker News Reader

RAD Debugger

github.com

148 pointsdavikr52 comments

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.

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

We can't even load a debugging session from yesterday and review it! We have a long way to go.

Time Travel Debugging provided by WinDbgX doesn't count? Or are they talking about all of the commands executed, etc. along with that?

The page is quite dated and probably predates it.

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.

[1] https://jakob.engbloms.se/archives/1564

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.

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:

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...

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.

1. <https://corecursive.com/brain-injury-with-jason-mcdonald/>

The fact that the best example I could find being a StackOverflow question about whether such a feature even exists kinda proves your point: https://stackoverflow.com/questions/2780793/xcode-debugging-...

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?

> we can't see bitmaps! We can't hear sound buffers. We can't view vertex arrays.

I kinda miss Lauterbach...

Have they made any progress on that? If so, it's not obvious from the screenshots and linked repo.

Future Linux support is already confirmed so don't worry!

Amazing!

Does anyone have a screenshot or video of it in use?

Being limited to windows makes it difficult to try out, and understand what it brings over existing debugger options.

Here are two screenshots:

https://twitter.com/mrexodia/status/1745769835215139131

https://twitter.com/MyNameIsMJP/status/1745663984408351028

https://pbs.twimg.com/media/GDo3tH8WgAAaIrw?format=png&name=...

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)

Thank you very much!

In case anyone else saw the name and was wondering: yes, it is "RAD" as in RAD Game Tools, which was acquired by Epic a few years ago.

Their website is beautiful

http://www.radgametools.com/

Not necessarily asking you specifically, but posting here because I noticed it on their website that you linked:

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

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.

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.

I wish they were, new games being 120GB+ is insane.

For video to be a major contributor to a game size is a very rare occurrence. Games are 120GB+ in size because texture sizes continue to grow.

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.

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.

- Growth of Unreal and Unity will stall.

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.

i dont understand how you launch a graphical debugger and not add a screenshot to the readme.md

"The RAD Debugger is currently in ALPHA"

Wouldn't really call it launched, just in development publicly.

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!

[1]: https://web.archive.org/web/20160806065601/http://www.radgam...

> 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.

Looks great, been following Ryan's work for awhile so excited to see his take on a fully realized production app.

Anyone seeing any groundbreaking features or reasons to try this over x64dbg or other existing debuggers?

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.

Super excited for this. Clearly has a ways to go. And tbh I kinda wish it used Dear ImGui rather than a weird, janky, custom tool.

The fact that it’s MIT open source is incredible.

Can you cite done specific instances of jank?

Weird docking. Panels don’t disappear when empty. No visible controls. Have to use shortcuts or toolbar to split/remove panels.

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.

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!

Completely detached from the debugging experience but that actually looks like a cute little custom GUI framework ...and it's all in C!

Which language(s) does it aim to support?

> 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.

Would look like C/C++

Reply on news.ycombinator.com