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
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.
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.
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!
> 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.
Readit News
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.
Time Travel Debugging provided by WinDbgX doesn't count? Or are they talking about all of the commands executed, etc. along with that?
I kinda miss Lauterbach...
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)
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.
Wouldn't really call it launched, just in development publicly.
[1]: https://web.archive.org/web/20160806065601/http://www.radgam...
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.